[FFmpeg-trac] #3859(undetermined:new): mp4: start_time never zero

FFmpeg trac at avcodec.org
Mon Oct 13 13:10:48 CEST 2014


#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


More information about the FFmpeg-trac mailing list