Rpi: v4l2src + omxh264enc + tcpserversink

[Krutskikh Ivan]

Ok, after a lot of googling I've seemed to find out the very viable
explanation on what is happening:

"Short answer why your pipeline don't work now.
omxh264enc (h264 encoder) generate something call SPS NAL.
This SPS NAL contain basic information as width, height ,................
all basic information that you neeed before you start decoding something.
And this buffer is generated only ONCE at start.
And tcpserver dump this sps as you connect to server after some time."

The source is
https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=6852&start=225

The are also some pathes to gst-omx attached. I would try those after
weekend. I remember now that the same issue stoped me from streaming h264
from local files on the server...

2015-06-04 18:59 GMT+03:00 Krutskikh Ivan <stein.hak at gmail.com>:

> 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/c96fb3fc/attachment.html>