Recherche avancée

Sur d’autres sites (10500)

• ffmpeg dash/hls wrong timestamp when using mp4, -ss, and -copyts

  6 décembre 2019, par user2114284

  I have noticed some inconsistencies with the output timestamp when using ffmpeg with the dash/hls muxers with mp4, -ss, and -coptyts and I am wondering if it is a bug or if I am just misunderstanding something about how ffmpeg is supposed to work.

  Here I seek 15 seconds in the input and use the copyts argument to copy the input timestamp :

  However, when checking the output with ffprobe, it shows the timestamps starting at 30 seconds, double what I would expect :

  ffmpeg -ss 15 -i big_buck_bunny_720p_10mb.mkv -to 30 -copyts -acodec aac -vcodec libx264 -f hls -hls_time 2 -hls_init_time 2 -hls_list_size 0 -hls_segment_type fmp4 out.m3u8
  
  
  
  cat init.mp4 out0.m4s | ffprobe -show_frames -pretty -
  
  
  
  [FRAME]
  
  media_type=video
  
  stream_index=0
  
  key_frame=1
  
  pkt_pts=384000
  
  pkt_pts_time=0:00:30.000000
  
  pkt_dts=384000
  
  pkt_dts_time=0:00:30.000000
  
  best_effort_timestamp=384000
  
  best_effort_timestamp_time=0:00:30.000000
  
  ...

  If I switch the hls_segment_type to mpegts, the timestamp shows around 15 seconds which I would expect :

  ffmpeg -ss 15 -i big_buck_bunny_720p_10mb.mkv -to 30 -copyts -acodec aac -vcodec libx264 -f hls -hls_time 2 -hls_init_time 2 -hls_list_size 0 -hls_segment_type mpegts out.m3u8
  
  
  
  ffprobe -i out0.ts -show_frames -pretty
  
  
  
  [FRAME]
  
  media_type=audio
  
  stream_index=1
  
  key_frame=1
  
  pkt_pts=1474080
  
  pkt_pts_time=0:00:16.378667
  
  pkt_dts=1474080
  
  pkt_dts_time=0:00:16.378667
  
  best_effort_timestamp=1474080
  
  best_effort_timestamp_time=0:00:16.378667
  
  ...

  I also see the timestamp being doubled when using -ss, -copyts, and mp4 with the dash muxer. Similarly, the dash muxer seems to output the correct timestamps when switched to webm.

  I have seen the same results with several different input files. Am I misunderstanding something about how ffmpeg works, or is this a bug somewhere in the mp4 segmenting ?

• configure : Mention the dash demuxer in the libxml2 help text.

  14 mai 2018, par Carl Eugen Hoyos

  configure : Mention the dash demuxer in the libxml2 help text.
  

  • [DH] configure

• movenc : Allow writing a DASH sidx atom at the start of files

  21 octobre 2014, par Martin Storsjö

  movenc : Allow writing a DASH sidx atom at the start of files
  This is mapped to the faststart flag (which in this case
  
  perhaps should be called "shift and write index at the
  
  start of the file"), which for fragmented files will
  
  write a sidx index at the start.
  When segmenting DASH into files, there’s usually one sidx
  
  at the start of each segment (although it’s not clear to me
  
  whether that actually is necessary). When storing all of it
  
  in one file, the MPD doesn’t necessarily need to describe
  
  the individual segments, but the offsets of the fragments can be
  
  fetched from one large sidx atom at the start of the file. This
  
  allows creating files for the DASH ISO BMFF on-demand profile.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/movenc.c
  • [DBH] libavformat/movenc.h