February 2002 - MPlayer-dev-eng - lists.mplayerhq.hu

wrong positioning of vobsubs
by Felix Buenemann 22 Mar '02

22 Mar '02

Hi Kim Minh, the positioning of vobsubs is wrong, they are placed too high because you don't calculate, that the black borders present on the dvd are cropped away in the divx. Example: NTSC Anamorphic 16:9 DVD -> 720x480 -> streched to 854x480 for proper aspect Movie encoded is not 16:9 but 2.35:1, so real video res is 854x362 the unused space is filled with black bars of each 118px above and below movie to get the 480px. Now when compressing to DivX the black bars are cropped away and only the 854x362 area is resized and encoded to 640x272. Now your code calculates the subtitle placement as if the black bars were still present, which results in the subs beeing displayed to higher to the top of the video instead of (somewhat) directly at the bottom. -- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________

2 2

Decoder With Motion Compensation
by Mike Melanson 11 Mar '02

11 Mar '02

Hi team, Okay, so I've been delaying on the task of writing the RoQ video decoder. This is my first attempt at writing a decoder for motion-compensated YUV output data. What should I know about implementing a motion-compensated decoder for MPlayer? Any special facilities I should be aware of? It seems to me that I need to allocate 2 output buffers to work with: One for the current frame and one with the previous frame's data so I can copy YUV data from the last frame to the current one. I've only written relatively simple RGB decoders so far that only need to allocate 1 output buffer. I'll need 2 output buffers now, so how should I allocate them with A'rpi's new allocation scheme that involves something like: imgtype = IMGTYPE_STATIC; I'm still not quite sure what that's for. Also, I saw someone write that there's a new X entension in the works called XVmc, a common X interface into motion compensation hardware. How far along is this support? Any plans to support it in MPlayer? Which video hardware has such MC support? Thanks... -- -Mike Melanson

7 18

Audio Filter Layer
by Alex Beregszaszi 09 Mar '02

09 Mar '02

Hi, we should move ao_plugin and related plugins from libao api level, it should be handled by dec_audio. Needed for proper support from mencoder. Are there any plans regarding audio filter support in mplayer's new filter layer? Anders? Btw, is anyone working on audio volume normalizer? (i saw pl_volume) - alex

5 6

Patch, allows subtitles out of film area
by Tomas Konir 09 Mar '02

09 Mar '02

Hi I made small patch, which allows show subtitles out of film area. Anyone wrote a few time ago, that is not possible, because of library design or any other thing. I made it only for XV driver (i think, it can be made for other drivers too). This patch add posibility to create area (called sub_box) for subtitles under film area. Two options are privided. Using -subbox 'num' make sub_box area with num% size from film height. Using -autosubbox create sub_box area automatically to fill the screen. As addon there are two keys 'r' and 't' to allow moving with subtitles up or down. Patch is included as file and can be found on http://molly.vabo.cz/~moje/mplayer-subtitles.diff MOJE -- Tomas Konir Brno ICQ 25849167

2 1

[PATCH] A-V sync & Sub delay messages OSD
by Marcin Juszkiewicz 09 Mar '02

09 Mar '02

Hi all It's my 1st patch to mplayer. It is made as "cvs diff -c" (I can send you unified tomorrow - sorry). This patch change displaying "A-V sync" and "sub delay" messages to be visible with "osdlevel=1" for a moment. I made it because they was visible only in osdlevel=2 (time counter) which I don't like, but yesterday I have a movie with too badly synchronized subtitles which I had to synchronize few times during watching. Pressing z/x works but I don't get any info when not using osd with time counter. BTW. indenting scheme used in mplayer sources isn't too much readable ;) -- Marcin Juszkiewicz mailto:marcinj@netbox.pl

2 1

Re: [PATCH] Development (Was: Clean up demuxers)
by Daniel Egger 05 Mar '02

05 Mar '02

Hija, since many people bitched about broken threads (hey, what about bitching about the unkosher no-CC: rule?) I subscribed to the list and thus this is the last broken mail from me here. <lots of bitching skipped> > it may help on few specific architecture (non-x86) in inner loops, Yes, it does. Quite a lot in fact since many have some sort of decrement and jump if non-zero mnemonic which is quite efficient. > but the return value (flag, can be -1, 0 1) of demuxer read is not the place > where changing it to unsigned help... I see. Didn't realise that it can be negative also. Why's that BTW? > but why shoudl we put it into cvs??? > if you wnat to find referers, change it in your tree. If it makes you happy I'll stick to that. > i still say: placing static arrays in header files is a VERY BAD IDEA. > also gcc says tat, yo ushould know :) Has it's uses, but in this case you're right. > the way you used is bad, it's a bit better than switch(){} but if we change > it, then change it to the right solution: single function pointer set by > demux_open. Iff you can find a good place where you can setup the pointer it's okay. I've to dig more through the source though to find one without loosing flexibility wrt alternative implemenations. > we won't accept cosmetics patches. so if you can't do more, don't do. > if you don't like indenting or other views of current source, it is YOUR > problem. everyone ha sits coding style, and we won't accept patches changing > it. We're not talking about STYLE here. Code like: if(! IS_RUNNING(config)) { if(strcasecmp(opt,"vcd") == 0) { char* s; if(!param) return ERR_MISSING_PARAM; s = (char*)malloc((strlen(param) + 6 + 1)*sizeof(char)); sprintf(s,"vcd://%s",param); entry = play_tree_new(); play_tree_add_file(entry,s); free(s); } else if(strcasecmp(opt,"dvd") == 0) { is a punishable offense in a few countries. If you cannot accept cleanup to such a evil (and probably buggy - I wouldn't even dare to run a checker when I see this) codefragment it's probably not the right project to participate for me. That's what I was talking about in the first place. > and renaming variables is really not welcomed. it makes impossible to > replace demuxer.c with older version, or even merge with developers > branches. it's simply codmetics change and won't be allowed here. So you have troubles using development tools? Say it so and I might be able to live with that. Otherwise this is simply FUD. > ... and when you want to call type=2 demuxer's read you cann array[2]. > insteda, why don't you set up a single function pointer when opens teh > demuxer (so demuxer type=2 could set ptr=ptr2, type=5 set ptr=ptr5 etc). > i'm sure it's faster than indexing an array and THEN referencing the func ptr Yes, you're right. It's pretty clear now; just had troubles to grok your language, sorry. It's not necessarily faster BTW, but then again my statement above applies here. Albeu wrote: > Critics are in the other thread (if we can call this a thread), I agree at 100% with > Apri and I try to say the same thing about how you should do. Explain ? Here : > typedef int (demx_fill_buffer_func*)(demuxer_t* demux, ....other args....); > struct demuxer_t { > ...... > demux_fill_buffer_func fill_buffer; > demux_seek_func seek; > ...... > } > Then in demux fill : > demuxer->fill_buffer(demuxer,ds); Got it. The problem I originally had still applies though: To make this (or mine) code work I had to equalise the parameters of all functions which means additional parameter tossing even for demuxers which don't need them and thus unnecessary overhead. Ideally there should only be one pointer which is passed over to the demuxers to not loose performance and keep it clean but therefor I would either need to add an additional pointer to demuxer_t which carries the stream_t (or whatever it is called) or the other way round but I've no idea which way is better or if it's even possible to derive one from the other; The code suggests that this is possible for a few demuxers because they already do it but if someone can enlighten me, I'd be really grateful. -- Servus, Daniel

20 110

Re: Mozilla Plugin
by Andrew Docherty 03 Mar '02

03 Mar '02

After having a look at the options, plugger (which i could never get to work with mozilla) and mozstreamer which I could never compile, I would like to see the following in an mplayer plugin: * ability to play embedded media player files (asx asf) (as mplayer does this already it only requires passing the correct window and src info to mplayer) * minimal gui components, initially play, pause, stop and a progress bar. * XPCOM components to enable script interaction with the plugin (compatible with media player) * Interactive stream download (ala quicktime) so the stream can be progressivly saved and replayed. I plan to do use the existing gui implementation get embedded and mplayer output and minimal buttons running. The other points can wait for that to be acheived. Andrew >On Wed, 27 Feb 2002, Andrew Docherty wrote: > >> I haven't done any development on MPlayer before, but I'm interested in writing >> a plugin for mozilla, I've fiddled around with this and have a rudimentary >> plugin working - so it seems to be quite feasible. >> > Before going any further I'd like to know if anyone else has also started on >> this, has almost finished, has suggestions for which direction I should head >> or any other comments. > >Answer: Nope, to the best of my knowledge, no one is attempting to >write an MPlayer plugin for Mozilla. Have at it. I'm just curious what you >have in store the plugin (what does it do, exactly?), and how you plan to >go about doing it? > > Thanks, and good luck... >-- > -Mike Melanson

2 3

BUG - incorrect fps detected on NTSC DVDs result in jumpy video
by Christian Lambert 02 Mar '02

02 Mar '02

Hi Ivan, I uploaded the file called test.vob in the incoming directory. Notice that there are a few interlaced frame for about 1 or 2 seconds at the beginning of the movie, then when the logo starts it jumps to "film" and stays that way. You will notice at the first scene that has a slow camera pan that you can see that it's really jumpy. Also, I noticed that the video and audio isn't always in sync on all DVDs. That is maybe due to the ac3 delay value which isn't read and interpreted by mplayer? Sometime that value is 0 so in that case there is no sync problems, but it's sometime a negative or positive value between 0 and 100ms. So it's about what I'm seeing in some NTSC DVDs. Not sure exactly where that value is stored in the VOB file, but maybe in the header of the AC3 stream itself. By using dvd2avi (a windows program) you can see how it's interpreting the "film" frames versus the interlaced frames and also extract the ac3 delay value. See the web page for more details. http://www.doom9.org/mpg/dvd2avi.htm -Christian |Can you upload a sample file in 'incomming' (about 50mb) |There was explanation about bad mastering and converting that makes fields |soup. |Anyway i don't have dvd and i cannot get/play dvd from your regeon. | |Best Regards | Ivan Kalvachev |

2 1

Correctly Printing FOURCCs
by Mike Melanson 01 Mar '02

01 Mar '02

Hi team, This is a terribly minor, nagging issue that only affects big-endian users. The following code: unsigned int fourcc; printf ("fourcc: %.4s", (char *)&fourcc); prints the FOURCC backwards on big endian systems ('MARC' instead of 'CRAM', ' war' instead of 'raw '). I wanted to make a macro that will break it down into 4 printable chars, like so: printf ("fourcc: %c%c%c%c", FOURCC_PRINTF_PARMS(fourcc)); The macro will be replaced with the appropriate bit shifts. There are a bunch of files I'll have to touch to fix up all the %.4s modifiers. Just a heads up. If there are no serious objections and no one has a better solution, I'll get going on it tonight. Thanks... -- -Mike Melanson

6 9

Enough Already, Egger
by Mike Melanson 01 Mar '02

01 Mar '02

Hi Daniel (Egger), Look, enough already. Please? Yes, we developers know that the organization of certain subsystems (notably the demuxers and the decoders) can use some work. And we're working on reworking them. Yes, the documentation leaves a little to be desired and we acknowledge that fact as well. That's why Gabucino, the documentation maintainer, has taken it upon himself to rewrite the docs and he is open to polite suggestions about the direction to take the new docs. I appreciate that you're interested enough in MPlayer to have argued your case this long. But what's your goal here? I tried to help you out here. I suggested that you could help us out with the Cinepak color issue on PPC. In fact, there is a LOT of work yet to be done on the PPC. You have a kickin' PPC machine and we could really use your help in that area. Make little changes to the codebase and then the core developers will trust you enough to make big changes to the codebase. But all of this arguing about finer style points is wearing very thin. It's wasting your time and it's really starting to waste our time. I don't like the look of a lot of the MPlayer codebase, either, but the reality is that it works and I've learned to live with it. You should, too, if you'd like to make a useful contribution to the project. -- -Mike Melanson

4 13