GNOME Bugzilla – Bug 785985
vaapi decoder/h264parse: renegotiation always happens whenever SPS/SPS subset arrives in case of MVC stream
Last modified: 2018-11-03 15:51:06 UTC
Reproduce step (should be on the master): 1\ Produces MVC stream gst-launch-1.0 -v videotestsrc pattern=ball name=left \ videotestsrc name=right glstereomix name=mix \ left. ! video/x-raw,width=640,height=480! glupload ! mix. \ right. ! video/x-raw,width=640,height=480! glupload ! mix. \ mix. ! video/x-raw'(memory:GLMemory)',multiview-mode=frame-by-frame ! \ queue ! glcolorconvert ! gldownload ! vaapih264enc num-views=2 ! filesink location=output_va.264 2\ Play the stream with glimagesink gst-play-1.0 output_va.264 --videosink="glimagesink output-multiview-mode=side-by-side" The produced stream by vaapih264enc contains IDR following SPS/SPS subset periodically (per every 1 sec), which leads to renegotiation from h264parse whenever SPS/SPS subset arrives in the middle of stream. Because h264parse determines whether to update src cpas or not with current src caps, which is always different from current sps. For example, If current sps is SPS for base view, current src caps is from sps subset. If curresnt sps is SPS subset for dependant view, current src caps is from sps. So h264parse always updates src caps to profile high if SPS, and then updates to profile stereo-high again if sps susbset. I expect this shouldn't happen if it's on the same stream. Does h264parse need to something more for this case? Or decoder should be handling this case?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/65.