[Kdenlive-devel] <capabilities>

[Rolf Dubitzky]

On Sunday 02 February 2003 03:13 pm, Jason Wood wrote:
> From Kdenlive's (and the users) point of view, we do not want to have to
> specify which library to use, rather which file format we want.

I don't think so. The standard case will be that you just take what piave 
offers as the default for let's say:

<outstream>
  <file>
    <container format="rawdv" />
  </file>
</outstream>

For this example you dont need to know anything about what library will be 
used. But it might very well be possible, that you want to choose the 
library, and if only to compare quality or test stuff.  You can do that with:

<outstream name="libdv">
  <file>
    <container format="rawdv" />
  </file>
</outstream>


> So, instead of saying "We want to use fmpeg, libdv, etc." we say "We want
> to save as .avi, raw dv, .mpg, etc."

You dont have to say "I want ffmpg"  just omit the name, and you'll get 
whatever full fills the request best.

> So how do I discover these broad-speaking container types, and display them
> to the user? The semantic information to allow me to construct them needs
> to be within the capabilities XML.

just read the outsream, and look for outstreams which provide "file" and then 
look at the container and codecs available.

> Here, we have to seperate containers mixed together. Avi's can play many
> different types of codecs than just raw DV, whilst raw DV as a .dv file is
> in essence, a container on it's own.

true, thats, why there is a container with format="rawdv"  there will be a 
container "avi" and this container will maybe contain a fourcc="DVCS" video 
track (which is DV).

> Are you talking here about the file format selection when exporting?

No. When exporting, I expect the GUI to tell me what format to use.

> > From a semantic point of view the second is a change, the first would
> > already contain the option, that's true, but all that is about 0.1% of
> > the coding work to support subtitles.
>
> But with the first one, there would be no extra coding needed within the
> GUI ;-) So any coding needed would be restricted to the renderer.

;-))  Oh, be sure, there will be a lot of coding necessary in the gui if there 
are more things than just audio and video streams ;-))  
 But as I said, I don't really care. If you prefere <codec type="audio" ..>  
over <audiocodec ...> I have no problem with it ;-)

> > I think
> >
> > <formats> <format .../> </formats>  looks pretty redundant. What's the
> > use of the additional tags?
>
> In this case, it is probably not the best way to mark it up. The idea is to
> put as much semantic information into the XML as makes sense - by just
> having a list of <format> tags, Kdenlive has no idea on how they should be
> displayed - should they be grouped together, or are they individual pieces
> of information? In this case, Kdenlive can ignore the information, but
> there are likely to be other cases where it is useful to display the
> information to the user. Now, how do I decide which information can be
> ignored, and which cannot? ;-)

At this state, I guess you will just have to know. grouping does not help you 
in this case. you just have to know, that format is something that you are 
not interested in. If it wold be grouped, you still would have to know, that 
you are not interested in "formats", you gained nothing.  Later, when there 
are things, that should be displayed in groups, we have to put them into 
groups. But as long as there is no need... In german we have a saying "Don't 
talk about unlayed eggs" ;-))

> My whole aim from all this is to try and get the capabilities format into a
> position where the GUI does not need to know too many specifics about it.

This is video editing GUI after all. It will have to know a litle about what 
it displays. You are going into a direction, where displaying aspects are 
tranbsfered to the render engine, I don't think that's a good idea. I don't 
want this protokoll to get to complicated and to be a second XUL.

> Ok, yes, there is no problem with merging inputs/outputs, so long as it is
> consistant with the encoding/decoding.

ok. I'll change it.

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************