August 2003 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] xml docs fix and mpst:// docs
by Alban Bedel 14 Jul '04

14 Jul '04

Hi, I wrote a little doc for the mpst:// stuff. I also fixed the tv examples and found a little mistake in the edl docs. The mpst docs are not in the patch as i don't have DocBook installed so i can't chacek that everything is ok. Albeu

9 23

[PATCH] (main) configure script output neat-ening
by Alex Sisson 12 Jul '04

12 Jul '04

Hi, Just a little patch that just seperates all the checks into sections (video inputs, audio, codecs, etc) to make its output a bit clearer when youre trying to check if a certain thing is being detected. (yes i know theres the summary bit at the bottom but i dont like that as much :-)) Basically just added some echos, moved the video+audio checks above the video checks, and because there were a few things (zlib etc) in the wrong place have moved them down to the 'other' section. Alex Sisson ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/

5 8

[PATCH] Continue playing Real-format streams after errors
by Pekka Enberg 29 Jan '04

29 Jan '04

Hi, I get the following error at random intervals (sometimes within a minute of starting to play the stream, sometimes after ten to fifteen minutes) when watching AssemblyTV [1] Real-format stream: ******** !!!!!!!! BUG!! len=-194 !!!!!!!!!!! ******** I traced the problem to demux_real_fill_buffer() in libmpdemux/demux_real.c. For whatever reason, vpkg_length gets value greater than len leading to negative value of len. This confuses MPlayer so much that the video streaming effectively stops. The patch allows MPlayer to continue playing the video stream. However, the audio stream is always skipping badly after the bug is triggered (it doesn't restore to normal either). I'm running Red Hat Linux 8.0 on AMD Athlon. The patch is against MPlayer-current of today. P.S. Please cc me as I'm not subscribed to the list. 1. http://www.assemblytv.net/ -Pekka diff -urN MPlayer-20030807/libmpdemux/demux_real.c MPlayer-real-stream-fix/libmpdemux/demux_real.c --- MPlayer-20030807/libmpdemux/demux_real.c 2003-08-02 21:45:24.000000000 +0300 +++ MPlayer-real-stream-fix/libmpdemux/demux_real.c 2003-08-07 23:19:46.000000000 +0300 @@ -654,6 +654,15 @@ break; } // whole packet (not fragmented): + if (vpkg_length > len) { + printf("\n******** WARNING: vpkg_length=%i > len=%i ********\n", vpkg_length, len); + /* + * To keep the video stream rolling, we need to break + * here. We shouldn't touch len to make sure rest of the + * broken packet is skipped. + */ + break; + } dp_hdr->len=vpkg_length; len-=vpkg_length; stream_read(demuxer->stream, dp_data, vpkg_length); dp->pts=(dp_hdr->len<3)?0:

3 5

MPlayer for MorphOS patch
by DET Nicolas 25 Jan '04

25 Jan '04

Hello ! You will find in this mail a patch for MPlayer <- Cool ! This patch will allow you to compile MPlayer on MorphOS :-) I've tested it with the lastest CVS (15.07.03). And it works. Nevertheless, I 've got crash on certain MPEG4 familly codec, I think something is broken in MPlayer but I'm not sure at all, still investigating. Moreover, I had to modify a little the libavcodec. I can give a patch it someone is interrested. It would be nice to include this changes on the CVS. But someone should modify the configure script to detect MorphOS stuff. You will notice that this patch is very big. The main reason is that it contains also config.h, config.mak and others stuff ... This should be avoid with a good configure script. By the way, It would be cool to notice me some days before the 0.91 release, this way I could package a nice binary version for MorphOS user. Indeed, it's not common to compile something for a "normal" MorphOS user. I would also be notice if this "news" appears on the MPlayer web site. PS: MorphOS is new OS for PowerPC computer (aka 'old' Amiga with PPC and the Pegasos Computer http://www.pegasosppc.com) Have fun Bye

3 2

Re: [xine-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API
by bartscgr＠t-online.de 12 Jan '04

12 Jan '04

hallo benjamin, > > I was working with this kind of design before, but > > nobody seemed interested in doing it. Basicly the > > language of the API layer is immaterial, what > > matters is the messages and data getting passed > > through it (my system used a message/struct 2 > > parameter function for everything). If you set up > > all the data as XML-like structs with messages that > > tell you what you're expecting to see I think it can > > be done language and platform independant at the > > same time. Yes there will be some bloat from the ID > > overhead, but as long as you're passing frames and > > not say, individual pixels, it should be ok. There's > > no reason you can't pass video frames, config info, > > etc basicly as XML documents through an API designed > > to handle them. > > > So we basically wrap this in CORBA then? ;) *lol* ... yeah, overengineering seems to be quite common in those "do-the-right-thing-fixed-forever-joined-effort" style aproaches :> > Seriously: We need a simple little set of functions that a plugin needs to > implement. If it is not dead simple, nobody will implement it. > That was the important part: If it is not dead simple, nobody will > implement it. And that goes for apps _and_ plugins. my point exactly. this is just about defining simple, easy-to-use apis for various multimedia plugins/modules. i too think we should just define a basic set of functions which each plugin type should support, not more. the api should be extensible, though - both, individual implementations should be able to add fields and functions as well as there should be a possibility to add (probably optional) functions to the api in the future over the weekend i have looked through mplayer g2's and xine's stream/input and demux module apis and found them to be quite similar - it should definitely be possible to define a common interface here. i'm planning to set up a little website documenting the two aproaches, maybe i'll also look at other media players (not sure how many aproaches i'll be able to keep in my mind simultaneously ;) ). hope this will be a good starting point for a common api guenter -- "Voraussagen sind ausserordentlich schwierig, vor allem solche ueber die Zukunft." (N. Bohr)

14 31

[PATCH] detection of powerpc 745x
by Soeren Sonnenburg 11 Jan '04

11 Jan '04

it adds the -mcpu=7450 -march=7450 -maltivec -mabi=altivec options for those G4 ppc on linux. Soeren.

4 3

[PATCH] fix wrong dts-aid in open
by f.stock＠t-online.de 11 Jan '04

11 Jan '04

Hello, with using the new support for dts-passthrough I recognized, that the -v option shows not the correct aid's for dts: |[open] audio stream: 0 audio format: ac3 (5.1) language: de aid: 128 |[open] audio stream: 1 audio format: ac3 (5.1) language: en aid: 129 |[open] audio stream: 2 audio format: dts (unknown) language: de aid: 130 |[open] audio stream: 3 audio format: ac3 (stereo) language: en aid: 131 (in this example the 130 must be a 138). Further I changed the textual description from the channels (experimental I got, that 0=Mono, and 4=5.1/6.1 (alle my 6.1 DTS ES give this information, but I got one which is only 5.1 which returns this too). This is the first time I contribute something. It's not much, but I hope my 0.002 Eurocents is better than nothing. begin-base64 644 - LS0tIE1QbGF5ZXItMjAwMzA3MDIvbGlibXBkZW11eC9vcGVuLmMub2xkCTIw MDMtMDYtMjAgMTc6MjQ6MDYuMDAwMDAwMDAwICswMjAwCisrKyBNUGxheWVy LTIwMDMwNzAyL2xpYm1wZGVtdXgvb3Blbi5jCTIwMDMtMDctMDMgMDA6MTc6 MzYuMDAwMDAwMDAwICswMjAwCkBAIC02Niw3ICs2Niw3IEBACiAgICAgICAg IHsgImFjMyIsInVua25vd24iLCJtcGVnMSIsIm1wZWcyZXh0IiwibHBjbSIs InVua25vd24iLCJkdHMiIH07CiAKIGNoYXIgKiBkdmRfYXVkaW9fc3RyZWFt X2NoYW5uZWxzWzZdID0KLQl7ICJ1bmtub3duIiwgInN0ZXJlbyIsICJ1bmtu b3duIiwgInVua25vd24iLCAidW5rbm93biIsICI1LjEiIH07CisJeyAibW9u byIsICJzdGVyZW8iLCAidW5rbm93biIsICJ1bmtub3duIiwgIjUuMS82LjEi LCAiNS4xIiB9OwogI2VuZGlmCiAKICNpbmNsdWRlICJjdWVfcmVhZC5oIgpA QCAtMzQ5LDggKzM0OSwxMSBAQAogCSAgc3dpdGNoICggYXVkaW8tPmF1ZGlv X2Zvcm1hdCApCiAJICAgewogCSAgICBjYXNlIDA6IC8vIGFjMworCSAgCSAg ICBkLT5hdWRpb19zdHJlYW1zW2QtPm5yX29mX2NoYW5uZWxzXS5pZD1hYzNh aWQ7CisJCSAgICBhYzNhaWQrKzsKKwkJICAgIGJyZWFrOwogCSAgICBjYXNl IDY6IC8vIGR0cwotCSAgICAgICAgICAgIGQtPmF1ZGlvX3N0cmVhbXNbZC0+ bnJfb2ZfY2hhbm5lbHNdLmlkPWFjM2FpZDsKKwkgICAgICAgICAgICBkLT5h dWRpb19zdHJlYW1zW2QtPm5yX29mX2NoYW5uZWxzXS5pZD1hYzNhaWQrODsK IAkJICAgIGFjM2FpZCsrOwogCQkgICAgYnJlYWs7CiAJICAgIGNhc2UgMjog Ly8gbXBlZyBsYXllciAxLzIvMwo= ==== Florian -- int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u) ["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&& I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}

3 2

Re: [matroska-devel] Re: Common Opensource codec API
by ChristianHJW 02 Jan '04

02 Jan '04

Ronald Bultje wrote: >Howdy, > >On Fri, 2003-06-27 at 01:47, Guenter Bartsch wrote: > > >>so, basically i think it would be interesting to see if it is possible >>to agree on a common standard for free multimedia plugins, especially >>for >> I 'd have high hopes on this also, but i am not convinced that it is possible to find a common denominator easily. >>let's see, what he says :) one problem with gstreamer imho is their many >>g'isms, not sure what the current state there is. i think a common api >>should not be dependant on stuff like glib or gobject (though i love >>glib i don't think it's a good idea to force everyone into using it). >> >> > >As said above, I tend to agree that it's not a good dependency for a >core thing such as a codec API. > I fully agree here BBB. This codec API can maybe base on a small lib, but thats it. Alex Stewarts' libuci was more an example lib how UCI could be used from an app, while on the codec side this wasnt required at all IIRC: >What I'd love to see is the codec API not being an actual lib, but just >a protocol, like X. Each application can then write it's own >implementation code for this, and the codec API can, if wanted, provide >a header file describing all structs (if any) etc. used in the protocol. >Tying ourselves to one and the same lib likely won't work, even now >we're already reproducing so much of the same code... Do people agree >with this? > > LOL. Maybe OT here, but this reminds me that somebody was comparing EBML, the backbone of matroska and a kind of binary XML, with a printer protocol for LAN printers once ... :) ... >Ok, now back to the actual question, what would it look like. A protocol >describes structs or data fields, documents what properties mean what, >etc. If we want a common demuxer API, I'd very much prefer if people >would use the parent-child object stuffing I described in the beginning >of this email. Each bytestream can export codec streams, which can be >anything, including but not limited to audio, video, subtitle, teletext, >private data or whatever. Types define the actual type of the codec >stream, and by means of a child class, all specifics are filled in for >the particular stream. >For audio, this is rate, channels, maybe (in case of raw audio) the >bitsize (8, 16) or container type (uint8_t, int16_t, maybe expansions of >these for future reference), this can also be float data, btw! We just >need to document what property name means what, and then simply make a >name/value pair system that describes all these. >For video, this would be width, height, ... For subtitles, this would be >nothing at first, I guess. >The parent object describes things like timestamps, duration, the actual >data+size. > >Codecs: much easier. One input, one output. Properties are the same as >the properties for the codec stream in the demuxer in case of the >encoded data. For the decoded data, the same applies, but we'll probably >want to provide some more properties for 'raw' data. Anyway, this just >needs specifying. The mimetypes document above is what we currently use, >other comments are welcome, of course. > >Concerns from my side, for as far as my experience goes with codecs in >GStreamer: do we want to separate between codec and bytestream in case >where these are (almost) the same, such as ogg/vorbis, mp3, etc? If so, >what are the exact tasks of the parser (e.g. defining properties >required by the codec, maybe metadata) and the codec (decoding), and >what do we do if these interfere (e.g. I'm being told that not ogg, but >vorbis contains the metadata of a stream!). > > BBB, can you invest a couple of hours and come up with a small doc describing such a protocol, so it could be discussed on the lists that have been involved and were expressing interest in such a solution ? >And just to state clearly: our final goal is to propose a standardized >API or interface of how codecs, muxer/demuxer libraries etc. should look >to be usable by our applications. It is not to define how a bytestream >should look. ;). Just so I (and you) know what we're actually talking >about. > Alex had the following plans for UCI : UCI : codec API UFI : filter API UMI : muxing API, so that various containers could be used from supporting apps All those required a different level of complexity, with UCI being lowest. UCI itself could not handle streams with more than one substreams in it ( like DV type 1 ), but this was supported by UMI then. Very unfortunately not even UCI was getting anywhere close to completion and we had no sign of Life from Alex since a couple of months now, but maybe somebody find the time to look at what he did and documented so far ? http://uci.sf.net . BBB, is Alex' approach similar to a protocol approach as suggested by you ? >Enough typing for now, I'd better get back to actual work here. :-o. >Comments are very much appreciated. ;). >Thanks for reading, Ronald > > Great ideas BBB, of course i only understand half of it ;-) ..... any other devs care to comment more in detail ? Could such a 'protocol' solution be something you would want to support ? Christian

8 18

Re: [xine-devel] Common Opensource codec API , was : Re: the road to 1.0 and beyond
by bartscgr＠t-online.de 28 Dec '03

28 Dec '03

hallo christian, one the one hand i am happy the subject has changed as this discussion was getting pretty off-topic, on the other hand i dislike two things about the new topic: - opensource while i dislike the word in itself (i never really understood what the opensource movement is about), i think it limits this discussion to just opensource codecs - but binary-only codecs play an important role in today's free software world, like it or not (think quicktime, think real codecs for examples) - codecs i'd like to broaden the discussion to all kinds of plugins, especially demuxers and a common input abstraction layer so, basically i think it would be interesting to see if it is possible to agree on a common standard for free multimedia plugins, especially for - a common input abstraction layer - demuxers - codecs and maybe also - audio/video output among some media player projects. > Ronald 'BBB' Bultje, one of the core devs of the Gstreamer team is > reading here AFAIK, so he could make contact i guess. > > The Gstreamer people do have a nice API with their 'gst plugin API' > AFAIK, but it doesnt help them a lot as its tied to Gstreamer as a > framework and so no codec developers will support it natively. So, in > the end, they have to make all the plugins themselves now ( i guess BBB > is doing that ) and also maintain them. is there some documentation available on gstreamer's plugin api? sounds very interesting to me, but what i found on their website was pretty incomplete and hat lots of broken links in it. gstreamer is definitely worth looking into, though. i have also added mplayer's developement list to the recipients of this mail as i think their mplayer g2 efforts might be a good time to think about common standards as well. > I was talking with Erik 'omega' Waltinsen a couple of times on IRC, he's > the founder of Gstreamer and does certainly know a lot about this kind > of stuff, and he told me he had a neat concept in the very back of his > brains already, but just no time to bring it onto paper. Maybe if you > guys showed some real interest in cooperating with them here, you could > start an avalanche .... let's see, what he says :) one problem with gstreamer imho is their many g'isms, not sure what the current state there is. i think a common api should not be dependant on stuff like glib or gobject (though i love glib i don't think it's a good idea to force everyone into using it). so, let's hear what people have to say. this is the time for constructive proposals, all flames and all mplayer vs xine vs gstreamer vs whatever ranting will go directly into /dev/null. guenter -- "The other day I put instant coffee in my microwave oven ... I almost went back in time." -- Steven Wright

3 2

Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API
by Toby Hudon 28 Dec '03

28 Dec '03

----- Original Message ----- From: Leif Johnson <leif(a)ambient.2y.net> Date: Mon, 30 Jun 2003 12:53:36 -0400 To: bartscgr(a)ra.informatik.uni-stuttgart.de Subject: Re: [xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API > You all might find some inspiration in LADSPA, a pretty nice audio plugin > API hammered out on the linux-audio-dev mailing list : http://ladspa.org/. > It's written for audio plugins only, but I thought some of the concepts > might be helpful for more generic types of plugins. > > leif > Sorry I'm not a linux user so I probably wouldn't be able to do much with it. Can you give me a quick overview? -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup

3 2