After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756816 - libs: initialize h264 and h265 parse info structures
libs: initialize h264 and h265 parse info structures
Status: RESOLVED NOTABUG
Product: gstreamer-vaapi
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-10-19 16:27 UTC by Víctor Manuel Jáquez Leal
Modified: 2015-10-20 14:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decoder: h264, h265: initializate parser info (1.70 KB, patch)
2015-10-19 16:27 UTC, Víctor Manuel Jáquez Leal
rejected Details | Review

Description Víctor Manuel Jáquez Leal 2015-10-19 16:27:01 UTC
Instead of only allocating the parser info structures for h264 and h265, they also should be initialized to zero, to avoid process garbage data.

Others parser don't use gstvaapminiobject based structures for their parser info.
Comment 1 Víctor Manuel Jáquez Leal 2015-10-19 16:27:47 UTC
Created attachment 313676 [details] [review]
decoder: h264, h265: initializate parser info

Instead of only allocating the parser info structures for h264 and h265,
they also should be initialized to zero, to avoid process garbage data.
Comment 2 Víctor Manuel Jáquez Leal 2015-10-19 16:30:07 UTC
I had this patch floating around. It is better if it's posted for review :)
Comment 3 sreerenj 2015-10-19 21:09:33 UTC
Review of attachment 313676 [details] [review]:

The gst_vaapi_parser_info_h264/h265_new() is getting invoked a number of times for each frame,,so basically at least 30 times in one second for 30fps stream ...It could be much more than that based on the number of slices, nal units per frame etc...
I wouldn't prefer to add an overhead of *N* memset() per second unless there is a real reason to add... :)
Comment 4 Víctor Manuel Jáquez Leal 2015-10-20 11:28:52 UTC
(In reply to sreerenj from comment #3)
> Review of attachment 313676 [details] [review] [review]:
> 
> The gst_vaapi_parser_info_h264/h265_new() is getting invoked a number of
> times for each frame,,so basically at least 30 times in one second for 30fps
> stream ...It could be much more than that based on the number of slices, nal
> units per frame etc...
> I wouldn't prefer to add an overhead of *N* memset() per second unless there
> is a real reason to add... :)

Wow...

Wouldn't be better allocate a pool of those structures and reuse them???
Comment 5 sreerenj 2015-10-20 11:56:48 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #4)
> (In reply to sreerenj from comment #3)
> > Review of attachment 313676 [details] [review] [review] [review]:
> > 
> > The gst_vaapi_parser_info_h264/h265_new() is getting invoked a number of
> > times for each frame,,so basically at least 30 times in one second for 30fps
> > stream ...It could be much more than that based on the number of slices, nal
> > units per frame etc...
> > I wouldn't prefer to add an overhead of *N* memset() per second unless there
> > is a real reason to add... :)
> 
> Wow...
> 
> Wouldn't be better allocate a pool of those structures and reuse them???

-- this will complicate things further
-- we can't predict the number of slices in a frame in advance
-- we can't predict the number of non-VCL nal units in a frame
-- the current implementation is optimized for multiple purposes
Comment 6 Víctor Manuel Jáquez Leal 2015-10-20 14:19:51 UTC
(In reply to sreerenj from comment #5)
> 
> -- this will complicate things further
> -- we can't predict the number of slices in a frame in advance
> -- we can't predict the number of non-VCL nal units in a frame
> -- the current implementation is optimized for multiple purposes

Roger!

Since bug 755161 is going to be merged and closed soon, this doesn't make sense. Closing then.

Thanks Sree!