You can tweak the parameters from there to go higher or lower resolution.
That won't work for the Pi, because it doesn't have the horsepower to
encode the video, (and they don't have audio in, but that's a different
problem). They do have a dedicated video processor that can output h264,
so if I can feed that to ffmpeg, then I might be able to get somewhere.
That lead me to something like this:
The rapivid parameters are specifying 999999 seconds of 1280x720 video
at 30fps with a 3Mb/s bitrate, main h264 profile, 30 frame GOP, output
to std out, include headers (SPS, PPS which seemed like it might be
useful), and quantization level 10 (which is fairly high quality).
I am trying to do kind of the same thing, except instead of grabbing what
the camera is spitting out, I am trying to grab the output from an iPad
that is sent via AirPlay to the rPi. If I try to grab the frame buffer
using ffmpeg -f fbdev -r 10 -i /dev/fb0 out.avi , the result "out.avi"
doesn't have anything of value in it. I am using rPlay on the rPi to turn
the rPi into an AppleTV, basically.
On Sun, Jan 26, 2014 at 5:51 PM, Daryll Strauss <[hidden email]>wrote:
> I've got this idea of using a raspberry pi as a cheap camera system to
> stream live events. You can get a board with a camera for $60, and $under
> $100 all in with Wifi, case, compact flash, power, etc.
> Streaming to YouTube works with the following command on my laptop:
> ffmpeg -f alsa -ar 44100 -b:a 128k -i pulse -f v4l2 -i /dev/video0
> -codec:v libx264 -s 1280x720 -r 30 -profile:v main -b:v 3000k -f flv
> -codec:a aac -strict experimental rtmp://a.rtmp.youtube.com/live2/STREAM
> You can tweak the parameters from there to go higher or lower resolution.
> That won't work for the Pi, because it doesn't have the horsepower to
> encode the video, (and they don't have audio in, but that's a different
> problem). They do have a dedicated video processor that can output h264, so
> if I can feed that to ffmpeg, then I might be able to get somewhere. That
> lead me to something like this:
> raspivid -t 999999 -w 1280 -h 720 -fps 30 -b 3000000 -pf main -g 30 -o -
> -ih -qp 10 -n | avconv -re -f h264 -i - -b:a 128k -f s16le -ar 44100 -ac 2
> -i /dev/zero -f flv -codec:v copy -codec:a aac -strict experimental out.flv
> The rapivid parameters are specifying 999999 seconds of 1280x720 video at
> 30fps with a 3Mb/s bitrate, main h264 profile, 30 frame GOP, output to std
> out, include headers (SPS, PPS which seemed like it might be useful), and
> quantization level 10 (which is fairly high quality).
> It spits out lines like:
> frame= 191 fps= 95 q=-1.0 size= 0kB time=10000000000.00 bitrate=
> frame= 206 fps= 82 q=-1.0 size= 0kB time=10000000000.00 bitrate=
> frame= 2845 fps= 31 q=-1.0 size= 34789kB time=0.02
> That's quite odd, because the time is always 0.02 and the bitrate is
> wrong. Something gets written to out.flv, but if I ffprobe out.flv I see:
> Input #0, flv, from '/tmp/out.flv':
> encoder : Lavf53.21.1
> Duration: 00:00:00.04, start: 0.000000, bitrate: 200 kb/s
> Stream #0.0: Video: h264 (Main), yuv420p, 1280x720, 1k tbr, 1k tbn, 2k
> Stream #0.1: Audio: aac, 44100 Hz, 2 channels, 200 kb/s
> Clearly that's not right and doesn't play. The total bitrate is just the
> audio. The tbr, and tbc are wrong. I should be seeing something like this:
> Input #0, flv, from '/usr/tmp/good.flv':
> encoder : Lavf54.63.104
> Duration: 00:00:11.65, start: 0.044000, bitrate: 3058 kb/s
> Stream #0:0: Video: h264 (Main), yuv420p, 1280x720, 3000 kb/s, 30 tbr,
> 1k tbn, 60 tbc
> Stream #0:1: Audio: aac, 44100 Hz, stereo, fltp, 128 kb/s
> It seems like the copy is sort of working, but the timing information
> isn't getting passed through. I'd tried a variety of options to get this
> working, but I'm stumped.
> Anyone have a suggestion for me?
> ffmpeg-user mailing list
> [hidden email] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user >
Sorry to step on peoples toes Lou. That wasn't my intent. avconv was the
package that shipped with the Raspberry Pi Debian distribution so I used
it. Thanks for the info.
On Jan 26, 2014 10:08 PM, "Lou" <[hidden email]> wrote:
On the contrary, we are here to help you!
The administrator of the Debian "ffmpeg" packet will not
tell you that avconv contains several hundred known,
user-reported bugs not present in FFmpeg, he will not
tell you about the many (known!) security-relevant
issues in avconv that nobody cares about and I find it
unlikely that he is going to tell you what happens with
bug reports and enhancement requests for avconv...
I came across your post a few days ago while trying to do exactly the same. I have now succeeded to live stream to Youtube and would like to share my solution so that others do not need to spend as much time tinkering with ffmpeg :-)
2) Through numerous attempts I worked out that the bitrate sent with audio being AAC-encoded was very low! (in fact significantly lower than what raspivid was producing) and thus Youtube refused to take it. The trick is with the order of the command line arguments to ffmpeg. I used the following (where XXXXXXX is the youtube RTMP stream identifier):
a) '-re' is the right enabler for getting the appropriate bitrate out of the audio encoding. It seems the Pi can cope with AAC encoding very well. I have obviously not tested any real audio input as I have no soundcard for it.
b) '-g 50' there is a minimum requirement for the keyframe interval of less than or equal to 2 seconds. I have been able to work out that this corresponds to less than or equal to 2*fps. (Note that I could not find the unit for the -g parameter anywhere, not even for ffmpeg itself. So this is guessing really.) See Youtube's streaming requirements https://support.google.com/youtube/answer/2853702?topic=2853713&hl=en.
Despite Youtube's bandwidth requirements. I could easily stream 1080p@25fps+AAC with only 600~700Kbps of bandwidth available.
c) The audio stream part of the command seems to need to come before the video part, because of '-re'.
Hope this is useful to people looking into streaming to Youtube live with the Pi! :-)
On 6 April 2014 21:33, kathodus <[hidden email]> wrote:
> (Note that I could not find the
> unit for the -g parameter anywhere, not even for ffmpeg itself. So this is
> guessing really.)
-g is one of the parameters associated with individual video encoders.
If you have a look at this section of the docs you'll see that many
video CODECs describe the 'g' option as "the size of a GOP", or