[Libva] Compilation of vaapiparse elements
Sreerenj
sreerenj.balachandran at intel.com
Fri Sep 11 07:26:52 PDT 2015
Hi,
Check this: https://bugzilla.gnome.org/show_bug.cgi?id=754845 :)
This is a gstreamer related topic, please move any further discussion to
#754845
On 11.09.2015 17:03, Engin Firat wrote:
> Hello Sree,
>
> Thank you for your response. I will file a bug against gstreamer-vaapi.
>
> I have some questions to to get a better view to the problem:
> 1. The built-in codec parsers are developed within gstreamer-vaapi
> element and they have the same code with codecparsers coming from
> gstreamer-bad plugin except they includes some minor patches?
We have gstreamer-codecparsers
(https://github.com/01org/gstreamer-codecparsers) which is for early
enablement. I usually push patches to upstream first and then
cherry-pick from there.
But sometimes upstream is too slow to integrate patches, and I push
directly to our own tree. Also we are supporting multiple gstreamer
versions (1.2, 1.4 and 1.6) in a single gstreamer-vaapi
tree, so you will get more features in built-in codecparsers comparing
with upstream parsers (if you are using older GStreamer versions)
> 2. When built-in codec parsers are enabled, does vaapidecode element
> gain a self parse property?
Irrespective of the enable/disable built-in codecparsers, vaapidecode
will always do parsing by itself ..In practice there is a bottleneck
here, we are doing the parsing twice, once in parser element
and then in vaapidecode. This is a larger topic: more info here:
https://bugzilla.gnome.org/show_bug.cgi?id=691712
https://bugzilla.gnome.org/show_bug.cgi?id=704865
For now the decision is to do parsing inside vaapidecode always :)
> 3. Why we cannot get a vaapiparse_h264 element in case built-in codec
> parsers are enabled (enable-builtin-codecparsers)?
> libgstvaapi_parse.so is correctly linked and loaded but
> vaapiparse_h264 element is not produced.
If you enable builtin-codecparsers, you must get the vaapiparse_h264 !!
(unless you disabled the built-in videoparsers)
if you disable builtin-codecparsers, you should still get
vaapiparse_h264 (unless you disabled the built-in videoparsers), but
there is bug preventing this which we will fix soon
>
> I have been disabling the builtin-codecparsers because I want to get
> vaapiparse_h264 element. The main problem is I cannot decode 1080p
> streaming video coming from an IP camera. The resolutions 720p, 960p
> is okey, but I cannot decode 1080p video and I think that maybe this
> element can be a solution.
>
> My pipeline is: rtspsrc ! rtph264depay ! h264parse ! vaapidecode !
> queue ! vaapisink
>
> The output of the pipeline is in attached file named *gst.out.*
> I have debugged with ddd and saw where is the problem. You can find
> the call stack in attached screen shot.
>
> Could you please assist me what is the problem? Regards.
>
> Regards.
>
>
>
>
> On 9 September 2015 at 11:13, Sreerenj
> <sreerenj.balachandran at intel.com
> <mailto:sreerenj.balachandran at intel.com>> wrote:
>
> Hi Firat,
>
> Thanks for catching this.
> Here the local video parser plugin (libgstvaapi_parse.so) is only
> trying to link against the local(builtin) codec parser library.
> But since you disabled the builtin-codecparser at compile time
> ,the videoparsersesr is not getting the link correctly.
>
> Fix is needed in gst/vaapi/Makefile.am,,,
>
> BTW, why can't you use the builtin-codecparsers?? We always make
> sure the built-in codecparsers are up to date with upstream..
> Also if someone uses older GStreamer versions, I prefer using the
> built-in codecparsers since upstream is missing some patches...
>
> Could you please file a bug against gstreamer-vaapi
> :https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi..
> I will fix it, or you can attach the patch too :)
>
>
> On 08.09.2015 19:54, Engin Firat wrote:
>> Hello all,
>>
>> I have written the same problem before gstreamer-devel forum but
>> I cannot find any support to assist me in this problem. So I am
>> writing here, expecting to find some support here.
>>
>> Here is the link to post in gstreamer-devel forum.
>>
>> http://gstreamer-devel.966125.n4.nabble.com/Compilation-of-gstreamer-vaapi-from-source-tc4673454.html
>>
>> Meanwhile I have been working on problem and I want to share a
>> more detailed version of the problem:
>>
>> I have compiled gstreamer, gstreamer-base and gstreamer-bad of
>> versions 1.5.90.
>> I have compiled gstreamer-vaapi 0.6.0 version. Before compilation
>> I have been using the following flags to configure the library:
>>
>> *./configure --prefix=/usr/local --enable-builtin-videoparsers
>> --enable-builtin-codecparsers=no --enable-encoders*
>> *
>> *
>> The library was compiled successfully and I have installed it.
>> After installation I run the following command:
>> *$ gst-inspect-1.0 -b*
>>
>> and I got the following output:
>> *(gst-plugin-scanner:26005): GStreamer-WARNING **: Failed to load
>> plugin '/usr/local/lib/gstreamer-1.0/libgstvaapi_parse.so':
>> /usr/local/lib/gstreamer-1.0/libgstvaapi_parse.so: undefined
>> symbol: gst_h265_parser_free*
>> *Blacklisted files:*
>> * libgstvaapi_parse.so*
>> *
>> *
>> I control the file *libgstvaapi_parse.so* *, *the following is
>> portion of output that contains h265 word:
>>
>> *000000000001c3b0 t gst_h265_parse_class_intern_init*
>> *000000000001da80 t gst_h265_parse_event*
>> *000000000001d880 t gst_h265_parse_finalize*
>> *000000000001c720 t gst_h265_parse_format_from_caps*
>> *000000000001c640 t gst_h265_parse_get_caps*
>> *000000000001dc90 t gst_h265_parse_get_property*
>> *000000000001d8b0 t gst_h265_parse_get_string.isra.1.part.2*
>> *00000000000229b0 t gst_h265_parse_get_type*
>> *000000000001f480 t gst_h265_parse_handle_frame*
>> *000000000001c380 t gst_h265_parse_init*
>> *000000000001ddb0 t gst_h265_parse_negotiate*
>> *000000000022dfd8 b gst_h265_parse_parent_class*
>> *000000000001f380 t gst_h265_parse_parse_frame*
>> *0000000000020bf0 t gst_h265_parse_pre_push_frame*
>> *000000000022dfd0 b GstH265Parse_private_offset*
>> *000000000001cc20 t gst_h265_parse_process_nal*
>> *000000000001d500 t gst_h265_parse_push_codec_buffer*
>> *000000000001d620 t gst_h265_parse_reset*
>> *000000000001d570 t gst_h265_parse_reset_frame*
>> * U gst_h265_parser_free*
>> * U gst_h265_parser_identify_nalu*
>> * U gst_h265_parser_identify_nalu_hevc*
>> * U gst_h265_parser_identify_nalu_unchecked*
>> * U gst_h265_parser_new*
>> * U gst_h265_parser_parse_nal*
>> * U gst_h265_parser_parse_pps*
>> * U gst_h265_parser_parse_slice_hdr*
>> * U gst_h265_parser_parse_sps*
>> * U gst_h265_parser_parse_vps*
>> *000000000001c900 t gst_h265_parser_store_nal*
>> *0000000000020610 t gst_h265_parse_set_caps*
>> *000000000001dd20 t gst_h265_parse_set_property*
>> *000000000001d8e0 t gst_h265_parse_src_event*
>> *000000000001d800 t gst_h265_parse_start*
>> *000000000001d710 t gst_h265_parse_stop*
>> *000000000001e060 t gst_h265_parse_update_src_caps*
>> *000000000001cb20 t gst_h265_parse_wrap_nal*
>> * U gst_h265_slice_hdr_free*
>> *
>> *
>> It seems that, the symbol *gst_h265_parser_free *actually is not
>> undefined. However this is normal in circumstances where this
>> undefined symbol is defined somewhere else. So I have controlled
>> the ldd output of the *libgstvaapi_parse.so* file to see the
>> external dependencies:
>>
>> *$ ldd libgstvaapi_parse.so *
>> *
>> *
>> The following is the output:
>> *
>> *
>> *linux-vdso.so.1 => (0x00007fffe5aa6000)*
>> *libgstcodecparsers_vpx.so.0 =>
>> /usr/local/lib/libgstcodecparsers_vpx.so.0 (0x00007faec7ba9000)*
>> *libgstvideo-1.0.so.0 => /usr/local/lib/libgstvideo-1.0.so.0
>> (0x00007faec793c000)*
>> *libgstbase-1.0.so.0 => /usr/local/lib/libgstbase-1.0.so.0
>> (0x00007faec76de000)*
>> *libgstreamer-1.0.so.0 => /usr/local/lib/libgstreamer-1.0.so.0
>> (0x00007faec73c4000)*
>> *libgobject-2.0.so.0 =>
>> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007faec7173000)*
>> *libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
>> (0x00007faec6e6a000)*
>> *libgstpbutils-1.0.so.0 => /usr/local/lib/libgstpbutils-1.0.so.0
>> (0x00007faec6c40000)*
>> *libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> (0x00007faec6a22000)*
>> *libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faec665b000)*
>> *libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faec6355000)*
>> *libgmodule-2.0.so.0 =>
>> /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007faec6151000)*
>> *librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faec5f48000)*
>> *libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faec5d44000)*
>> *libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
>> (0x00007faec5b3c000)*
>> *libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
>> (0x00007faec58fd000)*
>> *libgstaudio-1.0.so.0 => /usr/local/lib/libgstaudio-1.0.so.0
>> (0x00007faec56b3000)*
>> */lib64/ld-linux-x86-64.so.2 (0x00007faec8045000)*
>> *libgsttag-1.0.so.0 => /usr/local/lib/libgsttag-1.0.so.0
>> (0x00007faec5479000)*
>> *libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faec5260000)*
>>
>>
>> I have found that the symbol is defined in
>> *libgstcodecparsers-1.0.so <http://libgstcodecparsers-1.0.so>
>> *but libgstvaapi_parse.so does not have any dependency on this
>> library nor files it is depended.
>>
>> Could you please help me to find the problem?
>>
>> Regards.
>>
>>
>> _______________________________________________
>> Libva mailing list
>> Libva at lists.freedesktop.org <mailto:Libva at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/libva
>
> --
> Thanks
> Sree
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> Libva mailing list
> Libva at lists.freedesktop.org <mailto:Libva at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/libva
>
>
>
>
> --
> *Engin FIRAT*
> Adoniss Yazılım Bilişim
> Elektronik Araştırma Geliştirme
> Limited Şirketi
>
> +90 506 884 82 07 (Mobile)
>
> ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi
> İnönü Bulvarı / ANKARA (Address)
>
>
--
Thanks
Sree
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150911/ef119142/attachment-0001.html>
More information about the Libva
mailing list