[Kdenlive-devel] <capabilities>

[Jason Wood]

(filled in the subject name since I forgot to last time ;-)


On Sunday 02 Feb 2003 10:05 am, Rolf Dubitzky wrote:
> Hi Jason,
>
> On Saturday 01 February 2003 08:58 pm, Jason Wood wrote:
> > Firstly, "OutRawDVStream" is not exactly a user friendly name :-)
>
> ;-)  yes, I agree. its just the classname, because I'm lazy. This name is
> something kdenlive should NOT use to select something.
>
> > I think
> > we need to add another "human readable" message somewhere, which in this
> > case would say simply "Raw DV" (or perhaps ".dv file")
>
> The name does NOT describe the audio/video format. It describes the kind of
> stream plugin. I suggest to rename it to something like "libdv". The
> "ffmpeg" plugin might also support "raw dv" video streams.

Ok, here is the problem that needs to be solved.

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.

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

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.

> There are several possibiities to save DV audio/video data. I know of
> three:
>
> a)  "raw DV" : nothing but DV data in a sequence.
> b)  "avi DV type 1" : avi with raw DV data in the video stream and no
> audio. c)  "avi DV type 2" : avi with raw DV data in the video stream and
> the audio a second time in the audio stream.

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. 

> If you want to write data of type a) you should query for
> <outstream>
>   <file>
>     <container format="rawdv" />
>   </file>
> <outsream>
>
> You might get a "OutRawDVStream" (which should be renamed to "libdv
> stream") _or_ a "ffmpeg stream" or "gstreamer stream".  There is not yet a
> priority system, but evntually we'll need one. In case you want to override
> the default priority, you might want to add
>
> <outstream name="gstreamer">
>   <file>
>     <container format="rawdv" />
>   </file>
> <outsream>
>
> to the query to select a specific codec implementation.

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

> > I am wondering about the way video codecs are currently specified. I
> > agree that it makes sense to have them seperated out into their own
> > group, but I am unsure as to the current XML for specifying them. My
> > concern is that the video/audio codec sections are specified by name,
> > which may be a problem if, for instance, we need to define some other
> > codec groups of some unknown type in the future. I think a change to
> > something like this might be better
> >
> >
> > 		<codeclist name="video">
> > 			<libdv_encoder/>
> > 		</codeclist>
> > 		<codeclist name="audio">
> > 			<libdv_decoder/>
> > 		</codeclist>
> >
> > Whta do you think?
>
> I don't care, because it is the same effort to add
>
>     <codeclist name="spu" />   (subtitles)
>
> than to add
>
>     <spucodec  />
>
> 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.

> > >           <outstream name="SDLStream">
> > >               <screen>
> > >                   <X11 fallback="rgb" visual="xv" />
> > >                   <X11 visual="rgb" />
> > >               </screen>
> > >               <about>
> > > Use SDL to display video. Uses xv overlay if available.
> > >               </about>
> > >           </outstream>
> > >       </outputs>
> >
> > Hmmm, I am wondering about whether or not the streams to video and
> > streams to file should be mixed into the same "outputs" section. I guess
> > that it makes sense for piave, which handles all streams in a similar way
> > now, but it is not consistant with the VEML interface (which handles
> > video streams seperately to video exports). What do you think? Basically,
> > does it make more sense for the streams be seperated into file and screen
> > groups in the renderer, or should they be seperated in the GUI?
>
> I don't understand. They are seperated into file and screen.
> <outstream> <file> ... </file> </outstream> is definitely a file. Same with
> screen. I could thinking about a <network> type. The GUI shold know about
> these categories and display them where apropriate. When I select "render
> project" you can display file streams only if you want.
>
> > >       <codecs>
> > >           <decoder name="libdv_decoder">
> > >               <format fourcc="DVSD" />
> > >               <format fourcc="dvsd" />
> > >               <format fourcc="DVCS" />
> > >               <format fourcc="dvcs" />
> > >               <format fourcc="dvc" />
> > >               <about>
> > > This codec uses libdv to decode DV video.
> > >               </about>
> > >           </decoder>
> > >           <encoder name="libdv_encoder">
> > >               <about>
> > > This codec uses libdv to encode DV video.
> > >               </about>
> > >           </encoder>
> > >       </codecs>
> > >   </capabilities>
> >
> > Here, what purpose do the formats play? I think some description of the
> > differences should be given. Actually, since this is for decoding
> > purposes only, Kdenlive only needs to consider this as "informational",
>
> Yes, piave needs this information internally. You know, this whole property
> system is to much work to be used only for communication with kdenlive. I
> use it inside piave too. If I have an AVI file with a video track "DVCS" I
> need to find a codec that supports this fourcc. kdenlive can ignore this
> info.
>
> > but I think
> > that using groups to mark up the information would be useful.
> >
> > So, at the minimum, something like :
> >
> > 		<formats>
> > 			<format fourcc="DVSD">
> > 			...
> > 			...
> > 		</formats>
>
> 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? ;-)

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.

> > In this case, I don't actually know what fourcc means - is it better to
> > use a more generic markup tag for this kind of thing?
>
> no. fourcc is "four character code". This is the technical term for the way
> an AVI and quicktime container specifies the kind of video data it
> contains.

ok.

> > Finally, should encoder and decoder be seperated into seperate groups
> > like inputs and outputs are, or should inputs and outputs be defined
> > within an outer tag of "iostreams" or something? I think we should be
> > consistant :-)
>
> I don't like redundancy, it just causes traffic and misunderstandings, so I
> would prefere to get rid of the separation between <inputs/> and
> <outputs/>, since it is redundant information with the following
> <outstream>/<instream> tag. I like your "iostreams" suggestion.

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

Cheers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk