<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
Check this: <a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/show_bug.cgi?id=754845">https://bugzilla.gnome.org/show_bug.cgi?id=754845</a> :)<br>
<br>
This is a gstreamer related topic, please move any further
discussion to #754845<br>
<br>
<div class="moz-cite-prefix">On 11.09.2015 17:03, Engin Firat wrote:<br>
</div>
<blockquote
cite="mid:CACVgt24zGq9hGDCZkOtaHbsqD_zLpbvX8PnDxbcQmCU2AQ_RmA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Hello Sree,
<div><br>
</div>
<div>Thank you for your response. I will file a bug against
gstreamer-vaapi.</div>
<div><br>
</div>
<div>I have some questions to to get a better view to the
problem:</div>
<div>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?</div>
</div>
</blockquote>
<br>
We have gstreamer-codecparsers
(<a class="moz-txt-link-freetext" href="https://github.com/01org/gstreamer-codecparsers">https://github.com/01org/gstreamer-codecparsers</a>) which is for early
enablement. I usually push patches to upstream first and then
cherry-pick from there.<br>
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<br>
tree, so you will get more features in built-in codecparsers
comparing with upstream parsers (if you are using older GStreamer
versions)<br>
<br>
<blockquote
cite="mid:CACVgt24zGq9hGDCZkOtaHbsqD_zLpbvX8PnDxbcQmCU2AQ_RmA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>2. When built-in codec parsers are enabled, does
vaapidecode element gain a self parse property?</div>
</div>
</blockquote>
<br>
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<br>
and then in vaapidecode. This is a larger topic: more info here:<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/show_bug.cgi?id=691712">https://bugzilla.gnome.org/show_bug.cgi?id=691712</a><br>
<a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/show_bug.cgi?id=704865">https://bugzilla.gnome.org/show_bug.cgi?id=704865</a><br>
<br>
For now the decision is to do parsing inside vaapidecode always :)<br>
<br>
<blockquote
cite="mid:CACVgt24zGq9hGDCZkOtaHbsqD_zLpbvX8PnDxbcQmCU2AQ_RmA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
<br>
If you enable builtin-codecparsers, you must get the vaapiparse_h264
!! (unless you disabled the built-in videoparsers)<br>
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<br>
<br>
<blockquote
cite="mid:CACVgt24zGq9hGDCZkOtaHbsqD_zLpbvX8PnDxbcQmCU2AQ_RmA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>My pipeline is: rtspsrc ! rtph264depay ! h264parse !
vaapidecode ! queue ! vaapisink</div>
<div><br>
</div>
<div>The output of the pipeline is in attached file named <b>gst.out.</b></div>
<div>I have debugged with ddd and saw where is the problem. You
can find the call stack in attached screen shot.</div>
<div><br>
</div>
<div>Could you please assist me what is the problem? Regards.</div>
<div><br>
</div>
<div>Regards.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 September 2015 at 11:13, Sreerenj
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sreerenj.balachandran@intel.com"
target="_blank">sreerenj.balachandran@intel.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi Firat,<br>
<br>
Thanks for catching this.<br>
Here the local video parser plugin (libgstvaapi_parse.so)
is only trying to link against the local(builtin) codec
parser library.<br>
But since you disabled the builtin-codecparser at compile
time ,the videoparsersesr is not getting the link
correctly.<br>
<br>
Fix is needed in gst/vaapi/Makefile.am,,,<br>
<br>
BTW, why can't you use the builtin-codecparsers?? We
always make sure the built-in codecparsers are up to date
with upstream..<br>
Also if someone uses older GStreamer versions, I prefer
using the built-in codecparsers since upstream is missing
some patches...<br>
<br>
Could you please file a bug against gstreamer-vaapi :<a
moz-do-not-send="true"
href="https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi"
target="_blank"><a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi">https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi</a></a>..<br>
I will fix it, or you can attach the patch too :)
<div>
<div class="h5"><br>
<br>
<div>On 08.09.2015 19:54, Engin Firat wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Here is the link to post in gstreamer-devel
forum.</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://gstreamer-devel.966125.n4.nabble.com/Compilation-of-gstreamer-vaapi-from-source-tc4673454.html"
target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Compilation-of-gstreamer-vaapi-from-source-tc4673454.html</a><br>
</div>
<div><br>
</div>
<div>Meanwhile I have been working on problem and
I want to share a more detailed version of the
problem:</div>
<div><br>
</div>
<div>I have compiled gstreamer, gstreamer-base and
gstreamer-bad of versions 1.5.90.</div>
<div>I have compiled gstreamer-vaapi 0.6.0
version. Before compilation I have been using
the following flags to configure the library:</div>
<div><br>
</div>
<div><b>./configure --prefix=/usr/local
--enable-builtin-videoparsers
--enable-builtin-codecparsers=no
--enable-encoders</b><br>
</div>
<div><b><br>
</b></div>
<div>The library was compiled successfully and I
have installed it. After installation I run the
following command:</div>
<div><b>$ gst-inspect-1.0 -b</b><br>
</div>
<div><br>
</div>
<div>and I got the following output:</div>
<div>
<div><b>(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</b></div>
<div><b>Blacklisted files:</b></div>
<div><b> libgstvaapi_parse.so</b></div>
<div><b><br>
</b></div>
<div>I control the file <b>libgstvaapi_parse.so</b> <b>,
</b>the following is portion of output that
contains h265 word:</div>
<div><br>
</div>
<div>
<div><b>000000000001c3b0 t
gst_h265_parse_class_intern_init</b></div>
<div><b>000000000001da80 t
gst_h265_parse_event</b></div>
<div><b>000000000001d880 t
gst_h265_parse_finalize</b></div>
<div><b>000000000001c720 t
gst_h265_parse_format_from_caps</b></div>
<div><b>000000000001c640 t
gst_h265_parse_get_caps</b></div>
<div><b>000000000001dc90 t
gst_h265_parse_get_property</b></div>
<div><b>000000000001d8b0 t
gst_h265_parse_get_string.isra.1.part.2</b></div>
<div><b>00000000000229b0 t
gst_h265_parse_get_type</b></div>
<div><b>000000000001f480 t
gst_h265_parse_handle_frame</b></div>
<div><b>000000000001c380 t gst_h265_parse_init</b></div>
<div><b>000000000001ddb0 t
gst_h265_parse_negotiate</b></div>
<div><b>000000000022dfd8 b
gst_h265_parse_parent_class</b></div>
<div><b>000000000001f380 t
gst_h265_parse_parse_frame</b></div>
<div><b>0000000000020bf0 t
gst_h265_parse_pre_push_frame</b></div>
<div><b>000000000022dfd0 b
GstH265Parse_private_offset</b></div>
<div><b>000000000001cc20 t
gst_h265_parse_process_nal</b></div>
<div><b>000000000001d500 t
gst_h265_parse_push_codec_buffer</b></div>
<div><b>000000000001d620 t
gst_h265_parse_reset</b></div>
<div><b>000000000001d570 t
gst_h265_parse_reset_frame</b></div>
<div><b> U
gst_h265_parser_free</b></div>
<div><b> U
gst_h265_parser_identify_nalu</b></div>
<div><b> U
gst_h265_parser_identify_nalu_hevc</b></div>
<div><b> U
gst_h265_parser_identify_nalu_unchecked</b></div>
<div><b> U gst_h265_parser_new</b></div>
<div><b> U
gst_h265_parser_parse_nal</b></div>
<div><b> U
gst_h265_parser_parse_pps</b></div>
<div><b> U
gst_h265_parser_parse_slice_hdr</b></div>
<div><b> U
gst_h265_parser_parse_sps</b></div>
<div><b> U
gst_h265_parser_parse_vps</b></div>
<div><b>000000000001c900 t
gst_h265_parser_store_nal</b></div>
<div><b>0000000000020610 t
gst_h265_parse_set_caps</b></div>
<div><b>000000000001dd20 t
gst_h265_parse_set_property</b></div>
<div><b>000000000001d8e0 t
gst_h265_parse_src_event</b></div>
<div><b>000000000001d800 t
gst_h265_parse_start</b></div>
<div><b>000000000001d710 t gst_h265_parse_stop</b></div>
<div><b>000000000001e060 t
gst_h265_parse_update_src_caps</b></div>
<div><b>000000000001cb20 t
gst_h265_parse_wrap_nal</b></div>
<div><b> U
gst_h265_slice_hdr_free</b></div>
</div>
<div><b><br>
</b></div>
<div>It seems that, the symbol <b>gst_h265_parser_free
</b>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 <b>libgstvaapi_parse.so</b> file
to see the external dependencies:</div>
<div><br>
</div>
<div>
<div><b>$ ldd libgstvaapi_parse.so </b></div>
<div><b><br>
</b></div>
<div>The following is the output:</div>
<div><b><br>
</b></div>
<div><b><span style="white-space:pre-wrap"> </span>linux-vdso.so.1
=> (0x00007fffe5aa6000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstcodecparsers_vpx.so.0
=>
/usr/local/lib/libgstcodecparsers_vpx.so.0
(0x00007faec7ba9000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstvideo-1.0.so.0
=> /usr/local/lib/libgstvideo-1.0.so.0
(0x00007faec793c000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstbase-1.0.so.0
=> /usr/local/lib/libgstbase-1.0.so.0
(0x00007faec76de000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstreamer-1.0.so.0
=> /usr/local/lib/libgstreamer-1.0.so.0
(0x00007faec73c4000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgobject-2.0.so.0
=>
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x00007faec7173000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libglib-2.0.so.0
=>
/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x00007faec6e6a000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstpbutils-1.0.so.0
=>
/usr/local/lib/libgstpbutils-1.0.so.0
(0x00007faec6c40000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libpthread.so.0
=>
/lib/x86_64-linux-gnu/libpthread.so.0
(0x00007faec6a22000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libc.so.6
=> /lib/x86_64-linux-gnu/libc.so.6
(0x00007faec665b000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libm.so.6
=> /lib/x86_64-linux-gnu/libm.so.6
(0x00007faec6355000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgmodule-2.0.so.0
=>
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x00007faec6151000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>librt.so.1
=> /lib/x86_64-linux-gnu/librt.so.1
(0x00007faec5f48000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libdl.so.2
=> /lib/x86_64-linux-gnu/libdl.so.2
(0x00007faec5d44000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libffi.so.6
=>
/usr/lib/x86_64-linux-gnu/libffi.so.6
(0x00007faec5b3c000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libpcre.so.3
=> /lib/x86_64-linux-gnu/libpcre.so.3
(0x00007faec58fd000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgstaudio-1.0.so.0
=> /usr/local/lib/libgstaudio-1.0.so.0
(0x00007faec56b3000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>/lib64/ld-linux-x86-64.so.2
(0x00007faec8045000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libgsttag-1.0.so.0
=> /usr/local/lib/libgsttag-1.0.so.0
(0x00007faec5479000)</b></div>
<div><b><span style="white-space:pre-wrap"> </span>libz.so.1
=> /lib/x86_64-linux-gnu/libz.so.1
(0x00007faec5260000)</b></div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>I have found that the symbol is defined in <b><a
moz-do-not-send="true"
href="http://libgstcodecparsers-1.0.so"
target="_blank">libgstcodecparsers-1.0.so</a>
</b>but libgstvaapi_parse.so does not have any
dependency on this library nor files it is
depended. </div>
<div><br>
</div>
<div>Could you please help me to find the
problem?</div>
<div><br>
</div>
<div>Regards.</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Libva mailing list
<a moz-do-not-send="true" href="mailto:Libva@lists.freedesktop.org" target="_blank">Libva@lists.freedesktop.org</a>
<a moz-do-not-send="true" href="http://lists.freedesktop.org/mailman/listinfo/libva" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libva</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Thanks
Sree</pre>
<p>---------------------------------------------------------------------<br>
Intel Finland Oy<br>
Registered Address: PL 281, 00181 Helsinki <br>
Business Identity Code: 0357606 - 4 <br>
Domiciled in Helsinki </p>
<p>This e-mail and any attachments may contain
confidential material for<br>
the sole use of the intended recipient(s). Any review or
distribution<br>
by others is strictly prohibited. If you are not the
intended<br>
recipient, please contact the sender and delete all
copies.</p>
</div>
<br>
_______________________________________________<br>
Libva mailing list<br>
<a moz-do-not-send="true"
href="mailto:Libva@lists.freedesktop.org">Libva@lists.freedesktop.org</a><br>
<a moz-do-not-send="true"
href="http://lists.freedesktop.org/mailman/listinfo/libva"
rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libva</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div><b style="font-family:arial,helvetica,sans-serif"><span
style="border-collapse:collapse;font-family:arial,sans-serif">Engin
FIRAT</span></b></div>
<span>
<div><font size="1">Adoniss Yazılım Bilişim </font></div>
<div><font size="1">Elektronik </font><span
style="font-size:x-small">Araştırma Geliştirme </span></div>
<div><font size="1">Limited Şirketi</font></div>
<div>
<p
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;margin:0px"><font
size="1">+90 506 884 82 07 (Mobile)</font></p>
<font size="1">ODTÜ Teknokent, </font><span
style="font-size:x-small">ODTÜ-Halıcı Yazılımevi </span></div>
<div><span style="font-size:x-small">İnönü Bulvarı /
ANKARA (Address)</span></div>
<div>
<p
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;margin:0px"><font
size="1"><img moz-do-not-send="true"
src="http://gdurl.com/hml0"><br>
</font></p>
</div>
</span></div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thanks
Sree</pre>
<p>---------------------------------------------------------------------<br>
Intel Finland Oy<br>
Registered Address: PL 281, 00181 Helsinki <br>
Business Identity Code: 0357606 - 4 <br>
Domiciled in Helsinki </p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>