After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752103 - mpegaudioparse: dummy data skip condition
mpegaudioparse: dummy data skip condition
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.4
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-08 04:58 UTC by sangkyu.choi
Modified: 2018-11-03 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add dummy data skip code (1.29 KB, application/mbox)
2015-07-08 04:58 UTC, sangkyu.choi
  Details
add dummy data skip code (1.29 KB, patch)
2015-07-08 05:00 UTC, sangkyu.choi
needs-work Details | Review

Description sangkyu.choi 2015-07-08 04:58:37 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;
   }
Comment 1 sangkyu.choi 2015-07-08 05:00:56 UTC
Created attachment 307049 [details] [review]
add dummy data skip code
Comment 2 Sebastian Dröge (slomo) 2015-07-08 08:49:51 UTC
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.
Comment 3 sangkyu.choi 2015-07-08 13:35:58 UTC
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.
Comment 4 Sebastian Dröge (slomo) 2015-07-08 13:54:37 UTC
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.
Comment 5 sangkyu.choi 2015-07-09 07:27:06 UTC
OK, i will try it

thank you~^^
Comment 6 sangkyu.choi 2015-07-24 05:13:47 UTC
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   }
Comment 7 GStreamer system administrator 2018-11-03 15:01:53 UTC
-- 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.