[Bug 752962] v4l2videodec: Add resolution change support

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Jul 28 07:49:28 PDT 2015


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

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #2 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
About 1, it's not going to be trivial in the current architecture, but I would
be please to see how you handle it.

About 2, I agree. It will though break my plan of passing the header, and wait
to see if the decoder is happy before letting data flow. If the header is part
of that caps, that would have let us skip the decoder if it does not support
certain flavour of a certain encoding (think MFC with many MPEG2 video stream,
or with H264 stream with unpaired field).

About 3, this is driver job, should have nothing special to do in GStreamer.
Unless I'm mistaken ?

About 4, zero payload buffers is there for backward compatibility. Make sure
you also support "after EPIPE". There is also the LAST flag, but I believe hte
EPIPE case is sufficient, even if a bit late (next gst_v4l2_video_dec_loop ()
call).

Note that I'll probably have to delay these change to the next development
cycle, it's very late now in the 1.5/1.6 process to make such a change. The
only way around is if you can prove you didn't break support for existing
implementation. Known to be used are MFC (Exynos 4 and 5), this is known to
work with hardkernel kernels. CODA is also known to work from upstream with
very little patches.

-- 
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