[Kdenlive-devel] <

[Rolf Dubitzky]

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.

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.

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.

> 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.


> >           <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, 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.

> 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.

> This is very much all up in the air, so expect a couple of weeks of heavy
> discussion ;-)

;-)

Cheers,
Rolf

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