[MPlayer-G2-dev] playtree export structure [Was: Re: Developing a GTK2 GUI]

[Fabian Franz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Sonntag, 3. August 2003 19:14 schrieb Arpi:
> Hi,
>
> ps: don't cc: me, i'm subscribed :)

rofl :) :) ok

>
> > > welcome back. what about the stream/demux metadata/playlist export we
> > > talked about last time, before you disappeared? :)
> > >
> > :) Had some stuff to do, to get popular on LinuxTag with Knoppix on Mac
> > : ...
> >
> > ;-)
>
> you could meet other mplayer developers there (@linuxtag) :)

yeah, I didn't know this as mplayer had no booth ...

>
> > ok, back on topic ...
> >
> > I'm still interested in this development.
> >
> > However its a hard task to do a specification ...
> >
> > I would like to have something transparent and extensionable ...
> >
> > So that for the structure it does not matter if it is a CD, a DVD or a
> > url ...
>
> yes
>
> > Hm, but thats not easily possible ...
>
> yes
>
> > And that was the point in my thinking where I got stuck ...
> >
> :(
> :
> > Perhaps we could do again a brainstorming based on the previous work ...
>
> sure.
>
> I think we should try to define what do we want to reach, ie. what kind of
> data it have to contain, mayeb with examples. It truned out to be helpful
> for API design in practice, at least to me.
>
> So, as a start, I try to list what kind of media we support already:
> - cdda/cddb:  1-D list of tracks, with the usual stuff (length, title etc)
> - dvd:  2 level depth tree, dvd "titles" at top level, chapters bellow it.
>   also, alternatives (multiple angles) possible for titles.
> - dvb/mpeg-ts: 1-D list of "programs", ie. pairs of audio and video
> channels - ascii playlists (.pls, .asx, .ram etc): 1-D or hierarchical
> (tree) structure of files. alternatives (different bitrate/quality of same
> media) possible. - "reference movie" (quicktime .mov files): 1-D (?) list
> of titles, alternatives (multiple resolution/bitrate/player version)
> possible
>
> From this, we "just" need a tree design, where 2 kind of "children" exists:
> - real children (nodes, which define different content)
> - alternatives
>
> So sth like:
>
> typedef struct entry_s {
> 	char* name; // to be displayed in gui playlist editor / menu
> 	demux_metadata_t meta;
> 	URL_t* url;
> 	struct entry_s * children; // or call it 'nodes'
> 	struct entry_s * alternatives;
> 	struct entry_s * next; // for linked list
> } entry_t;
>
> But probably this is too simplified...

hm, I don't think so that its too simplified ...

I think there need to be also an type-field as then the parser functions know, 
of which type the metadata-struct is ...

Hm: 

another idea: One could store all metadata-information as strings as in mpcf.

Is it possible to have all entries presented as url ?
Ok, it _must_ be possible ...

But how on a CD does the playlist-"parser/control" then know, that the demuxer 
and codec can be kept open, when tracktitle changes, but its the same media 
... ?

I think its then nice to also have playlists as an entry in the "Playtree" ...

So, one can delete the playlist and all entries that belong to it, are removed 
... (as long as the playlist is not changed of course ...)

What about Audio-CDs or DVDs should the program ask for it, if they are not in 
Drive ?

Or just ignore this entries ... 

hm, what I did not like about the last playtree-structure was that it was soo 
complicated, that everything was not easy to program and it was hardly 
possible for me to program an high-level-api ...

Btw. I like you design of array-lists in stream better than with next-pointers 
...

Its much more easily to use ...

But how does one go "up", from that again, if one is in an subnode ...

Saving this information would be easy, but has overhead ...

Lol, an idea I had (Thats possibly much too simplified):

struct entry_list_s;

struct entry_s
{
  int type;
  URL_t* url;
  demux_metadata_t meta;
  entry_list_s list;
} entry_t;

typedef struct entry_list_s {
  int num_entries; // number of available entries
  int max_entries; // number of allocated entries 
(if(num_metas>=max_metas)realloc())
  entry_t* entries;
} entry_list_t;

type determines now if list is: 

 * an own object
 * a sublist 
 * alternatives

You ask yourself what happens if there are muplitple files and alternatives ?

They are nested:

file1 - meta entry with type alternative
  - alternative 1
  - alternative 2
  - alternative 3
file 2 - meta entry with type sublist
  - file 1
  - file 2
  ...

Name and so on can be read from Meta-Data ...

cu

Fabian

> Any better ideas?
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer G2, the Movie Framework for all -
> http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> MPlayer-G2-dev at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE/Lp4yI0lSH7CXz7MRAt+wAJ9CGurmG/9FodflBEH0vTDo66VP2wCdF3kH
Sdn9sNq3nLpFXXImvUejqG4=
=6sij
-----END PGP SIGNATURE-----