Hi! I'm writing an article detailing streaming to Twitch from a web camera,
using ffmpeg.
I tried to explain the ffmpeg command-line I'm using, however, as I don't know
ffmpeg
that well, my understanding of the command-line itself is limited. Could you
please
see if there's anything obviously (or non-obviously) wrong with the following
text?
> First, let's cover a simple streaming case - no sound involved, just video.
> We have a USB
> camera (available as /dev/video0), and we have a Twitch RTMP URL, which we
> should send our stream to. A basic ffmpeg command-line that does the job of is
> as follows:
>
> ffmpeg -f v4l2 -s "$INRES" -r "$FPS" -i /dev/video0 -vcodec h264_omx -g $GOP
> -keyint_min $FPS -b:v $CBR -minrate "100k" -maxrate $CBR -pix_fmt yuv420p
> -bufsize "500k" -preset "veryfast" -f flv
> "rtmp://$SERVER.twitch.tv/app/$STREAM_KEY"
>
> That's a lot of parameters for a single command! Let's go through it so that
> you understand what's going on. First, here's the breakdown of all parts this
> command-line consists of:
>
> ffmpeg {global options} -f {input type} {input options} -i {input} {codec}
> {codec options} -f {output type} {output}
>
> We're only using one global option - "-hide-banner", which tells ffmpeg not to
> print its version information on start. Our webcam is /dev/video0 - in your
> case, it might end with another number (say, you're using a laptop with a
> webcam). To capture video from the webcam, we're using the Video4Linux system
> and the corresponding ffmpeg plugin called "v4l2", and we tell it the
> resolution to use and FPS (frames per second) that we want. Twitch requires
> that we compress our video as H.264 - this would usually be a CPU-intensive
> task, but Raspberry Pi has hardware H264 encoding support. We can get that
> support if we use the h264_omx ffmpeg plugin.
>
> Even though compression means we don't send full frames all the time, we still
> need to send a full frame once in a while - packets can get lost and glitches
> can happen. A frame sent for the image synchronization purpose is called a
> keyframe - the "-g" parameter tells how often keyframes will be made (say,
> $GOP
> is double the $FPS, then a keyframe will be formed each 2 seconds), and the
> "-keyint_min" parameter allows additional keyframes to appear if necessary
> (say, the video changes rapidly) This explains the "-g $GOP -keyint_min $FPS"
> part. Now, what about "-b:v $CBR -minrate "100k" -maxrate $CBR"? These are the
> h264_omx codec parameters, and they restrict the bitrate of the resulting
> stream - bitrate is, in our case, how much data we're sending per second.
>
> ... [a long not-ffmpeg-related explanation of what bitrates mean and why we
> need
> a constant bitrate for Twitch]
>
> After all the bitrate-related parameters, we have parameters defining the
> color
> encoding scheme (Twitch requires the YUV420 scheme) and buffer size - the
> buffer in question is the one ffmpeg uses to check whether bitrate is constant
> enough; setting your "bufsize" to the same value as your bitrate is a good
> starting point. The last parameter is the compression quality - as in, how
> much
> time should be spent on compression. The "fast"-er the preset, the less time
> is
> spent compressing and the more bandwidth will be taken by your video - you
> have
> options like "veryslow", "slow", "medium", "fast" and "veryfast", and some
> more
> in between.
I'm sorry if this request is taken as asking for too big of a favour (full
disclosure: I'm
getting paid to write this). I just really, really would hate to explain things
in a wrong
way and push it onto the readers, and I hope you can help make a ffmpeg
streaming
tutorial that explains things well (which, in my experience, is a rare
occurence).
Cheers!
Arsenijs
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
