mxflib-developers — All MXFLib developers

RE: [Mxflib-developers] Coding style

[Stuart C. <st...@rd...>]

Yes.  I think the most important cataloguing would be into those areas
where there are potential bugs (or known bad behaviour) and those areas
where there is missing functionality or optimisation needed.  Perhaps
during such a process we should mark such areas with "FIXME" and "TODO"
respectively.

Large projects like Gnome don't release a minor version until all
FIXMEs are fixed, and won't release a major version until all TODOs
are addressed.

Stuart

On Tue, 2004-04-27 at 12:54, Oliver Morgan wrote:
> More to the point: we need a concerted program to catalog them, eliminate
> the worst, and eventually resolve all of them - whatever they are called.
> 
> Cataloguing them is easier if they are all marked the same way. Consistency
> is good. "dragons" is as good as anything for now.
> 
> Oliver
> 
> > -----Original Message-----
> > From: mxf...@li... 
> > [mailto:mxf...@li...] On 
> > Behalf Of Stuart Cunningham
> > Sent: Tuesday, April 27, 2004 7:40 AM
> > To: Matt Beard
> > Cc: mxf...@li...
> > Subject: Re: [Mxflib-developers] Coding style
> > 
> > On Tue, 2004-04-27 at 12:06, Matt Beard wrote:
> > > Developers,
> > > 
> > > Can we try and keep a consistent coding style.  My main two 
> > gripes are that 
> > > we all stick to the "DRAGONS:" tag for any code that needs 
> > attention in the 
> > > (near) future and that we all maintain the doxygen 
> > documentation tags.
> > 
> > I, a number of my colleagues and even developers we have met 
> > at NAB and
> > the recent LinuxUser & Developer Expo, have remarked about the use
> > of "DRAGONS" in the MXFlib source.  Our complaints include:
> >   "FIXME" and "TODO" are the more conventional and well-known tags
> >   marking code that needs attention.  Editors such as emacs and gvim
> >   have specific markup support for these tags.  "FIXME" is described
> >   in the Jargon File:
> >     http://www.catb.org/~esr/jargon/html/F/FIXME.html
> > 
> >   We have noticed that "DRAGONS" has been used in cases where "TODO"
> >   is appropriate - i.e. the code works as it is, but there is missing
> >   functionality, or the code could be optimised with more work.
> > 
> >   For Unix developers "DRAGONS" means a program similar to
> >   a daemon, such as cron, so its use in comments of source code for
> >   executables or libraries can be ambiguous.  The Jargon File 
> > describes
> >   this usage of "DRAGONS".
> > 
> > I would suggest we try to make MXFlib appeal to the widest 
> > possible set
> > of developers.  I believe this would mean using conventions used in
> > the Free Software and Open Source Software communities.  Of course,
> > coding style can be a matter of religion, but I feel we should try to
> > appeal to most developers.
> > 
> > 
> > Stuart
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> > For a limited time only, get FREE Ground shipping on all orders of $35
> > or more. Hurry up and shop folks, this offer expires April 30th!
> > http://www.thinkgeek.com/freeshipping/?cpg=12297
> > _______________________________________________
> > Mxflib-developers mailing list
> > Mxf...@li...
> > https://lists.sourceforge.net/lists/listinfo/mxflib-developers
> > 
-- 
Stuart Cunningham <st...@rd...>
BBC Research & Development

RE: [Mxflib-developers] Coding style

[Oliver M. <ol...@me...>]

More to the point: we need a concerted program to catalog them, eliminate
the worst, and eventually resolve all of them - whatever they are called.

Cataloguing them is easier if they are all marked the same way. Consistency
is good. "dragons" is as good as anything for now.

Oliver

> -----Original Message-----
> From: mxf...@li... 
> [mailto:mxf...@li...] On 
> Behalf Of Stuart Cunningham
> Sent: Tuesday, April 27, 2004 7:40 AM
> To: Matt Beard
> Cc: mxf...@li...
> Subject: Re: [Mxflib-developers] Coding style
> 
> On Tue, 2004-04-27 at 12:06, Matt Beard wrote:
> > Developers,
> > 
> > Can we try and keep a consistent coding style.  My main two 
> gripes are that 
> > we all stick to the "DRAGONS:" tag for any code that needs 
> attention in the 
> > (near) future and that we all maintain the doxygen 
> documentation tags.
> 
> I, a number of my colleagues and even developers we have met 
> at NAB and
> the recent LinuxUser & Developer Expo, have remarked about the use
> of "DRAGONS" in the MXFlib source.  Our complaints include:
>   "FIXME" and "TODO" are the more conventional and well-known tags
>   marking code that needs attention.  Editors such as emacs and gvim
>   have specific markup support for these tags.  "FIXME" is described
>   in the Jargon File:
>     http://www.catb.org/~esr/jargon/html/F/FIXME.html
> 
>   We have noticed that "DRAGONS" has been used in cases where "TODO"
>   is appropriate - i.e. the code works as it is, but there is missing
>   functionality, or the code could be optimised with more work.
> 
>   For Unix developers "DRAGONS" means a program similar to
>   a daemon, such as cron, so its use in comments of source code for
>   executables or libraries can be ambiguous.  The Jargon File 
> describes
>   this usage of "DRAGONS".
> 
> I would suggest we try to make MXFlib appeal to the widest 
> possible set
> of developers.  I believe this would mean using conventions used in
> the Free Software and Open Source Software communities.  Of course,
> coding style can be a matter of religion, but I feel we should try to
> appeal to most developers.
> 
> 
> Stuart
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Mxflib-developers mailing list
> Mxf...@li...
> https://lists.sourceforge.net/lists/listinfo/mxflib-developers
> 

Re: [Mxflib-developers] Coding style

[Stuart C. <st...@rd...>]

On Tue, 2004-04-27 at 12:06, Matt Beard wrote:
> Developers,
> 
> Can we try and keep a consistent coding style.  My main two gripes are that 
> we all stick to the "DRAGONS:" tag for any code that needs attention in the 
> (near) future and that we all maintain the doxygen documentation tags.

I, a number of my colleagues and even developers we have met at NAB and
the recent LinuxUser & Developer Expo, have remarked about the use
of "DRAGONS" in the MXFlib source.  Our complaints include:
  "FIXME" and "TODO" are the more conventional and well-known tags
  marking code that needs attention.  Editors such as emacs and gvim
  have specific markup support for these tags.  "FIXME" is described
  in the Jargon File:
    http://www.catb.org/~esr/jargon/html/F/FIXME.html

  We have noticed that "DRAGONS" has been used in cases where "TODO"
  is appropriate - i.e. the code works as it is, but there is missing
  functionality, or the code could be optimised with more work.

  For Unix developers "DRAGONS" means a program similar to
  a daemon, such as cron, so its use in comments of source code for
  executables or libraries can be ambiguous.  The Jargon File describes
  this usage of "DRAGONS".

I would suggest we try to make MXFlib appeal to the widest possible set
of developers.  I believe this would mean using conventions used in
the Free Software and Open Source Software communities.  Of course,
coding style can be a matter of religion, but I feel we should try to
appeal to most developers.


Stuart

[Mxflib-developers] Coding style

[Matt B. <ma...@be...>]

Developers,

Can we try and keep a consistent coding style.  My main two gripes are that 
we all stick to the "DRAGONS:" tag for any code that needs attention in the 
(near) future and that we all maintain the doxygen documentation tags.

Matt

[Mxflib-developers] Next release

[Matt B. <ma...@be...>]

Guys,

I intend to make a new release of MXFLib as soon as possible.

There hasn't yet been a release that is not dependent on KLVLib and there 
have been quite a few other changes.

Please e-mail me with any significant bugs you know about, or any features 
you are just bursting to have included ASAP and I will work out when I can 
do the next release.

Matt

[Mxflib-developers] Removal of KLVLib dependency

[Matt B. <ma...@be...>]

I intend to check in a version of MXFLib without the dependency on 
KLVLib.  This is likely to happen next weekend (27/28 March). The only 
major change this should make is that KLVLib will no longer be compiled and 
linked in when MXFLib is built. However, please be aware that the 
transition may not be completely snag-free - especially if your projects 
rely on any of the KLVLib code or definition.  Please treat this as an 
advance warning that a) the CVS version on Monday 29th March is likely to 
be significantly different than on 26th; and b) You may find some 
difficulty building code after merging the changes (if either I have messed 
up or you have added your own dependencies).

Matt

[Mxflib-developers] Use of the developers list

[Matt B. <ma...@be...>]

Developers,

The mxflib-delevopers list is intended for general announcements relevant 
to anyone doing mxflib development (e.g. "A new version will be released 
next week - please contact me if you want your latest fixes included"). I 
would prefer it if general discussion about mxflib development was kept to 
the forum on SourceForge 
(https://sourceforge.net/forum/forum.php?forum_id=220045).

I should have made this more clear when I set up the list so please don't 
interpret this as a slap-on-the-wrist for those that have been using it for 
discussions.

Matt

[Mxflib-developers] Event Tracks

[Oliver M. <ol...@me...>]

Matt:

at the moment, we have Timeline Tracks and Static Tracks, no Event
Tracks

class Package contains:

//! Add a timeline track to the package
TrackPtr AddTrack(ULPtr DataDef, Uint32 TrackNumber, Rational EditRate,
std::string TrackName = "", Uint32 TrackID = 0);

//! Add a static track to the package
TrackPtr AddTrack(ULPtr DataDef, Uint32 TrackNumber, std::string
TrackName = "", Uint32 TrackID = 0);


and then specifically for DM:


TrackPtr AddDMTrack(Rational EditRate, std::string TrackName =
"Descriptive Track", Uint32 TrackID = 0);
TrackPtr AddDMTrack(Uint32 TrackNumber, Rational EditRate, std::string
TrackName = "Descriptive Track", Uint32 TrackID = 0)

// Add a STATIC DM Track
TrackPtr AddDMTrack(std::string TrackName = "Descriptive Track", Uint32
TrackID = 0);
TrackPtr AddDMTrack(Uint32 TrackNumber, std::string TrackName =
"Descriptive Track", Uint32 TrackID = 0);



I propose adding:

const Int64 EventUnspecified = -1;
const Int64 EventInstantaneous = 0;

//! Add an event track to the package
TrackPtr AddTrack(ULPtr DataDef, Uint32 TrackNumber, Rational EditRate,
Int64 DefaultDuration = EventUnspecified, std::string TrackName = "",
Uint32 TrackID = 0);

/* this has 6 arguments to distinguish it from the others.

the default value of DefaultDuration is the const EventUnspecified which
has the distinguished value, and (I suppose) should be used when adding
a DMSegment, if SetDuration() has not been called. */

// Add an EVENT DM Track
TrackPtr AddDMTrack(Rational EditRate, Int64 DefaultDuration =
EventUnspecified, std::string TrackName = "Descriptive Track", Uint32
TrackID = 0);
TrackPtr AddDMTrack(Uint32 TrackNumber, Rational EditRate, Int64
DefaultDuration = EventUnspecified, std::string TrackName = "Descriptive
Track", Uint32 TrackID = 0)





Does this work for you?
If so, when is the right moment to add to SF?
Should we make another release first (especially since asdcplib is now
building upon the current HEAD revision)?

thanks
Oliver

Re: [Mxflib-developers] Overriding file IO in mxflib

[Mathew S. <mat...@eu...>]

Matt Beard wrote:

> At 09:50 05/02/2004, Mathew Spencer wrote:
>
>> There is one very good reason for this (in the GStreamer example) as 
>> far as I can see.  I want to abstract the MXF file IO to allow for 
>> the GStreamer pipeline to control it (In this case, the file io is 
>> controlled by a GstBytestream structure), but the dictionary and 
>> types file loading still needs to be done by the generic access 
>> methods.  I have already written the code that allows this to be 
>> achieved and will supply a patch (hopefully today, I'll see how my 
>> time goes).
>
>
> At the moment the sax parser will still read from a file as it is 
> within klvlib, soon this will not be the case. There are a number of 
> ways to get around this - such as the client code switching its 
> handlers from file mode to stream mode after loading the dictionaries.
>
>> One other point, the MXFLIB_NO_FILE_IO system requires the library to 
>> be recompiled for each purpose, with this method you simply need to 
>> supply the library with an alternate set of access methods at run time.
>
>
> It seems to be a very bad idea to add an extra layer between the file 
> i/o and the library as this will kill many optimizations.  Consider 
> the case of checking for EOF - normally this will optimize into a read 
> of a single value from a memory structure. If non-file handling were 
> to be required in a significant proportion of applications it may be 
> worth building this layer in, but at the moment it would simply reduce 
> the efficiency for everyone.  A simple answer might be to "optionally" 
> add this layer - so you either have file only (with full 
> optimizations) or switchable (with a little extra overhead).

Agreed.
I have attached a tarball with the modifications I made to mxffile and 
system.h to enable runtime selection of io methods.  Its not very 
elegant at the moment, but it works and could form a starting point for 
getting this functionality into mxflib.

For what its worth, I now have a gstreamer plugin that will play some 
formats of MXF file (namely XDCam formats at the moment, others to come 
soon).

By the way Matt, have you had a chance to look at the Autotools version 
of mxflib that I sent you?

> Matt

Regards,
Mat


*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended 
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
*************************************************************************

Re: [Mxflib-developers] Overriding file IO in mxflib

[Matt B. <ma...@be...>]

At 09:50 05/02/2004, Mathew Spencer wrote:

>There is one very good reason for this (in the GStreamer example) as far 
>as I can see.  I want to abstract the MXF file IO to allow for the 
>GStreamer pipeline to control it (In this case, the file io is controlled 
>by a GstBytestream structure), but the dictionary and types file loading 
>still needs to be done by the generic access methods.  I have already 
>written the code that allows this to be achieved and will supply a patch 
>(hopefully today, I'll see how my time goes).

At the moment the sax parser will still read from a file as it is within 
klvlib, soon this will not be the case. There are a number of ways to get 
around this - such as the client code switching its handlers from file mode 
to stream mode after loading the dictionaries.

>One other point, the MXFLIB_NO_FILE_IO system requires the library to be 
>recompiled for each purpose, with this method you simply need to supply 
>the library with an alternate set of access methods at run time.

It seems to be a very bad idea to add an extra layer between the file i/o 
and the library as this will kill many optimizations.  Consider the case of 
checking for EOF - normally this will optimize into a read of a single 
value from a memory structure. If non-file handling were to be required in 
a significant proportion of applications it may be worth building this 
layer in, but at the moment it would simply reduce the efficiency for 
everyone.  A simple answer might be to "optionally" add this layer - so you 
either have file only (with full optimizations) or switchable (with a 
little extra overhead).


Matt

[Fwd: Re: [Mxflib-developers] Overriding file IO in mxflib]

[Mathew S. <mat...@eu...>]

*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended 
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
*************************************************************************

Re: [Mxflib-developers] Overriding file IO in mxflib

[Matt B. <ma...@be...>]

At 15:51 02/02/2004, Mathew Spencer wrote:
>Hi all,
>
>I am currently working on wrapping mxflib so that it can be used as a 
>plugin to a gstreamer pipeline (for those that don't know gstreamer, its 
>an open source direct-show style streaming media framework.  See 
>http://freedesktop.org/~gstreamer ).

Ack.


>For me to be able to do this, I need to be able to abstract the file IO 
>functions.  There seems to be some support to do this already through use 
>of the MXFLIB_NO_FILE_IO,

Yes, this was added to allow the library to be used with DirectShow.

>but under linux, using this flag causes problems with klvlib's file io 
>functions as KLVFile is hard coded to FILE*.

Hmm, not sure why, but I am currently re-working the code to remove klvlib 
dependency so it should go away soon...

>Is anyone aware of this problem?  Is there a recommended solution to this 
>problem?
>
>Could I suggest a list of callback functions to be used (much as in a 
>linux device driver) with a set of defaults defined for the currently 
>supported platforms.  This should also allow the removal of duplicate 
>function declarations in mxflib's system.h.

I would be interested in a few more details of this proposal - at the 
moment if you specify MXFLIB_NO_FILE_IO then the client code provides file 
I/O functions with the same name as the normal library ones.  This should 
be about as efficient as possible without adding stream code to the library.

>I am willing to supply a patch to achieve this (although I am only able to 
>test under Linux here).

Is this really necessary? - if you believe so then I would be happy to look 
at the code.


>Regards,
>
>Mat


Matt

[Mxflib-developers] Overriding file IO in mxflib

[Mathew S. <mat...@eu...>]

Hi all,

I am currently working on wrapping mxflib so that it can be used as a 
plugin to a gstreamer pipeline (for those that don't know gstreamer, its 
an open source direct-show style streaming media framework.  See 
http://freedesktop.org/~gstreamer ).

For me to be able to do this, I need to be able to abstract the file IO 
functions.  There seems to be some support to do this already through 
use of the MXFLIB_NO_FILE_IO, but under linux, using this flag causes 
problems with klvlib's file io functions as KLVFile is hard coded to FILE*.

Is anyone aware of this problem?  Is there a recommended solution to 
this problem?

Could I suggest a list of callback functions to be used (much as in a 
linux device driver) with a set of defaults defined for the currently 
supported platforms.  This should also allow the removal of duplicate 
function declarations in mxflib's system.h.

I am willing to supply a patch to achieve this (although I am only able 
to test under Linux here).

Regards,

Mat



*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended 
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
*************************************************************************

Re: [Mxflib-developers] autotools for mxflib

[Matt B. <ma...@be...>]

This sounds like a question for Stuart...

Matt


At 10:13 27/01/2004, Mathew Spencer wrote:
>Hi all,
>
>I have modified mxflib to use the GNU autotools to allow for easier cross 
>platform compilation.  If I were to submit a patch what are the chances of 
>it being integrated.
>For your information, I added a sub directory 'mxflib' and placed all the 
>mxflib .cpp and .h files into it.  This is to remove a dependency on the 
>extracion of the tarball to be in a directory called mxflib.  I have also 
>created pkg-config scripts for automatic dependeny extraction.  I will 
>also add a .spec file soon for automaticly creating an RPM from.
>
>Hope to hear from you soon,
>
>Mat
>
>
>
>*************************************************************************
>The information contained in this message or any of its
>attachments may be privileged and confidential and intended for the 
>exclusive use of the addressee. If you are not the
>addressee any disclosure, reproduction, distribution or other
>dissemination or use of this communication is strictly prohibited
>*************************************************************************
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Mxflib-developers mailing list
>Mxf...@li...
>https://lists.sourceforge.net/lists/listinfo/mxflib-developers
>

[Mxflib-developers] autotools for mxflib

[Mathew S. <mat...@eu...>]

Hi all,

I have modified mxflib to use the GNU autotools to allow for easier 
cross platform compilation.  If I were to submit a patch what are the 
chances of it being integrated.
For your information, I added a sub directory 'mxflib' and placed all 
the mxflib .cpp and .h files into it.  This is to remove a dependency on 
the extracion of the tarball to be in a directory called mxflib.  I have 
also created pkg-config scripts for automatic dependeny extraction.  I 
will also add a .spec file soon for automaticly creating an RPM from.

Hope to hear from you soon,

Mat



*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended 
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
*************************************************************************

[Mxflib-developers] New mailing list for mxflib developers

[Matt B. <ma...@be...>]

Hi all,

I have set up a mailing list for mxflib developers and subscribed all those 
that are currently members of the project. I will use this list for sending 
any important developer related messages.

First message:  I have added some rules for who can check-in what to the 
docs section of the SourceForge page - please read the doc before checking 
in any code.

Thanks,


Matt Beard