[MPlayer-G2-dev] [RFC] first draft of stream/demux-metadata support (+playlist-infos)

[Arpi]

Hi,

> > >         (Int-)Reference:
> > >                 name: title2
> > >                 offset: 1987
> >
> > hmm
> > what's that offset?
> 
> pos in stream-layer ... as the control-unit needs to "say" to stream-layer go 
> to "chapter 5" instead it says go to: offset/pos 1656

then it should be off_t instead of int :)
but i vote for a void*, so strea/demux layer could store its internal
reference there. (think of demuxers where you cannot always describe a title
with an offset, for example in a mov file).

> > > Proposed structures:
> >
> > i guess we should move metadata stuff to the stream layer.
> > as demuxer already depend son stream layer, and includes stream.h, it could
> > use the same.
> yeah, good idea. Problem is: What if meta-data from stream and demux layer are 
> different. (i.e. asf-"streaming" which gets an title from stream and another 
> one from demuxer ?)

it's UI's problem.
our (stream & demuxer writers) job is to store as many info as we can
retrieve from input media in some structs and pass it to teh UI.
then it's UI's problem how does it visualize that.
i can imagine playlists with [+] sign before the urls which you can click to
get the tree of its titles, chapters etc. each one has play time at the end
of line, and if you move the mouse over the line you get more info (artist
etc) in a floating popup window :)
EOD (end of dreaming)

> > > -> Metadata as list. (as already implemented)
> > > <SPEC>-META as an struct specific to media.
> > >
> > > Reference: (somewaht similar to metadata, which should not be specific to
> > > demuxer-level)
> > >
> > > struct ref_list_s;
> > >
> > > typedef struct ref_entry_s
> > > {
> > >   char* name;
> > >   int offset;
> > >   Url_t *URL;
> > >   int bitrate; // perhaps present in Url_t ?
> > >   int quality;
> > >   ...
> > >   int type; // external / internal reference
> > >   ref_list_t* alternatives;
> > >   ref_list_t* sublist;
> > > } ref_entry_t;
> >
> > good!
> > i like the idea of reusing stream layer's URL_t to keep urls parsed instead
> > of as plain strings.
> 
> In my dream-structure everything would be handled by player as url "cdda://1, 
> cdda://2,dvd://1/1-4/" would be a playlist but demuxer/stream (for cdda) 
> would only be opened once and the second title would be just an seek 
> internally.

:)

> > > typedef struct ref_list_s {
> > >   int num_refs; // number of available entries
> > >   int max_refs; // number of allocated entries
> > > (if(num_metas>=max_metas)realloc())
> > >   ref_entry_t* refs;
> > > } ref_list_t;
> > >
> > >
> > > So CD is a flat structure, which do not use alternatives or sublist.
> > > MOV can make use of alternatives to allow player an choice.
> >
> > also does .asx and .rmf...  we should also handle playlists at demuxer
> > level, so don't forget about them!
> 
> :)

don't laugh, it must be ported/implemented :)
sth like demux_playlist.c to parse the various playlist formats.
(or independent demux_asx demux_pls etc maybe)

also there will be demux_sub to parse subtitles, but it's another game.

> > > DVD does make heavy use of sublist, as disk/titles/chapters have a
> > > somewaht nested strucutre.
> >
> > yes
> >
> > > One goal in later implementation should be simplicity.
> >
> > yep. but we cannot (and shouldn't) avoid the hierarchical (tree) structure
> > of the struct.
> 
> yes.
> 
> >
> > btw, shouldn't we put metadata and references into the same struct?
> > (as there is metadata for references)
> 
> yes! That is a very good idea.
> 
> Perhaps with this the structure can be simplified as it only needs Url_t, 
> (+bitrate, quality) for external (i.e. new demuxer/codec open) and offset/pos 
> for internal reference. (demuxer/stream already open)

yes.
btw don't put things like bitrate, quality etc into the struct.
they are all optional metadata info.

imho a struct would look like this:

typedef struct {
    URL_t* url;
    off_t pos;
    metadata_list* meta;
    metadata_list* sub;
} metadata_entry_t;

hmm maybe combining meta with ref isn't that good idea.
what about this:

typedef struct {
    URL_t* url;
    off_t pos;
    metadata_list* meta;
    ref_list_t* refs;
} ref_entry_t;

hmm but it doesn't handle alternatives.

better ideas?

> Hm, while thinking about it, I agree that it should be combined.
> 
> reference
>   |_ metadata_list_t
>   |_ url
>   |_ pos
> 
> and reference is organized itself in a reference-list.
> 
> Hm, perhaps it could be more combined and reference is jsut another type for 
> meta_data ust like cd_info and dvd_info structures ? (of course it can't be 
> called STRING_LIST then :-) )

hmm, yes!!!
you won't believe but it was my original plan when created demux_meta_t or
what, i just forgot it :)

btw imho we don't want/need cd_+info dvd_info and such structs, use more
elementary/basic types, it's easier for all than supporting many kinds of
format-specific structs. this way gui don't have to know these structs, just
see what info is available and show it to the user.

think of third-party plugins, ie. plugins written by ppl who can't add new
types/structs into the gui or the core. ok it isn't so important :)

but in my dreams, g2 gui is somewhat runtime generated, based on the structs
exported by the core libs, be it config (preferences dialogs) or playlists
(metadata stuff) or anything.
it also means that you can add new code without messing with the gui.

i hoep new config layer will be flexible enough to define gui stuff without
any dependancy or knowledge on gui internals.
if you can describe your filters options in a struct, and te gui will
generate a nice settings window with mouse-over help etc from it, no matter
if it uses gtk, qt, win32, macos APIs or plain ncurses :)

> > > num=add_ext_reference(reflist,name, url) // returns the index ...
> > > add_ext_reference_alternative(reflist,num, name, url, bitrate, quality,
> > > ...) add_ext_reference_alternative(reflist,num, name2, url2, bitrate2,
> > > quality2, ...)
> > >
> > > num=add_reference(reflist,dvdname, offset) // returns the index ...
> > > add_reference_sublist(reflist,num, chaptername, offset)
> > > add_reference_sublist(reflist,num, chaptername2, offset2)
> 
> those were just examples, that make it kind of easy to use the API ...
> 
> With num one can get into each wanted level ...
> 
> > >
> > > Later CONTROL-program can get the data via:
> > >
> > > for (i=0;i<reflist.num_refs;i++)
> > > {
> > >   printf("Name: %s\n",reflist.refs[i]->name);
> > > }
> > >
> > > Convert it into own playlist/playtree-format and so on...
> > >
> > > The whole thing shall be in stream_t stream* as
> > >
> > > meta_t *meta
> > > {
> > >   metadata_list_t data;
> > >   void* specific_data; // or struct some_specific_s (like stream_priv_s)
> > >   ref_list_t list;
> > > }
> >
> > hmm
> 
> hm ...

hm?


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu