A question about h264 encoder

[张若]

Actually, we need to use both the SW and HW encoder at the same time. And
we want the SW encoder for streaming and HW encoder for storage.
The SW encoder can have more options and parameters to control and change,
especially for a low delay. That's why we want to use SW for real time
streaming to client.
The HW encoder will only be used for on board sd card storage of capture
video.

2016-10-13 16:17 GMT+02:00 Tonu Jaansoo <tonu.jaansoo at gmail.com>:

> Why would you want to NOT use HW encoder, if it is available and working?
> As it was pointed out, CPU can't handle encoding the stream in realtime
> from source such as as a camera. (thats why there is HW encoder)
>
> Tõnu
>
> On 13 Oct 2016, at 14:58, 张若 <zr92zr at gmail.com> wrote:
>
> Anyway, thanks!
> But.. the board has both HW and SW 264 encoder on it. There is no problem
> to use x264enc.
> The problem is with videorate. If I use videorate and x264enc without
> setting drop-only as true, there will be problems while streaming. But that
> works fine without videorate, or works fine with using imxvpuenc_h264
> instead.
> I don't know why. I think that could be some problems with framerate,
> either with camera or encoder.
>
> 2016-10-13 14:26 GMT+02:00 Nuno Mota <mundumelga at gmail.com>:
>
>> It is quite simple.
>>
>> imxvpuenc_h264 uses imx hardware encoder.
>> x264enc uses the cpu, so It's software encoder. You wont be able to use
>> it on an ARM CPU. Imx just cant handle it.
>>
>> Check "top" and you will se the cpu load/usage...
>>
>> On Oct 13, 2016 1:17 PM, "张若" <zr92zr at gmail.com> wrote:
>>
>>> I found the solution myself. But still not understand the reason
>>> thoroughly.
>>>
>>> The problem is with the videorate, it needs to be set with
>>> drop-only=true, especially for the board. Otherwise, it seems to duplicate
>>> several frames and cause a large delay as well.
>>> But I still don't why does this happen? and why there is no problem
>>> while using imxvpuenc_h264?
>>>
>>> Hope somebody could explain that!
>>>
>>> Thanks!
>>>
>>>
>>>
>>> 2016-10-13 11:32 GMT+02:00 张若 <zr92zr at gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I am working on the imx6 board. There are two h264/x264 encoder, HW
>>>> encoder named imxvpuenc_h264 and SW encoder named x264enc. I tried both of
>>>> them. But problem appears.
>>>>
>>>> The pipeline looks like this: (the video camera capture is 720p)
>>>>
>>>> imxv4l2videosrc -> capsfilter1 -> videoscale -> videorate ->
>>>> videoconvert -> capsfilter2 -> imxvpuenc_h264 (or x264enc) -> queue ->
>>>> h264parse -> mpegtsmux -> rtpmp2tpay -> udpsink
>>>>
>>>> While using imxvpuenc_h264, there is no large latency, but using
>>>> x264enc will cause a really large latency (sometimes around 10s and frame
>>>> stucks).
>>>>
>>>> When I set "capsfilter2" to lower resolution such as 320x240, the
>>>> latency comes much shorter for x264enc. On the other hand, if I remove the
>>>> "videoscale -> videorate -> videoconvert" part while using x264enc, there
>>>> almost no latency for the streaming.
>>>>
>>>> For x264enc, I set "tune=zerolatency, key-int-max=32, bframes=0,
>>>> speed-preset=1, bitrate=4000 (may changes from 1000 to 10000)".
>>>>
>>>> I don't know the reason why it happens and how can I deal with that.
>>>> Please help!
>>>>
>>>> Thanks in advance!
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161013/e0ce1eb9/attachment-0001.html>