Recherche avancée

Sur d’autres sites (7639)

• How can ffmpeg concat MP3s with full metadata incl. cover art ?

  13 décembre 2022, par TEN

  Audio books inconveniently split into dozens of MP3s (with spaces in their names) should be merged into one MP3 in a subdirectory (in which ffmpeg version 4.2.7-0ubuntu0.1 is invoked), without time-consuming and possibly degrading conversions, reliably preserving all metadata incl. cover art (present and similar in all MP3s of a title, their differences being significant only in lengths and track numbers).

  


  However, rather than picking the latter from the first input MP3, the https://trac.ffmpeg.org/wiki/Concatenate#protocol loses the cover art, the https://trac.ffmpeg.org/wiki/Concatenate#demuxer documented as more flexible even loses all metadata :

  


  ffmpeg -v verbose -f concat -safe 0 -i <(printf "file '$PWD/%s'\n" ../in\ track*.mp3) -c copy "out.mp3"
...
Input #0, concat, from '/dev/fd/63':
Duration: N/A, start: 0.000000, bitrate: 192 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
Stream #0:1: Video: png, 1 reference frame, rgba(pc), 300x300, 90k tbr, 90k tbn, 90k tbc
Metadata:
title           : 12ae3b8152eaf255ae0315c59400c540.png
comment         : Cover (front)
...
Output #0, mp3, to 'out.mp3':
Metadata:
TSSE            : Lavf58.29.100
Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (copy)
...
[AVIOContext @ 0x561459f3dac0] Statistics: 1958050 bytes read, 0 seeks
[mp3 @ 0x561459f3f900] Skipping 0 bytes of junk at 110334.
[mp3 @ 0x561459f3f900] Estimating duration from bitrate, this may be inaccurate
No more output streams to write to, finishing.
size=   75793kB time=00:53:03.12 bitrate= 195.1kbits/s speed= 636x
video:0kB audio:75793kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000865%
Input file #0 (/dev/fd/63):
Input stream #0:0 (audio): 121847 packets read (77611658 bytes);
Input stream #0:1 (video): 40 packets read (4358440 bytes);
Total: 121887 packets (81970098 bytes) demuxed
Output file #0 (out.mp3):
Output stream #0:0 (audio): 121847 packets muxed (77611658 bytes);
Total: 121847 packets (77611658 bytes) muxed
[AVIOContext @ 0x561459ef6700] Statistics: 2 seeks, 298 writeouts
[AVIOContext @ 0x561459f39e40] Statistics: 2006324 bytes read, 0 seeks
[AVIOContext @ 0x561459ee0300] Statistics: 5040 bytes read, 0 seek


  


  The metadata incl. cover PNG as detected (as single-frame "video") should end up in the output MP3, but doesn't (even when adding -movflags use_metadata_tags possibly intended for other formats).

  


  -metadata track="1/1" (or without the /1 ?) may be required as the first input MP3 sometimes wrongly starts at a higher number.

  


  How do I make sure no metadata (incl. image) other than track numbers is lost when concatenating MP3s (by protocol or demuxer, from a set of input files with spaces in their names and a wildcard to match across track numbers) ?

  


• avfilter/vf_tinterlace : support full-range YUV

  9 décembre 2022, par Niklas Haas

  avfilter/vf_tinterlace : support full-range YUV
  This filter, when used in the "pad" mode, currently makes the
  
  distinction between limited and full range solely by testing for YUVJ
  
  pixel formats at link setup time. This is deprecated and should be
  
  improved to perform the detection based on the per-frame metadata.
  In order to make this distinction based on color range metadata, which
  
  is only known at the time of filtering frames, for simplicity, we simply
  
  allocate two copies of the "black" frame - one for limited range and the
  
  other for full range metadata. This could be done more dynamically (e.g.
  
  as-needed or simply by blitting the appropriate pixel value directly),
  
  but this change is relatively simple and preserves the structure of the
  
  existing code.
  This commit actually fixes a bug in FATE - the new output is correct for
  
  the first time. The previous md5 ref was of a frame that incorrectly
  
  combined full-range pixel data with limited-range black fields. The
  
  corresponding result has been updated.
  Signed-off-by : Niklas Haas <git@haasn.dev>
  

  • [DH] libavfilter/tinterlace.h
  • [DH] libavfilter/vf_tinterlace.c
  • [DH] tests/ref/fate/filter-pixfmts-tinterlace_pad

• fftools/ffmpeg : avoid storing full forced keyframe spec

  17 novembre 2022, par Anton Khirnov

  fftools/ffmpeg : avoid storing full forced keyframe spec
  It is not needed after the spec is parsed. Also avoids ugly string
  
  comparisons for each video frame.
  

  • [DH] fftools/ffmpeg.c
  • [DH] fftools/ffmpeg.h
  • [DH] fftools/ffmpeg_mux.c
  • [DH] fftools/ffmpeg_mux_init.c