Quoting James Almer (2024-09-15 00:12:52) > (is there a reason you wanted the view_id side data and this one > applied to the frame before get_buffer()?),
So that the caller knows what view is get_buffer() called for. > As this is now being called before ff_progress_frame_get_buffer() it > became a no-op and any stereo 3d side data in the input packet will be > appended to the frame, resulting in something like: > > > [Parsed_showinfo_0 @ 00000281481551c0] side data - View ID: view id: 0 > > [Parsed_showinfo_0 @ 00000281481551c0] side data - Stereo 3D: type - > > frame alternate, view - right, primary_eye - none > > [Parsed_showinfo_0 @ 00000281481551c0] side data - Spherical Mapping: > > rectilinear > > [Parsed_showinfo_0 @ 00000281481551c0] side data - Stereo 3D: type - > > unspecified, view - packed, primary_eye - none, baseline: 19240, > > horizontal_disparity_adjustment: 0.0200, horizontal_field_of_view: 63.400 > > We don't really want to lose the information that's coded in the > container but not in the bitstream (Which happened in the previous > version of the patch too), so we should instead amend the container > level side data with the bitstream information. > > Something like: That results in this information NOT being available to caller in get_buffer(). The least bad solution I see is have ff_decode_frame_props() merge container information into existing side data, if set. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
