On 23 May 2017, at 11:20, Christian Ebert <[email protected]> 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
>>
>> <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
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
