Quoting James Almer (2024-06-22 04:41:11) > Given that a video stream/frame may have only one view coded, or both packed > in > an undefined way, and as the values of AVStereo3DView and AVStereo3DType may > clash (namely if type is AV_STEREO3D_2D, then AV_STEREO3D_VIEW_PACKED would be > invalid, and if it's anything other than it, then only AV_STEREO3D_VIEW_PACKED > would be valid), this commit adds a new type value AV_STEREO3D_VIEW that > signals the user that AVStereo3D.view contains information about the nature of > the stream, with the added constrain that AVStereo3D.view should be ignored if > AVStereo3D.type is anything other than AV_STEREO3D_VIEW. > > Signed-off-by: James Almer <jamr...@gmail.com> > --- > This is the only way i could think of to work around the fact AVStereo3DType > and AVStereo3DView just can't work well together if we want to keep AVStereo > backwards compatible.
I don't really see what actual problem is this supposed to address, rather it seems to me it just muddles the situation further. When type is AV_STEREO3D_2D, the video is monoscopic and everything else in AVStereo3D should be ignored. In this light I also don't see the point of patch 1. Nontrivial values of AVStereo3DView are meaningful only for a stereoscopic non-packed video, i.e. AV_STEREO3D_FRAMESEQUENCE. -- 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".
