GNOME Bugzilla – Bug 756816
libs: initialize h264 and h265 parse info structures
Last modified: 2015-10-20 14:19:51 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.
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.
I had this patch floating around. It is better if it's posted for review :)
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... :)
(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???
(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
(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!