[Bug 725145] libde265 based HEVC/H.265 decoder plugin

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725145
  GStreamer | gst-plugins-bad | git

--- Comment #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-08-29 09:06:57 UTC ---
(In reply to comment #10)
> > > > This uses the input frame for output if I'm not mistaken... which is going to
> > > > cause problems if the input is not in presentation order.
> > > 
> > > As before I was following gst-ffmpeg on this. I have a couple of streams for
> > > testing where the input is not in presentation order, but don't see any obvious
> > > problems.
> > 
> > As this is in the code path without direct rendering, did you make sure it goes
> > through that actually? The problem here is that you will output the current
> > GstVideoCodecFrame (which has the current PTS and DTS) with an actual video
> > frame that has a DTS before the current one, but has the PTS of the frame that
> > should come now.
> 
> I also tested the code with the non-direct rendering path which runs fine with
> my non-presentation order streams. Shouldn't that be the case anyway as the
> plugin returns frames with correct PTS?

Yes but you store the frame with the correct PTS in the wrong
GstVideoCodecFrame. Consider the following case:

- input 1
- no output

- input 2
- no output

- input 3
- output 2 (stored in GstVideoCodecFrame for 3)

This will confuse the internal bookkeeping inside GstVideoDecoder. It might be
enough to just get the GstVideoCodecFrame from the decoder with the
corresponding PTS, assuming the input has PTS. If you have no other way of
correlating input frames and output frames.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.