On Wed, Sep 10, 2014 at 10:47:12PM +0200, Tomas Härdin wrote: > 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. yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
