[FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?
cus at passwd.hu
Tue Jun 20 00:38:29 EEST 2017
On Mon, 19 Jun 2017, Mark Burton wrote:
>> On 15 Apr 2017, at 13:25, Christian Ebert <blacktrash at gmx.net> 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.
>>> 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.
More information about the ffmpeg-user