On Tue, 2014-09-09 at 12:37 +0200, Michael Niedermayer wrote: > On Mon, Sep 08, 2014 at 12:17:14PM +0000, Gaullier Nicolas wrote: > > I did not found an easy way to set up initialization values to properly > > handle defaults but I am not a highly skilled developer, and maybe someone > > will find how to implement this more elegantly. > > They are also many other properties in mxf that are only optional, for > > example component depth and horizontal/vertical subsampling factors that > > are actually parsed, but as far from now it does not seem sufficiently > > useful to distinguish between the initialization value '0' and 'not > > present'. > > In my opinion, in the solely case of the field dominance, when it is > > found/set to '0', it seems interesting to fail/raise a warning at least, > > but it is somewhat particular and should not involve a big code refactoring > > to handle this. > > field_dominance could be initilaized to -1 (or some named identifer > that is -1) > and a case -1 be added to the switch()
Initializing to the default value (1 = MXF_TFF) makes more sense. For any illegal value the demuxer should probably complain so the user can complain at whoever wrote the bad muxer they're using. /Tomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
