Re: gstreamer: v4l2videodec plugin

[ayaka]

在 2016年05月15日 15:41, Nicolas Dufresne 写道:

> Le vendredi 13 mai 2016 à 11:45 +0300, Stanimir Varbanov a écrit :
>> One thing which bothers me is how the extra-controls property
>> working,
>> i.e. I failed to change the h264 profile for example with below
>> construct:
>>
>> extra-controls="controls,h264_profile=4;"
> Yes, and profile should be negotiated with downstream in GStreamer. For
> common controls, like bitrate, it should be exposed as separate
> properties instead.

Please try the new patches in
https://github.com/hizukiayaka/gst-plugins-good
And look at this commit
https://github.com/hizukiayaka/gst-plugins-good/commit/92b99ba9322cf8a1039b877315b12bc9813e95cf

NOTE: even you could set those extra controls and driver accepted. It
doesn't mean it would work.
I looked at the s5p-mfc driver, it just set it then leave it alone. I
may fix this bug in the few weeks.
>
> Nicolas

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Philipp Zabel-2]

Am Samstag, den 14.05.2016, 15:07 +0300 schrieb Stanimir Varbanov:
[...]

> > While I got you. I would be very interested to know who QCOM driver
> > interpreted the width and height expose on capture side of the decoder.
> > I'm adding Philippe Zabel in CC here (he's maintaining the
> > CODA/Freescale decoder). In Samsung MFC driver, the width and height
> > expose by the driver is the display size. Though, recently, Philippe is
> > reporting that his driver is exposing the coded size. Fixing one in
> > GStreamer will break the other, so I was wondering what other drivers
> > are doing.
>
> In qcom driver s_fmt on capture queue will return bigger or the same as
> coded resolution depending on the width/height. This is related to hw
> alignment restrictions i.e 1280x720 on output queue will become 1280x736
> on capture queue. The the userspace can/must call g_crop to receive the
> active resolution for displaying.

Since in that case the input video is nominally 1280x720, and we are not
cropping away anything from that, this shouldn't use G_CROP (which maps
to G_SELECTION with V4L2_SEL_TGT_CROP_ACTIVE), but G_SELECTION with
V4L2_SEL_TGT_COMPOSE_DEFAULT on the capture queue.

For mem2mem devices, cropping should happen at the output queue, and
composing at the capture queue. For devices that don't scale, such as
decoders, the output crop rectangle should have the same size as the
capture compose rectangle.

Is there any reason not to update the MFC driver to use G_SELECTION? The
g_crop implementation could be kept for backwards compatibility.

regards
Philipp

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-3]

Le jeudi 19 mai 2016 à 15:25 +0200, Philipp Zabel a écrit :
> Is there any reason not to update the MFC driver to use G_SELECTION?
> The
> g_crop implementation could be kept for backwards compatibility.

Videobuf2 already provide this backward compatible implementation, so
there is no reason not to port that driver (if this is not done
already, maybe ask Kamil ?).

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel