Clip format proposal

Hi all,
I have finalised the LiVES 1.0 internal clip format. I would like to 
propose this as a common format for exchanging clips between all our 
applications. Instead of the "header.lives" file, we could use 
"header.clip" for example.

What do you all think of this proposal ? I attach the LiVES clip format 
document for your consideration.

Gabriel.
http://lives.sourceforge.net

LiVES clip format version 1.0

Internal format of a clip

Video: a sequence of jpeg or png*, numbered consecutively
00000001.jpg, 00000002.jpg, etc.

*png enabled version of LiVES only. Frames are called 00000001.png,
 00000002.png, etc.

Audio: a raw pcm file

header.lives file: a header file with the following contents:

<header_version>
string, max length 16 chars: currently "1.0"

Re: Clip format proposal

reinventing the wheel again? 
there are mxf and aaf already. 

bye
andarz

On Sun, 2006-12-10 at 17:39 +0100, salsaman wrote:
> Hi all,
> I have finalised the LiVES 1.0 internal clip format. I would like to 
> propose this as a common format for exchanging clips between all our 
> applications. Instead of the "header.lives" file, we could use 
> "header.clip" for example.
> 
> What do you all think of this proposal ? I attach the LiVES clip format 
> document for your consideration.
> 
> Gabriel.
> http://lives.sourceforge.net
> 
> plain text document attachment (clip_format.txt)
> LiVES clip format version 1.0
> 
> Internal format of a clip
> 
> Video: a sequence of jpeg or png*, numbered consecutively
> 00000001.jpg, 00000002.jpg, etc.
> 
> *png enabled version of LiVES only. Frames are called 00000001.png,
>  00000002.png, etc.

Re: Clip format proposal

Andraž Tori wrote:

>reinventing the wheel again? 
>there are mxf and aaf already. 
>
>bye
>andarz
>  
>
Andraz,
sometimes your blatant cynicism really annoys me. It's not reinventing 
the wheel. The format I proposed is *simple* method of passing clip data.

As you well know, AAF is used for edit decision lists and therefore it's 
designed to hold multiple clip data and so on. It's also very complex to 
implement.

I don't know mxf, but I see there is an entire book on the subject, 
which would lead me to suspect it is also very complex and very much 
overkill for what I am suggesting (i.e. exchanging single clips with a 
minimal amount of overhead).

But still if you feel my suggestion should be put down without even 
discussion of the merits then that is your right. On the other hand, I 
think it would be great to be able to exchange clips between LiVES and 
cinelerra for example. You could implement this in half an hour. What 
are you afraid of ?

Regards,
Gabriel.

Re: Clip format proposal

Hello!

im sorry i dont think i know the context very much, but just came up 
with an interesting idea (hopefully i understand what you are trying to 
achieve).

maybe this can be implemented as a metadata layer for jack.

as there is a lot of need for a well designed video data sharing API, a 
metadata sharing layer would be a logical extension.

as far as i know video jack doesnt exist yet and as these things tend to 
converge anyway i think it could really help data sharing amongst 
applications.

also i am looking to share video over the network and am looking for 
just such a solution.

well just an idea:)

Cheers,
Slavko

salsaman wrote:
> Andraž Tori wrote:
> 
>> reinventing the wheel again? there are mxf and aaf already.
>> bye
>> andarz
>>  

Re: Clip format proposal

hey salsaman,

salsaman <salsaman <at> xs4all.nl> (on Sun, 10 Dec 2006 17:39:49 +0100):

  > header.lives file: a header file with the following contents:

can i suggest the header file to be a well-formed XML file (including <?xml version="1.0"?>, and,
primarily, a root node)? Defining a namespace (early) is also often a good idea.

Also, i'd like to suggest using dublin core, maybe in rdf, for most metadata.

Third, i think XML generall prefers '-' over '_' as a separator. I'm unsure if '_' is even valid as element name.

-dan

--

-- 
http://0xDF.com/
http://iterative.org/

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://www.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

Re: Clip format proposal

daniel fischer wrote:

>hey salsaman,
>
>salsaman <salsaman <at> xs4all.nl> (on Sun, 10 Dec 2006 17:39:49 +0100):
>
>  > header.lives file: a header file with the following contents:
>
>can i suggest the header file to be a well-formed XML file (including <?xml version="1.0"?>, and,
primarily, a root node)? Defining a namespace (early) is also often a good idea.
>
>Also, i'd like to suggest using dublin core, maybe in rdf, for most metadata.
>
>Third, i think XML generall prefers '-' over '_' as a separator. I'm unsure if '_' is even valid as element name.
>
>-dan
>
>
>  
>

Hi Dan,
thanks for your comments ! I'd be interested to see an example of how 
you think the header file should be formated. My idea was also that the 
"keywords" field could be used to optionally store dublin core data (I'm 
not so familiar with it).

Although my preference is not to use xml, since this adds another 
dependency to every application, so perhaps some simple pre-processing 
could be done to convert the header file into xml before parsing it ? 

Re: Clip format proposal

Slavko Glamočanin wrote:

> Hello!
>
> im sorry i dont think i know the context very much, but just came up 
> with an interesting idea (hopefully i understand what you are trying 
> to achieve).
>
> maybe this can be implemented as a metadata layer for jack.
>
> as there is a lot of need for a well designed video data sharing API, 
> a metadata sharing layer would be a logical extension.
>
> as far as i know video jack doesnt exist yet and as these things tend 
> to converge anyway i think it could really help data sharing amongst 
> applications.
>
> also i am looking to share video over the network and am looking for 
> just such a solution.
>
> well just an idea:)
>
> Cheers,
> Slavko

Hi Slavko,
that might be an interesting idea. However, it's not really necessary 
for video jack, since you would already know most of the fields - at 
least width, height, and bpp; and all of the audio parameters are 
unneccessary since jack uses float for audio. Also, video jack will only 

Re: Clip format proposal

Just a couple of corrections to my proposal:

header_version should be an integer (not a string), current value is 100.

fps may be 0. if and only if frames is 0.

Gabriel.

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
https://www.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org

Re: Clip format proposal

On Sun, 2006-12-10 at 23:51 +0100, salsaman wrote:
> Andraž Tori wrote:
> 
> >reinventing the wheel again? 
> >there are mxf and aaf already. 
> >
> >bye
> >andarz
> >  
> >
> Andraz,
> sometimes your blatant cynicism really annoys me. It's not reinventing 
> the wheel. The format I proposed is *simple* method of passing clip data.
> 
> As you well know, AAF is used for edit decision lists and therefore it's 
> designed to hold multiple clip data and so on. It's also very complex to 
> implement.
> 
> I don't know mxf, but I see there is an entire book on the subject, 
> which would lead me to suspect it is also very complex and very much 
> overkill for what I am suggesting (i.e. exchanging single clips with a 
> minimal amount of overhead).

I am not going into another "standardisation process"... :) One was
enough.

I'd like to point out the old saying in unix world from 87...:
"Those who do not understand Unix are condemned to reinvent it ..."

AAF/MXF was created with exactly what you are talking in mind:

Re: Clip format proposal

Andraž Tori wrote:

>On Sun, 2006-12-10 at 23:51 +0100, salsaman wrote:
>  
>
>>Andraž Tori wrote:
>>
>>    
>>
>>>reinventing the wheel again? 
>>>there are mxf and aaf already. 
>>>
>>>bye
>>>andarz
>>> 
>>>
>>>      
>>>
>>Andraz,
>>sometimes your blatant cynicism really annoys me. It's not reinventing 
>>the wheel. The format I proposed is *simple* method of passing clip data.
>>
>>As you well know, AAF is used for edit decision lists and therefore it's 
>>designed to hold multiple clip data and so on. It's also very complex to 
>>implement.
>>
>>I don't know mxf, but I see there is an entire book on the subject, 
>>which would lead me to suspect it is also very complex and very much 
>>overkill for what I am suggesting (i.e. exchanging single clips with a 
>>minimal amount of overhead).