rtpvp9depay ! vp9dec pipeline crashes when a single RTP packet is missed

[Michael Franzl]

Using latest gstreamer and gst-plugins-good version 1.13.0 git revision
f88a7801e4 (24. December 2017), using the following receiving pipeline:

gst-launch-1.0 -v udpsrc port=50000 ! netsim drop_probability=0.02 !
"application/x-rtp, payload=127, encoding-name=VP9" ! rtpvp9depay !
vp9dec ! autovideosink

... and the following sending pipeline:

gst-launch-1.0 -v videotestsrc ! 'video/x-raw,width=320,height=240' !
vp9enc cpu-used=5 ! rtpvp9pay ! udpsink host=127.0.0.1 port=50000

... the receiving pipeline crashes (on the first missing RTP packet
dropped by the `netsim` element) with the following error:


ERROR: from element /GstPipeline:pipeline0/GstVP9Dec:vp9dec0: Failed to
decode frame
Additional debug info:
gstvpxdec.c(684): gst_vpx_dec_handle_frame ():
/GstPipeline:pipeline0/GstVP9Dec:vp9dec0:
corrupt frame


The same happens using an older gstreamer version (1.10.4 in Debian
Stretch), only the older version does not recover with nice error
messages, but segfaults.

What I would expect is that the pipeline doesn't crash, because a real
network is always lossy. If there is corrupted or missing VP9 data, the
decoder should just go on, even if it would create visual artefacts in
the output. Or alternatively, simply freeze the last valid video image,
and wait for a new keyframe to recover. The vp8dec element does exactly
this. Example:

Receiving pipeline:

gst-launch-1.0 -v udpsrc port=50000 ! netsim drop_probability=0.1 !
"application/x-rtp, payload=127, encoding-name=VP8" ! rtpvp8depay !
vp8dec  ! autovideosink

Sending pipeline:

gst-launch-1.0 -v videotestsrc ! videoconvert !
'video/x-raw,width=320,height=240' ! vp8enc ! rtpvp8pay ! udpsink
host=127.0.0.1 port=50000

The receiving pipeline creates visual artefacts, but doesn't crash.

Is there a way to keep the vp9dec decoder running even with corrupted
inputs?

If this qualifies for a bug report, I can file it.

Thanks,
Michael