summaryrefslogtreecommitdiff
path: root/omx/gstomxvideo.h
Commit message (Collapse)AuthorAgeFilesLines
* omxvideoenc: remove unsupported formats from caps templateGuillaume Desmottes2020-04-101-1/+4
| | | | | | | Our encoder implementation actually supports a small subset of the formats supported by the decoder. Those are the formats for which we have a copy path in gst_omx_video_enc_fill_buffer() and which are not filtered out in filter_supported_formats().
* video: remove BGR from supported formatGuillaume Desmottes2020-04-101-1/+1
| | | | | It's not supported by either decoder or encoder and is even not listed in gst_omx_video_get_format_from_omx() so it can't work.
* omxbufferpool: use gst_video_meta_set_alignment()Guillaume Desmottes2019-11-051-0/+3
| | | | | | | Tell buffer consumer about our paddings. v4l2src can now uses these paddings information when trying to import buffers to configure the v4l2 driver accordingly.
* omxvideo: add debug infos to find_nearest_frame()Guillaume Desmottes2019-06-171-1/+1
| | | | | | Those debug infos have proved to be very helpful when debugging timestamp issues. They are often linked to gst-omx picking the wrong frame when trying to map from OMX.
* omxvideo: use GST_VIDEO_CAPS_MAKE() for template capsGuillaume Desmottes2019-01-251-0/+4
| | | | | Simplify the code and so we advertise the formats actually supported by gst-omx.
* omxvideodec: ignore very little variations of the framerateJulien Isorce2017-12-141-0/+2
| | | | | | | | | | | | | If less than 1%. The dynamic format change should not happen when the resolution does not change and when only the framerate changes but very slightly, i.e. from 50000/1677=29.81 to 89/3=29.66 so a "percentage change" of less than 1% (i.e. 100*(29.81-29.66)/29.66 = 0.50 < 1 ). In that case just ignore it to avoid unnecessary renegotiation. https://bugzilla.gnome.org/show_bug.cgi?id=759043
* gstomxvideodec: fix framerate overflowJulien Isorce2017-12-131-0/+2
| | | | | | | | | Some live streams can set the framerate to 50000/1677 (=29.81). GstVideoInfo.fps_n << 16 is wrong if the fps_n is 50000 (i.e. greater than 32767). https://bugzilla.gnome.org/show_bug.cgi?id=759043
* omxvideo: Include the separate headers too for compatibility with 1.0.xSebastian Dröge2014-06-241-0/+2
|
* omx: add an helper to convert OMX color format to GStreamer color formatAurélien Zanelli2014-04-151-0/+3
|
* omx: Rename function from _4_ to _for_ for claritySebastian Dröge2014-03-121-1/+1
|
* omxvideo: start sharing more code between video decoder and encoderChristian König2014-03-121-0/+55
Identical functionality spread of two different components. We can't use a common base class because of different inheritance, but let's try to share the code anyway. https://bugzilla.gnome.org/show_bug.cgi?id=726024
View Lorry Controller Status