On Sat, Jan 28, 2017 at 4:13 AM, James Almer <jamr...@gmail.com> wrote: > On 1/27/2017 11:21 PM, Aaron Colwell wrote: >> On Fri, Jan 27, 2017 at 5:46 PM James Almer <jamr...@gmail.com> wrote: >> >> yeah. I'm a little confused why the demuxing code didn't implement this to >> begin with. > > Vittorio (The one that implemented AVSphericalMapping) tried to add this at > first, but then removed it because he wasn't sure if he was doing it right.
Hi, yes this was included initially but then we found out what those fields were really for, and I didn't want to make the users get as confused as we were. As a matter of fact Aaron I mentioned this to you when I proposed that we probably should have separated the classic equi projection from the tiled one in the specification, in order to simplify the implementation. >>> I know you're the one behind the spec in question, but wouldn't it be a >>> better idea to wait until AVSphericalMapping gets a way to propagate this >>> kind of information before adding support for muxing video projection >>> elements? Or maybe try to implement it right now... >>> >> >> I'm happy to implement support for the projection specific info. What would >> be the best way to proceed. It seems like I could just place a union with >> projection specific structs in AVSphericalMapping. I'd also like some > > I'm CCing Vittorio so he can chim in. I personally have no real preference. The best way in my opinion is to add a third type, such as AV_SPHERICAL_TILED_EQUI, and add the relevant fields in AVSphericalMapping, with a clear description about the actual use case for them, mentioning that they are used only in format. By the way, why do you mention adding a union? I think four plain fields should do. Please keep me in CC. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
