[Libva] codec parser issues between gst-plugins-bad and gstreamer-vaapi

Yuan, Feng feng.yuan at intel.com
Tue Dec 18 01:06:39 PST 2012


> -----Original Message-----
> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
> Sent: Tuesday, December 18, 2012 4:49 PM
> To: Yuan, Feng
> Cc: Li, Jocelyn; Zhang, Ouping; Beauchesne, Gwenole;
> libva at lists.freedesktop.org; Zhong, CongX
> Subject: Re: [Libva] codec parser issues between gst-plugins-bad and
> gstreamer-vaapi
> 
> Ho;
> 
> 2012/12/18 Yuan, Feng <feng.yuan at intel.com>:
> 
> >> With Gwenole's patch applied, do we still see playback stop issue?
> >
> > I think it can only fix X error but not lost frame issues. Cong is following
> this issue in <playbin2> <sync=false> and have got some reasons of
> surfaces exhausted in <queue> which break the pipeline. Maybe we
> should not test raw h.264 streams with <playbin2> or <queue>  together
> with <sync=false>.
> 
> I didn't know there is an X error, but the videoparsers now use the system
> codecparsers/ functions and gst-vaapi use the local ones.
> Otherwise, there were indeed cases where we could write beyond the
> struct size, thus corrupting stack or memory.
It doesn't crashed maybe GstH264SPS structure size in Gst-plugins-bad is larger or same as in gst-vaapi. I didn't compare the exact size. Since structure fields different, then width/height will be parsed in wrong field and got width=-1, height=16, so this maybe the reason x error caused. 

> 
> The sync=false issue is an independent problem. I have not investigated
> this one yet. From what I see, at least on my side, is that with sync=false +
> playbin2, some streams would not stop immediately at the end of the
> stream. However, there is no issue with sync=false + explicit pipeline
> (somedemux ! vaapidecode ! vaapisink sync=false).
Cong has done some investigation on playbin2 with sync=false. And said pipeline stopped by GstVaapiSurface exhausted, we have 20 surfaces created in decoder, but playbin2 has some queues, so the pipeline would looks more like (somedemux ! vaapidecode ! *queue* ! vaapisink sync=false), the <queue> may use up all surfaces then after vaapidecode tried more than 100 times and return GST_FLOW_UNEXPECTED, finally pipeline got EOS message, this is reasonable. You can try add a queue. Since we didn't handle timestamp in h264decoder on raw stream, I think QA can test raw streams only on manual pipeline without <queue>.

Thanks,
Wind

> >> -----Original Message-----
> >> From: libva-bounces+jocelyn.li=intel.com at lists.freedesktop.org
> >> [mailto:libva-bounces+jocelyn.li=intel.com at lists.freedesktop.org] On
> >> Behalf Of Zhang, Ouping
> >> Sent: Tuesday, December 18, 2012 11:05 AM
> >> To: Yuan, Feng; Gwenole Beauchesne
> >> Cc: Beauchesne, Gwenole; libva at lists.freedesktop.org; Zhong, CongX
> >> Subject: Re: [Libva] codec parser issues between gst-plugins-bad and
> >> gstreamer-vaapi
> >>
> >> Git apply Gwenole's patch(gst.vaapi.hide.codecparsers.patch), it can
> >> fix bug 55305 and bug 56652 on master branch and QA branch.
> >>
> >> But when configure --enable-encoders on master branch with the
> patch,
> >> decoding can't work well with the following error:
> >> (gst-plugin-scanner:13863): GStreamer-WARNING **: Failed to load
> >> plugin
> >> '/usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstvaapi.so':
> >> /usr/lib/x86_64-
> >> linux-gnu/gstreamer-0.10/libgstvaapi.so: undefined symbol:
> >> vaapi_encoder_dump_bytes
> >>
> >> (gst-plugin-scanner:13864): GStreamer-WARNING **: Failed to load
> >> plugin
> >> '/usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstvaapi.so':
> >> /usr/lib/x86_64-
> >> linux-gnu/gstreamer-0.10/libgstvaapi.so: undefined symbol:
> >> vaapi_encoder_dump_bytes
> >> WARNING: erroneous pipeline: could not set property "video-sink" in
> >> element "playbin20" to "vaapisink sync=false"
> >>
> >> -----Original Message-----
> >> From: Yuan, Feng
> >> Sent: Tuesday, December 18, 2012 9:52 AM
> >> To: Gwenole Beauchesne; Zhang, Ouping
> >> Cc: Beauchesne, Gwenole; libva at lists.freedesktop.org; Zhong, CongX
> >> Subject: RE: [Libva] codec parser issues between gst-plugins-bad and
> >> gstreamer-vaapi
> >>
> >>
> >> > -----Original Message-----
> >> > From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
> >> > Sent: Monday, December 17, 2012 9:40 PM
> >> > To: Yuan, Feng
> >> > Cc: Beauchesne, Gwenole; libva at lists.freedesktop.org; Zhong, CongX
> >> > Subject: Re: [Libva] codec parser issues between gst-plugins-bad
> >> > and gstreamer-vaapi
> >> >
> >> > Hi,
> >> >
> >> > 2012/12/10 Yuan, Feng <feng.yuan at intel.com>:
> >> >
> >> > >> If you tell me it works, yes. :) Otherwise, I didn't test the
> >> > >> patch since I don't have the issue, but I understand the cause
> >> > >> based on what you said.
> >> > >
> >> > > I just simply tried the patch on my machine and it works.
> >> > > QA will test it tomorrow and let you know the result soon.
> >> >
> >> > Applied. No news from QA, though there is no reason this shouldn't
> >> work.
> >>
> >> Good.
> >> Sorry, I'm busy on Tizen these days so didn't tell you the result. QA
> >> tried it but said it was failed. I didn't check their environment not sure
> why failed.
> >> But yours can work in my machine. Cong wrote a similar patch like
> >> yours < -fvisibility=hidden> and said his can work, in my option,
> >> your and his patch should have the same result.
> >>
> >> Ouping/Cong,
> >>      Could you pull master branch and test it again? maybe you need
> >> try $git clean -dxf first and reply the result.
> >>
> >> Thanks,
> >> Wind
> >> _______________________________________________
> >> Libva mailing list
> >> Libva at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/libva


More information about the Libva mailing list