Recherche avancée

Sur d’autres sites (10333)

• cosmetics : Write NULL pointer equality checks more compactly

  14 août 2014, par Gabriel Dume

  cosmetics : Write NULL pointer equality checks more compactly
  Signed-off-by : Diego Biurrun <diego@biurrun.de>
  

  • [DH] avconv.c
  • [DH] avconv_opt.c
  • [DH] avplay.c
  • [DH] cmdutils.c
  • [DH] compat/getopt.c
  • [DH] libavcodec/atrac3.c
  • [DH] libavcodec/cook.c
  • [DH] libavcodec/dvbsub.c
  • [DH] libavcodec/dvdsubdec.c
  • [DH] libavcodec/dvdsubenc.c
  • [DH] libavcodec/dxa.c
  • [DH] libavcodec/h263dec.c
  • [DH] libavcodec/h264.c
  • [DH] libavcodec/h264_parser.c
  • [DH] libavcodec/h264_ps.c
  • [DH] libavcodec/h264_refs.c
  • [DH] libavcodec/huffyuvdec.c
  • [DH] libavcodec/interplayvideo.c
  • [DH] libavcodec/lcldec.c
  • [DH] libavcodec/libmp3lame.c
  • [DH] libavcodec/libxvid.c
  • [DH] libavcodec/libxvid_rc.c
  • [DH] libavcodec/motion_est.c
  • [DH] libavcodec/mpeg12dec.c
  • [DH] libavcodec/mpegaudiodec_template.c
  • [DH] libavcodec/mpegvideo.c
  • [DH] libavcodec/mpegvideo_enc.c
  • [DH] libavcodec/options.c
  • [DH] libavcodec/opus_celt.c
  • [DH] libavcodec/qdm2.c
  • [DH] libavcodec/roqvideo.c
  • [DH] libavcodec/rv10.c
  • [DH] libavcodec/tiffenc.c
  • [DH] libavcodec/tscc.c
  • [DH] libavcodec/utils.c
  • [DH] libavcodec/vc1dec.c
  • [DH] libavcodec/vp3.c
  • [DH] libavcodec/vp8.c
  • [DH] libavcodec/zmbv.c
  • [DH] libavcodec/zmbvenc.c
  • [DH] libavdevice/v4l2.c
  • [DH] libavformat/avs.c
  • [DH] libavformat/matroskadec.c
  • [DH] libavformat/matroskaenc.c
  • [DH] libavformat/movenc.c
  • [DH] libavformat/mpegts.c
  • [DH] libavformat/nsvdec.c
  • [DH] libavformat/rtpenc.c
  • [DH] libavformat/rtspdec.c
  • [DH] libavformat/rtspenc.c
  • [DH] libavformat/sdp.c
  • [DH] libavutil/eval.c
  • [DH] libavutil/internal.h

• Merge commit ’0b5a26e8bcd219efe5da3a6d39b588fabf91f2b9’

  3 avril 2017, par Clément Bœsch

  Merge commit ’0b5a26e8bcd219efe5da3a6d39b588fabf91f2b9’
  * commit ’0b5a26e8bcd219efe5da3a6d39b588fabf91f2b9’ : (35 commits)
  
    qdm2 : Convert to the new bitstream reader
  
    qcelp : Convert to the new bitstream reader
  
    pcx : Convert to the new bitstream reader
  
    opus : Convert to the new bitstream reader
  
    nellymoser : Convert to the new bitstream reader
  
    jvdec : Convert to the new bitstream reader
  
    hqx : Convert to the new bitstream header
  
    hq_hqa : Convert to the new bitstream reader
  
    gsm : Convert to the new bitstream reader
  
    g72x : Convert to the new bitstream reader
  
    g2meet : Convert to the new bitstream reader
  
    fraps : Convert to the new bitstream reader
  
    flashsv : Convert to the new bitstream reader
  
    faxcompr : Convert to the new bitstream reader
  
    exr : Convert to the new bitstream reader
  
    escape130 : Convert to the new bitstream reader
  
    escape124 : Convert to the new bitstream reader
  
    dvdsubdec : Convert to the new bitstream reader
  
    dss_sp : Convert to the new bitstream reader
  
    cook : Convert to the new bitstream reader
  
    ...
  This merge is a noop, see
  
  http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
  Merged-by : Clément Bœsch <u@pkh.me>
  

  • [DH] doc/libav-merge.txt

• FFmpeg segmentation and transcoding missing frames

  15 décembre 2022, par Davidec0018

  I code videos for hobbies and have a decent understanding of ffmpeg and mkvmerge. I prefer to encode video when my computer is on for other things as well, so I recently looked for a way that I could resume encoding after the computer was turned off.

  


  I tried a virtual machine, saving the whole state and it seems to work very well, but the performance is very slow and with the same settings the encoding time is much longer than normal.

  


  I then tried to divide the starting video into several segments, so as to resume from the appropriate segment after restarting the computer.

  


  I tried to do this with ffmpeg :

  


  ffmpeg -i input -map 0:v:0 -c copy -f segment -segment_time 300 -reset_timestamps 1 segment%03d.mkv


  


  But also with the mkvtoolnix gui.

  


  Both operations provide an excellent result.Trying to merge the segments into one video, with ffconcat or mkvtoolnix the result is perfect.

  


  The problem arises when segments are encoded. I use a simple script based on slow preset for every segment in loop (I use both windows and linux) :

  


  ffmpeg -i input.mkv -threads 0 -map 0 -c:a copy -c:s copy -preset slow -pix_fmt yuv420p10le -c:v libx265 -x265-params crf=18:bframes=8:aq-mode=2:aq-strength=1.0 output.mkv


  


  Putting them together in the same way, the video also looks quite good, and with the naked eye you don't notice the passage of the various segments, but analyzing them with ffmpeg I notice that the individual segments have slightly shorter durations and a different number of frames, even 2 or 3 less. When putting together very long videos, you notice even 2 seconds of difference with the original, which also causes the audio and subtitles to go into desynch.

  


  I know the problem has to do with keyframes, timestamps and stuff like that. But I don't understand why. FFmpeg, as well as mkvmerge should split the video exactly where the keyframes are, about 300 seconds apart, so as not to mess up the video structure and allow for good encoding and reassembling.

  


  The problem is just encoding with ffmpeg that removes some frames from the original segments. Sometimes I noticed during the encoding of some segments the following error code, or maybe warning, because the encoding worked anyway :

  


  [hevc @ 0x55758bf92dc0] First slice in a frame missing.
    Last message repeated 6 times
[hevc @ 0x55758c2000c0] First slice in a frame missing.


  


  I've read every discussion about it on the net, I've tried to segment both with mp4 and mkv format, with and without audio, but the problem remains. Where am I doing wrong ?