Recherche avancée

Sur d’autres sites (4578)

• lavc/libopenh264 : Drop openh264 runtime version checks

  9 décembre 2023, par Kalev Lember

  lavc/libopenh264 : Drop openh264 runtime version checks
  With the way the runtime checks are currently set up, every single
  
  openh264 release, no matter how minor, is considered an ABI break and
  
  requires ffmpeg recompilation. This is unnecessarily strict because it
  
  doesn't allow downstream distributions to ship any openh264 bug fix
  
  version updates without breaking ffmpeg's openh264 support.
  Years ago, at the time when ffmpeg's openh264 support was merged,
  
  openh264 releases were done without a versioned soname (the library was
  
  just libopenh264.so, unversioned). Since then, starting with version
  
  1.3.0, openh264 has started using versioned sonames and the intent has
  
  been to bump the soname every time there's a new release with an ABI
  
  change.
  This patch drops the exact version check and instead adds a minimum
  
  requirement on 1.3.0 to the configure script.
  Signed-off-by : Kalev Lember <klember@redhat.com>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] configure
  • [DH] libavcodec/libopenh264.c
  • [DH] libavcodec/libopenh264.h
  • [DH] libavcodec/libopenh264dec.c
  • [DH] libavcodec/libopenh264enc.c

• How to "mimic" -c copy when using filters with ffmpeg ? Is there a built-in feature or I'll need some scripting ? [closed]

  29 décembre 2023, par Fabio Freitas

  I'm aware that any stream ffmpeg processes is decoded before applying any desired changes and then re-encoded, which means the stream in question can't simply be copied with -c copy.

  


  Still, I'm not yet very knowledgeable on dealing with media files. Currently, the single issue I'm addressing is cropping black bars from the sides when 4:3 is encoded as 16:9.

  


  That's fairly simple, and I quickly managed to get it going.

  


  Then I noticed some weird stuff via mediainfo and the explorer's side panel. Stream sizes, bitrates and some other details were different than expected.

  


  ---

  


  That's where -c copy comes in. Over the years, every time I tried to solve this, answers would stop at "-c copy can't be used if the stream will be decoded", which is good enough to stop noobs like me from wasting time.

  


  But since I don't know how to use advanced encoding settings, the -c copy I'm looking for is actually how can I re-encode my processed stream using the same (or most similar) settings used before I decoded it.

  


  Is there such an option in ffmpeg ? Are these settings I'm looking for even obtainable by any means ? And if "no" and "yes", could I use ffprobe to write a script for ffmpeg ?

  


  BTW, I'm on Windows 11, but I have Git's SCM tools available.

  


• libavformat : add RCWT closed caption muxex

  14 janvier 2024, par Marth64

  libavformat : add RCWT closed caption muxex
  Signed-off-by : Marth64 <marth64@proxyid.net>
  Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
  
  used open source tool for processing 608/708 closed caption (CC) sources.
  
  It can be used to archive the original, raw CC bitstream and to produce
  
  a source file file for later CC processing or conversion. As a result,
  
  it also allows for interopability with ccextractor for processing CC data
  
  extracted via ffmpeg. The format is simple to parse and can be used
  
  to retain all lines and variants of CC.
  A free specification of RCWT can be found here :
  
  https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
  
  This muxer implements the specification as of 01/05/2024, which has
  
  been stable and unchanged for 10 years as of this writing.
  This muxer will have some nuances from the way that ccextractor muxes RCWT.
  
  No compatibility issues when processing the output with ccextractor
  
  have been observed as a result of this so far, but mileage may vary
  
  and outputs will not be a bit-exact match.
  Specifically, the differences are :
  
  (1)  This muxer will identify as "FF" as the writing program identifier, so
  
  as to be honest about the output's origin.
  (2)  ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
  
  data differently than ccextractor from embedded SEI/user data.
  
  For example, DVD captioning bytes will be translated to ATSC A53 format.
  
  This allows ffmpeg to handle 608/708 in a consistant way downstream.
  
  This is a lossless conversion and the meaningful data is retained.
  (3)  This muxer will not alter the extracted data except to remove invalid
  
  packets in between valid CC blocks. On the other hand, ccextractor
  
  will by default remove mid-stream padding, and add padding at the end
  
  of the stream (in order to convey the end time of the source video).
  

  • [DH] Changelog
  • [DH] doc/muxers.texi
  • [DH] libavformat/Makefile
  • [DH] libavformat/allformats.c
  • [DH] libavformat/rcwtenc.c
  • [DH] tests/fate/subtitles.mak