Recherche avancée

Sur d’autres sites (6850)

• FFMPEG, want to encode 720x480 and automatically scale to 640x480 or 854x480 as necessary depending on the ratio

  2 décembre 2023, par boxylogan

  EDIT : See appended notes at the bottom of the post.

  


  Note : all MKVs are sourced from my original Farscape Starburst DVDs, MPEG2.
I've been slowly re-encoding my old TV shows into a crisper format and I have for some shows, mainly extras (but also full episodes) MKVs that are a mix of 4:3 and 16:9. Usually I open the files up in Mediainfo and find out which ones are 4:3, stick them in one folder to encode in 640x480, then the same with 16:9. It's worked fine for the umpteen amount of times I've had to encode my shows.
I would like to try to expedite the process with a single FFMPEG command that can automatically detect if the files are 4:3 or 16:9 and encode them properly to 640x480 or 854x480.

  


  My main FFMPEG commands have been these two, depending on which aspect ratio I'm using :

  


  854x480p

  


  `for i in *.mkv; do ffmpeg -i "$i" -c:v libx264 -profile:v main -level:v 4.0 -crf 20 -c:a copy -map 0 -vf scale=854:480,setdar=16/9 encoded/"${i%.mkv}.mkv"; done


  


  640x480p

  


  `for i in *.mkv; do ffmpeg -i "$i" -c:v libx264 -profile:v main -level:v 4.0 -crf 20 -c:a copy -map 0 -vf scale=640:480,setdar=4/3 encoded/"${i%.mkv}.mkv"; done


  


  These two have worked fine lately since I got away from the extraneous -x264-params nonsense I picked up years ago. Again, I'm trying to streamline. I found this command a day ago and it SEEMED to look PERFECT :

  


  `for i in *.mkv; do ffmpeg -i "$i" -c:v libx264 -profile:v main -level:v 4.0 -crf 20 -c:a copy -map 0 -vf scale=w='if(gt(dar,854/480),min(854,iw*sar),2*trunc(iw*sar*oh/ih/2))':h='if(gt(dar,854/480),2*trunc(ih*ow/iw/sar/2),min(480,ih))' encoded/"${i%.mkv}.mkv"; done


  


  Looks perfect and works great for 640x480. The only problem is that it returns 852x480, every time. I even tried a modification I found where you set the setsar=1 AFTER the scale filter, and it does nothing.

  


  These are the first warnings I get when I try to run the command, with a 16:9 video, but it still completes :

  


  `[Parsed_scale_0 @ 0x56299c22fcc0] Circular references detected for width 'if(gt(dar, 854/480), min(854,iw*sar), 2*trunc(iw*sar*oh/ih/2))' and height 'if(gt(dar, 854/480), 2*trunc(ih*ow/iw/sar/2), min(480,ih))' - possibly invalid.
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[Parsed_scale_0 @ 0x56299c20e5c0] Circular references detected for width 'if(gt(dar, 854/480), min(854,iw*sar), 2*trunc(iw*sar*oh/ih/2))' and height 'if(gt(dar, 854/480), 2*trunc(ih*ow/iw/sar/2), min(480,ih))' - possibly invalid.


  


  It encodes and I can see the resolution it outputs to :

  


  `Stream #0:0(eng): Video: h264 (H264 / 0x34363248), yuv420p(tv, top coded first (swapped)), 852x480 [SAR 1:1 DAR 71:40], q=2-31, 29.97 fps, 1k tbn


  


  The next video is a 4:3 video and gives these warnings, however the video still completes, this time the video encodes properly to 640x480 :your text

  


  `[Parsed_scale_0 @ 0x5623084d4140] Circular references detected for width 'if(gt(dar, 854/480), min(854,iw*sar), 2*trunc(iw*sar*oh/ih/2))' and height 'if(gt(dar, 854/480), 2*trunc(ih*ow/iw/sar/2), min(480,ih))' - possibly invalid.
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (copy)`your text`
Press [q] to stop, [?] for help
[Parsed_scale_0 @ 0x5623084d7080] Circular references detected for width 'if(gt(dar, 854/480), min(854,iw*sar), 2*trunc(iw*sar*oh/ih/2))' and height 'if(gt(dar, 854/480), 2*trunc(ih*ow/iw/sar/2), min(480,ih))' - possibly invalid.


  


  The output details :

  


  `Stream #0:0(eng): Video: h264 (H264 / 0x34363248), yuv420p(tv, top coded first (swapped)), 640x48 [SAR 1:1 `your text`DAR 4:3], q=2-31, 29.97 fps, 1k tbn


  


  TL ;DR

  


  EDIT : The actual problem is that the command is encoding the 16:9 aspect ratio files to 852x480 instead of 854x480. 854x480 is actually what I would like. 640x480 for the 4:3 is fine. Apologies, for the lack of clarification.

  


  Videos encode (from original Farscape Starburst DVDs MPEG2) properly to libx264 640x480 for 4:3 but not to 854x480 for 16:9. 16:9 instead encodes to 852x480, despite what command is telling it to do.

  


  Advice ? Thanks in advance ! Anything to make my re-encoding a little bit less tedious. I've been googling for hours and searching, but nothing seems to make it click. Thank you again !

  


• fftools/ffmpeg : remove deprecated -[av]bsf

  18 décembre 2023, par Anton Khirnov

  fftools/ffmpeg : remove deprecated -[av]bsf
  They were marked as deprecated over 10 years ago.
  

  • [DH] doc/ffmpeg.texi
  • [DH] fftools/ffmpeg_opt.c

• ffmpeg memory leak when opening libx264 encoder

  18 octobre 2023, par ksb496

  I have spotted a memory leak issue when I use the libx264 encoder in the FFmpeg C API. Specifically, when it comes to deallocate memory after encoding a video. After tracking the factor that causes it, I realized that it happens after invoking avcodec_open2, which allocates some memory that afterwards cannot be freed. Once the video is processed, calling avcodec_close and then avcodec_free_context does not entirely free all the allocated memory.

  


  After some investigation, I found out that the problem could be located in AVCodecContext::priv_data being allocated but not being freed afterwards. In this question a solution to the issue is proposed. However, I tried to implement it without success (the memory being leaked seems to be exactly the same).

  


  As a matter of fact, the following simple code (which includes the patch that was proposed in the aforementioned question), in which the codec is being opened and closed multiple times without even writing a single frame or allocating an AVFormatContext, illustrates the memory leak.

  


  #include &#xA;extern "C"{&#xA;#include &#xA;#include <libavcodec></libavcodec>avcodec.h>&#xA;#include <libavutil></libavutil>opt.h>&#xA;}&#xA;&#xA;int main()&#xA;{&#xA;    avcodec_register_all();&#xA;&#xA;    AVCodec *codec;&#xA;    AVCodecContext *c;&#xA;    for (int n=0; n&lt;2000; n&#x2B;&#x2B;)&#xA;    {&#xA;        codec = avcodec_find_encoder_by_name("libx264");&#xA;        c=avcodec_alloc_context3(codec);&#xA;        c->pix_fmt=AV_PIX_FMT_YUV420P;&#xA;        c->width=1920;&#xA;        c->height=1080;&#xA;        c->time_base=(AVRational){1, 30};&#xA;        c->framerate=(AVRational){30, 1};&#xA;        avcodec_open2(c, codec, NULL);&#xA;        avcodec_close(c);&#xA;        av_opt_free(c->priv_data);&#xA;        av_freep(&amp;c->priv_data);&#xA;        avcodec_free_context(&amp;c);&#xA;    }&#xA;    return 0;&#xA;}&#xA;

  


  It must be remarked that if the line codec = avcodec_find_encoder_by_name("libx264") is replaced to an invocation to an internal/native encoder, e.g., codec = avcodec_find_encoder(AV_CODEC_ID_MPEG4), then the memory leak issue completely disappears. Hence, it certainly seems to be an issue related to some private data of the external encoder not being properly freed.

  


  It is also worth mentioning that I am using an old version of ffmpeg and libx264. To be more precise, ffmpeg version 2.8git and libx264 version 0.136.x. For technical reasons that are beyond the scope of this question, it is not possible to upgrade the libraries to newer versions onto the project in which these are being used. I am fully aware that most of the involved ffmpeg/libx264 code has been probably changed along the years and many functions became deprecated or fixed, and thus reporting this as a possible bug in the ffmpeg developer's mailbox is out of the question.

  


  Nevertheless, I am still asking this here because I would like to know whether it is just some mistake on my end and/or something I am not taking into account when it comes to free all the memory relative to an external encoder (best case scenario). Otherwise, I would like to know whether there can be some reasonably cheap solution through some custom code or function that can be implemented as a patch (assuming it is indeed an issue related to ffmpeg/libx264), no matter if it makes the whole deallocation code less elegant or concise. If someone is still working on these older versions of ffmpeg and can come up with a workaround, that would be highly appreciated.