[Bug 787093] omx: add dynamic buffer mode from OMX 1.2.0

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Oct 2 14:02:51 UTC 2017


https://bugzilla.gnome.org/show_bug.cgi?id=787093

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #7 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Guillaume Desmottes from comment #6)
> > To be robust, this check need to be done for every incoming buffers, in case
> > it changed. The dynamic buffer mode can't handle it, but this way you'll be
> > able to at least warn that buffers are dropped. Of course, bonus point if
> > you want a proper way to fallback.
> 
> We can't really fallback so maybe dynamic mode should only be implemented if
> nBufferAlignment == 0?

Well, if this is the only thing you are checking, this means you accept VMALLOC
memory, for fallback is trivial. If you have checked some other things, that
result in other type of memory, then alignment will likely be a page anyway,
and won't be by chance.

GStreamer allocation negotiation is not complete, so we have to make guesses on
what is likely enough and implement as many fallback as possible.

> It's a bit risky to enable it automatically if, by chance, the first buffer
> is mapped on an address fitting the alignment and then fail later when
> another buffer doesn't.
> Do we have a way to know for sure if all incoming buffers will satisfy this
> requirement ? GST_BUFFER_POOL_OPTION_VIDEO_ALIGNMENT doesn't seem to give us
> that.

No, but we have a lot of code that depends these to be consistent (all our ORC
code crashes deeply without checking if the pool have accepted teh
VIDEO_ALIGNMENT or not). It's a mess when it crash deeply in the stack
(specially with OMX). What I meant is that you have to fail the hard way.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list