[Bug 796169] vaapidec: Sample video that renders fine with FFMPEG but not in GStreamer

[GStreamer (GNOME Bugzilla)]

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

--- Comment #25 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
(In reply to sreerenj from comment #24)
> SEI Buffering period header can also activate the SPS. May it is missing
> there?
> I have seen a lot of SEI headers in the stream, didn't get time to analyze
> it.

Ok, to be looked at.

(In reply to sreerenj from comment #23)
> (In reply to Nicolas Dufresne (ndufresne) from comment #21)
> > I'm trying to understand what to do. What I see from FFMPEG code (assuming
> > I'm reading it properly), whenever it starts a new frame, it will first go
> > over the DPB to find all frame with unpaired fields. When one is found,
> > there is two venue, pair it with the new frame, otherwise it's a lost field,
> > and it must be concealed. In the software decoder, they copy the previous
> > field of the same parity, I don't see any concealment on the VAAPI side
> > there.
> > 
> > Is the software FFMPEG decoder method what you had in mind when you say
> > "cache 2 fields" ?
> 
> 
> I was thinking to wait for the next field too before making an assumption.
> But I afraid that this could break the current design of gstreamer-vaapi.
> Again, it won't work well if there is two immediate field-parity order
> change in consecutive frames.
> 
> What we need is some heuristics to find whether the field was missing or
> not. I mean, how to distinguish field-parity change from "missing the first
> field" scenario.
> 
> As you said checking in dpb for the unpaired field could be an option to try.

What's the semantic for gst_vaapi_decoder_h264_start_frame /
gst_vaapi_decoder_h264_end_frame ? Is that really frames ? or it's in hidden
pictures/fields ?

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