IMX Scaler / CSC m2m driver.
Florian Vaussard
florian.vaussard at gmail.com
Mon Feb 8 15:56:32 UTC 2016
Hello Nicolas,
On 02/08/2016 03:41 PM, Nicolas Dufresne wrote:
> Le lundi 08 février 2016 à 08:32 +0100, Florian Vaussard a écrit :
>> Hello Nicolas,
>>
[...]
>>
>> The pipeline of Ian in the aforementioned thread was (if I am not
>> mistaking):
>>
>> gst-launch-1.0 filesrc location=
>> Downloads/big_buck_bunny_1080p_h264.mov !
>> qtdemux ! h264parse ! v4l2video3videodec capture-io-mode=dmabuf !
>> v4l2video0convert output-io-mode=dmabuf-import !
>> video/x-raw,width=1920,height=1080 ! ximagesink sync=false
>>
>> Currently I am using only v4l2videoNdec + fbdevsink. I am porting
>> Philipp's
>> patches to linux 4.4 to get the IPU color converter but there is some
>> work due
>> to recent changes in media and I am lacking time. So first I am
>> looking at the
>> performances obtained by other people.
>>
>> I saw some out-of-tree DRM/KMS sinks [1][2] but they don't appear to
>> be merged
>> in gstreamer and both appear to be 2 years old, thus it will probably
>> take some
>> time to get them up and running :-/ Do you know any other
>> alternatives?
>
> I believe this work will start being merges as soon as I have the time.
> kmssink is the only way forward at the moment. Don't expect anything to
> be fast with fbdevsink or ximagesink. They both require a copy and RGB
> colorspace to be used. glimagesink gained support for DMABuf recently,
> that works nicely on Intel GPU and ARM Mali (that my testing of it),
> but unfortunatly DMABuf isn't part of the IMX.6 proprietary GL stack
> (they got their own vendor API instead).
>
> https://bugzilla.gnome.org/show_bug.cgi?id=761059
>
That is very good news indeed, as I know that fbdevsink is not a good option
performance-wise.
>>
>> So before going into this, I just wanted to be sure that one can get
>> good
>> performances at the end of the day without being trapped in a dead-
>> end.
>
> It's not a dead-end, there is already people managing good performance
> there. But clearly time constrained lead them to create not so nice
> "vendor" branch of everything. The upstreaming process is going well
> though, in all front. I see regular patches on the Linux Kernel, I also
> receive patches and get bug report on GStreamer to tweak certain aspect
> of the v4l2decoder support. Feel free to jump in and contribute
> something.
>
Upstream software has clearly improved over the last years. I was just unsure of
the effort needed to get a working environment with descent performances. But
all the pieces seem available now, even if not upstreamed. For sure I will
contribute if needed.
Thank you for your advices.
Florian
More information about the gstreamer-devel
mailing list