GNOME Bugzilla – Bug 742602
aacparse assumes random bitrates after filler packets
Last modified: 2016-08-11 13:34:57 UTC
Created attachment 294116 [details] gdp stream dump. run with GST_DEBUG=*aa*:6 gst-launch-1.0 filesrc location=aacstream.gdp ! gdpdepay ! aacparse ! fakesink and grep for rate: 0 i've got a pushsrc based element that reads aac stream data from an encoder device and observed data flow errors when trying to mux that into a container. when looking at the debug output of the aacparse element, it seems to switch to random bitrates after handling invalid frames
I do see the caps changing from 48000Hz/2channel to 96000/3channel for a bit, so the behavior on corupt frame seems to have changed a bit. Still, there is no CRC on these frames AFAICT, and it seems valid to change rate/channels. Rate/channels goes back to the original setup after the corruption. Your wording seems to imply that you might not be seeing the rate/channels go back to their original value ?
the provided stream actually was corrupt, usually it would go back to the correct values unless bitrate was detected as 0 and therefore crashed downstream elements that couldn't handle that. browsing aacparse code i saw that the mechanism to regain sync on the stream seem to be extremely ineffective though, it skips through the payload byte per byte, mapping and unmapping the data every time
The non determinic behavior you saw seems odd. I do not see any problems with valgrind which would indicate this. It could be that this got fixed as a side effect of a patch since 1.4.1 though, as I always get the same 48k/96k/48k detection here testing with your supplied file and command line.
Trying again, I do not see a 96k switch, so if there was a bug to do with that, this appears fixed. Can you still see the random bitrate bug ? I'm also running with https://bugzilla.gnome.org/show_bug.cgi?id=769278, but this should only touch LOAS stuff.
works! thank you vincent