[Libva] Compilation of vaapiparse elements
Engin Firat
engin.firat at adonissyazilim.com
Fri Sep 11 09:38:45 PDT 2015
Okey thank you so much.
For ones interested in 1080p decode problem a bug is filed:
https://bugzilla.gnome.org/show_bug.cgi?id=754898
On 11 September 2015 at 19:01, Sreerenj <sreerenj.balachandran at intel.com>
wrote:
> Good,,,Go ahead :)
>
>
> On 11.09.2015 18:58, Engin Firat wrote:
>
> It works with software decoder (avdec_h264). I am going to file a bug.
>
> On 11 September 2015 at 18:46, Sreerenj <sreerenj.balachandran at intel.com>
> wrote:
>
>>
>>
>> On 11.09.2015 18:39, Engin Firat wrote:
>>
>> So you are saying that, vaapiparse_h264 and h264parse elements are the
>> same but former one has the last changes since changes to plugins-bad
>> generally integrates late.
>>
>>
>> Right :)
>>
>> And what do you think about 1080p resolution. This will alse be handled
>> in bug #754845 .
>>
>>
>> Does it working with software decoder?? For eg: avdec_h264??? If not ,
>> issue is something else, discuss in gstremaer irc channel #gstreamer or
>> file a bug against upstream gstreamer.
>> If it works fine with avdec_h264 and not with vaapidecode, please file a
>> new bug against gstreamer-vaapi and share the sample too.
>>
>>
>> Regards.
>>
>> On 11 September 2015 at 17:26, Sreerenj <
>> <sreerenj.balachandran at intel.com>sreerenj.balachandran at intel.com> wrote:
>>
>>> 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>
>>> 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>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>
>>>> 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>
>>>> 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 listLibva at lists.freedesktop.orghttp://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
>>>> 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 <%2B90%20506%20884%2082%2007> (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.
>>>
>>
>>
>>
>> --
>> *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.
>>
>
>
>
> --
> *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.
>
--
*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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150911/bdafd6c2/attachment-0001.html>
More information about the Libva
mailing list