Recherche avancée

Sur d’autres sites (3838)

• avutil/avutil : make AV_TIME_BASE_Q available in C++

  18 septembre 2023, par Zhao Zhili

  avutil/avutil : make AV_TIME_BASE_Q available in C++
  ISO C++ forbids compound-literals. It's not available with MSVC.
  
  This is a known issue from 10 years ago, and that's why there is a
  
  av_get_time_base_q().
  Since we have no plan to remove AV_TIME_BASE_Q, just make it
  
  available in C++.
  There are multiple choices :
  
  1. Use C++11 syntax : AVRational1, AV_TIME_BASE
  Users may still use C++98 to write new code. So no.
  2. Use av_get_time_base_q().
  It's for this purpose. But it's not compile time constants as
  
  AV_TIME_BASE_Q in C.
  So I choose av_make_q() as Anton's suggestion.
  https://libav-devel.libav.narkive.com/ZQCWfTun/patch-0-2-fix-avutil-h-usage-from-c
  
  Signed-off-by : Zhao Zhili <zhilizhao@tencent.com>
  

  • [DH] doc/APIchanges
  • [DH] libavutil/avutil.h
  • [DH] libavutil/version.h

• configure : rework parsing —cpu arguments to support all features unless blacklisted

  17 septembre 2023, par James Almer

  configure : rework parsing —cpu arguments to support all features unless blacklisted
  Keeping an ever growing list of CPUs just to pass -march to the compiler and
  
  enable fast_cmov is a waste of time. Every CPU we know has limitations is
  
  already handled here, so just fallback to enabling everything when a passed in
  
  argument is not one of those.
  This will enable optimizations for CPU architectures released in the past 7 or
  
  so years with supported GCC and clang compilers when used as argument in
  
  configure, instead of silently ignoring them.
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] configure

• Aspect ratio problems at transcoding with ffmpeg [closed]

  19 novembre 2023, par udippel

  I have a huge collection of videos from the last 20+ years, videos in all sorts of formats. I use gerbera as open source UPnP-AV media server. Our TV handles only very limited of these formats. Therefore I use the transcoding feature of gerbera (I don't want to convert the 2000+ files ; thereby avoiding loss of multiple audio tracks, (multiple) subtitles, and so forth).

  


  This is my current unified argument line for ffmpeg :
-c:v mpeg2video -maxrate 20000k -vf setdar=16/9 -r 24000/1001 -qscale:v 4 -top 1 -c:a mp2 -f mpeg -y
It works pretty okay, except of the aspect ratios. Well, I don't understand this fully, because ffprobe for File A states :
Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 624x464 [SAR 1:1 DAR 39:29], 1500 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
This file displays very well.
File B comes as :
Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 960x720, SAR 1:1 DAR 4:3, 23.98 fps, 23.98 tbr, 1k tbn, 180k tbc (default)
This file displays horribly squeezed vertically and doesn't fill the screen left and right neither, with the same settings of the TV. Also, playing this file (and others, naturally) the TV doesn't offer the 14:9 display option, which is available e.g. for the file further up.

  


  Both have same SAR, DAR, almost identical H:V ratios (1.345, 1.333) ; and almost identical DAR.

  


  My questions :

  


  

  1. Why, despite of almost identical pixel ratios, DAR and SAR are these files handled so differently in one and the same session on the same TV (SONY), please ?

  


  2. With which method could I instruct ffmpeg to display the second file properly, too, please ?
(I have already tried 'scale' ; but to no avail. Which could have been foreseen, since the ratios are already very close.)
My guess is, that the (tv, bt709, progressive) mess things up.
(I have already tried to add the yuv420p in the argument line, also to no avail.)

  


  


  Appreciate any help,

  


  Uwe

  


  I have already tried to add a 'scale' option ; but to no avail. Which could have been foreseen, since the ratios are already very close.
I have already tried to add the yuv420p in the argument line, also to no avail.
I have already tried force_original_aspect_ratio, but also here, nothing improving.
Also, I played with -aspect, but the aspects are okay, and would need individual corrections, which I can't and don't to do for 2000+ files. A simple 16:9 doesn't cut it.