#3859: mp4: start_time never zero
-------------------------------------+-------------------------------------
Reporter: blacktrash | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: git-master | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by blacktrash):
Replying to [comment:15 cehoyos]:
> Do I understand correctly that the issue is not reproducible with the
native aac encoder?
No, as I've shown in https://trac.ffmpeg.org/ticket/3859#comment:13 the
problem is present with all aac encoders. It just varies how pronounced it
is. According to Martin it has to be that way: http://sourceforge.net/p
/opencore-amr/mailman/message/32912765/
From a practical POV the results are almost random, see:
http://sourceforge.net/p/opencore-amr/mailman/message/32912560/ resulting
in over 2 seconds extra duration ...
So I guess I have to butcher around with atrim in practice to get sort of
well behaved HLS streams. Trying to get clarity that I am able to
understand is a bit like being sent from Pontius to Pilates and back ;-)
iTunes gives best result regarding start_time and duration:
http://sourceforge.net/p/opencore-amr/mailman/message/32913564/ (start
time 0, duration + ~0.1) but maybe this will result in more actual async,
I don't know.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/3859#comment:16>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
