The advantage of binding between Surface and Context.
by Hirokazu Honda
Hi,
According to libva document
(http://01org.github.io/libva_staging_doxygen/group__api__core.html#ga4af3...),
Surfaces are bound to a context if passing them as an argument when
creating the context.
Seeing intel-vaapi-driver code, the surfaces are just stored in
object_context.render_targets.
A surface processed by
vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in
vaBeginPicture(). (object_context.current_render_target)
It looks like a surface can be processed using a context by being
specified in vaBeginPicture(), even if it is not bound to the context.
Here, my questions are below.
What is the advantage of binding?
In what circumstances do we need to associate the context with surfaces?
In which scenarios passing surfaces to vaCreateContext is required,
and in which it is not?
Best Regards,
Hirokazu Honda
3 years
Fwd: VPP/h264enc invalid SurfaceID
by Matteo Valdina
No, I didn't see any error in the dmesg.
Yesterday I run the test without the decoder and it worked for 24 hours (we
stopped the test).
Thanks
On Fri, Jul 27, 2018, 00:19 Xiang, Haihao <haihao.xiang(a)intel.com> wrote:
>
> Maybe it is not a memory leak issue because the time varies from 6 minutes
> to
> 14+ hours. Did you see any error message in the dmesg output?
>
> Thanks
> Haihao
>
> > Is what I suspect but I have also a decoder running in the same process
> and I
> > never saw this failure in other parts of gstreamer-vaapi.
> >
> > Could you provide any advice on how to debug this? I fear that run inside
> > Valgrind will be not feasible.
> >
> > Thanks
> >
> > >
> > > On Thu, Jul 26, 2018 at 10:22 AM Víctor Jáquez <vjaquez(a)igalia.com>
> wrote:
> > > > On Thu, 26 Jul 2018 at 07:50, Matteo Valdina wrote:
> > > > > Hi,
> > > > > I'm facing a bug with the intel-vaapi-driver and gstreamer-vaapi.
> > > > >
> > > > > My pipeline is something like:
> > > > >
> > > > > v4l2src -> vaapipostproc-> vaapih264enc -> rtp
> > > > >
> > > > > This is a 4K@30 stream in NV12 and encoded in High profile at
> 6Mbps.
> > > > > The VPP is there when there is a need to rescale the frame.
> > > > >
> > > > > After an undefined enough of time that it could be from 6 minutes
> to 14
> > > > > hours (or more), vaapi fails to create a SurfaceID and the pipeline
> > > > stopped.
> > > > >
> > > > > If the VPP is processing data (unfortunately I noticed that if you
> set
> > > > the
> > > > > rescale mode to fast it pass through the rescaler without needs to
> > > > rescale
> > > > > the frame) it fails with these error:
> > > > >
> > > > > Jul 16 22:01:46 localhost gstd[2669]: failed to apply VPP filters
> (error
> > > > 2)
> > > > > Jul 16 22:01:46 localhost gstd[2669]: error: Internal data stream
> error.
> > > > > Jul 16 22:01:46 localhost gstd[2669]: error: streaming stopped,
> reason
> > > > > error (-5)
> > > > >
> > > > > I added additional logs in this failure is reported in the
> vaEndPicture
> > > > > with invalid SurfaceID.
> > > > > Adding more logs I noticed that gstreamer-vaapi fails to create the
> > > > surface
> > > > > and pass to the rescaler a surfaceid -1.
> > > > >
> > > > > If I disable the VPP the issue is not resolved but moved to the
> > > > > vaapih264enc with the following error:
> > > > >
> > > > > Jul 23 17:22:03 localhost gstd[2329]: create H264 picture failed,
> > > > > frame timestamp:3:03:07.581673496
> > > > > Jul 23 17:22:03 localhost gstd[2329]: failed to process reordered
> frames
> > > > > Jul 23 17:22:03 localhost gstd[2329]: failed to encode frame 15901
> > > > (status -2)
> > > > > Jul 23 17:22:03 localhost gstd[2329]: error: Internal data stream
> error.
> > > > > Jul 23 17:22:03 localhost gstd[2329]: error: streaming stopped,
> reason
> > > > > error (-5)
> > > >
> > > > It this case it look you are in a memory exhaustion condition, where
> the
> > > > encoder
> > > > cannot allocate further memory. A memory leak somewhere?
> > > >
> > > > In the case of the VPP looks similar, as if the driver couldn't
> allocate a
> > > > new
> > > > surface.
> > > >
> > > > >
> > > > > Also here it looks like the vaapi fails to create a valid
> SurfaceID.
> > > > >
> > > > > I'm currently on gstreamer 1.14.0, libva 2.1.0, intel-vaapi-driver
> > > > 2.1.0,
> > > > > kernel 4.12.14 and the CPU is a Intel(R) Celeron(R) CPU 3965U @
> 2.20GHz.
> > > > >
> > > > > Any suggestion on how to debug this issue?
> > > > > Enable LIBVA_TRACE is not viable because it will exhaust the space
> in a
> > > > > couple of hours.
> > > > > I should try to update to the latest libva, intel-vaapi-driver?
> > > > >
> > > > > Best
> > > > > Matteo Valdina
> > > >
> > > > > _______________________________________________
> > > > > intel-vaapi-media mailing list
> > > > > intel-vaapi-media(a)lists.01.org
> > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media
> > > >
> > >
> > >
> > > --
> > > “There are two ways of constructing a software design: One way is to
> make it
> > > so simple that there are obviously no deficiencies, and the other way
> is to
> > > make it so complicated that there are no obvious deficiencies. The
> first
> > > method is far more difficult.”
> > > - Tony Hoare
> >
> >
> > _______________________________________________
> > intel-vaapi-media mailing list
> > intel-vaapi-media(a)lists.01.org
> > https://lists.01.org/mailman/listinfo/intel-vaapi-media
3 years, 11 months
Re: [intel-vaapi-media] VPP/h264enc invalid SurfaceID
by Matteo Valdina
Is what I suspect but I have also a decoder running in the same process and
I never saw this failure in other parts of gstreamer-vaapi.
Could you provide any advice on how to debug this? I fear that run inside
Valgrind will be not feasible.
Thanks
>
> On Thu, Jul 26, 2018 at 10:22 AM Víctor Jáquez <vjaquez(a)igalia.com> wrote:
>
>> On Thu, 26 Jul 2018 at 07:50, Matteo Valdina wrote:
>> > Hi,
>> > I'm facing a bug with the intel-vaapi-driver and gstreamer-vaapi.
>> >
>> > My pipeline is something like:
>> >
>> > v4l2src -> vaapipostproc-> vaapih264enc -> rtp
>> >
>> > This is a 4K@30 stream in NV12 and encoded in High profile at 6Mbps.
>> > The VPP is there when there is a need to rescale the frame.
>> >
>> > After an undefined enough of time that it could be from 6 minutes to 14
>> > hours (or more), vaapi fails to create a SurfaceID and the pipeline
>> stopped.
>> >
>> > If the VPP is processing data (unfortunately I noticed that if you set
>> the
>> > rescale mode to fast it pass through the rescaler without needs to
>> rescale
>> > the frame) it fails with these error:
>> >
>> > Jul 16 22:01:46 localhost gstd[2669]: failed to apply VPP filters
>> (error 2)
>> > Jul 16 22:01:46 localhost gstd[2669]: error: Internal data stream error.
>> > Jul 16 22:01:46 localhost gstd[2669]: error: streaming stopped, reason
>> > error (-5)
>> >
>> > I added additional logs in this failure is reported in the vaEndPicture
>> > with invalid SurfaceID.
>> > Adding more logs I noticed that gstreamer-vaapi fails to create the
>> surface
>> > and pass to the rescaler a surfaceid -1.
>> >
>> > If I disable the VPP the issue is not resolved but moved to the
>> > vaapih264enc with the following error:
>> >
>> > Jul 23 17:22:03 localhost gstd[2329]: create H264 picture failed,
>> > frame timestamp:3:03:07.581673496
>> > Jul 23 17:22:03 localhost gstd[2329]: failed to process reordered frames
>> > Jul 23 17:22:03 localhost gstd[2329]: failed to encode frame 15901
>> (status -2)
>> > Jul 23 17:22:03 localhost gstd[2329]: error: Internal data stream error.
>> > Jul 23 17:22:03 localhost gstd[2329]: error: streaming stopped, reason
>> > error (-5)
>>
>> It this case it look you are in a memory exhaustion condition, where the
>> encoder
>> cannot allocate further memory. A memory leak somewhere?
>>
>> In the case of the VPP looks similar, as if the driver couldn't allocate
>> a new
>> surface.
>>
>> >
>> > Also here it looks like the vaapi fails to create a valid SurfaceID.
>> >
>> > I'm currently on gstreamer 1.14.0, libva 2.1.0, intel-vaapi-driver
>> 2.1.0,
>> > kernel 4.12.14 and the CPU is a Intel(R) Celeron(R) CPU 3965U @ 2.20GHz.
>> >
>> > Any suggestion on how to debug this issue?
>> > Enable LIBVA_TRACE is not viable because it will exhaust the space in a
>> > couple of hours.
>> > I should try to update to the latest libva, intel-vaapi-driver?
>> >
>> > Best
>> > Matteo Valdina
>>
>> > _______________________________________________
>> > intel-vaapi-media mailing list
>> > intel-vaapi-media(a)lists.01.org
>> > https://lists.01.org/mailman/listinfo/intel-vaapi-media
>>
>>
>
> --
> “There are two ways of constructing a software design: One way is to make
> it so simple that there are obviously no deficiencies, and the other way is
> to make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult.”
> - Tony Hoare
>
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
3 years, 11 months
VPP/h264enc invalid SurfaceID
by Matteo Valdina
Hi,
I'm facing a bug with the intel-vaapi-driver and gstreamer-vaapi.
My pipeline is something like:
v4l2src -> vaapipostproc-> vaapih264enc -> rtp
This is a 4K@30 stream in NV12 and encoded in High profile at 6Mbps.
The VPP is there when there is a need to rescale the frame.
After an undefined enough of time that it could be from 6 minutes to 14
hours (or more), vaapi fails to create a SurfaceID and the pipeline stopped.
If the VPP is processing data (unfortunately I noticed that if you set the
rescale mode to fast it pass through the rescaler without needs to rescale
the frame) it fails with these error:
Jul 16 22:01:46 localhost gstd[2669]: failed to apply VPP filters (error 2)
Jul 16 22:01:46 localhost gstd[2669]: error: Internal data stream error.
Jul 16 22:01:46 localhost gstd[2669]: error: streaming stopped, reason
error (-5)
I added additional logs in this failure is reported in the vaEndPicture
with invalid SurfaceID.
Adding more logs I noticed that gstreamer-vaapi fails to create the surface
and pass to the rescaler a surfaceid -1.
If I disable the VPP the issue is not resolved but moved to the
vaapih264enc with the following error:
Jul 23 17:22:03 localhost gstd[2329]: create H264 picture failed,
frame timestamp:3:03:07.581673496
Jul 23 17:22:03 localhost gstd[2329]: failed to process reordered frames
Jul 23 17:22:03 localhost gstd[2329]: failed to encode frame 15901 (status -2)
Jul 23 17:22:03 localhost gstd[2329]: error: Internal data stream error.
Jul 23 17:22:03 localhost gstd[2329]: error: streaming stopped, reason
error (-5)
Also here it looks like the vaapi fails to create a valid SurfaceID.
I'm currently on gstreamer 1.14.0, libva 2.1.0, intel-vaapi-driver 2.1.0,
kernel 4.12.14 and the CPU is a Intel(R) Celeron(R) CPU 3965U @ 2.20GHz.
Any suggestion on how to debug this issue?
Enable LIBVA_TRACE is not viable because it will exhaust the space in a
couple of hours.
I should try to update to the latest libva, intel-vaapi-driver?
Best
Matteo Valdina
3 years, 11 months
