Sur d’autres sites (8114)

• Libav Transcoding to H264 : Frames being dropped

  21 juin 2014, par roman

  I’m sorry if my question isn’t too well formulated, I’m only now getting started with FFmpeg and Libav. I’m not too knowledgable about media formats either, I pretty much learned all I know about the topic this past month. I’ve been doing as much research as I can, and have gotten pretty far, but I’ve only now gotten to the point where I’m almost unsure what my question actually is ! These are more like observations, but hopefully some of the experts can help me out here.

  I’m trying to transcode Gifs into MP4s using FFmpeg’s libraries, but I’m running into a strange issue when using the H264 Codec. In my transcoding loop, I keep a count of the number of frames that I write out (by verifying the return value of av_write_frame). In a particular sample, I count a total of 166 frames written out. If I examine FFmpeg’s converted file using FFprobe (the functionality I’m wanting to emulate using my program, a conversion from Gif to MP4), FFmpeg’s output file also seems to have 166 frames, but when I examine my output with FFprobe, I seem to only have 144 frames. What I find a bit interesting is that if I simply change my codec from H264 to MPEG4, my output appears to have the 166 frames, matching FFmpeg’s output and my counter. I get very similar results with different Gif files, where my counter of frames written matches FFmpeg’s output’s frame count, but my output seems to drop some frames.

  Encoder settings :

  ostream_codec_context->codec_id = CODEC_IN_USE;  //CODEC_ID_H264 or CODEC_ID_MPEG4
  
  ostream_codec_context->pix_fmt = AV_PIX_FMT_YUV420P;
  
  ostream_codec_context->codec_type = AVMEDIA_TYPE_VIDEO;
  
  ostream_codec_context->flags = CODEC_FLAG_GLOBAL_HEADER;
  
  ostream_codec_context->profile = FF_PROFILE_MPEG4_SIMPLE;
  
  
  
  ostream_codec_context->gop_size = istream_codec_context->gop_size;
  
  ostream_codec_context->time_base = istream_codec_context->time_base;
  
  
  
  ostream_codec_context->width  = (istream_codec_context->width  / 2) * 2;
  
  ostream_codec_context->height = (istream_codec_context->height / 2) * 2;    

  Transcoding loop :

  I’ve omitted some error-checking code and debugging statements

  avformat_write_header(oformat_context, NULL);
  
  while (av_read_frame(iformat_context, &packet) == 0 ) 
  
  {
  
     if (packet.stream_index == istream_index) 
  
     {   
  
        avcodec_decode_video2(istream_codec_context, ipicture, &full_frame, &packet);
  
        if (full_frame) 
  
        {
  
           sws_scale(image_conversion_context, 
  
                     (uint8_t const * const *) ipicture->data,
  
                     ipicture->linesize, 0, istream_codec_context->height,
  
                     opicture->data, opicture->linesize);
  
  
  
           opicture->pts = av_rescale_q(packet.pts, istream_codec_context->time_base,
  
                                        ostream->time_base);
  
  
  
           ret = avcodec_encode_video2(ostream_codec_context, &packet, 
  
                                       opicture, &got_packet);
  
           if (!ret)
  
           {
  
              ret = av_write_frame(oformat_context, &packet);
  
              if (ret < 0)
  
                 num_frames_written++;
  
           }
  
        }
  
     }
  
     av_free_packet(&packet);
  
     av_init_packet(&packet);
  
  }

  I’m also having issues with my output’s bit-rate. I can try setting it with the rest of my encoder settings, but the bit-rate that FFprobe shows is not the same as what I give the codec context. I tried setting the bit-rate to constant values just to see how it affected my output, and although my output’s bit-rate isn’t the same as what I give it, I found that my input definitely seems to influence the output’s actual bit-rate. I found a post that seems to be dealing with my issue, but the solution listed there does not seem to fix my issue.

  http://ffmpeg.org/pipermail/libav-user/2012-July/002492.html

  Another thing worth mentioning is that my various time bases don’t seem to match up with those of FFmpeg’s output. Notably, my output’s TBC seems to be twice the inverse of my output codec context’s time base. I’m not too sure if this is an issue with the Gif file format, my output codec context’s always seems to be set to 1/100.

  Bit-rate calculation and setting

  int calculated_br = istream_codec_context->time_base.den *     
  
                      avpicture_get_size(AV_PIX_FMT_YUV420P, ostream_codec_context->width, 
  
                                         ostream_codec_context->height);    
  
  
  
  ostream_codec_context->bit_rate = calculated_br;
  
  ostream_codec_context->rc_min_rate = calculated_br;
  
  ostream_codec_context->rc_max_rate = calculated_br;
  
  ostream_codec_context->rc_buffer_size = calculated_br;

  I’ve got a hunch that all these issues could be related to me not setting my PTS/DTS correctly, even though my output’s pts/dts values match those of FFmpeg’s output.

  I would appreciate some help,
  Thank you !

• Reducing the Quality Loss experienced on Videos when applying Bicubic Interpolation when Upscaling ? [closed]

  9 mai 2024, par Solomon Williams

  VMAF Quality Loss when applying bicubic interpolation to a video when upscaling with ffmpeg

  


  First of all, I'm a bit of a beginner to this specific topic therefore any advice would be greatly appreciated !

  


  For a project that I've currently been working on, I've been essentially trying to simulate the requirement to downscale/upscale resolution when transmitting video files using ffmpeg. During this process, I have found that whenever I've needed to upscale resolution on a transcoded file via bicubic interpolation, the resultant video will have lost more VMAF quality (around 10-20 points to be precise) than would be expected.

  


  My questions are as follows : Can this problem be prevented/mitigated at all, and if so how would I do so ? If not, are there any ways to potentially get around this or better ways to retain the inherent VMAF quality of the underlying transcoded video file when upscaling to client side ?

  


  I have tried to distil the problem down into a simplified format by isolating the specific effect of bicubic interpolation on a video that doesn't change it's resolution (i.e stays at 1080p). I've also attached a little visual diagram to hopefully better represent what I'm describing.enter image description here

  


  For example, I might start with an original 1080p '.mov' file on which I'll perform two initial transcodes : 1 to create a Reference (1Mbit/s, 1080p) file for VMAF calculation, and another to create a demo Transcode file with the same exact specifications (1Mbits, 1080p again) for which I intend to upscale. I then "upscale" my demo Transcode file using bicubic interpolation to 1080p which I'll call Upscaled demo Transcode (I get that not changing the resolution is not technically upscaling). Finally, I calculate VMAF between my Reference and Upscaled demo Transcode, such that these two files are literally the same other than applying bicubic interpolation to the latter :

  


  ffmpeg -y -i **ORIGINAL.mov** -vf "fps=25, scale=1920:1080, format=yuv420p, yadif" -c:v vp8 -b:v 1M **REFERENCE_file.mkv**

ffmpeg -y -i ORIGINAL.mov -vf "fps=25, scale=1920:1080, format=yuv420p, yadif" -c:v vp8 -b:v 1M  **DEMO_TRANSCODE.mkv**
                
ffmpeg -i DEMO_TRANSCODE.mkv -vf "fps=25, scale=1920:1080:*flags=bicubic*, format=yuv420p" -c:v vp8 -b:v 1M **UPSCALED_DEMO_TRANSCODE.mkv**

(VMAF) ffmpeg -i **UPSCALED_DEMO_TRANSCODE.mkv** -i **REFERENCE_file.mkv** -filter_complex libvmaf -f null - 


  


  You would expect VMAF to be output 95-97 but instead inexplicably I'm getting values of anywhere from 70-85 (presumably dependant on video length/content).

  


  While I've purposely kept 1080p the same here, in reality I would usually downscale to a lower res such as (240p, 480p, 720p etc) in the first transcode and then upscale back to 1080p for the second but I've purposely used this example to better illustrate the effect I'm describing.

  


• avformat/matroskadec : Free right buffer on error

  3 mai 2020, par Andreas Rheinhardt

  avformat/matroskadec : Free right buffer on error
  Since commit 979b5b89594c7628bd846c63198cb64ef9d81d16, reverting the
  
  Matroska ContentCompression is no longer done inside
  
  matroska_parse_frame() (the function that creates AVPackets out of the
  
  parsed data (unless we are dealing with certain codecs that need special
  
  handling)), but instead in matroska_parse_block(). As a consequence,
  
  the data that matroska_parse_frame() receives is no longer always owned
  
  by an AVBuffer ; it is owned by an AVBuffer iff no ContentCompression needed
  
  to be reversed ; otherwise the data is independently allocated and needs
  
  to be freed on error.
  Whether the data is owned by an AVBuffer or not is indicated by a variable
  
  buf of type AVBufferRef * : If it is NULL, the data is independently
  
  allocated, if not it is owned by the underlying AVBuffer (and is used to
  
  avoid copying the data when creating the AVPackets).
  Because the allocation of the buffer holding the uncompressed data happens
  
  outside of matroska_parse_frame() (if a ContentCompression needs to be
  
  reversed), the data is passed as uint8_t ** in order to not leave any
  
  dangling pointers behind in matroska_parse_block() should the data need to
  
  be freed : In case of errors, said uint8_t ** would be av_freep()'ed in
  
  case buf indicated the data to be independently allocated.
  Yet there is a problem with this : Some codecs (namely WavPack and
  
  ProRes) need special handling : Their packets are only stored in
  
  Matroska in a stripped form to save space and the demuxer reconstructs
  
  full packets. This involved allocating a new, enlarged buffer. And if
  
  an error happens when trying to wrap this new buffer into an AVBuffer,
  
  this buffer needs to be freed ; yet instead the given uint8_t ** (holding
  
  the uncompressed, yet still stripped form of the data) would be freed
  
  (av_freep()'ed) which certainly leads to a memleak of the new buffer ;
  
  even worse, in case the track does not use ContentCompression the given
  
  uint8_t ** must not be freed as the actual data is owned by an AVBuffer
  
  and the data given to matroska_parse_frame() is not the start of the
  
  actual allocated buffer at all.
  Both of these issues are fixed by always freeing the current data in
  
  case it is independently allocated. Furthermore, while it would be
  
  possible to track whether the pointer from matroska_parse_block() needs
  
  to be reset or not, there is no gain in doing so, as the pointer is not
  
  used at all afterwards and the sematics are clear : If the data passed
  
  to matroska_parse_frame() is independently allocated, then ownership
  
  of the data passes to matroska_parse_frame(). So don't pass the data
  
  via uint8_t **.
  Fixes Coverity ID 1462661 (the issue as described by Coverity is btw
  
  a false positive : It thinks that this error can be triggered by ProRes
  
  with a size of zero after reconstructing the original packets, but the
  
  reconstructed packets can't have a size of zero).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c