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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Jun 1 07:07:24 UTC 2018


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

--- Comment #35 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #32)
> Ok, I wonder how many time I'll need to read this, this code is hard to
> follow. So reading through find_first_field() correct, before you hack:
> 
> 0. Get the previous frame (for current view)
> 
> 1. If the previous frame is missing a field, and current slice is
> progressive (!slice_hdr->field_pic_flag), fill the gap in previous frame and
> add it to the DPB.
> 
> 2. If the previous frame is a frame, and the first field of the previous
> frame is different parity then this "new frame" slice parity, assume there
> was a missing picture.
> 
> 3. If the slice if from the same frame_num as previous frame, then take the
> previous frame as current to complete it, unless the parity is the same
> (looks like this case is a bitstream error though), in which case, just
> finish previous frame and start a new one.
> 
> 4. I don't fully understand this one, but basically we pick the first field
> of previous frame, fill_picture_other_field_gap() which adds it to the DPB.
> That is very odd. 

At this point, 1) both previous and current frames are interlaced 2) frame-num
value changed. Then it indicates that the previous frame has a missing field
Frame-num shouldn't be changing between two fields of a frame (that is my
understanding of the spec).

>If the previous frame first field parity is different then
> current slice parity, assume there was a missing first field.
> 
> So basically two 2 implements what I had in mind already. And that's why it
> mostly work with your hack. But case 4 seems to mess-up a little bit. I'm
> very surprised we just assume field was missing, if some bitstream is passed
> twice, it would endup overriding pictures ... Is that normal thing to do ?

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


More information about the gstreamer-bugs mailing list