[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Sasi Inguva]

>From ISO-IEC-14496-12
*10 Sample Groups*
*10.1 Random Access Recovery Points*
*10.1.1.1*
*Definition*
*class AudioRollRecoveryEntry() extends AudioSampleGroupEntry (’roll’)*
*{*
*signed int(16) roll_distance;*
*}*


*An AudioRollRecoveryEntry documents the pre‐roll distance required in
audio streams in whichevery sample can be independently decoded, but the
decoder output is only assured to be correct afterpre‐rolling by the
indicated number of samples.*








*10.1.1.3roll_distance is a signed integer that gives the number of samples
that must be decoded inorder for a sample to be decoded correctly. A
positive value indicates the number of samplesafter the sample that is a
group member that must be decoded such that at the last of theserecovery is
complete, i.e. the last sample is correct. A negative value indicates the
number ofsamples before the sample that is a group member that must be
decoded in order for recoveryto be complete at the marked sample. The value
zero must not be used; the sync sample tabledocuments random access points
for which no recovery roll is needed.*


This patch sets the sgpd and sbgp atoms irrespective of whether it's
fragmented or not. So the byte addresses for some atoms will change for all
MP4 files .

On Fri, Aug 4, 2017 at 12:11 PM, Derek Buitenhuis <
derek.buitenhuis at gmail.com> wrote:

> On 8/4/2017 7:46 PM, Sasi Inguva wrote:
> > According to https://developer.apple.com/library/content/documentation/
> QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> >
> > Signed-off-by: Sasi Inguva <isasi at google.com>
> > ---
> >  libavformat/movenc.c                | 70 +++++++++++++++++++++---------
> -------
> >  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
> >  tests/ref/fate/copy-psp             |  4 +--
> >  tests/ref/fate/movenc               | 12 +++----
> >  4 files changed, 49 insertions(+), 41 deletions(-)
>
> Is there a reference for ISOBMFF too? Because this changes mp4 output as
> well mov.
>
> > diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
> > index 09e603aeb7..47bcf9d515 100644
> > --- a/tests/ref/fate/movenc
> > +++ b/tests/ref/fate/movenc
> > @@ -1,18 +1,18 @@
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2335, time nopts, type header atom -
> > +write_data len 2389, time nopts, type header atom -
> >  write_data len 788, time 1000000, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -214242e9c7c93171d2f47f5b47776559 3269 non-empty-moov
> > +17a37691eba8b858cf15e60aa9a7dbf7 3323 non-empty-moov
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2667, time nopts, type header atom -
> > +write_data len 2721, time nopts, type header atom -
> >  write_data len 908, time 966667, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -44467d568a3cc38d414fd8ed4b2a968f 3721 non-empty-moov-elst
> > +0026ffe059c06c592021f972bf2c5e79 3775 non-empty-moov-elst
> >  write_data len 36, time nopts, type header atom ftyp
> > -write_data len 2575, time nopts, type header atom -
> > +write_data len 2629, time nopts, type header atom -
> >  write_data len 908, time 1000000, type sync atom moof
> >  write_data len 110, time nopts, type trailer atom -
> > -de22b98a3885f9b4b83cdd48ff46aeb9 3629 non-empty-moov-no-elst
> > +c184e168ac1e5bb3d9c70e580ab6179c 3683 non-empty-moov-no-elst
> >  write_data len 20, time nopts, type header atom ftyp
> >  write_data len 1171, time nopts, type header atom -
> >  write_data len 728, time 0, type sync atom moof
> >
>
> Can you confirm what exactly changes in these fragmented MP4 API tests?
>
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>