Rpi: v4l2src + omxh264enc + tcpserversink

[Krutskikh Ivan]

I've been experimenting with this setup for a whole day right now. Seams
that omxh264enc does not honor the target-bitrate and control-rate
parameters, which might result in a buggy stream. Has anyone observed such
an behavior? I'm using RPi2 btw

2015-06-03 21:13 GMT+03:00 Krutskikh Ivan <stein.hak at gmail.com>:

> It's gstreamer 1.2 which is default for rasbian wheezy. Can this situation
> be helped with a queue after v4l2src? The weirdest thing that I mentioned
> earlier is that streaming to local file works fine. Streaming to
> tcpserversink however fails =(
>
> 2015-06-03 21:08 GMT+03:00 Nicolas Dufresne <
> nicolas.dufresne at collabora.com>:
>
>> Le Wednesday 03 June 2015 à 18:25 +0300, Krutskikh Ivan a écrit :
>> > gst-launch-1.0 v4l2src device=/dev/video0 ! videoscale ! videoconvert
>> > ! videorate ! omxh264enc target-bitrate=1000000 control-rate=1 !
>> > “video/x-h264,profile=high" ! h264parse ! mpegtsmux !  tcpserversink
>> > host=0.0.0.0 port=5000
>>
>> The problem is most likely that v4l2src does not allocate enough buffer
>> for the encoder. I'm not sure which version of GStreamer this is, hence
>> not able to give better advices. In 1.4, v4l2src should be copying out
>> buffers as soon as the local queue is near empty. Then on 1.5+ it will
>> try and be a little smarter. On 1.2, it would most likely just stall.
>>
>> One generic change you could do is to try and select a lower profile
>> (like constrained-baseline), this will disable b-frames, hence reduce
>> the number of buffer required. It will also reduce your latency.
>>
>> Nicolas
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150604/4e01b92c/attachment.html>