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 659943 - [ac3parse] it does not correcly check for ac3/e-ac3 switch
[ac3parse] it does not correcly check for ac3/e-ac3 switch
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-23 13:39 UTC by Julien Isorce
Modified: 2011-09-24 21:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch for ac3parse (980 bytes, patch)
2011-09-23 13:39 UTC, Julien Isorce 		committed Details | Review

Description Julien Isorce 2011-09-23 13:39:20 UTC 
Created attachment 197355 [details] [review]
patch for ac3parse

Wrong check expression, see attached patch
Comment 1 Tim-Philipp Müller 2011-09-23 15:28:09 UTC 
Thanks, pushed:

 commit 2131a3b7f8dbfb8304475d32af2a636f28efb50b
 Author: Julien Isorce <julien.isorce@gmail.com>
 Date:   Fri Sep 23 15:36:36 2011 +0200

    ac3parse: correctly check for ac3/e-ac3 switch
    
    https://bugzilla.gnome.org/show_bug.cgi?id=659943


Out of curiosity: in what context do you encounter this? Is it a valid thing to happen within one and the same stream?
Comment 2 Julien Isorce 2011-09-23 15:43:08 UTC 
Well, this is a ac3 stream where there is one e-ac3 buffer at some point.
Actually I encountered it when decodein a iec61937 stream (around spdif).

In gst_ac3_parse_parse_frame of gstac3parse.c, there is a "if (G_UNLIKELY (sid)) {" at line 583.

In my context, the sid of this e-ac3 buffer is 7 and sample rate 48000 so the next "return GST_FLOW_OK;" is executed.

Reading the code I found the incorrect ac3parse->eac != ac3parse->eac.

Note that the fix does not resolve the e-ac3 buffer detection because of the "return GST_FLOW_OK;"

I think the check "if (G_LIKELY (ac3parse->sample_rate > 0))" at line 593 is not enough,  it should also check for ac3parse->eac == eac or something
Comment 3 Julien Isorce 2011-09-23 15:46:06 UTC 
And the iec61937 stream comes from a STB (set top box for TV) when capturing on the spdif coaxial or optical output.

The e-ac3 buffer was emitted after a zapping. I do not know if the STB is doing something wrong or not.
Comment 4 Tim-Philipp Müller 2011-09-24 21:32:55 UTC 
Interesting. I would prefer it if it just ignore that one-off (?) e-ac3 buffer and treated it as garbage unless it' s more permanent change, but I guess that would complicate things a bit...