GStreamer-devel

vaapidecodebin (h264) and change resolution.

classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Matteo Valdina
Reply | Threaded
Open this post in threaded view
♦
♦
|

vaapidecodebin (h264) and change resolution.

Matteo Valdina
Hi y'all,
As I wrote in other emails, I'm playing with vaapi and I'm probably becoming annoying...

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.

VLC is able to decode the same stream.

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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c, 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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c, 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


Any suggestion? Could be a bug? Is it a supported scenario?

I'm using (1.13.0, master branch, gst-build) but I can see the same problem with 1.12.2.
 
Best
Matteo

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Victor Jaquez
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: vaapidecodebin (h264) and change resolution.

Victor Jaquez
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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c,
> 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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c,
> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Matteo Valdina
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: vaapidecodebin (h264) and change resolution.

Matteo Valdina
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 <[hidden email]> 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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c,
> 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)01640028ffe1002a67640028ac3c4201e0089797ff0001000110000003001000000303ce00000302dc6c000089545bdef72801000568ee01070c,
> 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
[hidden email]
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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page