vaapidecode parse error handling

[Matt Staples]

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.

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.

Thanks,
-Matt
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Victor Jaquez]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matt Staples]

I'm using 1.8.2.  I didn't realize vaapidecode was later ditched.
What's the replacement?

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. <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Victor Jaquez]

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. <[hidden email]> 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
> > [hidden email]
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matt Staples]

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?

On Wed, Jan 11, 2017 at 11:01 AM, Víctor M. Jáquez L.
<[hidden email]> 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. <[hidden email]> 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
>> > [hidden email]
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Victor Jaquez]

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.
> <[hidden email]> 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. <[hidden email]> 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
> >> > [hidden email]
> >> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> [hidden email]
> >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel