Notices


Reply
Thread Tools
Posts: 150 | Thanked: 3 times | Joined on Jan 2007
#341
@konttori:
Hehe thanks I will try the new version on my billy-boy machine, hope it will work long enough. With M$ you never know, especially when some virus is freaking you out.
So my windows will either die by itself(with a little help from my nasty icq-virus) or by steel(...an axe lying around).
Is this AMD problem only related to a AMD+windows combination, or is there a 1.31 linux version, too?
I am going to test about10-15 avi files. Will report if the sync problems occurs.
Thanks again.
 
Posts: 150 | Thanked: 3 times | Joined on Jan 2007
#342
Ok, another file out of sync. Tried with MC 1.30 for Linux and 1.31 for Win. One-Pass and Two-pass. Serge, I can't cut the movie because then it's comletely out of sync. I can put it on my private ftp or http server (190mb) and you can download it if you want. Please PN me... Must hurry now...
 
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#343
Originally Posted by DCr33P View Post
Ok, another file out of sync. Tried with MC 1.30 for Linux and 1.31 for Win. One-Pass and Two-pass. Serge, I can't cut the movie because then it's comletely out of sync. I can put it on my private ftp or http server (190mb) and you can download it if you want. Please PN me... Must hurry now...
Can you check the original file properties ('mplayer -identify' output would be nice to have) and post them here? It might have something special in it. Also try watching both the original and converted file with the pc version of MPlayer (http://www.mplayerhq.hu/design7/dload.html) and some other video players to check if there are any sync problems.

Audio sync problems could be caused by mplayer not having enough cpu resources to play video in realtime (if you disabled -framedrop option for example). Try transcoding the same video with lower bitrate/resolution and check if it helps.

Another source of problems could be DSP audio decoder, you can try running mplayer with '-ao esd -ac ffmp3' options to use ARM core for decoding audio.

If nothing helps, I'll try to download and have a look at this video file myself.

Even if you find a solution that works for you, please provide some kind of feedback, it may help other people having the same problem. Thanks.
 
Posts: 150 | Thanked: 3 times | Joined on Jan 2007
#344
Unfortunetly, I am not at home and have no Linux PC(Can't even try on n800, cause I send back my SD card today), so I can't give you mplayer output right now. But the -ao esd -ac ffmp3 parameter worked when I tried tonight. The problem is that the performance got very bad with this option, even while the cpu ist just 3/4 of maximum (2/4 when without -ao esd -ac ffmp3). Isn't mplayer using ARM Core for decoding, so cpu should be 100% in use? Or did I misunderstand something? Nevertheless, I'll have my Tux back soon (And hopefully a new working SD card) and I will post outputs.

PS: The movie worked good in every other windows player(WM,VLC) and Linux player(mplayer,vlc) I tried...

Last edited by DCr33P; 2007-02-28 at 19:07.
 
Posts: 144 | Thanked: 21 times | Joined on Mar 2007 @ Finland
#345
I did some testing with latest mplayer (mplayer_1.0rc1-maemo.10) with default settings (VO nokia770). And i got N800.

Very high quality 1500 kbps 704x384 XviD (audio 150 kbps mp3) seems to lag, but maybe armv6 video decoding can be optimized little bit.

High quality 4:3 512x384 1070 kbps XviD (audio 128 kbps mp3) and 711 kbps 352x288 XviD (96 kbps) seems to work pretty fine. Of course there are some serious tearing problems, but hopefully Nokia will fix that in a future firmware/patch.

Do you have any idea how much mplayer performance can be optimized? Whats the limit of flawlessy playback?
 
Posts: 449 | Thanked: 29 times | Joined on Jun 2006
#346
Originally Posted by jmk View Post
Very high quality 1500 kbps 704x384 XviD (audio 150 kbps mp3) seems to lag, but maybe armv6 video decoding can be optimized little bit.
Why would you need a video of this quality for a screen that is only 4" wide? I use between 2000 to 2500 kbps to reencode my DVD's for a 37" LCD screen an I don't notice a difference. On a 4" screen 800kbps is more then enough.
 
Posts: 144 | Thanked: 21 times | Joined on Mar 2007 @ Finland
#347
Originally Posted by bac522 View Post
Why would you need a video of this quality for a screen that is only 4" wide? I use between 2000 to 2500 kbps to reencode my DVD's for a 37" LCD screen an I don't notice a difference. On a 4" screen 800kbps is more then enough.
That was just a test . I am so lazy that i don't want re-encode my XviD files which i have already on my computer.
 
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#348
Originally Posted by DCr33P View Post
Unfortunetly, I am not at home and have no Linux PC(Can't even try on n800, cause I send back my SD card today), so I can't give you mplayer output right now. But the -ao esd -ac ffmp3 parameter worked when I tried tonight. The problem is that the performance got very bad with this option, even while the cpu ist just 3/4 of maximum (2/4 when without -ao esd -ac ffmp3). Isn't mplayer using ARM Core for decoding, so cpu should be 100% in use? Or did I misunderstand something? Nevertheless, I'll have my Tux back soon (And hopefully a new working SD card) and I will post outputs.

PS: The movie worked good in every other windows player(WM,VLC) and Linux player(mplayer,vlc) I tried...
Cpu usage is not constant when decoding video and can vary quite a lot between different frames, so having cpu loaded too high is generally a bad sign (you may run out of cpu resources any time). It is very important to have framedropping enabled (it is set by default, so you don't need to do anything) so skipping displaying of some frames may help to keep video and audio in sync for complicated scenes. If you are getting too much frames dropped and playback is not very good, you need to transcode video to lower bitrate or resolution or both.

MPlayer is using ARM core for decoding video and can use DSP core for decoding MP3 audio.

Anyway, was the audio/video sync better for '-ao esd -ac ffmp3' option?

Also please try to run a few more tests to check that the results are reproducible. Do you always get audio sync problems when trying to play this video with the default mplayer settings or it can occur sometimes?
 
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#349
Originally Posted by jmk View Post
I did some testing with latest mplayer (mplayer_1.0rc1-maemo.10) with default settings (VO nokia770). And i got N800.

Very high quality 1500 kbps 704x384 XviD (audio 150 kbps mp3) seems to lag, but maybe armv6 video decoding can be optimized little bit.
Yes, it can be optimized for sure. Upstream ffmpeg has some armv6 optimizations in SVN already that are still not used in mplayer build for N800. Using these optimizations is in my todo list for the next version of maemo mplayer. I can't provide precise predictions about optimizations limits. Benchmarking, identifying bottlenecks, optimizing them, benchmarking again and so on is the process of improving performance. Once there are no bottlenecks visible, we can consider that the optimization is mostly done.

High quality 4:3 512x384 1070 kbps XviD (audio 128 kbps mp3) and 711 kbps 352x288 XviD (96 kbps) seems to work pretty fine. Of course there are some serious tearing problems, but hopefully Nokia will fix that in a future firmware/patch.
Actually tearing problems in mplayer are now worse than they could be. After trying different methods of fixing tearing without much success, I disabled all vsync completely and used what seems to provide the best performance (another option was to still have tearing but work slower).

I got a bit busy lately at work (yes, even on weekends), so did not have much time left for mplayer. Also I'm waiting for n800 firmware update as there does not seem to be much point in trying to workaround tearing problems currently.
 
Posts: 150 | Thanked: 3 times | Joined on Jan 2007
#350
Ok, here's my output from within the n800:
Code:
AVI file format detected.
ID_VIDEO_ID=0
ID_AUDIO_ID=1
VIDEO:  [DIVX]  400x240  24bpp  23.980 fps  512.2 kbps (62.5 kbyte/s)
Clip info:
 Software: MEncoder 1.0rc1-3.4.2
ID_CLIP_INFO_NAME0=Software
ID_CLIP_INFO_VALUE0=MEncoder 1.0rc1-3.4.2
ID_CLIP_INFO_N=1
ID_FILENAME=n800-bsg-3-16.avi
ID_DEMUXER=avi
ID_VIDEO_FORMAT=DIVX
ID_VIDEO_BITRATE=512208
ID_VIDEO_WIDTH=400
ID_VIDEO_HEIGHT=240
ID_VIDEO_FPS=23.980
ID_VIDEO_ASPECT=1.6667
ID_AUDIO_FORMAT=85
ID_AUDIO_BITRATE=101624
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=2570.06
[nokia770] Nokia N800 hardware detected
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
ID_VIDEO_CODEC=ffodivx
==========================================================================
Trying to force audio codec driver family dspmp3...
Opening audio decoder: [dspmp3] MP3 audio pass-through for Nokia 770 (fake decoder)
AUDIO: 48000 Hz, 2 ch, ??, 32.0 kbit/2.08% (ratio: 4000->192000)
ID_AUDIO_BITRATE=32000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
Selected audio codec: [dspmp3] afm: dspmp3 (MP3 audio pass-through for Nokia 770)
==========================================================================
AO: [gst] 48000Hz 2ch ?? (1 bytes per sample)
ID_AUDIO_CODEC=dspmp3
Starting playback...
VDec: vo config request - 400 x 240 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1,67:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1,6667
VO: [nokia770] 400x240 => 400x240 Planar YV12  [fs] [zoom]
SwScaler: using unscaled yuv420p -> yuyv422 special converter
A:  -0,1 V:   0,5 A-V: -0,562 ct: -0,050  13/ 13 48%  7%  3,1% 0 0 45%
Without any parameters I got a video(!!!) delay of approx. 1 sec. So the audio is too early. Serge, you said that framedropping is on by default, so I used that, cause I haven't toggled framdropping off. With "-ao esd -ac ffmp3" the A/V is nearly synced. There's just a delay of ~100ms, so it's quite good, except for the overall perormance.
The delay occurs every time I used this converted movie. There are files which work perfect, but there are encoded with the same options. From now on I will put all my converted movies together to collect them and hopefully see any similarity in movies which work and which do not work. Right now I just see randomly working and not working movies...
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 17:22.