[meta-freescale] [meta-fsl-arm][PATCH 3/5] gst1.0-fsl-plugin: Add Freescale Gstreamer1.0 Plugin for MX6

[Carlos Rafael Giani]

Here are some significant differences I've found so far:

* The FSL VPU decoder element estimates the timestamps. It doesn't 
really use the upstream DTS/PTS. My plugins don't estimate anything. 
Instead, they associate encoded frames with decoded pictures using an 
ID, and using that, the GstVideoDecoder base class then copies the 
encoded frame's DTS/PTS to the matching decoded picture. As Lauren said, 
the customer can choose here.

* Their VPU decoder also operates differently in how it deals with 
insufficient output framebuffers. My decoder waits with a pthread 
condition until enough output framebuffers are available. Theirs allows 
operation even with insufficient buffer and then tries to cope with an 
"insufficient output buffers" error. I have found the latter approach to 
cause problems with h264 high profile videos that use a lot of B-frames, 
but perhaps they have workarounds for that elsewhere. I didn't test it 
enough yet to confirm this.

* The FSL plugins include audio codec elements. I was thinking about 
writing elements for these as well in gstreamer-imx, but was discouraged 
from doing so, since they offer no substantial benefits over the 
community codecs, and exist mainly for customers who want a full 
audio/video solution from FSL.

* FSL plugins have a v4l based sink, while gstreamer-imx has an EGL 
based one. The v4l one is potentially more power efficient, but the EGL 
one works much better with compositing desktop managers like Weston. 
Both the FSL plugins and gstreamer-imx also have an IPU-based sink, 
though I never got theirs to work.

* The FSL plugins also include a custom demuxer for several formats, 
called "aiur". It probably can demux some problematic videos better 
(there are a lot of broken videos out there), but I suspect its there 
mainly for the same reason as the audio codecs: to provide a full 
audio/video solution.


Personally, I am no fan of the timestamp estimation thing. It can 
correct playback of certain videos that have broken timestamps, yes, but 
I think such timestamp corrections shouldn't be part of a video decoder. 
Instead, it should be a separate step prior to decoding, or perhaps be 
part of the demuxer. Furthermore, the frame ID approach mentioned above 
is more in line with how libav, GStreamer, Android, Chromium handle 
decoding.


By the way, there is another FSL library I have written an alternative 
for: libimxvpuapi (mine) vs. FSL wrapper. Main difference is again the 
frame ID thing. The contents of libimxvpuapi are essentially the core of 
gstreamer-imx' VPU de- and encoder. For a future version I plan on 
refactoring gstreamer-imx to use this library. It would reduce its code 
size considerably, thus boosting maintainability.



On 08/31/2014 08:02 PM, Eric Nelson wrote:
> Hi Lauren,
>
> On 08/30/2014 08:30 PM, Lauren Post wrote:
>> In this case we have reasons specific to our test case environments that
>> require us to create our own plugin set.
>>
> Can you at least tell us what they are?
>
> Presumably these test cases were generated to match a use case,
> and users of Carlos's versions might want/need to know.
>
>> *From:*John Weber [mailto:rjohnweber at gmail.com]
>> *Sent:* Saturday, August 30, 2014 6:21 PM
>> *To:* Post Lauren-RAA013
>> *Cc:* Daiane Angolini; meta-freescale at yoctoproject.org; Carlos Rafael Giani
>> *Subject:* Re: [meta-freescale] [meta-fsl-arm][PATCH 3/5]
>> gst1.0-fsl-plugin: Add Freescale Gstreamer1.0 Plugin for MX6
>>
>>   
>>
>> Hi Lauren,
>>
>> On Friday, August 29, 2014, Lauren Post <Lauren.Post at freescale.com
>> <mailto:Lauren.Post at freescale.com>> wrote:
>>
>> Freescale developed their own Gstreamer 1.0 plugins so they are not a
>> replacement but another choice that customers can use.
>>
>> Can we get a comparison with what Carlos has done?  Having two sets of
>> plugins that perform the same function would be very confusing.
>>
>> Also, I would think Freescale wouldn't bother to spend valuable
>> resources on work when they could make use of the community has already
>> done.
>>
> Thanks in advance,
>
>
> Eric