Recherche avancée

Sur d’autres sites (13026)

• When rTorrent finishes, run FFmpeg and convert audio track in mkv to ac-3 5.1

  11 septembre 2021, par miniHessel

  What is the best approach for this ? I saw the following answer, is that still a valid approach ? If so, how do you execute that when a torrent finishes ? I mostly want to convert dts-hd either 5.1 or 7.1. Sometimes also Atmos.

  


• Google’s YouTube Uses FFmpeg

  9 février 2011, par Multimedia Mike — General

  Controversy arose last week when Google accused Microsoft of stealing search engine results for their Bing search engine. It was a pretty novel sting operation and Google did a good job of visually illustrating their side of the story on their official blog.

  This reminds me of the fact that Google’s YouTube video hosting site uses FFmpeg for converting videos. Not that this is in the same league as the search engine shenanigans (it’s perfectly legit to use FFmpeg in this capacity, but to my knowledge, Google/YouTube has never confirmed FFmpeg usage), but I thought I would revisit this item and illustrate it with screenshots. This is not new information— I first empirically tested this fact 4 years ago. However, a lot of people wonder how exactly I can identify FFmpeg on the backend when I claim that I’ve written code that helps power YouTube.

  Short Answer
  How do I know YouTube uses FFmpeg to convert multimedia ? Because :

  1. FFmpeg can decode a number of impossibly obscure multimedia formats using code I wrote
  2. YouTube can transcode many of the same formats
  3. I screwed up when I wrote the code to support some of these weird formats
  4. My mistakes are still present when YouTube transcodes certain fringe formats

  Longer Answer (With Pictures !)
  Let’s take a video format named RoQ, developed by noted game designer Graeme Devine. Originated for use in the FMV-heavy game The 11th Hour, the format eventually found its way into the Quake 3 engine as well as many games derived from the same technology.

  Dr. Tim Ferguson reverse engineered the format (though it would later be open sourced along with the rest of the Q3 engine). I wrote a RoQ playback system for FFmpeg, and I messed up in doing so. I believe my coding error helps demonstrate the case I’m trying to make here.

  Observe what happened when I pushed the jk02.roq sample through YouTube in my original experiment 4 years ago :

  
  
  

  Do you see how the canyon walls bleed into the sky ? That’s not supposed to happen. FFmpeg doesn’t do that anymore but I was able to go back into the source code history to find when it did do that :

  
  
  

  Academic Answer
  FFmpeg fixed this bug in June of 2007 (thanks to Eric Lasota). The problem had to do with premature colorspace conversion in my original decoder.

  Leftovers
  I tried uploading the video again to see if the problem persists in YouTube’s transcoder. First bit of trivia : YouTube detects when you have uploaded the same video twice and rejects the subsequent attempts. So I created a double concatenation of the video and uploaded it. The problem is gone, illustrating that the backend is actually using a newer version of FFmpeg. This surprises me for somewhat esoteric reasons.

  Here’s another interesting bit of trivia for those who don’t do a lot of YouTube uploading— YouTube reports format details when you upload a video :

  
  
  

  So, yep, RoQ format. And you can wager that this will prompt me to go back through the litany of unusual formats that FFmpeg supports to see how YouTube responds.

• thread_queue_size during Live Streaming from ffmpeg

  11 mars 2017, par user2967920

  I’m trying to stream a webcam stream froma RaspberryPi-B to Youtube. The webcam used is a Logitech C920. If I use the h264 stream from the camera itself, it works fine using

  ffmpeg -f alsa -i hw:1,0 -f v4l2 -vcodec h264 -video_size 854x480 -r 25 -i /dev/video0 -acodec aac -b:a 64000 -ar 48000 -bufsize 64k -b:v 1200k -bufsize 1024k  -maxrate 1800k -vcodec copy -g 60 -r 30 -f flv
  
   rtmp://a.rtmp.youtube.com/live2/stream_here

  So, for this to work with other non h264 cameras like the Pi Cam or any other cheaper webcam, it needs to work with the raw stream and get converted to h264 using libx264. This is the whole point of using the Pi. Hence the second command set.

  ffmpeg -f alsa -ac 2 -i hw:1,0 -f v4l2 -i /dev/video0 -framerate 25 -video_size 1280x720  -c:v libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/stream_name

  So this results in the following issue.

  ffmpeg version git-2017-03-03-68ee800 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 4.9.2 (Raspbian 4.9.2-10)
  
    configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --extra-libs=-lasound --enable-pthreads
  
    libavutil      55. 47.101 / 55. 47.101
  
    libavcodec     57. 82.100 / 57. 82.100
  
    libavformat    57. 66.103 / 57. 66.103
  
    libavdevice    57.  3.100 / 57.  3.100
  
    libavfilter     6. 74.100 /  6. 74.100
  
    libswscale      4.  3.101 /  4.  3.101
  
    libswresample   2.  4.100 /  2.  4.100
  
    libpostproc    54.  2.100 / 54.  2.100
  
  Guessed Channel Layout for Input Stream #0.0 : stereo
  
  Input #0, alsa, from 'hw:1,0':
  
    Duration: N/A, start: 1488650966.446293, bitrate: 1024 kb/s
  
      Stream #0:0: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
  
  Input #1, video4linux2,v4l2, from '/dev/video0':
  
    Duration: N/A, start: 2227.042654, bitrate: 159252 kb/s
  
      Stream #1:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 864x480, 159252 kb/s, 24 fps, 24 tbr, 1000k tbn, 1000k tbc
  
  Stream mapping:
  
    Stream #1:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
  
    Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
  
  Press [q] to stop, [?] for help
  
  [video4linux2,v4l2 @ 0x2e42310] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
  
  Illegal instruction
  
  pi@raspberrypi:~ $

  If I add

  thread_queue_size 512 

  I end up with

  pi@raspberrypi:~ $ ffmpeg -f alsa -ac 2 -i hw:1,0 -f v4l2 -thread_queue_size 512 -i /dev/video0 -framerate 25 -video_size 1280x720  -c:v libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -c:a aac -b:a 128k -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/zqg7-98wy-60b6-f2yx
  
  ffmpeg version git-2017-03-03-68ee800 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 4.9.2 (Raspbian 4.9.2-10)
  
    configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --extra-libs=-lasound --enable-pthreads
  
    libavutil      55. 47.101 / 55. 47.101
  
    libavcodec     57. 82.100 / 57. 82.100
  
    libavformat    57. 66.103 / 57. 66.103
  
    libavdevice    57.  3.100 / 57.  3.100
  
    libavfilter     6. 74.100 /  6. 74.100
  
    libswscale      4.  3.101 /  4.  3.101
  
    libswresample   2.  4.100 /  2.  4.100
  
    libpostproc    54.  2.100 / 54.  2.100
  
  Guessed Channel Layout for Input Stream #0.0 : stereo
  
  Input #0, alsa, from 'hw:1,0':
  
    Duration: N/A, start: 1488651430.836193, bitrate: 1024 kb/s
  
      Stream #0:0: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
  
  Input #1, video4linux2,v4l2, from '/dev/video0':
  
    Duration: N/A, start: 2691.407641, bitrate: 159252 kb/s
  
      Stream #1:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 864x480, 159252 kb/s, 24 fps, 24 tbr, 1000k tbn, 1000k tbc
  
  Stream mapping:
  
    Stream #1:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
  
    Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native))
  
  Press [q] to stop, [?] for help
  
  Illegal instruction
  
  pi@raspberrypi:~ $

  Where exactly does

  thread_queue_size

  Belong ?

  Notes :
  ffmpeg was built using this reference
  –extra-libs=-lasound & —enable=pthreads was used