aacparse: ADTS/LOAS parsing issue when incoming live data starts in the middle of a frame
Submitted by Nicolas Huet
Link to original bug (#738584)
Description
Created attachment 288604
fix ADTS/LOAS parsing issue if format is not detected yet
baseparse receives a first buffer with the end of a frame only with a flag SYNC_LOST (with the patch from https://bugzilla.gnome.org/show_bug.cgi?id=738237). The buffer starts with ff f and therefore a frame length is calculated. aaacparse returns not enough data.
Then baseparse receives a second buffer and the frame is considered as complete.
gst_aac_parse_check_adts_frame returns TRUE as the flag SYNC_LOST is not set. This is not strict enough as there was not a "full SYNC check" with the next frame.
The fix ensures that the aacparse->header_type is already found.
I include 2 files that show the issue and the patch that fix the issue
gst-launch-1.0 -v --gst-debug=aacparse:6 filesrc location= aac.gdp ! gdpdepay ! aacparse ! fakesink silent=false
gst-launch-1.0 -v --gst-debug=aacparse:6 filesrc location= aac2.gdp ! gdpdepay ! aacparse ! fakesink silent=false
This looks like to be a regression introduced by https://bugzilla.gnome.org/show_bug.cgi?id=657080
Patch 288604, "fix ADTS/LOAS parsing issue if format is not detected yet":
0001-aacparse-fix-ADTS-LOAS-parsing-issue-if-format-is-no.patch
Version: 1.4.3