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 <[email protected]> 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 <[email protected]> > 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 < >> <[email protected]>[email protected]> 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 < >>> <[email protected]>[email protected]> 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 >>>> [email protected]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 >>>> [email protected] >>>> 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)
_______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
