Recherche avancée

Sur d’autres sites (5657)

• sidxindex : Don’t adjust the Period start time depending on the track start time

  28 novembre 2014, par Martin Storsjö

  sidxindex : Don’t adjust the Period start time depending on the track start time
  This was only necessary to get playback to start with dash.js 1.2.0,
  
  it has been fixed in the git version.
  The previous behaviour was incorrect - the Period’s start time
  
  is irrespective of the actual first timestamp of the contents
  
  within the period. The Period start time only says when, within the
  
  global timeline, this particular piece should start to be played
  
  back.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tools/sidxindex.c

• Is it possible to generate a keyframe to start a spliced H.264 video segment ?

  3 janvier 2015, par Ethan T

  When segmenting files with ffmpeg, I am currently only able to splice on keyframe boundaries if I don’t want to reencode. This presents issues if I want to control timing down to a specific frame. To my knowledge, you can only start on a keyframe if you’re performing a stream copy. If you want to start on an arbitrary frame, you must reencode.

  However, for codecs that ffmpeg understands (like H.264), it seems like it would be technically possible to replace the desired first frame with a newly created keyframe without reencoding the rest of the video. This would represent a "smart copy" sort of behavior. For example, say my video consists of these frames and types :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Frame type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Keyframes:     ^            ^            ^

  (I frames are keyframes while p and b frames are not)

  Currently, if I want to remove the first few frames and start on exactly frame 20, I must reencode the entire stream beginning with that input frame. This would cause an undesired degradation in quality. Instead, if I perform a copy, ffmpeg would begin at the most recent keyframe :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Frame type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Desired start:                     ^
  
  Actual start:               ^

  Why can’t ffmpeg seek to frame 13 (the last complete keyframe prior to the cut point), fully calculate frame 20, and recreate frame 20 as an I frame ? It would then copy the remaining frames as before. Like this :

  Frame number:  0         1         2         3
  
                 0123456789012345678901234567890123
  
  Input type:    IppbppbppbppbIppbppbppbppbIppbppbp
  
  Output type:                       IpbppbIppbppbp

  It seems like this would be a very useful feature for splicing videos without losing quality. Is there any technical barrier (e.g. the H.264 spec or any other common codec) that prevents this approach ?

• mpegts : relax restrictions on matching the packet start in read_header

  4 février 2015, par Anton Khirnov

  mpegts : relax restrictions on matching the packet start in read_header
  analyze() is currently called both when probing and from read_header().
  
  It determines the packet start by looking for the sync byte, followed by
  
  unset Transport Error Indicator and valid adaptation_field_control.
  This makes sense to do when probing, but once we already know the format
  
  is MPEG-TS, it is counterproductive to be so strict — e.g. in some
  
  files the TEI might be set and analyze() might get called with a smaller
  
  buffer than the one used for probing, resulting in a failure.
  

  • [DBH] libavformat/mpegts.c