[Mplayer-dev-eng] SLOW HARDWARE

[Arpi]

Hi,

> 1. Is it possible to do in mplayer option like -aframedrop
> (drop audio frames instead of video)?
> What I mean: when I watch movie on slow hardware without enabled framedrop
> then sound outdistances video stream. This effect become since mplayer
> can't decode all audio frames (and skip part of them). We have that when we
> watch N video frame then audio is decoded from N+100 frame. In this connexion
> - is it possible that mplayer will drop audio frames instead of video (since with
> -nosound option it play in real-time)?
Dropping audio parts sounds terrible...
and it isn't possible. at least for mp3 and ac3.
for mp3, every frame depends on previous 2 frames. so you can't skip them.
for ac3, every frame depends on teh previous one.

Btw i already thinging about this problem.
The real problem is that video isn't real-time, it's a bit slower than
realtime. So we should slow down audio too but it sounds strange. So we
should use sometricks to play sound longer but with no pitch change.
There are various fourier-based filters to do it, but i think they are too
slow. So the only solution is lowering audio rate. try to play with -srate

> 2. Superficial analysis shows me that mplayer too frequently calls read() function
> to read next bit from file. There was report that on FreeBSD mplayer works faster
> than on Linux. In this connexion maybe it would be better to add mmap technology
> to read from memory, instead file directly. In this case system will read from
> file only 4K blocks that is much faster of calling read() function for each byte even
It is not true. CUrrently mplayer reads file by 2048 byte blocks. Check
stream.c...
It uses 2kB buffer, and read bytes from this buffer. if it's empty, it reads
2048 bytes from teh file (or 2324 bytes from VCD sector).

I'm already working on the new cache system, it will be integrated to
stream.c. It supports big buffers, and also backward caching.
Check TOOLS/cache2.c. It has nice simulation included :)
(random reads, and simulated low input bandwith)

I think it will solve this problem.

Btw for an average DivX, it is not a real problem.
A 800kbit tipical file uses 100kbyte/s, divided by 2k it's 50 read() per sec.

> from buffer. (You will be able to read from memory an each byte even in codecs).
> Am I wrong?
mapping big files (even 600MB, but what about >2Gb files?) to memory
will be hard...

> I can apply this feature (I did such changes but for 0.17-pre version but left them).
> But I'm not sure about stream64 patch - when and who will apply it.
I should apply it, but I have no time nowdays.
I want to change printf's to (int), instead of (long long).
Yes, they will show truncated values for >2GB offsets, but who cares?
They are debug printf's, used for demuxer and stream.c debugging.

> 3. Many from my friends have found that ffmpeg codec is better of win32-divx
> but they spend a lot of time to activate them. You promise to release a two (or more)

just put vfm=6 to the config file.. not too hard and doesn't takes too much
time :)

> codecs.conf - is it possible to do now?
Yea, I should do it... but no time today, sorry.
I have some deadlines with my commercial work :(


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu

_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng