Re: [RFC] first draft of stream/demux-metadata support (+playlist-infos)

Am Montag, 26. Mai 2003 20:23 schrieb Arpi:
> Hi,
>
> > I slept a while and think I found the different types, that need to be
> > supported (supposed playlist-handlers will be complete in demuxer-level
> > too)
> >
> > To-be-supported Examples:
> >
> > QT-MOVIE: (or other playlist)
> >
> > Metadata:
> >
> > Title: Foo's adventure
> > Author: Bar Bar cue
> > Date: 2005
>
> isn't title/etc per-track?
> (allowing multiple titles in single file)

yeah, but sometimes file has global title (i.e. album)

>
> > References:
> >         (Ext-)Reference:
> >                 url: foo-high-res.mov
> >                 bitrate: 16000
> >                 quality: 9
> >                 --
> >                 url: foo-medi-res.mov
> >                 --
> >                 url: foo-low-res1.mov
> >                 --
> >                 url: foo-low-res2.mov
> >         (Ext-)Reference:
> >                 url: foo-title2.mov
>
> hmm, does such grouping exists in movs?

yes, in mov-reference-files those are (always) alternative references, but 
that could be also in playlists or similar, where there are concurrent 
sources.

>
> > DVD:
> >
> > Metadata:
> >
> > Title: Foo on DVD
> > Author: Bar Bar Cue
> > Date: 2005
> >
> > DVD-META:
> >
> > Titles: 16
> > Chapters: 25
> > Subtitle-Languages: de en uk fr
> > Audio-Languages: de en
>
> no no no
> it's not so simple :(

:(

> the number of titles is global to a disc.
> then each titles has number of chapters, number of angles, sub and audio
> langue list.
> most dvd disc contain few titles, one for the movie (many chapters, audio
> languages etc), one for the trailers (few chapters, one chapter is one
> movie's trailer, usually single audio and a few subtitles), one for
> werkfilms (how we did that effect in matrix...) and so on.

hm ...

>
> > References:
> >         (Int-)Reference:
> >                 name: Main-Movie (title1)
> >                 offset: 1656
> >                 (Int-)Reference:
> >                         name: Chapter 1
> >                         offset: 1656
> >                 (Int-)Reference:
> >                         name: Chapter 2
> >                         offset: 1856
> >                    ...
> >         (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

>
> btw you should include length (play time) for cdda and dvd for titles and
> chapters.

hm, yeah.

>
> > CD:
> >
> > Metadata:
> >
> > Title: Bar is singing
> > Author: Foo's hidden microphone
> > Date: 2008
> >
> > CD-META:
> >
> > nb_tracks = 16
> > length = 00:57:68
> >
> > References:
> >         (Int-)Reference:
> >                 name: Foo Title 1
> >                 offset: 108
> >         (Int-)Reference:
> >                 name: Foo Title 2
> >                 offset: 206
> >
> > 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 ?)
>
> > -> 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!

:)

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

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 :-) )

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


cu

Fabian
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer G2, the Movie Framework for all -
> http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> [email protected]
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev