ffmpeg commandline to stream from V4L2 input to rtmpd
Thorsten Pferdekaemper
Hi,
I have succeeded in streaming TV over rtmpd. My TV card has a v4l2 driver. The commandline I am using is as follows:
ffmpeg -f oss -i /dev/dsp1 -r 25 -f video4linux2 -i /dev/video0 -r 25 -vcodec libx264 -vpre default -vpre baseline -b 500000 -s 320x240 -strict experimental -g 25 -me_method zero -acodec aac -ab 96000 -ar 48000 -ac 2 -f mpegts udp://127.0.0.1:10000?pkt_size=1316
This works, but it seems that 320x240 is the maximum size my server can handle. If I use a bigger size, the whole thing becomes choppy. Does someone know some smarter parameters to speed things a bit up? It does not have to have maximum quality all the time.
I have tried h263 and mp3, but both did not work.
Has somebody any idea? (Except of getting a faster machine..)
Thanks&Regards,
Thorsten
Max Lapshin
Video may become choppy because of lost dts in MPEG-TS
Simonr
What is the CPU usage?
It might be that ffmpeg which uses X264 to encode isn't able to do
higher resolutions in real time (on your CPU), hence the timestamps
(dts) will be late resulting in choppy video.
You could try changing some x264 parameters to make the encoding
quicker by producing either less quality or less compression. Try
experimenting with changing the deblocking filter from CABAC to CAVLC.
Regards,
Simon
Thorsten Pferdekaemper
I am not sure what you meant with "rtmp publish", but I am assuming
something like this:
ffmpeg -f oss -i /dev/dsp1 -r 25 -f video4linux2 -i /dev/video0 -b 2000000
-s 720x540 -f flv rtmp://127.0.0.1/flvplayback/tvstream
Indeed, this worked quite well. With basically full-size (720x540), my
system needed only about 50% CPU and the quality is ok.
The thing is that first rtmpd needs to be started and then the above
command.
I did not know about that possibility, but it's really not bad. Maybe only a
bit noisy, but this I might be able to reduce as well.
The stream can be played using "rtmp://<server-name>/flvplayback/tvstream".
It seems that the problem was the h264 codec. When I add
-vcodec libx264 -vpre default -vpre baseline
To the above, my CPU power is hardly enough to encode a 320x240 size.
Regards,
Thorsten
use rtmp publish.
You received this message because you are subscribed to "C++ RTMP Server"
mailing list.
To post to this group, send email to c-rtmp...@googlegroups.com
To unsubscribe from this group, send email to
c-rtmp-serve...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/c-rtmp-server?hl=en
Thorsten Pferdekaemper
the CPU is close to or equal to 100%. I am pretty sure as well that my
system is simply to slow for this, and so it comes to a choppy stream. What
else could the system do...?
I have checked this CABAC vs. CAVLC, but haven't found anything like that. I
wasn't aware that I am using a deblocking filter. I thought deblocking
filters were only for decoding...
How can I change it?
Regards,
Thorsten
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Simonr
Sent: Mittwoch, 1. Dezember 2010 11:48
To: C++ RTMP Server
Subject: [rtmpd:2176] Re: ffmpeg commandline to stream from V4L2 input to
rtmpd
Thorsten,
Regards,
Simon
You received this message because you are subscribed to "C++ RTMP Server"
Simonr
I don't use ffmpeg, so I am not sure of the command line switches but
I have messed around with X264 and you set different options to speed
up the encoding.
Have you looked at (http://mewiki.project357.com/wiki/X264_Settings)
and from that you could work out what setting you need and there must
be a way they can get passed by ffmpeg to X264. (ultrafast would be
the one to try)
According to the link CABAC is disabled by default in X264, however
without checking the code I can't be sure that it is not set by
ffmpeg. - However I would have thought the baseline setting you have
set would mean it is off.
Other alternatives:
Does the TV channel that you are trying to stream have a digital DVB
transmission via satellite or terrestrial stream?
If it does and it it broadcast in H.264 you then wouldn't need to
encode the video in the first place.
Challenges with this approach:
The stream is probably an interlaced stream which in my experiments
the CRMTP code/flash has problems with.
You might have to transcode the audio into aac-lc.
You will have to fix the CRTMP code as it only supports a single
multiplexed TS stream
If you have a GPU in your hardware setup you could you that to do the
decoding for you. NVidia has release code samples to achieve this.
Challenges with this approach:
Tricky to support more than one stream
Produces by default multi slice H.264 which CRMTP TS udp code doesn't
support
Update the CPU!!
Regards,
Simon
On Dec 3, 10:02 am, "Thorsten Pferdekaemper"
cs
I have this exact same setup: live tv streaming from a v4l2-compatible tuner
card.
I tried a few different formats&setups, but the best, most stable, and most
flexible setup
(for me...) turned out to be streaming in flv format from ffmpeg to rtmpd.
FYI, I don’t stream directly from v4l2 to ffmpeg;
I use an intermediate 'pipe buffer' command named 'bfr'
http://www.glines.org/software/bfr.html
Using 'bfr' allows me to create a small video buffer that I can feed into
ffmpeg, and thus helps avoid issues
With mpeg packets from the tuner card being dropped by ffmpeg due to any
processing latency.
Here's what my ffmpeg command looks like:
bfr -b 15m /dev/video0 \
| ffmpeg -re -i - -threads 0 \
-deinterlace -r 30 -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 \
-vpre faster -crf 29 -bufsize 1500k -maxrate 800k \
-f flv -metadata streamName='mp4:tvs' tcp://localhost:6666
This seems to work great for my application, and it keeps the stream at a
reasonable bitrate & quality.
The other advantage of this method is that it correctly sets up the
'streamName' variable so that I can name my streams and easily access a
given stream from my flash player frontend.
In this example, my stream url would be 'rtmp://<myserver>/live/mp4:tvs'
NOTE: I needed to hack the ffmpeg source code & rebuild it in order to get
the metadata option to work for custom metadata values. This can be somewhat
complicated, but it was worth the effort in my case.
BTW, Im also using this same 'flv wrapper' method to broadcast fm radio in
mp3 format.
Anyway, hope this helps...
cs
Mischa Spiegelmock
incredibly useful
cs
Assuming that you can handle getting the ffmpeg source, configuring, &
compiling it yourself, here's the patch:
@Approx. line 250-280? of flvenc.c, within the following function:
static int flv_write_header(AVFormatContext *s)
{
...lots of code here...
if(audio_enc){
... more code here...
put_amf_double(pb, audio_enc->codec_tag);
}
//add the following patch
AVMetadataTag *tag = NULL;
while ((tag = av_metadata_get(s->metadata, "", tag,
AV_METADATA_IGNORE_SUFFIX))) {
put_amf_string(pb, tag->key);
put_byte(pb, AMF_DATA_TYPE_STRING);
put_amf_string(pb, tag->value);
}
//end patch
put_amf_string(pb, "filesize");
...
As far as I remember, that should be all it needs.
If it doesn’t work, let me know & I'll take another look at the source.
Cheers,
cs
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Mischa Spiegelmock
Sent: Sunday, December 05, 2010 10:24 PM
To: c-rtmp...@googlegroups.com
Mischa Spiegelmock
chance you could post a patch file? We can bug the FFmpeg people to
include your patch too
cs
When I compiled ffmpeg, this patch had not yet been added to the source, so
I had to manually patch it myself.
But it looks like the patch was committed to the ffmpeg source a few months
ago:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-September/095988.html
So, just disregard my 'patch' comment...
Have you already tried setting arbitrary metadata tags? It *should* already
work 'out of the box'....
(if for some reason it still isn’t working, then let me know and I can take
another look at the source).