* Mark Burton on Monday, May 22, 2017 at 15:22:34 +0100
> On 15 Apr 2017, at 09:22, Christian Ebert <[email protected]> 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
>
> <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
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
