On 4/10/2017 1:20 PM, Vittorio Giovara wrote: > On Mon, Apr 10, 2017 at 11:49 AM, James Almer <jamr...@gmail.com> wrote: >>> In my opinion it would be enough to return int and >>> just AVERROR(EINVAL) in case it's not found. James would you be ok >>> with that, or do you have any preference? >> >> IMO, PROJECTION_UNKNOWN is an interesting addition. >> >> Assume for example a projection we don't currently support shows up in >> a file in the future, both the mov and matroska demuxers would ignore >> it and report the file as having no spherical metadata whatsoever. >> With PROJECTION_UNKNOWN the demuxers could report the presence of said >> metadata (and the generic values yaw/pitch/roll) while clearly stating >> it's unknown. > > I mean, if it's unknown, no demuxer can parse correctly any field: > nothing guarantees that future projections will keep y/p/r in the same > place.
y/p/r are part of the prhd box in ISOBMFF. If that were to change, the version field would be updated (We're currently skipping the version field, so maybe we should add a check right now). Projection specific boxes are currently cbmp, equi and mesh, which makes me realize that we don't even need to think of hypothetical future projections. For mesh files the unknown projection enum would come in handy today. In Matroska, y/p/r are standalone elements that may or may not be present somewhere inside the Spherical master. > Even so, what's the user going to do with knowing the fact that > the video contains spherical metadata it can't parse correctly/fully > support? So, I'm hesitant to add a new type for this uncertain > behaviour, wouldn't you agree? No, because that's the whole point of avprobe, the dump.c code, and other tools using the libraries: Informing the user of the contents and characteristics of their files. avconv and similar tools are what attempt to do something with them, and for unknown projections they would do nothing. libavformat as it is right now will be aware that there's spherical information in such files, but purposely pretend it's not there. I personally think that's not the best behavior. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
