Recherche avancée

Sur d’autres sites (5504)

• ulti : invert the order of parameters of ulti_decode_frame()

  18 décembre 2014, par Vittorio Giovara

  ulti : invert the order of parameters of ulti_decode_frame()
  This is the order that the caller uses in the rest of the file.
  
  Variables are modified to reflect the order above too and their
  
  initialization is merged with their declarationt. No behavioral
  
  change.
  Bug-Id : CID 732286
  

  • [DBH] libavcodec/ulti.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 ?

• movenc : Add an option for delaying writing the moov with empty_moov

  3 novembre 2014, par Martin Storsjö

  movenc : Add an option for delaying writing the moov with empty_moov
  This delays writing the moov until the first fragment is written,
  
  or can be flushed by the caller explicitly when wanted. If the first
  
  sample in all streams is available at this point, we can write
  
  a proper editlist at this point, allowing streams to start at
  
  something else than dts=0. For AC3 and DNXHD, a packet is
  
  needed in order to write the moov header properly.
  This isn’t added to the normal behaviour for empty_moov, since
  
  the behaviour that ftyp+moov is written during avformat_write_header
  
  would be changed. Callers that split the output stream into header+segments
  
  (either by flushing manually, with the custom_frag flag set, or by
  
  just differentiating between data written during avformat_write_header
  
  and the rest) will need to be adjusted to take this option into use.
  For handling streams that start at something else than dts=0, an
  
  alternative would be to use different kinds of heuristics for
  
  guessing the start dts (using AVCodecContext delay or has_b_frames
  
  together with the frame rate), but this is not reliable and doesn’t
  
  necessarily work well with stream copy, and wouldn’t work for getting
  
  the right initialization data for AC3 or DNXHD either.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/movenc.h
  • [DH] libavformat/version.h