GNOME Bugzilla – Bug 752103
mpegaudioparse: dummy data skip condition
Last modified: 2018-11-03 15:01:53 UTC
Created attachment 307048 [details] add dummy data skip code some file have a broken audio data(0xffff..) it take a long time to playback. because mpeg audio parser skip only one byte. i think that it needs a condition for long dummy data skip. mpeg audio parser detects sync-word and check frame header, but this dummy doesn't match a right config and skip one bytes. - gst_mpeg_audio_parse_handle_frame - /* make sure the values in the frame header look sane */ header = GST_READ_UINT32_BE (map.data); if (!gst_mpeg_audio_parse_head_check (mp3parse, header)) { *skipsize = 1; goto cleanup; }
Created attachment 307049 [details] [review] add dummy data skip code
Instead of this, it would seem nicer to do a header check on all data that is available instead of returning after every byte. That should also fix your problem, but at the same time also makes this more efficient in other cases.
yes, i agree you opinion ^^ every byte check is good logic. But, our circustom is embedded and not like a pc. too slow. i take a long long time for play.
That's my point, yes. Instead of special casing 0xffff here, you would run the header check on the complete available data instead of skipping one byte at a time.
OK, i will try it thank you~^^
how about this? i thinks it looks reasonable. /* make sure the values in the frame header look sane */ 699 header = GST_READ_UINT32_BE (map.data); 700 if (!gst_mpeg_audio_parse_head_check (mp3parse, header)) { 701 //*skipsize = 1; 702 *skipsize = map.size - 3; 703 goto cleanup; 704 }
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/200.