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

fixing rawi420 tv capture
by D Richard Felker III 23 Jul '02

23 Jul '02

Apparently some silly Intel win32 codec has the I420 fourcc, which conflicts with outfmt=i420 tv capture. This should be resolved by either removing I420 from the fourcc's for i263 (is it really used?) or else patching the tv stuff to use "i420" (lowercase) so it doesn't conflict. However I couldn't find where in the source the tv stuff sets the fourcc... Rich

2 3

problem in nuv demuxer?
by D Richard Felker III 23 Jul '02

23 Jul '02

After experimenting with tons of live tv capture programs, the only one I've found that remotely works is NuppelVideo's nuvrec. However, with -r (raw) it takes way too much disk space (not to mention disk bandwidth) to be usable, and the output of the RTjpeg codec is hideous even with -Q 255 -- certainly not suitable for reencoding with mpeg4. So, I tried the following experiment: mkfifo test.nuv nuvrec -n -S 1 -W 320 -H 240 -r test mencoder test.nuv -oac pcm -lavcopts vcodec=mjpeg:vqscale=2 Capturing like this works beautifully for ten seconds or so, but then mencoder always seems to crash. The problem seems to be that ds_read_packet is allocating a packet of length 0 and then trying to memcpy to its buffer. The crash is in an inline function from stream.h: 141 memcpy(mem,&s->buffer[s->buf_pos],x); I imagine the problem is that the nuv demuxer doesn't know how to deal with the case where it only reads a partial packet because the rest hasn't made it through the pipe yet, but this is just a guess. Apologies for posting this to the dev list if it's inappropriate (let me know if that's the case). I'm interested in helping to fix this though, if I can figure out how all this stuff works, so I figure it's at least somewhat relevant here. Rich

1 0

re:[PATCH] dirty frame stepping and and stay in pause after seek
by Dolphin in Ocean 23 Jul '02

23 Jul '02

Hi Michael, I've just joined the mailing list and I I use the latest version (0.90 pre5) but I can't find any variable called pkey which appears in your suggested [PATCH]. Could you tell me what's wrong? It's a feature that I deadly want to have... Thank you in advance. Regards, Fred. Details: ------------------------ @@ -1963,8 +1963,11 @@ guiGetEvent( guiCEvent,(char *)guiSetPlay ); } #endif + if(pkey!=32 && pkey!=112) //(*** I don't have these two lines in my 0.90 pre5 version) mplayer_put_key(pkey); // pass on the key + if(pkey!=32) //(*** compilation error... "pkey" not defeined) + osd_function=OSD_PAUSE ------------------------ __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/

3 2

libavcodec fix proposal (FreeBSD)
by Bohdan Horst 23 Jul '02

23 Jul '02

--- common.h Sat Jul 20 12:13:43 2002 +++ common.h Tue Jul 23 11:11:24 2002 @@ -109,10 +109,6 @@ #ifdef HAVE_AV_CONFIG_H -#ifdef __FreeBSD__ -#include <sys/param.h> -#endif - #ifndef INT64_C #define INT64_C(c) (c ## LL) #define UINT64_C(c) (c ## ULL) this include isn;t longer need and now generate a lot of warnings: In file included from avcodec.h:4, from allcodecs.c:19: common.h:167: warning: `MAX' redefined /usr/include/sys/param.h:214: warning: this is the location of the previous definition common.h:168: warning: `MIN' redefined /usr/include/sys/param.h:213: warning: this is the location of the previous definition in /usr/include/sys/param.h: #define MIN(a,b) (((a)<(b))?(a):(b)) #define MAX(a,b) (((a)>(b))?(a):(b)) in common.h: #define MAX(a,b) ((a) > (b) ? (a) : (b)) #define MIN(a,b) ((a) > (b) ? (b) : (a)) best regards -- / irl:Bohdan 'Nexus' Horst | mailto:nexus@irc.pl | irc:Nexus \ {---------------------------^----------v----------^------------} \ http://www.physd.amu.edu.pl/~nexus/ | Instytut Fizyki UAM /

3 2

VIRUS!? : [MPlayer-dev-eng] Fw:mplayer-dev-eng,congratulations
by Dolphin in Ocean 23 Jul '02

23 Jul '02

Be careful... __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/

2 1

[PATCH] get rid of 'implicit definition' in DS_Filter.c
by Sylvain Petreolle 23 Jul '02

23 Jul '02

all is in title : loader/dshow/DS_Filter.c ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 4

Audio filters first design proposal
by Anders Johansson 23 Jul '02

23 Jul '02

Hi, I have written a design proposal for the new audio filter structure, it is attached to this mail. Have a look, at it. I have so far not addressed the problem of memory buffers. I would still like to make them dynamic all the way into the buffering that is made by mplayer. I need to start looking at where I should put the calls to init, uninit, play, etc - please advise me on this. /. me, //Anders

4 6

[PATCH] for mencoder, 7% speed increase
by wander 23 Jul '02

23 Jul '02

Sorry again, didn't read the rules about sending patches (changed subject line, removed tabs out of patch) ---------- Forwarded message ---------- Hello, First of all I'd like to apoligise for the last posts I made here, the anwser was in the manual, I should have looked better. I made a patch for mencoder so that it prints info like this: Pos: 37.1s 1113f ( 2%) 178fps Trem: 4min 170mb A-V:0.031 [655:224] only once every second, because printing this info 178 times a second takes up quite a bit of processing power and our pathetic human eyes can't handle that anyway. This lead to a 7% increase in speed on my system. I thought about using GetTimer(), but I think the method I use now is more efficient, and the time between every update is allowed to fluctuate a bit. This patch doesn't touch the code for verbose printing btw, so if you want the old behaviour, you could turn on verbose mode. I hope you guys find this patch usefull, Wander

1 0

Patch for mencoder, 7% speed increase
by wander 22 Jul '02

22 Jul '02

Hello, First of all I'd like to apoligise for the last posts I made here, the anwser was in the manual, I should have looked better. I made a patch for mencoder so that it prints info like this: Pos: 37.1s 1113f ( 2%) 178fps Trem: 4min 170mb A-V:0.031 [655:224] only once every second, because printing this info 178 times a second takes up quite a bit of processing power and our pathetic human eyes can't handle that anyway. This lead to a 7% increase in speed on my system. I thought about using GetTimer(), but I think the method I use now is more efficient, and the time between every update is allowed to fluctuate a bit. This patch doesn't touch the code for verbose printing btw, so if you want the old behaviour, you could turn on verbose mode. I hope you guys find this patch usefull, Wander

1 0

RealPlayer codec support
by Florian Schneider 22 Jul '02

22 Jul '02

Hi. I am currently working on RealPlay codec support, i.e. using the closed source codecs to decode video and audio. The current status is: - only video for RV30 is implemented right now - the extended streaming header is (I hope) completely understood and implemented. RV30 implemented a new layer below the normal packets inside the video stream, which i call subpackets. a packet may contain multiple sub packets, and a data block (the one that will be copied to memory) may be spread over several (sub) packets. - I have written some wrapper programs for logging the communication between player and codec. - video decoding for RV30 has been implemented - unfortunately the decoded data seems to be incorrect: even though the input to the RV20toYUV420Transform() and the other functions seem to be identical, the output differs, resulting in an ugly video output. - for video decoding we only use drv[23].so.6.0, the rv[23]0.so.6.0 is just for demuxing (as far as I understand) - the audio codec is half way understood, but should be easier to finish than the video part - do we only need cook.so.6.0? - the case differentiation in the demuxer is somewhat ugly at the moment At the moment I am writing down all the documentation I have on paper, so I can send the patch tomorrow. I don't think it will be ready for CVS, but hopefully some people are interested. Since RV20 has the same interface, it should be possible to support it, too. Regards Flo

3 3