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

[PATCH] ffw-av - interactive fastforward/slow with audio speed adjust (1st draft)
by Steven Mueller 19 Oct '04

19 Oct '04

Hello, Here is a first attempt at a live interactive fast/slow-forward patch that also modifies the speed of sound playback to (approximately) match the video playback rate. It applies cleanly against current cvs as of the time of writing. It's still rather quirky, owing to my not quite understanding the A-V sync structure and the various audio output layers, and possibly due to limitations in the demuxers as postulated below. I've implemented sound output reinitialization to scale the sample rate, but I'm not sure if what I did was kosher, so I'd appreciate a few eyes on it. The patch adds three new mappable commands for input.conf: speed_set float set the playback rate. 1.0 is normal speed speed_mult float multiply the current speed (positive only) speed_incr float increment the current speed (can be negative) Default keyboard mappings: [, ] Decrease/increase the speed by a small factor (= 1.1) {, } Decrease/increase the speed by a large factor (= 2) Backspace Reset the speed to normal The playback_speed is implemented using the infrastructure for the -speed commandline argument, so the allowable range is .01 to 100. Caveats: 1. Not all sound drivers can accelerate the sound speed past a certain sample rate. Some also hold back the video speed. (For example, alsa9 on my system on certain divx files limits the playback rate to 1.0. However, the OSS emulation of my alsa driver does not suffer the same problem... The divx5.0 files from www.redvsblue.com exhibit this behavior, for example.) One can sort of work around this by specifying "-aop list=resample" on the commandline. This causes the speed modifications to apply to the resample audio plugin, and therefore uses more cpu but can have a wider range of possibilities. It also will not limit the video playback rate as far as I've seen. However (this is a big however!) increasing or decreasing the speed too much can cause the A-V sync to go very out of control. Using "-mc 10" can slightly alleviate this problem, but only to a certain extent (about 5x on my 1.3 ghz tbird). Every time I change the speed, alsa9 reports the same samplerate (48000) until I increase the speed too high (~10x), at which point the debug message suddenly shows the resampling being applied to the alsa chain directly and the sound reverts to 1x speed. Of course, this problem also happens with the -speed commandline option. 2. Changing the speed rate can cause minor jumps in the video file. On some files (notably quicktime and wmv), the movie is sped up for a short moment so that you miss a half second or so, regardless of whether you're slowing way down or speeding way up. Note that this phenomenon occurs when pausing and resuming in normal speed playback as well, so I'm thinking this could be limitations with the individual codecs' demuxers rather than with the way I reinitialize the sound. 3. Using a very low speed can make mplayer very unresponsive, since mplayer can only accept one command per rendered frame... 4. The speed display at the end of the status display line only appears when both audio and video are being played, but I'm not sure this field is good anyway since it easily puts the line length at more than 80 characters. Regardless, I can easily add it to the audio/video-only lines if anyone is interested. Another option would be to make it display the speed only when it is not 1x (which I kinda like best, actually...) TODO: * Add an OSD to display the new speed for a short while whenever it's changed (and the osd level is high enough) * Display speed on status line iff playback_speed != 1.0 +/- delta * Add an option to partially mute the sound volume a given amount whenever the speed is not exactly 1.0x (or maybe there should be some (configurable?) tolerance?) * Write proper documentation (changes to manpage and DOC files) * Examine the play loop more closely to determine whether the skips of accelerated playback in certain videos (as described above) can be avoided, and perhaps get the audio to more instantaneously sync, too... Anyway, I hope people find it useful, and I hope to get it to a point where it can be included in mplayer. After writing the bulk of the patch, I discovered the following thread in the archives, so I'm hoping there's still a bit of interest: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2003-February/015835.html Thanks, Steve PS - Sorry for the excessively long description. :) -- Steven Mueller diffusor(a)ugcs.caltech.edu

16 28

Patch: vo_shm - simple embedding vo
by Flemming Frandsen 13 Oct '04

13 Oct '04

I have a project where I want to play a movie as a texture in OpenGL in realtime, so naturally I turned to MPlayer, I copy+pasted from vo_tga and created a video out plugin that outputs frames to shared memory. It doesn't use any locking, so it should be low-overhead for both mplayer and the consumer, but that also means that the consumer must have it's own framerate (which my opengl application does have). It works by having the consumer set up a shared memory segment that holds the shmids of two frame buffers, vo_shm writes to the framebuffer with the lowest frame number and the consumer reads from the framebuffer with the higest frame number, that way they don't step on eachothers toes. I've tested it and it works quite nicely, so here is the patch if you'd like to include it: http://dion.swamp.dk/dl/mplayer-1.0pre1-shm1.diff.gz Any comments? -- Regards Flemming Frandsen - http://dion.swamp.dk PartyTicket.Net co founder & Yet Another Perl Hacker

4 11

[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

Patch concerning get_total_time
by Michael Behrisch 10 Jan '04

10 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, since there was no reaction when posting it to the users list I repost my patch for enabling get_total_time in ogg-files here. Greetings, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/nOMrZDyR4hR8HnQRArvPAKDM7zZl5MPuQwdPxTGlCgDubZYIjQCfddKt wD3/E2oKuvrp7dnmqMirPQA= =fhut -----END PGP SIGNATURE-----

2 1