[Bug 796863] vaapih264dec: H264 parse stops if missing an SPS/PPS

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796863

--- Comment #3 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
(In reply to Matteo Valdina from comment #2)
> I' using GStreamer 1.14.0 and I don't see what you describe.
> 
> I see that the slice_parse will continue to try to parse the same NALU each
> time and it does indefinitely.

Sure, this was fixed in master only, see bug #796832. But after this fix, there
will be over 10 decoder errors, and the decoder will give up, which is bad for
live pipeline. That's what I want to address here, we should ditch this bad API
and just try forever.

> 
> I suggest skipping the NALU that doesn't have the SPS/PPS until a new set
> SPS/PPS is available and next NALU are referring to this set.

We can't, because in some application, movement is better then correct images.
For this purpose, FFMPEG, which has a very high end error concealment, manages
to produce frames in the first part, creating movement on a gray background. So
if we add this filtering to h264parse, this behaviour won't be selectable (see
output-corrupt knob on avdec_h264).

> 
> It will be useful to raise a custom event (like GstUDPPacketLoss) that
> inform the pipeline of this error. In this case, the application can request
> a new I-frame and try to recover from this situation.

That's all implemented already. But it's decoder driven, the VAAPI decoder is
not there yet. When the decoder detects corrupted frames, it sends a custom
event upstream, which get wrapped into the RTCP feedback (if enabled). So that
the sender can send a new IDR (with headers if not out-of-band). This is common
in RTP, since we often only produce keyframes when requested.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.