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".

Reply via email to