June 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

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

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

[PATCH} Greek documentation
by Ironhell3 . 27 Dec '03

27 Dec '03

you can find the updated help_mp-el.h in the incoming directory ironhell3(a)hotmail.com Greece http://www.angelfire.com/on3/ironhell3index/HellWorld.html _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

[PATCH] New filter vf_ivtc, smart dropping of every 5th frame
by Johannes Guenther 12 Dec '03

12 Dec '03

Hi, after using mencoder for awhile I came across movies with (real) 29.97 fps which were created from a 24 fps source by inserting a duplicate frame after every 4th frame. When (re)encoding these movies it would be clever to drop these duplicated frames to save bandwidth and to eliminate the jerky motion artefacts. But to only use the option '-ofps 23.976' is not satisfactory because mencoder bluntly drops every 5th frame regardless of being duplicates or not; or missed I something? So I wrote a filter which does the job - other programs like transcode or VirtualDup already have one. There have also been requests concerning this issue: http://mplayerhq.hu/pipermail/mplayer-users/2002-September/020628.html http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-January/004502.html Some implementation details; how I see this problem; things I would like to discuss: - To detect the duplicated frames it is necessary to buffer at least 6 frames (you cannot display/encode the frames and decide afterwards 'Oh, I wanted to skip that frame'). But buffering (at least of this amount) is not supported by the vf-API (am I right?). So I had to expand it by introducing a new image-type MP_IMGTYPE_BUF. - Unfortunately I have to memcpy the whole frame to the buffer. It would be better to store only the meta-data/image-structure but this did not work (the information was lost during two calls of 'put_image'). - You need to also specify the '-mc 0' and '-noskip' option to mencoder otherwise mencoder complains about missing the first frames (which are gone to the buffer and were not yet displayed) and tries to insert frames. - 'put_image' is not noticed whether this is the last time it is called, but it needs to flush the buffer then, otherwise the last frames are lost. This cannot be done in 'uninit' because then everything is already over (files closed, image-structures invalid). The hack is to provide the total frame number as a hint to vf_ivtc via commandline, thus 'put_image' knows when it is its last time. - All in all it seems that the libMPcodecs API does not like buffering and skipping frames that much, it is not designed to provide such things, is it? For example a return code of 0 or -1 to indicate that a frames was skipped. (At least this information is not passed to mencoder) - Is a filter really the right way? Maybe it is better to provide this functionality directly by mencoder/mplayer. I'm not so intimate with the API details so it is likely that there are more elegant solutions. Despite all the problems and hacks the filter works here quite well and produces the correct result even if there is a change in the pattern of duplicated frames (counted as 'resyncs'). So, what so you think? Bye, Johannes -- http://beam.to/Hawk PGP Key fingerprint = 2F 72 52 1C CF 86 96 35 8A DD 8E F5 C6 05 CE C5

8 13

Translation fixes
by Nicolás Lichtmaier 30 Oct '03

30 Oct '03

As I told you all earlier, I've made a script to create .po files from the help files. By doing this I discovered some flaws in the translation files. This is the diff. I'm also attaching the new version of my tiny script. Index: help_mp-cz.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-cz.h,v retrieving revision 1.28 diff -u -r1.28 help_mp-cz.h --- help_mp-cz.h 31 Oct 2002 11:01:40 -0000 1.28 +++ help_mp-cz.h 20 Nov 2002 18:10:20 -0000 @@ -228,7 +228,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Nepovedlo se otevøít audio demuxer: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Nepovedlo se otevøít demuxer pro titulky: %s\n" #define MSGTR_TVInputNotSeekable "TV vstup neumoŸòuje posun (seek)! (Pravdìpodobnì \"posun\" bude pouŸit pro zmìnu kanálù ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Informace o demuxeru %s jiŸ pøítomno\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Informace o demuxeru %s jiŸ pøítomno!\n" #define MSGTR_ClipInfo "Informace o klipu: \n" // dec_video.c & dec_audio.c: Index: help_mp-de.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-de.h,v retrieving revision 1.57 diff -u -r1.57 help_mp-de.h --- help_mp-de.h 11 Nov 2002 19:42:22 -0000 1.57 +++ help_mp-de.h 20 Nov 2002 18:10:23 -0000 @@ -224,7 +224,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Öffnen des Audiodemuxers fehlgeschlagen: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Öffnen des Untertiteldemuxers fehlgeschlagen: %s\n" #define MSGTR_TVInputNotSeekable "TV-Input ist nicht durchsuchbar! (möglicherweise änderst du damit den Kanal ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Demuxerinfo %s existiert bereits\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Demuxerinfo %s existiert bereits!\n" #define MSGTR_ClipInfo "Clipinfo: \n" // dec_video.c & dec_audio.c: Index: help_mp-dk.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-dk.h,v retrieving revision 1.16 diff -u -r1.16 help_mp-dk.h --- help_mp-dk.h 19 Oct 2002 20:26:04 -0000 1.16 +++ help_mp-dk.h 20 Nov 2002 18:10:25 -0000 @@ -216,7 +216,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Kan ikke åbne lyddemuxer: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Kunne ikke åbne undertekstdemuxer: %s\n" #define MSGTR_TVInputNotSeekable "TV input er ikke søgebart! (kan være du skulle skifte kanal ;))\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s allerede tilstede\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s allerede tilstede!\n" #define MSGTR_ClipInfo "Klip info: \n" // dec_video.c & dec_audio.c: Index: help_mp-fr.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-fr.h,v retrieving revision 1.23 diff -u -r1.23 help_mp-fr.h --- help_mp-fr.h 14 Nov 2002 12:19:31 -0000 1.23 +++ help_mp-fr.h 20 Nov 2002 18:10:30 -0000 @@ -186,7 +186,7 @@ #define MSGTR_TooManyAudioInBuffer "\nDEMUXER: Trop (%d dans %d octets) de packets audio dans le tampon!\n" #define MSGTR_TooManyVideoInBuffer "\nDEMUXER: Trop (%d dans %d octets) de packets vidéo dans le tampon!\n" #define MSGTR_MaybeNI "Peut-être jouez-vous un flux/fichier mal multiplexé, ou le codec n'est pas là...\n"\ - "Pour les fichier .AVI, essayez l'option -ni." + "Pour les fichier .AVI, essayez l'option -ni.\n" #define MSGTR_SwitchToNi "\nFichier .AVI mal multiplexé - passage en mode -ni!\n" #define MSGTR_Detected_XXX_FileFormat "Fichier de type %s détecté!\n" #define MSGTR_DetectedAudiofile "Fichier audio détecté!\n" Index: help_mp-gr.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-gr.h,v retrieving revision 1.6 diff -u -r1.6 help_mp-gr.h --- help_mp-gr.h 27 Oct 2002 10:43:38 -0000 1.6 +++ help_mp-gr.h 20 Nov 2002 18:10:30 -0000 @@ -228,7 +228,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Áðïôõ÷ßá êáôÜ ôï Üíïéãìá ôïõ demuxer Þ÷ïõ: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Áðïôõ÷ßá êáôÜ ôï Üíïéãìá ôïõ demuxer demuxer õðïôßôëùí: %s\n" #define MSGTR_TVInputNotSeekable "TV input äåí åßíáé áíáæçôÞóéìï! (ðéèáíüí ç áíáæÞôçóç íá ãßíåé ãéá ôçí áëëáãÞ óôáèìþí ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Ïé ðëçñïöïñßåò ãéá ôï demuxer %s õðÜñ÷ïõí Þäç\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Ïé ðëçñïöïñßåò ãéá ôï demuxer %s õðÜñ÷ïõí Þäç!\n" #define MSGTR_ClipInfo "Ðëçñïöïñßåò ôïõ ìÝóïõ: \n" // dec_video.c & dec_audio.c: Index: help_mp-nl.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-nl.h,v retrieving revision 1.20 diff -u -r1.20 help_mp-nl.h --- help_mp-nl.h 19 Oct 2002 20:26:04 -0000 1.20 +++ help_mp-nl.h 20 Nov 2002 18:10:35 -0000 @@ -216,7 +216,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Kan audio demuxer niet openen: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Openen van de ondertiteling demuxer is mislukt: %s\n" #define MSGTR_TVInputNotSeekable "TV invoer is niet doorzoekbaar! (Waarschijnlijk zal zoeken de kanalen veranderen ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s reeds aanwezig\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s reeds aanwezig!\n" #define MSGTR_ClipInfo "Clip info: \n" // dec_video.c & dec_audio.c: Index: help_mp-pt_BR.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-pt_BR.h,v retrieving revision 1.6 diff -u -r1.6 help_mp-pt_BR.h --- help_mp-pt_BR.h 19 Oct 2002 20:26:04 -0000 1.6 +++ help_mp-pt_BR.h 20 Nov 2002 18:10:37 -0000 @@ -176,7 +176,7 @@ #define MSGTR_MpegNoSequHdr "MPEG: FATAL: EOF enquanto procurava pela sequência de cabeçalho\n" #define MSGTR_CannotReadMpegSequHdr "FATAL: Impossível ler a sequência do cabeçalho!\n" -#define MSGTR_CannotReadMpegSequHdrEx "FATAL: Impossível ler a extensão da sequência de cabeçalhon" +#define MSGTR_CannotReadMpegSequHdrEx "FATAL: Impossível ler a extensão da sequência de cabeçalho\n" #define MSGTR_BadMpegSequHdr "MPEG: Sequência de cabeçalho ruim!\n" #define MSGTR_BadMpegSequHdrEx "MPEG: Extenção da sequência de cabeçalho ruim!\n" Index: help_mp-sk.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-sk.h,v retrieving revision 1.8 diff -u -r1.8 help_mp-sk.h --- help_mp-sk.h 19 Oct 2002 20:26:04 -0000 1.8 +++ help_mp-sk.h 20 Nov 2002 18:10:40 -0000 @@ -217,7 +217,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "NemôŸem otvori» audio demuxer: %s\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "NemôŸem otvori» demuxer titulkov: %s\n" #define MSGTR_TVInputNotSeekable "v TV vstupe nie je moŸné sa pohybova»! (moŸno posun bude na zmenu kanálov ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s uŸ prítomné\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s uŸ prítomné!\n" #define MSGTR_ClipInfo "Clip info: \n" // dec_video.c & dec_audio.c: Index: help_mp-zh.h =================================================================== RCS file: /cvsroot/mplayer/main/help/help_mp-zh.h,v retrieving revision 1.11 diff -u -r1.11 help_mp-zh.h --- help_mp-zh.h 17 Nov 2002 12:31:02 -0000 1.11 +++ help_mp-zh.h 20 Nov 2002 18:10:42 -0000 @@ -62,8 +62,8 @@ #define MSGTR_NoHomeDir "ÕÒ²»µœHOMEÄ¿ÂŒ\n" #define MSGTR_GetpathProblem "get_path(\"config\")ÎÊÌâ\n" #define MSGTR_CreatingCfgFile "ŽŽœšconfigÎÄŒþ: %s\n" -#define MSGTR_InvalidVOdriver "ÎÞÐ§µÄÊÓÆµÊä³öÇý¶¯: %s\nÓÃ'-vo help' t²é¿Ž¿ÉÓÃµÄÊÓÆµÇý¶¯µÄÁÐ±í" -#define MSGTR_InvalidAOdriver "ÎÞÐ§µÄÊÓÆµÊä³öÇý¶¯: %s\nÓÃ'-vo help' t²é¿Ž¿ÉÓÃµÄÊÓÆµÇý¶¯µÄÁÐ±í" +#define MSGTR_InvalidVOdriver "ÎÞÐ§µÄÊÓÆµÊä³öÇý¶¯: %s\nÓÃ'-vo help' t²é¿Ž¿ÉÓÃµÄÊÓÆµÇý¶¯µÄÁÐ±í\n" +#define MSGTR_InvalidAOdriver "ÎÞÐ§µÄÊÓÆµÊä³öÇý¶¯: %s\nÓÃ'-vo help' t²é¿Ž¿ÉÓÃµÄÊÓÆµÇý¶¯µÄÁÐ±í\n" #define MSGTR_CopyCodecsConf "(°Ñetc/codecs.conf(ŽÓMPlayerµÄÔŽÂëÊ÷ÖÐ)žŽÖÆ/ÁŽœÓ ~/.mplayer/codecs.conf)\n" #define MSGTR_CantLoadFont "ÎÞ·šŒÓÔØ×ÖÌå: %s\n" #define MSGTR_CantLoadSub "ÎÞ·šŒÓÔØ×ÖÄ»: %s\n" @@ -222,7 +222,7 @@ #define MSGTR_OpeningAudioDemuxerFailed "Žò¿ªÒôÆµdemuxer: %sÊ§°Ü\n" #define MSGTR_OpeningSubtitlesDemuxerFailed "Žò¿ª×ÖÄ»demuxer: %sÊ§°Ü\n" #define MSGTR_TVInputNotSeekable "TVÊäÈë²»ÄÜËÑË÷! (¿ÉÄÜËÑË÷ÓŠžÃÓÃÀŽžü»»ÆµµÀ;)\n" -#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s ÒÑŸÏÔÊŸ\n!" +#define MSGTR_DemuxerInfoAlreadyPresent "Demuxer info %s ÒÑŸÏÔÊŸ!\n" #define MSGTR_ClipInfo "Clip info: \n" // dec_video.c & dec_audio.c: #! /bin/bash set -e process() { cpp -dD $1 | sed -ne 's/" *"//g' -e "s/\\\'/\'/g" -e 's/#define $[^ ]*$ $.*$/\1 \2/p' | sort } eng=help_mp-en.h process $eng > engmessages for f in help_mp*h ; do if [ $f = $eng ]; then continue fi l=$(echo $f | sed -ne 's/help_mp-$.*$\.h/\1/p' ) echo processing $l ... join engmessages <(process $f) | sed -ne 's/$[^ ]*$ $".*"$ $".*"$$/msgid \2\ msgstr \3\ /p' > $l.po msgfmt -o "$l.mo" "$l.po" || true done echo creating pot ... sed -ne 's/$[^ ]*$ $".*"$$/msgid \2\ msgstr ""\ /p' < engmessages > mplayer.pot

2 1

next-audio/video-track patch
by Rüdiger Kuhlmann 29 Oct '03

29 Oct '03

Attached the current next-audio/video-track patch, updated to current mplayer. Thanks for ignoring it for months. It also fixes a segfault and the unability to package. -- 100 DM = 51 € 13 ¢. 100 € = 195 DM 58 pf. mailto:ruediger@ruediger-kuhlmann.de http://www.ruediger-kuhlmann.de/

4 3