)]}' { "commit": "32f227bd8502d660266c008a9ef0872c0ac776fb", "tree": "93fcda610ce61739769e70a0781107dfdf635fd1", "parents": [ "da05532a51f15c223663c6c8912dfc513d1e01f3" ], "author": { "name": "Jonas Larsson", "email": "ljonas@google.com", "time": "Fri Mar 01 16:06:00 2019 -0800" }, "committer": { "name": "Jonas Larsson", "email": "ljonas@google.com", "time": "Fri Mar 01 16:32:30 2019 -0800" }, "message": "Fix cropping support to work like rest of GStreamer\n\nVPU must decode video to buffers with sizes that are even multiples\nof block size. For example, a 1080p h264 video is always encoded\n1088 px high (68*16\u003d1088), with cropping specified in the SPS.\nThere are also other HW imposed dimensional constraints.\n\nNXPs cropping strategy has been to output the entire padded frame,\nwith garbage on the right/bottom, plus a VideoCropMeta rectangle.\nThere are multiple problems with this. Basically no standard\nelements supports VideoCropMeta and the ones that do are only\ndisplay sinks. No filters like mixers and no support for GL\nelements beyond the basic glimagesink. appsinks need to handle\ncropping, GstDiscoverer is broken as it reports the padded and\nwrong dimensions for source media.\n\nNXP added flawed support in glupload to account for the crop\nbut that broke the standard rules of caps negotiation and with\nthat all GL filters. Instead of patching the\nsupposed-to-be-standard GStreamer framework let\u0027s fix this at\nthe source, the decoder.\n\nThe cropping rectangle is virtually never needed. As long as\nthe output frame is anchored at 0,0, or there\u0027s no crop at the\nleft/top, cropping is really just the same as modified stride\nand height.\n\nGstVideoDecoder supports different caps for output and allocation,\nNXP used the same for both. We start by allocating the full padded\nframe but we report the cropped dimensions in negotiations.\nWhen a frame as been decoded into the padded buffer we change\nthe VideoMeta dimensions to the cropped ones before pushing.\nThe pushed buffer still has the strides and plane offsets of the\npadded buffer, therefore standard functions like\ngst_video_frame_map that\u0027s used in all sinks and other standard\nelements work just fine.\n\nIn the event that cropping is done to the top/left we fall back to\nthe padded frame dimensions plus crop rectangle. I\u0027ve never seen\na video file with left/top cropping, or an encoder that produces\nthem.\n\nChange-Id: I20fa53dbaf7a6bebeae9e68655ba9ae030fdb2cb\n", "tree_diff": [ { "type": "modify", "old_id": "6b4982fcd585254b6699f8bfb7b44f8ad7d66d17", "old_mode": 33261, "old_path": "plugins/vpu/gstvpudecobject.c", "new_id": "46d6fc46429ce3979cafc563a76baa49fdf7ebff", "new_mode": 33261, "new_path": "plugins/vpu/gstvpudecobject.c" } ] }