June 2003 - MPlayer-G2-dev - lists.mplayerhq.hu

gui - skin engine
by Arpi 30 Jun '03

30 Jun '03

Hi, Just checked the skin cvs of gmplayer, and there are a lot of nice skins. It makes me wonder if we will support g1 skins in g2, or the g2 gui will have a new skin format? If we keep g1 format (maybe extend) then there should be a common, multiplatform skin loader/renderer library. If it's well written, then it's split to platform-independent and dependent parts. Ie there could be skin renderer/interface modules for Xlib, gtk, qt, win32 etc. Afaik Faust already proted teh g1 skin loader to win32, dunno how much it differs from the linux code. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

7 8

more on frame timing, framerate-changing filters
by D Richard Felker III 16 Jun '03

16 Jun '03

Hey. I'm working more on improving inverse-telecine stuff. Actually I think I'm going to test the new design on G1 (even though it's much more of a pain to deal with fields the way I want to in G1, it's easier to test with a fully-functional player, and people will be able to benefit from it sooner). Anyway, to get to the point, I'm hoping to make this code friendly for porting to G2 (I already have the timing-change stuff worked out for it), but I'd like to clear up how we want timing to work. Right now, it seems G2 has a duration field for the image, but I'm not sure whether that's preferred, or whether we should instead have a timestamp relative to the previous frame... IMO, for some filters, we may need to know *future* information to decide a duration, whereas we should already know the pts relative to prev frame. And of course, for performance purposes (and coding simplicity), it's optimal not to have to grab future frames from up the chain before we output a given frame. Consider for example the case of vf_decimate (near-duplicate frame dropper). If it wants to output duration, it has to grab frames into the future until it finds a non-duplicate. But with pts relative to previous, it can defer the task of decoding those extra frames until the current frame has been displayed, and *then* decoding those extra frames takes place during the "sleep time" anyway, so it won't cause the a/v sync to stutter on slow systems. Also, on another matter. I know G1's whole a/v sync system has been based on a lot of approximations and feedback measurement. This is great for mplayer, and probably also for encoding from variable-fps input to fixed-fps avi output with mencoder. However, especially with the new perfect-a/v-sync mpeg code in G2, I'd really like to see support for "exact" timing in G2. Maybe a way to use a time division base and specify all pts stuff in terms of those (exact) units. It would be much perferred for precision encoding and video processing work, and nice for output to containers like nut (mpcf) which will support such things. I'm envisioning my inverse telecine wanting to use a time base of 1/120 second, for flawless output of mixed telecine, 30fps progressive, and 60fps interlaced content as a single progressive output stream. (Such a perfect rip could *really* get the anime fansub groups interested in using mplayer/nut instead of the windows junk they use now....) If you're worried about not wanting all framerate-changing filters (or apps) to have to support this stuff, it could be an optional feature, where any filter in the chain can ignore the exact info and just use "float pts" the rest of the way down the chain... Rich

4 10

get_buffer/release_buffer vs. get_image/mpi
by Arpi 15 Jun '03

15 Jun '03

Hi, I've spent some time thinking on the $SUBJ, but i finally found a small issue being a show-stopper: releasing teh buffer. I don't really understand/knwo how is it done in ffmpeg (Michael?) but I see it as a big issue in our codec/filter layer: Ok, you do get_buffer() at any time (init or decode), and when filled by content (decoded video) you return it to caller. But when and where will it be released? The codec cannot release it, as it have to return it to caller and the caller will use its content. The caller can't release it, as it don't know about the allocators future plans (maybe its used as reference frame...) Maybe some kind of reference counters could help there, but it adds extra complexity, while my primary goal was simplify the buffering code. So i've decided to keep the mpi stuff for now, maybe we'll check get/release thingie again at g3 :) But i still have some idea, by simplifying mpi a bit (remove _IP and _IPB types, and the one-get_image-per-one-decode-call restriction) but keep the current per-filter allocation and release-at-uninit implementation. But i'm not even sure it worth the mess. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

3 3

[RFC] first draft of stream/demux-metadata support (+playlist-infos)
by Fabian Franz 14 Jun '03

14 Jun '03

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 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 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 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 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: -> 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; 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. DVD does make heavy use of sublist, as disk/titles/chapters have a somewaht nested strucutre. One goal in later implementation should be simplicity. 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) 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; } or similar. cu Fabian

2 4