Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

The latest nightly of Handbrake includes an option to add the sample group atom 
as well as the edit list. This is much more successful than the current ffmpeg 
mux when playing in QT X. Its still ignored in older QT decoders, but certainly 
this would be an improvement if ffmpeg could follow the Handbrake atom 
structure for the sound track.

Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 1 Jul 2017, at 20:24, Sasi Inguva  wrote:
>> On Sat, Jul 1, 2017 at 6:56 AM, Mark Burton [via FFmpeg-users] 
>> How about this for a partial solution - ffmpeg supports the audiotoolbox
>> aac encoder on macOS. For the sake of being able to create .mov which are
>> compatible with the Quicktime format, there is a single change which I
>> think could work well, albeit the ‘fix' would be limited to macOS system
>> encoders.
>> 
>> Currently a .mov created by ffmpeg when using the aac_at audiotoolbox
>> encoder creates a sound track edit list with a media time of 2112. This
>> will not work with Quicktime decoders, the file with decode out of sync. If
>> this value was 0 however, then the file will decode properly in sync.
>> 
>> For now, would it be possible to change this value to 0 when using the
>> aac_at encoder in ffmpeg?
>> 
>> Doing the same for the ffmpeg native aac encoder does help quite a bit,
>> about 1/2 frame out of sync as opposed to a full frame.

> 
> There is already a flag called -use_editlist in ffmpeg MOV muxer
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=ca389e3a97f92e05b1abfda29aa7bde25e1089a0;hb=HEAD#l88
>  
> 
> I think you can use that along with the audiotoolbox encoder to achieve what 
> you want.

I have tried this before, but by removing the editlist using this flag, the 
resulting file had major frame rate issues - for example a 24fps file, would 
come out at 23.99fps and would not play correctly - using my test file with 
burnt in timecode and a timecode track, it was easy to see that they were not 
keeping sync. This also results in a file which is longer than the true 
duration and Quicktime decoders can display a black frame at the end as a 
result.

Perhaps this is because the edit list is removed from all tracks, not just the 
audio, I don’t know, but it doesn’t currently achieve what I described above 
sadly.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Sasi Inguva]

There is already a flag called -use_editlist in ffmpeg MOV muxer
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=ca389e3a97f92e05b1abfda29aa7bde25e1089a0;hb=HEAD#l88
. I think you can use that along with the audiotoolbox encoder to achieve
what you want.

On Sat, Jul 1, 2017 at 6:56 AM, Mark Burton [via FFmpeg-users] <
ml+s933282n4680447...@n4.nabble.com> wrote:

> How about this for a partial solution - ffmpeg supports the audiotoolbox
> aac encoder on macOS. For the sake of being able to create .mov which are
> compatible with the Quicktime format, there is a single change which I
> think could work well, albeit the ‘fix' would be limited to macOS system
> encoders.
>
> Currently a .mov created by ffmpeg when using the aac_at audiotoolbox
> encoder creates a sound track edit list with a media time of 2112. This
> will not work with Quicktime decoders, the file with decode out of sync. If
> this value was 0 however, then the file will decode properly in sync.
>
> For now, would it be possible to change this value to 0 when using the
> aac_at encoder in ffmpeg?
>
> Doing the same for the ffmpeg native aac encoder does help quite a bit,
> about 1/2 frame out of sync as opposed to a full frame.
>
>
>
>
>
> > On 29 Jun 2017, at 18:52, Sasi Inguva <[hidden email]
> > wrote:
> > I am not knowledgeable enough about audio codec implementations, but I
> > don't think we can control an audio codec implementation to follow a
> > certain delay.  For AAC codec for example, I believe libfhg-aac sets
> 1600
> > samples of dealy, while libfdk-aac would set 1024 etc. Some one with
> more
> > knowledge can tag in here.
> >
> > On Thu, Jun 29, 2017 at 10:46 AM, Mark Burton <[hidden email]
> > wrote:
> >
> >>
> >>> On 28 Jun 2017, at 01:12, Sasi Inguva <[hidden email]
> >
> >> wrote:
> >>> I have been helping Mark test Marton's patch. I looked at the test
> file
> >> Mark
> >>> was using to test the sync. There are multiple reasons for audio being
> >>> off-sync.
> >>>
> >>> i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as
> >>> https://developer.apple.com/library/content/documentation/
> >> QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> >>> suggests to put. For this kind of file the spec says that, use the
> >>> historical solution of assuming the delay as 2112 samples. And this is
> >> what
> >>> the QuickTime player and iMovie on my MAC seem to be doing. However in
> >>> Ffmpeg we don't assume the delay as 2112 samples. If there is no edit
> >> list,
> >>> we assume it as zero.
> >>> Hence, when we transcode the video using ffmpeg, we are adding 2112
> >> samples
> >>> of silence in the transcoded file ( as actual audio data).
> >>> ii) On top of that ffmpeg AAC encoder itself introduces 1024 samples
> of
> >>> silence, and ffmpeg then uses edit list to denote that as the encoder
> >> delay.
> >>> However the spec says that along with the edit list, we should also
> set
> >> the
> >>> "sgpd" atom, ( which is what Marton's patch does).
> >>>
> >>> So to fix this, I hacked ffmpeg MOV demuxer to assume 2112 delay for
> AAC,
> >>> and combined it with Marton's patch.  I hoped that the file transcoded
> >> from
> >>> ffmpeg built from these two patches, will correctly match the original
> >> test
> >>> file when decoded with Apple tools (iMovie) .
> >>>
> >>> However it was not to be. It seems like even Apple tools don't respect
> >> the
> >>> new way of setting the encoder delay. When I decode the file using
> >> iMovie, I
> >>> observe that 2112 samples from the beginning are gone, indicating that
> >> Apple
> >>> is still assuming 2112 samples of delay for AAC.
> >>>
> >>> I am attaching the original test file, and the file I generated.
> >>> SyncTest_2sec_24p_Compressor_enc.mp4
> >>>  >> 2sec_24p_Compressor_enc.mp4>
> >>> SyncTestFfmpegAdEdit2112.mp4
> >>>  >> SyncTestFfmpegAdEdit2112.mp4>
> >>
> >> Thanks Sasi. So the short of this is that its unclear whether it is in
> >> fact possible to create a mov file which Apple tools will decode using
> the
> >> ‘new’ method.
> >>
> >> If Apple tools will always reliably use the 2112 decode method, would
> it
> >> not make more sense to include a new option in ffmpeg to encode in this
> way
> >> (same as Quicktime encoders) and therefore ensure accurate decode of
> the
> >> file in the actual formats decoder? If the current methods are either
> not
> >> fully meeting the spec or are simply being ignored by Quicktime, it
> would
> >> seem that in order to maintain compatibility with the format itself,
> having
> >> a way to encode with 2112 delay would be the most reliable way to go.
> >>
> >> Thanks
> >> Mark
> >> ___
> >> ffmpeg-user mailing list
> >> 

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Sasi Inguva]

I am not knowledgeable enough about audio codec implementations, but I
don't think we can control an audio codec implementation to follow a
certain delay.  For AAC codec for example, I believe libfhg-aac sets 1600
samples of dealy, while libfdk-aac would set 1024 etc. Some one with more
knowledge can tag in here.

On Thu, Jun 29, 2017 at 10:46 AM, Mark Burton  wrote:

>
> > On 28 Jun 2017, at 01:12, Sasi Inguva 
> wrote:
> > I have been helping Mark test Marton's patch. I looked at the test file
> Mark
> > was using to test the sync. There are multiple reasons for audio being
> > off-sync.
> >
> > i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as
> > https://developer.apple.com/library/content/documentation/
> QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> > suggests to put. For this kind of file the spec says that, use the
> > historical solution of assuming the delay as 2112 samples. And this is
> what
> > the QuickTime player and iMovie on my MAC seem to be doing. However in
> > Ffmpeg we don't assume the delay as 2112 samples. If there is no edit
> list,
> > we assume it as zero.
> > Hence, when we transcode the video using ffmpeg, we are adding 2112
> samples
> > of silence in the transcoded file ( as actual audio data).
> > ii) On top of that ffmpeg AAC encoder itself introduces 1024 samples of
> > silence, and ffmpeg then uses edit list to denote that as the encoder
> delay.
> > However the spec says that along with the edit list, we should also set
> the
> > "sgpd" atom, ( which is what Marton's patch does).
> >
> > So to fix this, I hacked ffmpeg MOV demuxer to assume 2112 delay for AAC,
> > and combined it with Marton's patch.  I hoped that the file transcoded
> from
> > ffmpeg built from these two patches, will correctly match the original
> test
> > file when decoded with Apple tools (iMovie) .
> >
> > However it was not to be. It seems like even Apple tools don't respect
> the
> > new way of setting the encoder delay. When I decode the file using
> iMovie, I
> > observe that 2112 samples from the beginning are gone, indicating that
> Apple
> > is still assuming 2112 samples of delay for AAC.
> >
> > I am attaching the original test file, and the file I generated.
> > SyncTest_2sec_24p_Compressor_enc.mp4
> >  2sec_24p_Compressor_enc.mp4>
> > SyncTestFfmpegAdEdit2112.mp4
> >  SyncTestFfmpegAdEdit2112.mp4>
>
> Thanks Sasi. So the short of this is that its unclear whether it is in
> fact possible to create a mov file which Apple tools will decode using the
> ‘new’ method.
>
> If Apple tools will always reliably use the 2112 decode method, would it
> not make more sense to include a new option in ffmpeg to encode in this way
> (same as Quicktime encoders) and therefore ensure accurate decode of the
> file in the actual formats decoder? If the current methods are either not
> fully meeting the spec or are simply being ignored by Quicktime, it would
> seem that in order to maintain compatibility with the format itself, having
> a way to encode with 2112 delay would be the most reliable way to go.
>
> Thanks
> Mark
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

> On 28 Jun 2017, at 01:12, Sasi Inguva  wrote:
> I have been helping Mark test Marton's patch. I looked at the test file Mark
> was using to test the sync. There are multiple reasons for audio being
> off-sync.
> 
> i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as 
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>  
> suggests to put. For this kind of file the spec says that, use the
> historical solution of assuming the delay as 2112 samples. And this is what
> the QuickTime player and iMovie on my MAC seem to be doing. However in
> Ffmpeg we don't assume the delay as 2112 samples. If there is no edit list,
> we assume it as zero.
> Hence, when we transcode the video using ffmpeg, we are adding 2112 samples
> of silence in the transcoded file ( as actual audio data). 
> ii) On top of that ffmpeg AAC encoder itself introduces 1024 samples of
> silence, and ffmpeg then uses edit list to denote that as the encoder delay. 
> However the spec says that along with the edit list, we should also set the
> "sgpd" atom, ( which is what Marton's patch does).
> 
> So to fix this, I hacked ffmpeg MOV demuxer to assume 2112 delay for AAC,
> and combined it with Marton's patch.  I hoped that the file transcoded from
> ffmpeg built from these two patches, will correctly match the original test
> file when decoded with Apple tools (iMovie) . 
> 
> However it was not to be. It seems like even Apple tools don't respect the
> new way of setting the encoder delay. When I decode the file using iMovie, I
> observe that 2112 samples from the beginning are gone, indicating that Apple
> is still assuming 2112 samples of delay for AAC.
> 
> I am attaching the original test file, and the file I generated.
> SyncTest_2sec_24p_Compressor_enc.mp4
> 
>   
> SyncTestFfmpegAdEdit2112.mp4
>   

Thanks Sasi. So the short of this is that its unclear whether it is in fact 
possible to create a mov file which Apple tools will decode using the ‘new’ 
method.

If Apple tools will always reliably use the 2112 decode method, would it not 
make more sense to include a new option in ffmpeg to encode in this way (same 
as Quicktime encoders) and therefore ensure accurate decode of the file in the 
actual formats decoder? If the current methods are either not fully meeting the 
spec or are simply being ignored by Quicktime, it would seem that in order to 
maintain compatibility with the format itself, having a way to encode with 2112 
delay would be the most reliable way to go.

Thanks
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Sasi Inguva]

I have been helping Mark test Marton's patch. I looked at the test file Mark
was using to test the sync. There are multiple reasons for audio being
off-sync.

i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as 
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
 
suggests to put. For this kind of file the spec says that, use the
historical solution of assuming the delay as 2112 samples. And this is what
the QuickTime player and iMovie on my MAC seem to be doing. However in
Ffmpeg we don't assume the delay as 2112 samples. If there is no edit list,
we assume it as zero.
Hence, when we transcode the video using ffmpeg, we are adding 2112 samples
of silence in the transcoded file ( as actual audio data). 
ii) On top of that ffmpeg AAC encoder itself introduces 1024 samples of
silence, and ffmpeg then uses edit list to denote that as the encoder delay. 
However the spec says that along with the edit list, we should also set the
"sgpd" atom, ( which is what Marton's patch does).

So to fix this, I hacked ffmpeg MOV demuxer to assume 2112 delay for AAC,
and combined it with Marton's patch.  I hoped that the file transcoded from
ffmpeg built from these two patches, will correctly match the original test
file when decoded with Apple tools (iMovie) . 

However it was not to be. It seems like even Apple tools don't respect the
new way of setting the encoder delay. When I decode the file using iMovie, I
observe that 2112 samples from the beginning are gone, indicating that Apple
is still assuming 2112 samples of delay for AAC.

I am attaching the original test file, and the file I generated.
SyncTest_2sec_24p_Compressor_enc.mp4

  
SyncTestFfmpegAdEdit2112.mp4
  








--
View this message in context: 
http://www.ffmpeg-archive.org/Create-an-AAC-stream-matching-the-Core-Media-Audio-packet-format-priming-etc-tp4679789p4680414.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 19 Jun 2017, at 22:38, Marton Balint  wrote:
> Can you measure how many samples are the delay before and after my patch? I'd 
> rather do some additional testing now, instead committing something that is 
> only half-correct.

I’ve reached out to the developer who was helping me. I believe he also wrote a 
second patch of his own. I don’t yet have a binary build I can test with 
myself, so I would like to test more files to check the results and give you a 
solid answer.

Essentially Quicktime is still assuming 2112 sample delay even with the 
patches, its just that it is ever so slightly better than normal, but it is 
still out of sync. In order to get Quicktime to adhere to a provided delay of 
1024, there would be other changes needed in ffmpeg.

It does appear that most (if not all) Quicktime based encoders are setup to 
output a file for the decoder to assume 2112 sample delay. We have not yet 
found one which uses the ‘modern’ method.

Thanks for your help on this Marton.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Marton Balint]

On Mon, 19 Jun 2017, Mark Burton wrote:


On 15 Apr 2017, at 13:25, Christian Ebert  wrote:
* Marton Balint on Saturday, April 15, 2017 at 12:25:58 +0200

On Sat, 15 Apr 2017, Christian Ebert wrote:

* Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200

Last time I checked (a year ago or so), ffmpeg created a correct .mov
edit list to signal the audio priming.

https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html


Hmm, a recent fix changed one of the hunk contexts... Could you try
this new attached patch?


I'm afraid for my purpose - segmenting - it does not make a
difference. I still get the same overlong first segments;
depending on codec - native aac has much shorter 'delays' than
fdk-aac, they are minute, but they still make the hls muxer set a
1 second higher TARGETDURATION, even when all segments are of the
exact duration up to the sixth decimal - this can be corrected
by hand because the spec tolerates such minimal divergences.

But again, for the purpose of segmenting it has not any effect.

It may well fix Mark's use case. I haven't checked that.


Hi Marton,

I wasn’t able to test your patch myself, but another very helpful 
developer did apply it and ran a test for me. The result was much better 
sync with your patch, although still not a complete match for the input 
file’s sync when decoded in Quicktime.


Adding the 'roll' sgpd atom and sample-to-group atoms does appear to be 
a requirement for AAC priming to be better understood by Quicktime. 
Although there is still something else happening to scupper perfect 
sync, it would be useful to apply this patch if possible.




Can you measure how many samples are the delay before and after my patch? 
I'd rather do some additional testing now, instead committing something 
that is only half-correct.


Thanks,
Marton
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 16 Jun 2017, at 10:17, ffm...@me.com wrote:
> I agree with Mark here. 
> Followed the issue now for a while and opened a similar (not went into this 
> deep technical level) issue some time ago.
> 
> I guess it should be marked as a bug and - if possible - should be fixed. 
> Thanks, Andreas

Thanks Andreas. I feel with Marton’s patch (if it can be applied) and a few 
extra tweaks we could be getting very close to finally solving this bug.

What is your setup and how are you experiencing this?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

> On 15 Apr 2017, at 13:25, Christian Ebert  wrote:
> * Marton Balint on Saturday, April 15, 2017 at 12:25:58 +0200
>> On Sat, 15 Apr 2017, Christian Ebert wrote:
>>> * Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200
 Last time I checked (a year ago or so), ffmpeg created a correct .mov
 edit list to signal the audio priming.
 
 https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>> 
>> Hmm, a recent fix changed one of the hunk contexts... Could you try
>> this new attached patch?
> 
> I'm afraid for my purpose - segmenting - it does not make a
> difference. I still get the same overlong first segments;
> depending on codec - native aac has much shorter 'delays' than
> fdk-aac, they are minute, but they still make the hls muxer set a
> 1 second higher TARGETDURATION, even when all segments are of the
> exact duration up to the sixth decimal - this can be corrected
> by hand because the spec tolerates such minimal divergences.
> 
> But again, for the purpose of segmenting it has not any effect.
> 
> It may well fix Mark's use case. I haven't checked that.

Hi Marton,

I wasn’t able to test your patch myself, but another very helpful developer did 
apply it and ran a test for me. The result was much better sync with your 
patch, although still not a complete match for the input file’s sync when 
decoded in Quicktime.

Adding the 'roll' sgpd atom and sample-to-group atoms does appear to be a 
requirement for AAC priming to be better understood by Quicktime. Although 
there is still something else happening to scupper perfect sync, it would be 
useful to apply this patch if possible.

Many thanks
Mark


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[ffmpeg]

I agree with Mark here. 
Followed the issue now for a while and opened a similar (not went into this 
deep technical level) issue some time ago.

I guess it should be marked as a bug and - if possible - should be fixed. 
Thanks, Andreas



> Am 9. Jun 2017 um 10:44 schrieb Mark Burton :
> 
> I appreciate I don't fully grasp the complexities or know the full story 
> here, but do you not think its fair to say this should be considered a major 
> ffmpeg bug or issue? It seems clear to me, and others, that the current .mov 
> muxer produces a file which is incompatible with Quicktime itself. AAC 
> priming in this container does not follow as advised and that appears to be 
> the main reason its breaks when decoded.
> 
> Going back to changing the file manually (after using aresample and asetpts 
> filters), I can get a file which decodes perfectly in Quicktime and VLC by 
> just changing the single value for duration in the sound edit list to match 
> the video track duration:
> 
> trak - Track
>   edts - Edits
>   elst - Edit List
>   'segment duration’
> 
> This file also imports perfectly into Avid Media Composer, a first. The movie 
> header still shows an overlong duration, but that does not appear to affect 
> playback. Its really just a hack though.
> 
> Surely it would be preferable to have a permanent solution to this which did 
> not require the use of multiple audio filters and manual hacks to produce a 
> working file with AAC for Quicktime.
> 
> Many thanks for your patience with this, I know I’ve been banging on this 
> door for a few months, so I apologise for clogging up your inboxes. Its not 
> my intention to be accusatory, I’m genuinely trying to help improve the tool 
> as best I can. A re-engagement from the experts here would be hugely 
> appreciated and I will do all I can to help.
> 
> Mark
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

I appreciate I don't fully grasp the complexities or know the full story here, 
but do you not think its fair to say this should be considered a major ffmpeg 
bug or issue? It seems clear to me, and others, that the current .mov muxer 
produces a file which is incompatible with Quicktime itself. AAC priming in 
this container does not follow as advised and that appears to be the main 
reason its breaks when decoded.

Going back to changing the file manually (after using aresample and asetpts 
filters), I can get a file which decodes perfectly in Quicktime and VLC by just 
changing the single value for duration in the sound edit list to match the 
video track duration:

trak - Track
edts - Edits
elst - Edit List
'segment duration’

This file also imports perfectly into Avid Media Composer, a first. The movie 
header still shows an overlong duration, but that does not appear to affect 
playback. Its really just a hack though.

Surely it would be preferable to have a permanent solution to this which did 
not require the use of multiple audio filters and manual hacks to produce a 
working file with AAC for Quicktime.

Many thanks for your patience with this, I know I’ve been banging on this door 
for a few months, so I apologise for clogging up your inboxes. Its not my 
intention to be accusatory, I’m genuinely trying to help improve the tool as 
best I can. A re-engagement from the experts here would be hugely appreciated 
and I will do all I can to help.

Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 26 May 2017, at 12:53, Christian Ebert > wrote:
> Yeah, filtering does not add an edit list (apparently the
> 'modern' solution):
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-25592
>  
> 
> and therefore QuickTime fails over to a hardcoded 'historical'
> default. That explains it.

Further to what you’ve pointed out here, I looked at the encoded file with Atom 
Inspector after having used the below audio filter command:

-af aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112

Atom Inspector reveals there are just 3 values which need changing to achieve a 
file which decodes in Quicktime with perfect sync and perfect duration. Using 
the AudioToolbox AAC encoder is again more successful, but it can be done with 
the native AAC encoder also, with one extra step (removing the first entry in 
the sound media Edit List).

The locations of the values which need to be altered are:

IN THE MOVIE HEADER
moov - Movie  //  mvhd - Movie Header  //  ‘duration'

IN THE SOUND MEDIA TRACK
trak - Track  //  tkhd - Track Header  //  ‘duration’
trak - Track  //  edts - Edits  //  elst - Edit List  //  'segment duration’


When these values are changed to match the video track duration, the file is 
‘fixed’ so to speak - in Quicktime based decoders it plays in perfect sync, 
ends exactly where its supposed to end and has a duration which matches the 
source. Its the first file with AAC audio I’ve had from ffmpeg which works in a 
Quicktime decoder. Obviously this is not a viable solution unless there is a 
way to do this programatically, its cumbersome and, I’m sure, a bit of a hack.

However it does appear to prove your point that the current method of ffmpeg 
mov file muxing is producing a file which fails to use "a complete 
implementation using the sample group structures” for AAC tracks which 
therefore results in the decoder falling back to the historical technique to 
handle AAC timing and synchronisation and hence the sync issue.

If anyone is still monitoring this thread, please can you take another look at 
this? It appears there may be two ways to address this.

1 - Alter the mov muxer to create a file which correctly conforms to "a 
complete implementation using the sample group structures” as set out here:
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html#//apple_ref/doc/uid/TP4939-CH2-SW11
 


2 - Alternatively, is there a way to programatically mux the mov file to record 
a duration which matches the source duration exactly?

Thanks
Mark


Command used in this example:
———
$ ffmpeg -v info -i input.mov -c:v libx264 -pix_fmt yuv420p -c:a aac_at -b:a 
128k -af aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112 output.mov
ffmpeg version N-86344-gb5a0971-tessus Copyright (c) 2000-2017 the FFmpeg 
developers
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg 
--extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl 
--enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm 
--enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb 
--enable-libopencore-amrwb --enable-libopus --enable-libsnappy --enable-libsoxr 
--enable-libspeex --enable-libtheora --enable-libvidstab 
--enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack 
--enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid 
--enable-libzmq --enable-libzvbi --enable-version3 --disable-ffplay 
--disable-indev=qtkit
  libavutil  55. 63.100 / 55. 63.100
  libavcodec 57. 96.101 / 57. 96.101
  libavformat57. 72.101 / 57. 72.101
  libavdevice57.  7.100 / 57.  7.100
  libavfilter 6. 91.100 /  6. 91.100
  libswscale  4.  7.101 /  4.  7.101
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mov':
  Metadata:
major_brand : qt  
minor_version   : 537199360
compatible_brands: qt  
creation_time   : 2016-10-15T16:52:53.00Z
timecode: 01:00:00:00
  Duration: 00:01:00.00, start: 0.00, bitrate: 118696 kb/s
Stream #0:0(eng): Video: dnxhd (DNXHD) (AVdn / 0x6E645641), yuv422p(tv, 
bt709/unknown/unknown), 1920x1080, 116391 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 
tbr, 24k tbn, 24k tbc (default)
Metadata:
  creation_time   : 2016-10-15T16:52:53.00Z
  handler_name: Apple Alias Data Handler
  encoder : Avid DNxHD Codec
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Mark Burton on Wednesday, May 24, 2017 at 13:20:34 +0100
> On 23 May 2017, at 11:20, Christian Ebert  wrote:
>>> So I looked back at your above -af and realised that the 1024 should 
>>> actually be 2112 which is Apple’s chosen fixed encoding delay.
>>> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>>>  
>>> 

Yes, the 'historical solution': implicit encoder delay:
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html#//apple_ref/doc/uid/TP4939-CH2-SW9

>>> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112
>> Strange, probably all depends on the demuxing application.
> My take on it is that Quicktime will always assume 2112 padding, so I believe 
> a .mov should be setup with this priming duration.

Yeah, filtering does not add an edit list (apparently the
'modern' solution):
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-25592
and therefore QuickTime fails over to a hardcoded 'historical'
default. That explains it.

There are some options referring to edit lists, but I haven't
tried whether, nevermind how, they could be used for this
purpose.

-- 
theatre - books - texts - movies
Black Trash Productions at home: https://blacktrash.org
Black Trash Productions on Facebook:
https://www.facebook.com/blacktrashproductions
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 23 May 2017, at 11:20, Christian Ebert  wrote:
>> So I looked back at your above -af and realised that the 1024 should 
>> actually be 2112 which is Apple’s chosen fixed encoding delay.
>> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>>  
>> 
>> 
>> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112
> Strange, probably all depends on the demuxing application.
My take on it is that Quicktime will always assume 2112 padding, so I believe a 
.mov should be setup with this priming duration.

> ffprobe -show_entries stream=codec_type,start_time,start_pts,duration result
> 
> for me gives 0 for all start values.
Which is then being pulled back -2112 samples on playback, which is why it goes 
out of sync I believe. Unless you have 2112 samples of empty audio before the 
source audio data starts, there will be a sync issue.

> Did you look at the atrim filter? It offers end, end_sample, and
> end_pts parameters. You may have to to some calculations.
> 
> Re-reading the article you referenced, it may even a better idea
> to use atrim instead of asetpts for the start as well.
> 
> Maybe:
> 
> -filter:a aresample=async=1:first_pts=0,atrim=start_pts=2112:end={-t value}
Thanks for the idea. I’m  not having much luck with this for the tail and 
unless I keep asetpts as before, the head is pulled out of sync.

I think the problem is that these trailing samples should just be trimmed on 
playback automatically. Thats works when we don’t add 2112 samples of padding, 
but with the required padding there are either too many trailing samples or it 
breaks the trailing detection process. I’ve tried to learn how this is 
signalled to the decoder, but I’m not really understanding it and its above my 
intellect grade.

It would be very useful to hear from the devs why (again with the greatest 
respect, I completely accept I’m not going to have a full picture here) ffmpeg 
does not follow the Quicktime file format spec for their .mov muxer in the way 
that Apple has advised, and ideally if there was a way to offer an extra option 
for this muxer to create aac files with Quicktime decoder compatibility.

Thanks
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Mark Burton on Monday, May 22, 2017 at 15:22:34 +0100
> On 15 Apr 2017, at 09:22, Christian Ebert  wrote:
>> Somewhat counterintuitive, but you never know:
>> 
>> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+1024
>> 
>> combined with the -t incantation.
> 
> It seems this issue is not going to garner much attention which is a little 
> disheartening. I can show how to reproduce it and would love to be able to 
> help.
> 
> So I looked back at your above -af and realised that the 1024 should actually 
> be 2112 which is Apple’s chosen fixed encoding delay.
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>  
> 
> 
> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112

Strange, probably all depends on the demuxing application.

ffprobe -show_entries stream=codec_type,start_time,start_pts,duration result

for me gives 0 for all start values.

> ...brings the native aac encoder almost perfectly into sync when played by a 
> Quicktime based decoder. There is a tiny discrepancy, but its 99.9% better 
> than without the -af line.
> 
> Further to this, using the AudioToolbox AAC encoder (aac_at) available in 
> ffmpeg on macOS only, with the above -af line, this discrepancy is gone and 
> the encoded file is a perfect sync match for the original source file.
> 
> The outstanding issue is the remaining samples for the file which are not 
> being trimmed, so the clip runs past the end of the picture and we get a 
> black frame. Perhaps the remaining samples are not being flagged in a way 
> that the decoder would expect, I’m really not sure.
> 
> I can use the '-t' command with the value for ('total duration of source' - 
> ‘0.041') to trim the end, but its has issues too.
> In my case of 24fps source, 0.041 is the duration of 1 frame. Doing this 
> shortens the overlong audio stream, but it removes the last frame of audio 
> and in some cases does strange things with the last two frames of audio. So 
> its not really usable in a production environment. Without subtracting 0.041, 
> the audio is still overlong.

Did you look at the atrim filter? It offers end, end_sample, and
end_pts parameters. You may have to to some calculations.

Re-reading the article you referenced, it may even a better idea
to use atrim instead of asetpts for the start as well.

Maybe:

-filter:a aresample=async=1:first_pts=0,atrim=start_pts=2112:end={-t value}

-- 
\black\trash movie   _SAME  TIME  SAME  PLACE_
   New York, in the summer of 2001

--->> https://blacktrash.org/underdogma/stsp.php
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 15 Apr 2017, at 09:22, Christian Ebert  wrote:
> Somewhat counterintuitive, but you never know:
> 
> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+1024
> 
> combined with the -t incantation.

Hi Christian,

It seems this issue is not going to garner much attention which is a little 
disheartening. I can show how to reproduce it and would love to be able to help.

So I looked back at your above -af and realised that the 1024 should actually 
be 2112 which is Apple’s chosen fixed encoding delay.
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
 


-filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112

...brings the native aac encoder almost perfectly into sync when played by a 
Quicktime based decoder. There is a tiny discrepancy, but its 99.9% better than 
without the -af line.

Further to this, using the AudioToolbox AAC encoder (aac_at) available in 
ffmpeg on macOS only, with the above -af line, this discrepancy is gone and the 
encoded file is a perfect sync match for the original source file.

The outstanding issue is the remaining samples for the file which are not being 
trimmed, so the clip runs past the end of the picture and we get a black frame. 
Perhaps the remaining samples are not being flagged in a way that the decoder 
would expect, I’m really not sure.

I can use the '-t' command with the value for ('total duration of source' - 
‘0.041') to trim the end, but its has issues too.
In my case of 24fps source, 0.041 is the duration of 1 frame. Doing this 
shortens the overlong audio stream, but it removes the last frame of audio and 
in some cases does strange things with the last two frames of audio. So its not 
really usable in a production environment. Without subtracting 0.041, the audio 
is still overlong.

So in short, this is super close to a solution for Quicktime environments, but 
still with one big issue. Hmm.

Best
Mark


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 9 May 2017, 15:42 +0100, Mark Burton , wrote:

> > > Do you not see the same behaviour?
> > No, unfortunately not.
> Can I ask - are you playing back your encoded file on macOS in either 
> Quicktime Player 7.x or Quicktime Player 10.x?
> I don’t believe you will see this unless you are using a Quicktime based 
> decoder.

> > If you say audio is off by one frame, I am not the right person to talk to 
> > because I have no idea how to reproduce.
> Sorry if this is not correct way to share a file, I’ll remove and re-share if 
> asked of course:
> https://www.dropbox.com/s/qz5c64rk6l8415o/SyncTest24p.mov?dl=0
> This is a simple 2 second sync test Quicktime file (DNx115, 24fps with PCM 
> audio) with a sync pop on the head and tail frame.
> If you have time, please could you try to encode this as follows and playback 
> in a Quicktime based player.
> ffmpeg -i SyncTest24p.mov -c:v libx264 -pix_fmt yuv420p -movflags faststart 
> -c:a aac -b:a 128k ffmpeg.mov
>
> - Do you hear a sync pop on the first frame of the encode when played back in 
> Quicktime based player?
> - Does the tail sync pop sound on frame :23 or frame :22?

> > If the effect can be multiplied by encoding several times with
> > FFmpeg, things would of course be different: Is that the case?
> No, it does not get any worse by encoding it many times in a row.

Carl is there a chance you’ve had time to further review this with the sample 
file provided?

I know there are literally thousands of areas of focus you must have to be 
looking into, but I really wouldn’t keep banging on this door if I didn’t 
genuinely feel this was a worthwhile cause. I’m aware also that the list COD 
asks us not to assume our issue is the most important, so I say that with the 
greatest respect.

I honestly don’t think it would be a stretch to say that, at preset, the ffmpeg 
MOV muxer appears to be incompatible with regards to way it handles aac priming 
with the Quicktime format. If there is anything else I can provide or test, 
please do ask, I’ll do whatever I can to help nail this down.

Thank you and regards,
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 9 May 2017, at 15:21, Carl Eugen Hoyos  wrote:
>> Do you not see the same behaviour?
> No, unfortunately not.

Can I ask - are you playing back your encoded file on macOS in either Quicktime 
Player 7.x or Quicktime Player 10.x?
I don’t believe you will see this unless you are using a Quicktime based 
decoder.

> If you say audio is off by one frame, I am not the right person
> to talk to because I have no idea how to reproduce.

Sorry if this is not correct way to share a file, I’ll remove and re-share if 
asked of course:
https://www.dropbox.com/s/qz5c64rk6l8415o/SyncTest24p.mov?dl=0 


This is a simple 2 second sync test Quicktime file (DNx115, 24fps with PCM 
audio) with a sync pop on the head and tail frame.

If you have time, please could you try to encode this as follows and playback 
in a Quicktime based player.

ffmpeg -i SyncTest24p.mov -c:v libx264 -pix_fmt yuv420p -movflags faststart 
-c:a aac -b:a 128k ffmpeg.mov

- Do you hear a sync pop on the first frame of the encode when played back in 
Quicktime based player?
- Does the tail sync pop sound on frame :23 or frame :22?

> If the effect can be multiplied by encoding several times with
> FFmpeg, things would of course be different: Is that the case?

No, it does not get any worse by encoding it many times in a row.

Many thanks for your continued help, its hugely appreciated.
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

> On 9 May 2017, at 15:16, Carl Eugen Hoyos  wrote:
>> Is this patch likely to be applied in the near future? Thanks.
> 
> The only comment I see above is that the patch does not fix
> any issue, so while I haven't looked at it, I consider this more
> of an argument against applying it.


Understood and makes perfect sense, thanks.
It was wishful thinking on my part and not properly taking in what Christian 
had reported back.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Carl Eugen Hoyos]

2017-04-18 14:21 GMT+02:00 Mark Burton :

> Do you not see the same behaviour?

No, unfortunately not.

I have dealt with (reproduced) several hundred issues related to
A/V sync over the last decade. Some of them were about mostly
missing audio, some about increasing desync, many (most) are
related to audio "missing" in the source media.
Some are desync in the range of seconds, many around 100ms
(which I still consider very bad), some significantly less: harder
to reproduce but still definitely bugs that should be fixed.

If you say audio is off by one frame, I am not the right person
to talk to because I have no idea how to reproduce.

If the effect can be multiplied by encoding several times with
FFmpeg, things would of course be different: Is that the case?

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Carl Eugen Hoyos]

2017-05-09 15:58 GMT+02:00 Mark Burton :
> On 15 Apr 2017, 11:26 +0100, Marton Balint , wrote:
>
>> Hmm, a recent fix changed one of the hunk contexts... Could
>> you try this new attached patch?
>
> Is this patch likely to be applied in the near future? Thanks.

The only comment I see above is that the patch does not fix
any issue, so while I haven't looked at it, I consider this more
of an argument against applying it.

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 15 Apr 2017, 11:26 +0100, Marton Balint , wrote:

> Hmm, a recent fix changed one of the hunk contexts... Could you try this
> new attached patch?

Is this patch likely to be applied in the near future? Thanks.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 15 Apr 2017, 09:18 +0100, Mark Burton , wrote:

> On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos , wrote:
> > 2017-04-14 23:44 GMT+02:00 Mark Burton :
> > > I find it hard having to accept an encode will always play out of
> > > sync on certain players.
> >
> > Could you elaborate a little?
> > So far, for every ticket, it either turned out that out-of-sync was
> > not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
> > by-one-frame which I consider hard to reproduce…
>
> Hi Carl,
>
> Thanks for taking the time to look at this again, it really is appreciated. 
> My environment is post production based. We work in DNxHD with PCM audio 
> which is in sync with the picture inside the Avid editing system. We export 
> using same as source to make a 24fps (not 23.976) Avid DNx115 video, 48khz 
> 24bit PCM audio Quicktime .mov file. This file plays back in any decoder in 
> sync, exactly the same as it did inside the Avid software.
>
> Take this file, encode with ffmpeg using native aac and playback in Quicktime 
> Player 7 or X or Switch or any other player which uses a Quicktime decoder 
> and it is now out of sync by 1 frame (audio is early). The same encode played 
> back in VLC shows about 1/2 frame of sync slip.
>
> I have yet to produce a .mov or .mp4 with any ffmpeg build with an AAC stream 
> which plays back in sync (the same sync as the source file) in Quicktime 
> based decoders.
>
> A good test file is to have a visual and audible 1 frame pip on the first 
> frame, then the same on the last frame. Create it with PCM audio and using a 
> video codes such as DNx or MJPEG. Encode this with a standard command:
>
> ffmpeg -i SyncTest24p.mov -c:v copy -c:a aac -b:a 128k ffmpeg_aac.mov
>
> The first frame where there used to be an audible pip, is now mute. The end 
> pip now plays approx. 1 frame early. I think in the past you’ve asked how can 
> we know that AV-sync is off by 0.04 seconds. I can’t tell you the ‘exact' 
> amount it is off by, but I do know that the first pip is gone completely and 
> end pip is approx. 1 frame early, but overall the sync in the encoded file 
> does not match the original and is therefore out of sync.
>
> Perhaps there is somewhere I could upload and share my test file for you to 
> test?
>
> I’m really mindful that my explanation may not be technically the best and 
> hopefully others who have been reporting this may chime in to offer data 
> which is more quantifiable. However, I will do anything I can to help resolve 
> this if at all possible.


Hi Carl,

Did you have any thoughts on this?

Christians fix helps with the sync issue, although not 100%, but the downside 
is that it creates an even longer audio track, which causes Quicktime decoders 
to create a bogus black end frame.

Do you not see the same behaviour?

Kind regards
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 15 Apr 2017, 09:22 +0100, Christian Ebert , wrote:

> * Mark Burton on Friday, April 14, 2017 at 22:44:52 +0100
> > > On 14 Apr 2017, at 22:22, Christian Ebert  wrote:
> > > > > Also, when you run with -v verbose, you'll see a delay (depends
> > > > > on audio codec), for you case it's probably 1024. Maybe try:
> > > > >
> > > > > -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
> > > >
> > > > 1024 looks correct. This method successfully changes the start, and the 
> > > > encoded audio plays, almost, 100% in sync. Its slightly cut off at the 
> > > > head, but only very slightly. However the downside of this method is 
> > > > that the audio now overruns the end of the picture further and is not 
> > > > trimmed from remaining samples I’m guessing. This results in a blank 
> > > > video frame being added to the tail of clip. ffprobe for ffmpeg_v3 
> > > > attached.
> > > >
> > > > I tried using -shortest, but that didn’t help address the above issue.
> > >
> > > Inserting
> > >
> > > -t `ffprobe -v quiet -of default=nw=1:nk=1 -select_streams V 
> > > -show_entries stream=duration SyncTest24p.mov`
> > >
> > > into your commandline should do the trick.
> >
> > Adding '-t 2.00’ to the command does help a little, but ultimately the 
> > final audio packet is still too large - 6ms in this case - and the black 
> > frame still occurs.
>
> Works for me with all my sample results I checked.
>
> Somewhat counterintuitive, but you never know:
>
> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+1024
>
> combined with the -t incantation.

Same result for me as before - the last packet is too large (1056) and is not 
being trimmed, so a black frame occurs at the end on playback.
When you say it works for you, was that with a Quicktime based decoder?

Thanks
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Marton Balint on Saturday, April 15, 2017 at 12:25:58 +0200
> On Sat, 15 Apr 2017, Christian Ebert wrote:
>> * Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200
>>> Last time I checked (a year ago or so), ffmpeg created a correct .mov
>>> edit list to signal the audio priming.
>>> 
>>> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> 
> Hmm, a recent fix changed one of the hunk contexts... Could you try
> this new attached patch?

I'm afraid for my purpose - segmenting - it does not make a
difference. I still get the same overlong first segments;
depending on codec - native aac has much shorter 'delays' than
fdk-aac, they are minute, but they still make the hls muxer set a
1 second higher TARGETDURATION, even when all segments are of the
exact duration up to the sixth decimal - this can be corrected
by hand because the spec tolerates such minimal divergences.

But again, for the purpose of segmenting it has not any effect.

It may well fix Mark's use case. I haven't checked that.

-- 
\black\trash movie_MORALISK  ANSTALT_
"Nix verstanden."

--->> https://blacktrash.org/underdogma/moraliskanstalt.php
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Marton Balint]

On Sat, 15 Apr 2017, Christian Ebert wrote:


* Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200

Last time I checked (a year ago or so), ffmpeg created a correct .mov
edit list to signal the audio priming.

https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Here is patch which writes Sample Group Description Atom and the
Sample-To-Group Atom as well, in addition to the already existing edit
list.

You can check if it makes a difference or not.


Unfortunately the patch doesn't apply.



Hmm, a recent fix changed one of the hunk contexts... Could you try this 
new attached patch?


Thanks,
MartonFrom 13857220fcdce7e0bf118d549c2f0d593bd5a029 Mon Sep 17 00:00:00 2001
From: Marton Balint 
Date: Sat, 20 Feb 2016 19:32:18 +0100
Subject: [PATCH] avformat/movenc: add support for writing AAC Audio Priming
 metadata

https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Signed-off-by: Marton Balint 
---
 libavformat/movenc.c| 21 ++---
 tests/ref/fate/adtstoasc_ticket3715 |  4 ++--
 tests/ref/fate/copy-psp |  4 ++--
 tests/ref/fate/movenc   | 12 ++--
 4 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e6e2313..c4c5287 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2250,14 +2250,14 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, MOVTrack *track)
 (AVRational){1, 1000},
 (AVRational){1, 48000});
 
-if (track->entry) {
-sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
-if (!sgpd_entries)
-return AVERROR(ENOMEM);
-}
+if (!track->entry)
+return 0;
 
-av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS);
+sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
+if (!sgpd_entries)
+return AVERROR(ENOMEM);
 
+if (track->par->codec_id == AV_CODEC_ID_OPUS) {
 for (i = 0; i < track->entry; i++) {
 int roll_samples_remaining = roll_samples;
 int distance = 0;
@@ -2284,6 +2284,13 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, MOVTrack *track)
 sgpd_entries[entries].group_description_index = distance ? ++group : 0;
 }
 }
+} else {
+entries++;
+sgpd_entries[entries].count = track->sample_count;
+sgpd_entries[entries].roll_distance = 1;
+sgpd_entries[entries].group_description_index = ++group;
+}
+
 entries++;
 
 if (!group) {
@@ -2346,7 +2353,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContext
 if (mov->encryption_scheme == MOV_ENC_CENC_AES_CTR) {
 ff_mov_cenc_write_stbl_atoms(>cenc, pb);
 }
-if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+if (track->par->codec_id == AV_CODEC_ID_OPUS || track->par->codec_id == AV_CODEC_ID_AAC) {
 mov_preroll_write_stbl_atoms(pb, track);
 }
 return update_size(pb, pos);
diff --git a/tests/ref/fate/adtstoasc_ticket3715 b/tests/ref/fate/adtstoasc_ticket3715
index 949b565..96795a2 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,5 +1,5 @@
-ef8ce3cbd1d86113e7c991a816086068 *tests/data/fate/adtstoasc_ticket3715.mov
-33270 tests/data/fate/adtstoasc_ticket3715.mov
+0221e04333e6ac432fa42960502f0d5a *tests/data/fate/adtstoasc_ticket3715.mov
+33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
 #media_type 0: audio
diff --git a/tests/ref/fate/copy-psp b/tests/ref/fate/copy-psp
index 6603d3f..81eb172 100644
--- a/tests/ref/fate/copy-psp
+++ b/tests/ref/fate/copy-psp
@@ -1,5 +1,5 @@
-6889223644fc560069c8591984175a62 *tests/data/fate/copy-psp.psp
-2041379 tests/data/fate/copy-psp.psp
+cada61453a2483ef8ba1fb82c8bbff25 *tests/data/fate/copy-psp.psp
+2041433 tests/data/fate/copy-psp.psp
 #extradata 0:   51, 0xaf6d1012
 #extradata 1:2, 0x00b200a1
 #tb 0: 1/9
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 09e603a..47bcf9d 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 100, 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 97, type sync atom moof
 write_data len 110, time nopts, type trailer atom -

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200
> Last time I checked (a year ago or so), ffmpeg created a correct .mov
> edit list to signal the audio priming.
> 
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> 
> Here is patch which writes Sample Group Description Atom and the
> Sample-To-Group Atom as well, in addition to the already existing edit
> list.
> 
> You can check if it makes a difference or not.

Unfortunately the patch doesn't apply.

> Regards,
> Marton

> From 64d9db76038b7b248bffe459b58b138c6b8fcc03 Mon Sep 17 00:00:00 2001
> From: Marton Balint 
> Date: Sat, 20 Feb 2016 19:32:18 +0100
> Subject: [PATCH] avformat/movenc: add support for writing AAC Audio Priming
> metadata
> 
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> 
> Signed-off-by: Marton Balint 
> ---
> libavformat/movenc.c| 21 ++---
> tests/ref/fate/adtstoasc_ticket3715 |  4 ++--
> tests/ref/fate/copy-psp |  4 ++--
> tests/ref/fate/movenc   | 12 ++--
> 4 files changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index e6a70bf..5779e3c 100644

I could not find commit e6a70bf either.

-- 
theatre - books - texts - movies
Black Trash Productions at home: https://blacktrash.org
Black Trash Productions on Facebook:
https://www.facebook.com/blacktrashproductions
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Carl Eugen Hoyos on Saturday, April 15, 2017 at 00:44:43 +0200
> 2017-04-14 23:44 GMT+02:00 Mark Burton :
>> I find it hard having to accept an encode will always play out of
>> sync on certain players.
> 
> Could you elaborate a little?
> So far, for every ticket, it either turned out that out-of-sync was
> not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
> by-one-frame which I consider hard to reproduce...

In theory it is probably correct that it's the task of the
decoding application to make the aac priming work. In many real
world scenarios this does not happen.

I do a lot of segmenting, and can always reproduce it with the
hls muxer:

https://trac.ffmpeg.org/ticket/3859
I closed it because, as per last comment I finally resorted to
the workaround(?) mentioned here.
https://trac.ffmpeg.org/ticket/3859#comment:13
https://sourceforge.net/p/opencore-amr/mailman/message/32912437/

If you see a HLS playlist where the TARGETDURATION is higher than
the duration of any segments than the first you can bet it has
been created by ffmpeg.

And if you don't clip at the end, you can easily get invalid
audio-only segments as last segment, and end of video may not be
detected in the majority of real world scenarios, arguably when
you play HLS in a browser.

So, apart from introducing minimal async, it also has other
repercussions.

Why not a warning, ideally with a hint as to how to best deal
with the situation, similar to the one about pix_fmpt yuv420p:

Use -pix_fmt yuv420p for compatibility with outdated media players.

Maybe there is no correct solution, and the delay hint in the
verbose output was certainly helpful, at least in my case; it
also points to some awareness of a potential problem area. It
just took me a long time to find it.

-- 
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies   --->>> https://blacktrash.org/underdogma
http://itunes.apple.com/podcast/underdogma-movies/id363423596
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Mark Burton on Friday, April 14, 2017 at 22:44:52 +0100
>> On 14 Apr 2017, at 22:22, Christian Ebert  wrote:
 Also, when you run with -v verbose, you'll see a delay (depends
 on audio codec), for you case it's probably 1024. Maybe try:
 
 -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>>> 
>>> 1024 looks correct. This method successfully changes the start, and the 
>>> encoded audio plays, almost, 100% in sync. Its slightly cut off at the 
>>> head, but only very slightly. However the downside of this method is that 
>>> the audio now overruns the end of the picture further and is not trimmed 
>>> from remaining samples I’m guessing. This results in a blank video frame 
>>> being added to the tail of clip. ffprobe for ffmpeg_v3 attached.
>>> 
>>> I tried using -shortest, but that didn’t help address the above issue.
>> 
>> Inserting
>> 
>> -t `ffprobe -v quiet -of default=nw=1:nk=1 -select_streams V -show_entries 
>> stream=duration SyncTest24p.mov`
>> 
>> into your commandline should do the trick.
> 
> Adding '-t 2.00’ to the command does help a little, but ultimately the 
> final audio packet is still too large - 6ms in this case - and the black 
> frame still occurs.

Works for me with all my sample results I checked.

Somewhat counterintuitive, but you never know:

-filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+1024

combined with the -t incantation.

-- 
theatre - books - texts - movies
Black Trash Productions at home: https://blacktrash.org
Black Trash Productions on Facebook:
https://www.facebook.com/blacktrashproductions
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos , wrote:

> 2017-04-14 23:44 GMT+02:00 Mark Burton :
> > I find it hard having to accept an encode will always play out of
> > sync on certain players.
>
> Could you elaborate a little?
> So far, for every ticket, it either turned out that out-of-sync was
> not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
> by-one-frame which I consider hard to reproduce…

Hi Carl,

Thanks for taking the time to look at this again, it really is appreciated. My 
environment is post production based. We work in DNxHD with PCM audio which is 
in sync with the picture inside the Avid editing system. We export using same 
as source to make a 24fps (not 23.976) Avid DNx115 video, 48khz 24bit PCM audio 
Quicktime .mov file. This file plays back in any decoder in sync, exactly the 
same as it did inside the Avid software.

Take this file, encode with ffmpeg using native aac and playback in Quicktime 
Player 7 or X or Switch or any other player which uses a Quicktime decoder and 
it is now out of sync by 1 frame (audio is early). The same encode played back 
in VLC shows about 1/2 frame of sync slip.

I have yet to produce a .mov or .mp4 with any ffmpeg build with an AAC stream 
which plays back in sync (the same sync as the source file) in Quicktime based 
decoders.

A good test file is to have a visual and audible 1 frame pip on the first 
frame, then the same on the last frame. Create it with PCM audio and using a 
video codes such as DNx or MJPEG. Encode this with a standard command:

ffmpeg -i SyncTest24p.mov -c:v copy -c:a aac -b:a 128k ffmpeg_aac.mov

The first frame where there used to be an audible pip, is now mute. The end pip 
now plays approx. 1 frame early. I think in the past you’ve asked how can we 
know that AV-sync is off by 0.04 seconds. I can’t tell you the ‘exact' amount 
it is off by, but I do know that the first pip is gone completely and end pip 
is approx. 1 frame early, but overall the sync in the encoded file does not 
match the original and is therefore out of sync.

Perhaps there is somewhere I could upload and share my test file for you to 
test?

I’m really mindful that my explanation may not be technically the best and 
hopefully others who have been reporting this may chime in to offer data which 
is more quantifiable. However, I will do anything I can to help resolve this if 
at all possible.

Many thanks and kind regards,
Mark


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 15 Apr 2017, 06:55 +0100, Marton Balint , wrote:

> On Sat, 15 Apr 2017, Carl Eugen Hoyos wrote:
>
> > 2017-04-14 23:44 GMT+02:00 Mark Burton :
> > > I find it hard having to accept an encode will always play out of
> > > sync on certain players.
> >
> > Could you elaborate a little?
> > So far, for every ticket, it either turned out that out-of-sync was
> > not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
> > by-one-frame which I consider hard to reproduce...
>
> Last time I checked (a year ago or so), ffmpeg created a correct .mov edit
> list to signal the audio priming.
>
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>
> Here is patch which writes Sample Group Description Atom and the
> Sample-To-Group Atom as well, in addition to the already existing edit
> list.
>
> You can check if it makes a difference or not.

Thanks Martin. I use a precompiled binary of the latest snapshot build from 
https://evermeet.cx/ffmpeg. Apologies, I’m not familiar with how to test an 
individual patch, but I’m sure it involves compiling the source and although 
I’ve used brew install a few times, I’m very much a novice in that area.

Has your patch not been committed to the project?

Thanks
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Marton Balint]

On Sat, 15 Apr 2017, Carl Eugen Hoyos wrote:


2017-04-14 23:44 GMT+02:00 Mark Burton :

I find it hard having to accept an encode will always play out of
sync on certain players.


Could you elaborate a little?
So far, for every ticket, it either turned out that out-of-sync was
not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
by-one-frame which I consider hard to reproduce...


Last time I checked (a year ago or so), ffmpeg created a correct .mov edit 
list to signal the audio priming.


https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Here is patch which writes Sample Group Description Atom and the 
Sample-To-Group Atom as well, in addition to the already existing edit 
list.


You can check if it makes a difference or not.

Regards,
MartonFrom 64d9db76038b7b248bffe459b58b138c6b8fcc03 Mon Sep 17 00:00:00 2001
From: Marton Balint 
Date: Sat, 20 Feb 2016 19:32:18 +0100
Subject: [PATCH] avformat/movenc: add support for writing AAC Audio Priming
 metadata

https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Signed-off-by: Marton Balint 
---
 libavformat/movenc.c| 21 ++---
 tests/ref/fate/adtstoasc_ticket3715 |  4 ++--
 tests/ref/fate/copy-psp |  4 ++--
 tests/ref/fate/movenc   | 12 ++--
 4 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e6a70bf..5779e3c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2250,14 +2250,14 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, MOVTrack *track)
 (AVRational){1, 1000},
 (AVRational){1, 48000});
 
-if (track->entry) {
-sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
-if (!sgpd_entries)
-return AVERROR(ENOMEM);
-}
+if (!track->entry)
+return 0;
 
-av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS);
+sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
+if (!sgpd_entries)
+return AVERROR(ENOMEM);
 
+if (track->par->codec_id == AV_CODEC_ID_OPUS) {
 for (i = 0; i < track->entry; i++) {
 int roll_samples_remaining = roll_samples;
 int distance = 0;
@@ -2284,6 +2284,13 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, MOVTrack *track)
 sgpd_entries[entries].group_description_index = distance ? ++group : 0;
 }
 }
+} else {
+entries++;
+sgpd_entries[entries].count = track->sample_count;
+sgpd_entries[entries].roll_distance = 1;
+sgpd_entries[entries].group_description_index = ++group;
+}
+
 entries++;
 
 if (!group)
@@ -2344,7 +2351,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContext
 if (mov->encryption_scheme == MOV_ENC_CENC_AES_CTR) {
 ff_mov_cenc_write_stbl_atoms(>cenc, pb);
 }
-if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+if (track->par->codec_id == AV_CODEC_ID_OPUS || track->par->codec_id == AV_CODEC_ID_AAC) {
 mov_preroll_write_stbl_atoms(pb, track);
 }
 return update_size(pb, pos);
diff --git a/tests/ref/fate/adtstoasc_ticket3715 b/tests/ref/fate/adtstoasc_ticket3715
index 949b565..96795a2 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,5 +1,5 @@
-ef8ce3cbd1d86113e7c991a816086068 *tests/data/fate/adtstoasc_ticket3715.mov
-33270 tests/data/fate/adtstoasc_ticket3715.mov
+0221e04333e6ac432fa42960502f0d5a *tests/data/fate/adtstoasc_ticket3715.mov
+33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
 #media_type 0: audio
diff --git a/tests/ref/fate/copy-psp b/tests/ref/fate/copy-psp
index 6603d3f..81eb172 100644
--- a/tests/ref/fate/copy-psp
+++ b/tests/ref/fate/copy-psp
@@ -1,5 +1,5 @@
-6889223644fc560069c8591984175a62 *tests/data/fate/copy-psp.psp
-2041379 tests/data/fate/copy-psp.psp
+cada61453a2483ef8ba1fb82c8bbff25 *tests/data/fate/copy-psp.psp
+2041433 tests/data/fate/copy-psp.psp
 #extradata 0:   51, 0xaf6d1012
 #extradata 1:2, 0x00b200a1
 #tb 0: 1/9
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 09e603a..47bcf9d 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 100, 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 -

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

> On 14 Apr 2017, at 22:22, Christian Ebert  wrote:
>>> Also, when you run with -v verbose, you'll see a delay (depends
>>> on audio codec), for you case it's probably 1024. Maybe try:
>>> 
>>> -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>>> 
>>> Especially the latter could be exactly the wrong thing for your
>>> purpose, but it doesn't hurt trying.
>> 
>> 1024 looks correct. This method successfully changes the start, and the 
>> encoded audio plays, almost, 100% in sync. Its slightly cut off at the head, 
>> but only very slightly. However the downside of this method is that the 
>> audio now overruns the end of the picture further and is not trimmed from 
>> remaining samples I’m guessing. This results in a blank video frame being 
>> added to the tail of clip. ffprobe for ffmpeg_v3 attached.
>> 
>> I tried using -shortest, but that didn’t help address the above issue.
> 
> Inserting
> 
> -t `ffprobe -v quiet -of default=nw=1:nk=1 -select_streams V -show_entries 
> stream=duration SyncTest24p.mov`
> 
> into your commandline should do the trick.

Adding '-t 2.00’ to the command does help a little, but ultimately the 
final audio packet is still too large - 6ms in this case - and the black frame 
still occurs.

[PACKET]
codec_type=audio
stream_index=1
pts=95232
pts_time=1.984000
dts=95232
dts_time=1.984000
duration=1056
duration_time=0.022000
convergence_duration=N/A
convergence_duration_time=N/A
size=406
pos=23401
flags=K_
[/PACKET]


> imho this is a muxing bug in dealing with aac priming in many
> situations, but making my case fell on deaf ears.

It feels a bit odd having to chase the output file in this way doesn’t it. I’ve 
read a number of the reports around this issue (perhaps some from you?) and 
there does appear to be a real difference of opinion on both sides.

How do you work round this in your products? I find it hard having to accept an 
encode will always play out of sync on certain players.

Thank so much for your help,

Regards
Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Mark Burton on Friday, April 14, 2017 at 21:45:07 +0100
>> * Mark Burton on Friday, April 14, 2017 at 16:57:06 +0100
>>> Here is the basic command to reproduce. I have attached the uncut loglevel 
>>> 99 console output for this command:
>>> ffmpeg -i SyncTest24p.mov -c:v libx264 -pix_fmt yuv420p -movflags faststart 
>>> -c:a aac -b:a 128k ffmpeg.mp4
>> 
>> Can you try:
>> 
>> -filter:a aresample=first_pts=0
> 
> Thanks for your reply and these options to test. This first one does not 
> appear to change the outcome. ffprobe for ffmpeg_v2 attached.
> 
>> Also, when you run with -v verbose, you'll see a delay (depends
>> on audio codec), for you case it's probably 1024. Maybe try:
>> 
>> -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>> 
>> Especially the latter could be exactly the wrong thing for your
>> purpose, but it doesn't hurt trying.
> 
> 1024 looks correct. This method successfully changes the start, and the 
> encoded audio plays, almost, 100% in sync. Its slightly cut off at the head, 
> but only very slightly. However the downside of this method is that the audio 
> now overruns the end of the picture further and is not trimmed from remaining 
> samples I’m guessing. This results in a blank video frame being added to the 
> tail of clip. ffprobe for ffmpeg_v3 attached
> .
> 
> I tried using -shortest, but that didn’t help address the above issue.

Inserting

-t `ffprobe -v quiet -of default=nw=1:nk=1 -select_streams V -show_entries 
stream=duration SyncTest24p.mov`

into your commandline should do the trick.

imho this is a muxing bug in dealing with aac priming in many
situations, but making my case fell on deaf ears.

-- 
\black\trash movie _SAME  TIME  SAME  PLACE_
 --->> https://blacktrash.org/underdogma/stsp.php
\black\trash audio   _ANOTHER  TIME  ANOTHER  PLACE_
--->> https://blacktrash.org/underdogma/atap.html
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Mark Burton]

On 14 Apr 2017, 17:47 +0100, Christian Ebert , wrote:

> * Mark Burton on Friday, April 14, 2017 at 16:57:06 +0100
> > I appreciate this is a tricky area and there appear to be different ways 
> > that some encoders create AAC streams with regards to the padding and 
> > remaining samples etc. I won’t pretend to fully understand all the factors, 
> > but I would like to ask a genuine question which purely comes from the 
> > point of view of wanting to create a file for my working environment - an 
> > environment dominated by Quicktime 7 and X playback / decoding tools. I’m 
> > no great fan of Quicktime and appreciate its not well loved here also. In 
> > my industry it is still very much the defecto playback engine though, so if 
> > I’m able to tailor a file for this decoder, it would be an enormous help.
> >
> > Let me also say, I am not accusing ffmpeg of having an issue, I have read a 
> > number of ‘bug’ reports surrounding ffmpeg and AAC priming and there being 
> > a sync discrepancy in the resultant encode when played back in certain 
> > decoders. I happen to see the exact same issue, but from some of the 
> > developers replies, I accept their position is that they feel ffmpeg is 
> > doing it the right way and its the decoders that are at fault.
> >
> > With that said, I’d like to approach this question purely from the point of 
> > view of finding out whether there is a way to tweak a command in order to 
> > change this way the aac stream is created to produce an mp4 or mov file 
> > using the native aac encoder which decodes in Quicktime 7 or X, in sync. 
> > Currently an encoded file plays back 1 frame out of sync (audio is early by 
> > approx. 1 frame). In VLC its about 1/2 a frame out of sync.
> >
> > The source file is a .mov, DNx115 24p (true 24p, not 23.976), PCM 24bit 
> > 48khz audio, which is in sync. This is film material where sync is crucial 
> > and always expected.
> >
> > Here is the basic command to reproduce. I have attached the uncut loglevel 
> > 99 console output for this command:
> > ffmpeg -i SyncTest24p.mov -c:v libx264 -pix_fmt yuv420p -movflags faststart 
> > -c:a aac -b:a 128k ffmpeg.mp4
>
> Can you try:
>
> -filter:a aresample=first_pts=0

Thanks for your reply and these options to test. This first one does not appear 
to change the outcome. ffprobe for ffmpeg_v2 attached.

> Also, when you run with -v verbose, you'll see a delay (depends
> on audio codec), for you case it's probably 1024. Maybe try:
>
> -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>
> Especially the latter could be exactly the wrong thing for your
> purpose, but it doesn't hurt trying.

1024 looks correct. This method successfully changes the start, and the encoded 
audio plays, almost, 100% in sync. Its slightly cut off at the head, but only 
very slightly. However the downside of this method is that the audio now 
overruns the end of the picture further and is not trimmed from remaining 
samples I’m guessing. This results in a blank video frame being added to the 
tail of clip. ffprobe for ffmpeg_v3 attached
.

I tried using -shortest, but that didn’t help address the above issue.

Last audio packet of original encode is:

[PACKET]
codec_type=audio
stream_index=1
pts=95232
pts_time=1.984000
dts=95232
dts_time=1.984000
duration=768
duration_time=0.016000
convergence_duration=N/A
convergence_duration_time=N/A
size=313
pos=24058
flags=K_
[/PACKET]

Last packet of encode using '-filter:a 
aresample=first_pts=0,asetpts=PTS-STARTPTS+1024’ is:

[PACKET]
codec_type=audio
stream_index=1
pts=96256
pts_time=2.005333
dts=96256
dts_time=2.005333
duration=800
duration_time=0.016667
convergence_duration=N/A
convergence_duration_time=N/A
size=313
pos=24038
flags=K_
[/PACKET]
ffprobe -select_streams a:0 -show_packets ffmpeg_v2.mp4
ffprobe version N-85343-gd0a3143-tessus Copyright (c) 2007-2017 the FFmpeg 
developers
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg 
--extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl 
--enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm 
--enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb 
--enable-libopencore-amrwb --enable-libopus --enable-libschroedinger 
--enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora 
--enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx 
--enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs 
--enable-libxvid --enable-libzmq --enable-libzvbi --enable-version3 
--disable-ffplay --disable-indev=qtkit
  libavutil  55. 60.100 / 55. 60.100
  libavcodec 57. 92.100 / 57. 92.100
  libavformat57. 72.100 / 57. 72.100
  libavdevice57.  7.100 / 57.  7.100
  libavfilter 6. 84.100 /  6. 84.100
  libswscale  4.  7.100 /  4.  7.100
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
Input #0, 

Re: [FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

[Christian Ebert]

* Mark Burton on Friday, April 14, 2017 at 16:57:06 +0100
> I appreciate this is a tricky area and there appear to be different ways that 
> some encoders create AAC streams with regards to the padding and remaining 
> samples etc. I won’t pretend to fully understand all the factors, but I would 
> like to ask a genuine question which purely comes from the point of view of 
> wanting to create a file for my working environment - an environment 
> dominated by Quicktime 7 and X playback / decoding tools. I’m no great fan of 
> Quicktime and appreciate its not well loved here also. In my industry it is 
> still very much the defecto playback engine though, so if I’m able to tailor 
> a file for this decoder, it would be an enormous help.
> 
> Let me also say, I am not accusing ffmpeg of having an issue, I have read a 
> number of ‘bug’ reports surrounding ffmpeg and AAC priming and there being a 
> sync discrepancy in the resultant encode when played back in certain 
> decoders. I happen to see the exact same issue, but from some of the 
> developers replies, I accept their position is that they feel ffmpeg is doing 
> it the right way and its the decoders that are at fault.
> 
> With that said, I’d like to approach this question purely from the point of 
> view of finding out whether there is a way to tweak a command in order to 
> change this way the aac stream is created to produce an mp4 or mov file using 
> the native aac encoder which decodes in Quicktime 7 or X, in sync. Currently 
> an encoded file plays back 1 frame out of sync (audio is early by approx. 1 
> frame). In VLC its about 1/2 a frame out of sync.
> 
> The source file is a .mov, DNx115 24p (true 24p, not 23.976), PCM 24bit 48khz 
> audio, which is in sync. This is film material where sync is crucial and 
> always expected.
> 
> Here is the basic command to reproduce. I have attached the uncut loglevel 99 
> console output for this command:
> ffmpeg -i SyncTest24p.mov -c:v libx264 -pix_fmt yuv420p -movflags faststart 
> -c:a aac -b:a 128k ffmpeg.mp4

Can you try:

-filter:a aresample=first_pts=0

Also, when you run with -v verbose, you'll see a delay (depends
on audio codec), for you case it's probably 1024. Maybe try:

-filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024

Especially the latter could be exactly the wrong thing for your
purpose, but it doesn't hurt trying.

-- 
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies   --->>> https://blacktrash.org/underdogma
http://itunes.apple.com/podcast/underdogma-movies/id363423596
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".