Recherche avancée

Sur d’autres sites (3606)

• ffmpeg : audio to opus and embed song cover to lossless vp9 in webm container

  14 mars 2020, par snow344

  im having some trouble in making a lossless webm of a audio file

  mpv plays it fine, but youtube won’t process it no matter what

  ffmpeg -i "audio.flac" -c:v vp9 -c:a libopus -lossless 1 -b:a 500k -pix_fmt yuv420p test.webm
  
  
  
      Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
  
      Stream #0:1: Video: mjpeg (Progressive), yuv444p(pc, bt470bg/unknown/unknown), 800x800 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc (attached pic)
  
      Metadata:
  
        comment         : Cover (front)
  
  File 'test.webm' already exists. Overwrite? [y/N] y
  
  Stream mapping:
  
    Stream #0:1 -> #0:0 (mjpeg (native) -> vp9 (libvpx-vp9))
  
    Stream #0:0 -> #0:1 (flac (native) -> opus (libopus))
  
  Press [q] to stop, [?] for help
  
  [swscaler @ 0000028ef88c6000] deprecated pixel format used, make sure you did set range correctly
  
  [libvpx-vp9 @ 0000028ef854cf00] v1.8.2
  
  Output #0, webm, to 'test.webm':
  
      Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p(progressive), 800x800 [SAR 1:1 DAR 1:1], q=-1--1, 90k fps, 1k tbn, 90k tbc (attached pic)
  
      Metadata:
  
        comment         : Cover (front)
  
        encoder         : Lavc58.73.101 libvpx-vp9
  
      Side data:
  
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  
      Stream #0:1: Audio: opus (libopus), 48000 Hz, stereo, s16, 500 kb/s
  
      Metadata:
  
        encoder         : Lavc58.73.101 libopus
  
  frame=    1 fps=0.2 q=0.0 Lsize=   15327kB time=00:04:11.17 bitrate= 499.9kbits/s speed=53.7x
  
  video:386kB audio:14853kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.574758%

  thanks in advance

• avformat/av1 : Avoid allocation + copying when filtering OBUs

  24 janvier 2020, par Andreas Rheinhardt

  avformat/av1 : Avoid allocation + copying when filtering OBUs
  Certain types of OBUs are stripped away before muxing into Matroska and
  
  ISOBMFF ; there are two functions to do this : One that outputs by
  
  directly writing in an AVIOContext and one that returns a freshly
  
  allocated buffer with the units not stripped away copied into it.
  The latter option is bad for performance, especially when the input
  
  does already not contain any of the units intended to be stripped away
  
  (this covers typical remuxing scenarios). Therefore this commit changes
  
  this by avoiding allocating and copying when possible ; it is possible if
  
  the OBUs to be retained are consecutively in the input buffer (without
  
  an OBU to be discarded between them). In this case, the caller receives
  
  the offset as well as the length of the part of the buffer that contains
  
  the units to be kept. This also avoids copying when e.g. the only unit
  
  to be discarded is a temporal delimiter at the front.
  For a 22.7mb/s file with average framesize 113 kB this improved the time
  
  for the calls to ff_av1_filter_obus_buf() when writing Matroska from
  
  313319 decicycles to 2368 decicycles ; for another file with 1.5mb/s
  
  (average framesize 7.3 kB) it improved from 34539 decicycles to 1922
  
  decicyles. For these files the only units that needed to be stripped
  
  away were temporal unit delimiters at the front.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavformat/av1.c
  • [DH] libavformat/av1.h
  • [DH] libavformat/matroskaenc.c
  • [DH] libavformat/movenc.c

• h264_mp4toannexb : Copy one NAL unit at a time

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Copy one NAL unit at a time
  If processing an input NAL unit triggers the insertion of data from
  
  extradata in front of said NAL unit, the output packet is grown (i.e.
  
  reallocated) once to accomodate both the new extradata as well as the
  
  input NAL unit itself ; this has been changed : In such a situation, the
  
  packet is now grown twice. While this is bad for performance, it allows
  
  to simplify the code and ultimately to stop reallocating the packet
  
  altogether.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c