vaapidecodebin (h264) and change resolution.

Matteo Valdina matteo.valdina at gmail.com
Fri Aug 11 19:02:52 UTC 2017


Thanks,

I open the bug https://bugzilla.gnome.org/show_bug.cgi?id=786173 with a
test application.

Best
Matteo

On Fri, Aug 11, 2017 at 3:22 AM, Víctor Jáquez <vjaquez at igalia.com> wrote:

> On Thu, 10 Aug 2017 at 21:13, Matteo Valdina wrote:
> > Hi y'all,
> >
> > I create a prototype that encode a video stream and sends RTP to the
> > network.
> > The other side is receiving the RTP stream and decode.
> >
> > My problem is when the encoded stream changes the resolution.
> > vaapidecodebin (h264) decode a corrupted stream. The corrupted frame is
> > first couples line some colors and the rest is green.
>
> It sounds like a bug too.
>
> > I noticed in logs that when h264parse sense the resolution changes the
> > vaapidecode change src caps with old width and height:
> >
> > 0:00:11.141138375 16310      0x11594f0 INFO               GST_EVENT
> > gstevent.c:809:gst_event_new_caps: creating caps event video/x-h264,
> > stream-format=(string)avc, alignment=(string)au,
> > codec_data=(buffer)01640028ffe1002a67640028ac3c42
> 01e0089797ff0001000110000003001000000303ce00000302dc6c000089
> 545bdef72801000568ee01070c,
> > level=(string)4, profile=(string)high, pixel-aspect-ratio=(fraction)1/1,
> > width=(int)1920, height=(int)1080, framerate=(fraction)30/1,
> > interlace-mode=(string)progressive, parsed=(boolean)true
> > 0:00:11.143496386 16310      0x11594f0 INFO             vaapidecode
> > gstvaapidecode.c:208:gst_vaapidecode_update_sink_caps:<decoder-bin-0>
> new
> > sink caps = video/x-h264, stream-format=(string)avc,
> alignment=(string)au,
> > codec_data=(buffer)01640028ffe1002a67640028ac3c42
> 01e0089797ff0001000110000003001000000303ce00000302dc6c000089
> 545bdef72801000568ee01070c,
> > level=(string)4, profile=(string)high, pixel-aspect-ratio=(fraction)1/1,
> > width=(int)1920, height=(int)1080, framerate=(fraction)30/1,
> > interlace-mode=(string)progressive, parsed=(boolean)true
> > 0:00:11.145759769 16310      0x11594f0 INFO               h264parse
> > gsth264parse.c:1850:gst_h264_parse_update_src_caps:<h264-parse-dec-0>
> PAR
> > 1/1
> > 0:00:11.145988562 16310      0x11594f0 INFO               baseparse
> > gstbaseparse.c:3986:gst_base_parse_set_latency:<h264-parse-dec-0>
> min/max
> > latency 0:00:00.033333333, 0:00:00.033333333
> > 0:00:11.150561630 16310      0x11594f0 INFO             vaapidecode
> > gstvaapidecode.c:373:gst_vaapidecode_update_src_caps:<decoder-bin-0> new
> > src caps = video/x-raw(memory:VASurface), format=(string)NV12,
> > width=(int)1280, height=(int)720, interlace-mode=(string)progressive,
> > multiview-mode=(string)mono,
> > multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/
> left-flipped/left-flopped/right-flipped/right-flopped/
> half-aspect/mixed-mono,
> > pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1
>
> Please open a bug, and provide a test app if it is possible. Perhaps we are
> forgetting to execute a drain the decoder before changing the caps.
>
> vmjl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>



-- 
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170811/5838e3cd/attachment.html>


More information about the gstreamer-devel mailing list