GNOME Bugzilla – Bug 685812
qtdemux: Forward cropping information downstream
Last modified: 2018-11-03 14:47:47 UTC
http://blender-mirror.kino3d.org/peach/bigbuckbunny_movies/big_buck_bunny_480p_h264.mov The demuxer claims width=853 and the h264 has width=854 but the decoded output has no valid data at the last pixel in every line. Some kind of cropping information should be forwarded downstream for this. In 0.10 gst-ffmpeg had code that cropped to the demuxer width/height.
The base video decoder should crop based on the demuxer width/height.
With only the width/height from the demuxer we have not enough information to do cropping correctly. We need at least something like (x, y, width, height).
Bug #693971 is the same about matroska. Bug #694068 about the same in h264parse, bug #740072 the same in h263parse.
There is no x/y value for this case, so there is no need fro cropping. If downstream of the decoder support GstVideoMeta, the decoder can just passthrough that value downstream. If it does not support GstVideoMeta, then gst_video_frame_copy() will do the job. Currently this works with avdec, didn't check if it's fully correct or not. It does not work with v4l2videodec yet, because I only recently learn this case existed. If there is a x/y value exposed, then it's non-trivial, and crop meta would be best. But then you are screwed because demuxers cannot query to know if crop-meta is supported downstream. You have to fix the demuxers, or make this caps feature. This is a big project. Then, you need to port all the decoder to support this.
-- 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/gst-plugins-good/issues/75.