[FFmpeg-devel] MXF : default fied dominance is TFF

[Michael Niedermayer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140911/4cab1c1f/attachment.asc>