vaapidecode parse error handling

[Víctor M. Jáquez L.]

On 01/11/17 at 11:15am, Matt Staples wrote:
> Ah, I remember that change being discussed now - sorry
> 
> It sounds like the problem I'm running into would be the same with the
> new vaapih264dec element though.  True?

True.

Looking at the log, it seems that we could do it better. Perhaps ditching the
frame if it is not a key frame.

> 
> On Wed, Jan 11, 2017 at 11:01 AM, Víctor M. Jáquez L.
> <vjaquez at igalia.com> wrote:
> > On 01/11/17 at 10:25am, Matt Staples wrote:
> >> I'm using 1.8.2.  I didn't realize vaapidecode was later ditched.
> >> What's the replacement?
> >
> > The decoders were split: vaapih264dec, vaapimpeg2dec, etc.
> >
> > But there is still the vaapidecodebin which is, basically, the vaapidecode +
> > vaapipostproc.
> >
> > vmjl
> >
> >>
> >> I've attached a log showing the parse error.
> >> Note that this includes a hack that I made to issue a
> >> GST_ELEMENT_ERROR prior to returning EOS.  (When our application sees
> >> the stream error, it rebuilds the pipeline using the libav decoder,
> >> and after that it, it streams without any errors.)
> >> I'll work on capturing the actual offending data, but that will take a
> >> bit as it's actually difficult to access outside of our application.
> >>
> >>
> >> On Wed, Jan 11, 2017 at 8:37 AM, Víctor M. Jáquez L. <vjaquez at igalia.com> wrote:
> >> > On 01/11/17 at 07:33am, Matt Staples wrote:
> >> >> Hi All,
> >> >>
> >> >> I ran into a problem with vaapidecode, where it failed to handle an
> >> >> H264 stream due to a parse error on an SEI packet.  The upstream
> >> >> h264parser element complained about the packet, but otherwise let it
> >> >> through with a warning.  But then vaapidecode printed a debug error
> >> >> message about it and then returned GST_FLOW_EOS.
> >> >
> >> > Which version of gstreamer-vaapi are you using? vaapidecode was ditched in
> >> > gstreamer 1.10
> >> >
> >> >> Two questions:
> >> >> 1. Is there a chance vaapidecode is parsing too strictly?  (The
> >> >> software decoder plays the same stream without any apparent problems.)
> >> >> 2. Is GST_FLOW_EOS really the desired behavior?  Our application can't
> >> >> distinguish this from a proper end-of-stream condition, and therefore
> >> >> can't effectively handle the error, e.g., by switching over to the
> >> >> software decoder and trying again.  I would think a GST_ELEMENT_ERROR
> >> >> (streaming feature) would be more appropriate in this case.
> >> >
> >> > Can you share a log? GST_DEBUG=vaapi*:5
> >> > If you have a sample media would be great.
> >> >
> >> > vmjl
> >> >
> >> > _______________________________________________
> >> > gstreamer-devel mailing list
> >> > gstreamer-devel at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel