GNOME Bugzilla – Bug 732453
encoder: h264: add support for more than 2 views
Last modified: 2015-03-13 01:43:11 UTC
Add support for H.264 MVC Multiview High profile encoding with more than 2 views. All views within the same accesss unit are provided in increasing order of view order index (VOIdx). The mappings to view_id could be provided with an additional gst_vaapi_encoder_h264_set_view_map(), which view_ids = an array of guint16 elements, and a guint parameter which represents the number of views, which must match the associated "num-views" property.
I understood that we can have view_id of any value (0 to 1023) and VOIdx in increasing order. But Why can't we keep it simple just like the current implementation? For eg: Num-views=3 then view_id and VOIdx in increasing order always and it is the duty of user to submit the view in correct order. ?? Is it really needed to provide a user control over view_ids. ?? Dynamically setting the view_id of each input frame is the advanced option, may be use the input GstVideoFrame's id flag value as view_id.Then user supposed to write some code to set the id value in video-frame.
Created attachment 297761 [details] [review] encoder: h264: add support for more than 2 views I have implemented the patch with a new property called "view-ids" which is an array of GVAlues of type guint. Please Let me know if you have any objection.
I think it should be made clear that in the gst-vaapi implementation, view_order_count == viewIdx. Besides, the current design also prevents from supporting inter-view prediction. This is unfortunate, because this is where additional compression gain could be obtained, especially for stereo-high-profile. This means that the way reference frames are maintained may need to be changed.
Having said that, based on your patch, we can now say that VA surfaces sent for encoding implies on the view order count, and your new array can now correctly be used to assign the view-ids. However, in this case, the array of view_ids needs to be correctly updated in the generated stream too. :) (packed headers)
(In reply to Gwenole Beauchesne from comment #3) > I think it should be made clear that in the gst-vaapi implementation, > view_order_count == viewIdx. > Agreed > Besides, the current design also prevents from supporting inter-view > prediction. This is unfortunate, because this is where additional > compression gain could be obtained, especially for stereo-high-profile. This > means that the way reference frames are maintained may need to be changed. Adding inter-view prediction support need more changes. I was thinking to create a new report for the same.
(In reply to Gwenole Beauchesne from comment #4) > Having said that, based on your patch, we can now say that VA surfaces sent > for encoding implies on the view order count, and your new array can now > correctly be used to assign the view-ids. However, in this case, the array > of view_ids needs to be correctly updated in the generated stream too. :) > (packed headers) The patch already taking care of the packed header updates..Am i missing something?
I will create another bug report for tracking the interview-prediction support.
commit 3f28da7f5a224178d104992fe902212015dfb2e4 Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Tue Feb 24 17:14:33 2015 +0200 encoder: h264: add support for more than 2 views Add support for H.264 MVC Multiview High profile encoding with more than 2 views. All views within the same accesss unit are provided in increasing order of view order index (VOIdx). Upto 10 view are supported for now. A new property "view-ids" has been provided for the plugins to set the view ids (which is an array of guint values) to be used for mvc encoding. https://bugzilla.gnome.org/show_bug.cgi?id=732453
It worked well on the SKL media driver beta release legacy feature RC version with gstreamer v1.4.5. So verified and closed the issue.