Recherche avancée

Sur d’autres sites (6524)

• FFMPEG : Convert multiple movies into plex direct play format

  4 avril 2021, par Sascha

  I have a large movie base which I watch over plex (Apple TV plex client with raspberry 4 plex server). However, for standardization and to ensure better direct play with plex, I wanted to convert the movies/series to new format.

  


  Therefore, my idea was to convert all movies to

  


  

  1. 1080p (1920*1080) / 16:9

  


  2. 30 fps

  


  3. mkv container

  


  4. H.264 (libx264)

  


  5. 8 bit Video Depth

  


  6. 320 kbps audio AAC

  


  7. keep only German and English version (audio / subtitle)

  


  


  which seems to be good settings for sustainable standardization. Dont know, if other settings (e.g. hevc) would be better. However, I can't combine the commands with the right ffmpeg options to let my server convert in the background. By now, I came up with the following two commands, which I want to combine, once ffmpeg gives me the right output, which it does not at the moment. It breaks in the conversion process and does not keep only German and English subtitles and audio. I

  


  Hope someone can help me out. Thanks a lot.

  


  find . -name '*.mp4' -or -name '*.wav' -exec ffmpeg -i {} basename {}.mkv \; -exec rm {} \;

for f in *.mkv; do echo "Starting with ${f} @ $(date +%T)"; ffmpeg -hide_banner -i "${f}" -map_metadata:g -1 -movflags faststart -c:v libx264 -preset slow -crf 20 -pix_fmt yuv420p -vf scale=1920:-1,setdar=16/9 -filter:v fps=fps=30 -c:a aac -b:a 320k -map0:s "${f}.2.mkv"; echo "Finished with ${f} @ $(date +%T)"; done


  


• FFMPEG is really slow at extracting subtitles

  3 mars 2021, par Gustav P Svensson

  I'm trying to extract the subtitles from a 1080P video, around 40min long. I'm currently using this command (using fluent-ffmpeg in node, but the translated command is this) :

  


  ffmpeg -threads 3  -map 0: -c copy 


  


  This command takes about 20-30 min to complete. I've searched quite a lot on how to speed up this process, if I look at my task manager I can see that ffmpeg is using 0.1% of the CPU which makes me think that it's possible to speed up this process.

  


  I'm not sure if the -threads option is actually doing anything when extracting subtitles but I don't think it should make it slower atleast ?

  


  So my question is, is it possible to speed up this process ? I appriciate any help.

  


  Full FFMPEG log:
fmpeg version 3.4.8-0ubuntu0.2 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration: --prefix=/usr --extra-version=0ubuntu0.2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, matroska,webm, from '/home/test.mkv:
  Metadata:
    encoder         : libebml v1.3.6 + libmatroska v1.4.9
    creation_time   : 2019-03-14T16:46:55.000000Z
  Duration: 00:41:20.29, start: 0.000000, bitrate: 6430 kb/s
    Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
    Metadata:
      BPS-eng         : 5788926
      DURATION-eng    : 00:41:20.020000000
      NUMBER_OF_FRAMES-eng: 59461
      NUMBER_OF_BYTES-eng: 1794581562
      _STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-03-14 16:46:55
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default)
    Metadata:
      title           : English
      BPS-eng         : 640000
      DURATION-eng    : 00:41:20.288000000
      NUMBER_OF_FRAMES-eng: 77509
      NUMBER_OF_BYTES-eng: 198423040
      _STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-03-14 16:46:55
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:2(eng): Subtitle: subrip
    Metadata:
      BPS-eng         : 80
      DURATION-eng    : 00:40:22.295000000
      NUMBER_OF_FRAMES-eng: 645
      NUMBER_OF_BYTES-eng: 24473
      _STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-03-14 16:46:55
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
    Stream #0:3(eng): Subtitle: subrip
    Metadata:
      title           : SDH
      BPS-eng         : 86
      DURATION-eng    : 00:40:31.012000000
      NUMBER_OF_FRAMES-eng: 709
      NUMBER_OF_BYTES-eng: 26142
      _STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-03-14 16:46:55
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Output #0, srt, to 'test6.srt':
  Metadata:
    encoder         : Lavf57.83.100
    Stream #0:0(eng): Subtitle: subrip
    Metadata:
      BPS-eng         : 80
      DURATION-eng    : 00:40:22.295000000
      NUMBER_OF_FRAMES-eng: 645
      NUMBER_OF_BYTES-eng: 24473
      _STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-03-14 16:46:55
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
  Stream #0:2 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=      46kB time=00:40:36.68 bitrate=   0.2kbits/s speed=11.6x    
video:0kB audio:0kB subtitle:24kB other streams:0kB global headers:0kB muxing overhead: 94.438766%


  


• avcodec/put_bits : Don't set size_in_bits, fix overflow

  25 mars 2021, par Andreas Rheinhardt

  avcodec/put_bits : Don't set size_in_bits, fix overflow
  A PutBitContext has a field called size_in_bits which is set to the
  
  context's bitsize init_put_bits() ; but it isn't used at all (the PutBits
  
  API uses pointers directly and not bit indexes), so remove it (due to
  
  ABI concerns the actual element is only removed at the next bump).
  Furthermore, the multiplication inherent in setting this field can lead
  
  to undefined integer overflows. This is particularly true for FFV1,
  
  which uses a very big worst-case buffer (37*4*width*height ; even
  
  ordinary 1080p triggers an overflow). Ticket #8350 is about this
  
  overflow which this commit fixes.
  This means that the effective range of the PutBits API is no longer
  
  restricted by the /8 as long as one isn't using put_bits_(count|left).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/put_bits.h