mplayer jerkiness. My fault?
 

I might have spoken too soon about mplayer being perfect on Diablo. I noticed last night that after ten minutes or so of video playback, it begins to drop frames. Quitting playback and resuming (thank §DEITY for that resume option!) fixes this -- for ten minutes.

I don't know whether this is my fault or not, but here are the particularities of my system:

- Diablo, last version;
- mplayer 1.0rc1-maemo.29.n8x0;
- Videos transcoded with "Nokia N800 Video Convert 0.84" at 400x240, 512 kbps video and 128 kbps audio (I tried with lower bitraes, but got no improvement);
- playing from (and this might be the culprit) a 4GB SD card, non-SDHC and rated (or rather printed on it) 150x speed. This card worked fine previously, with the occasional and familiar stutter in mplayer, and the rated speed appears to me plenty fast enough;
- no other application is running.

Has anyone noticed similar behaviour and/or (hopefully) a solution?

Re: mplayer jerkiness. My fault?
 

Similar problem here: I experimented with h.264-videos and found decent settings for the built-in media player. The same video is unwatchable in mplayer, video and sound stutter like hell and mplayer doesn't respond any more (or better: takes up to a minute to react to clicks/key presses).

I found it gets better when I reduce the bitrate even further, but it still isn't really good and I reach a level where video quality becomes bad. So given the fact that the built-in player has a better performance and a nicer UI, why should I bother getting mplayer to work?

Re: mplayer jerkiness. My fault?
 

That metalayer-crawler zombie b*st*rd makes for at least one argument...

Mind you, I'm not saying mplayer becomes unwatchable, merely that it begins to resemble my P910i at 15 fps.

Re: mplayer jerkiness. My fault?
 

RC1 doesn't handle wmv3 and h.264 too well.

Re: mplayer jerkiness. My fault?
 

I checked one of the transcoded files in Virtualdub and it reports "3ivx D4 4.5.1" as the video codec, but complains about variable audio rates. COuld any of these be the cause and if so, what encoder should I use?

I like N800 Video Convert because it's bloomingly fast.

Re: mplayer jerkiness. My fault?
 

maybe you should try to disable metalayer-crawler and see if there is any improvement. i get those stutters sometimes too, not only on videos but also on music. when i check the load applet it shows metalayer-crawler doing its thing.

thank you, metalayer-crawler for teaching me the virtue of patience. :p

Re: mplayer jerkiness. My fault?
 

RC2 is not better for H.264 either. MPlayer and FFmpeg do not have any ARM optimizations for H.264 yet. Have no idea about WMV3 because I don't have any such files and did not run benchmarks for it.

But that is not related to the original report. Slowdown after 10 minutes of playback sounds definitely suspicious. Does anybody else have this problem?

Re: mplayer jerkiness. My fault?
 

I tried the same video with a different transcoder, Konttori's Media Converter (v2.02). Unfortunately I found out afterwards that it defaults to the same codec (3ivx D4 4.5.1 -- what are the odds, eh?) and with the same result: Around minute 13 of a 25 minute video frames start dropping and audio gets ever so slightly choppy (the audio is a lot less annoying than the video, but it's definitely there).

Now, in fairness, this is a Penn&Teller ******** video, so it might just be that mplayer doesn't like the gratuitous swearing and rampantly unfunctional nudity. Still, I like it and I really wanna watch it, even if "jerkiness" gets a totally new meaning with boobs in the picture.:rolleyes:

Re: mplayer jerkiness. My fault?
 

There are general optimizations though:

From RC2 changelog:

* support SVQ3 and H.264 in X-QT over RTSP, now RTSP Apple keynotes work
(live555)
* support H.264 over RTSP (live555)
* H.264 decoding speedup
* Slice-based parallel H.264 decoding (-lavdopts fast:threads=N)
* lowres support for some H.264 files

Re: mplayer jerkiness. My fault?
 

Have you confirmed performance improvement on ARM? What are the numbers from your benchmarks? I know that mplayer/ffmpeg got some nice x86 optimizations for H.264 and also now supports parallel decoding on multicore CPUs, but that does not have much value for internet tablets.

In any case, H.264 decoding from mplayer is still slow on ARM and very far from hardware capabilities limit.

Re: mplayer jerkiness. My fault?
 

Bump.

The problem hasn't automagically gone away. My setup is still the same as in the first post, and the outcome is still the same:

Mplayer starts to drop both frames and audio (likely to stay in sync with video) after between 10:30 and 11:49 minutes of playback. Halting mplayer and resuming makes the problem go away -- until another ten to eleven and a half minutes have passed. I am now in the -- for me -- surreal situation that the built-in Media Player is actually better than mplayer, and I don't like it one bit. With the crawler disabled, the userfriendliness of Media Player is below that of mplayer with its GUI-ish frontend.

I've tried different transcoders, but as they all use mencoder as the backend, they unsurprisingly made no difference at all. I'm going to try a clip with PocketDivxEncoder, but I've had rather disappointing results with that transcoder and mplayer/Maemo in the past.

PS: Oh. Forgot: I tried a different card (2GB, no speed mention) and it plays in exactly the same way, i.e.: not very well.

Re: mplayer jerkiness. My fault?
 

Okay, in spite of the obvious lack of interest in this thread, I'll just muddle on, shall I?:rolleyes:

I tried transcoding a file with PocketDivXEncoder (incidentally, my transcoder of choice for everything not Nokia) and, provided I set "Xvid" in the advanced options, these files play back in mplayer without any of the stuttering I experienced before.

Now, while at first this may seem like a result, it gets me seriously wondering. PocketDivxEncoder also uses mencoder, but obviously it does something that all of the regular N8X0 transcoders don't -- at least on my N800.

So, while the problem hasn't been identified, it has at least been solved for my predicament. I'll continue with PocketDivXEncoder (which sadly is slower and, for the N800 at least, not as "automatic" as n800conv) and leave it at that.

Re: mplayer jerkiness. My fault?
 

I seem to remember that p-divx-e will allow you to see the arguments supplied to mencoder. When I wrote a script to transcode movies for various things I used pde to provide a friendly interface whilst I did all my initial hacking... I find I get pretty good results using this script:

http://www.zaurus.org.uk/download/sc...ecode-2pass.sh

--edit--
I have re-encoded a tv program specifically to watch in (k)mplayer using the above program and I will see whether it loses sync after 10-11 mins.

Re: mplayer jerkiness. My fault?
 

There is interest actually. I'm just trying to find some reproducible testcase to provide more usable feedback. A sample of encoded video could help.

Re: mplayer jerkiness. My fault?
 

It seems that, save for the difference in video codecs, there's another difference between the files, at least when examined by VirtualDub:

The files transcoded by n800videoconv or Konttori's Media Converter all receive a VirtualDub complaint about having variable audio bitrates. Unfortunately I have no idea how to turn that off in those transcoders or even if it's a bad or a good thing.

I'll try to put up a few samples.

Re: mplayer jerkiness. My fault?
 

...also might be interesting to see the various parameters being used to create the video file to be used on the N800 during all your trials and tribulations. I have a script on my MythTV box that will transcode (using mencoder) shows that it has recorded from television, and I've never had any problem at all viewing any of the transcoded video on my N800.

Karel -- take a look at the mythtv wiki page: http://www.mythtv.org/wiki/index.php...800_Tablet_PDA ...an earlier version of that page is where I started when I built the script on my system. There's quite a bit more information there explaining the process....

Re: mplayer jerkiness. My fault?
 

PDE uses MAD for audio encoding (128 kbps) and I've selected Xvid as the video encoder (and keep the bitrate to about 500), other than that those settings seem quite similar to what I have PDE do. I'm reasonably certain that the variable audio bitrate is the main culprit, but I can't read "mencoders" well enough to figure out if you have variable audio or not.

MythTV, eh? Is it as good as bittorrent?;)

Only kidding. I don't have Myth set up, but I do use a "sneaker" version: a DVD recorder, DVD-RW disks and VirtualDub. More work, but it's also more fun.:rolleyes:

Re: mplayer jerkiness. My fault?
 

> -oac mp3lame -lameopts mode=0:cbr:br=96

"use these audio compression options: mp3lame encoder, with the following parameters - mode 0, constant bitrate, bitrate=96"

...better; it's legal. ;)

Re: mplayer jerkiness. My fault?
 

well, it looks like that the OP's problem has to do with the fact that the other encoders are using the 3ivx codec in an AVI container that's causing the problem or the variable bit mp3 file. I would bet that it's the VBR mp3 that's the culprit and it would be easy to test if you are using virtualDubMod.

for the following, you'll need to have:
VirtualDubMod
a way to make a CBR MP3
the AVI codec of your choice (3ivx, xvid, dvix, etc etc)

Load your file into VDM and go to the streams menu and pull down to Stream List. It will show you the audio stream and you save as WAV, but sometimes it doesn't work at times. Check the file it outputs as if it's the size of an MP3, chances are it is (might have the WAV extension, but it's an MP3). If it doesn't work, use the demux option and then convert the MP3 file to a WAV file... then convert it back to a Constant Bit Rate (CBR) mp3.

Back in VDM and still in the Streams list you were in before, select the audio file and then hit the 'disable' button. Then hit the 'Add' button and go to the CBR mp3 you saved, and it will add it to the streams list. Hit 'Okay' then and it will return you to the main VDM window.

Next, go to the 'file' menu, pull down to 'save as' and it will bring up menu showing the save as options. At the bottom of the window, there are two pull-downs: video mode, and compression. You can change the first one to 'direct stream copy' and it will attempt to just add the new MP3 file to your existing video file (if you have the proper codec involved, that is... I think). If you don't, you can reconvert it into another video codec you do have (I'd suggest xvid, but use what you have). Change 'Video Mode' to 'fast recompress' and 'compression' to your codec of choice. Add a name to your file and hit 'save' and VDM will output your new video file to test out.

or, you can upload it and I could give it a try for ya :)

Re: mplayer jerkiness. My fault?
 

I think I've found another way of testing it: Konttori's Media Converter has the option of using Xvid as the video codec, but I've discovered that it still produces VBR sound tracks. I've encoded a file and I'll be testing it on mplayer in a few minutes. If mplayer hickups on it, I'm pretty much sure the VBR is the culprit.

As to your suggestion of using VirtualDub to remedy the audio: I found out that PocketDivXEncoder produces "nice" audio files, so I'm going to use that from now on. It would be nice if it had the Nokia tablets as a preselection, but the hassle is minor (I've sent a request to the developers of PDE to include a Nokia Tablet template).

But thanks nevertheless for the VDM tutorial...

Re: mplayer jerkiness. My fault?
 

I'm still quite unsure about the illegality of downloading TV shows from sites like EZTV. One could argue that removing the commercial blocks is naughty, but then why not outlaw going to the bathroom during a commercial break?

And if it's a matter of me catching shows months or years before they come to European networks (if at all), why then are visitors to the USA not banned from watching tv over there?

Re: mplayer jerkiness. My fault?
 

hey, I don't make the laws or enforce the laws... ;-)

did u see above, where I decoded the mencoder option line regarding constant bitrate audio?

Re: mplayer jerkiness. My fault?
 

Latest results. I transcoded the same file with Konttori's MediaConverter, setting Xvid as the codec. The file played jerkily from almost the beginning in mplayer, increasingly dropping frames and soundfragments as it went along.

The same file, transcoded with PocketDivXEncoder and the same settings (or so I thought, see below) played without any major flaws at all (there is a very slight, extremely short stutter every three minutes or so, but this has been the case with the tablets from the beginning; it used to be much, much worse).

This is the file information mplayer on the tablet gives:
For the MediaConverter file:
video codec: xvid
bitrate: 499 kbps
res: 400x224
audio codec: mad
bitrate: 32 kbps
samples: 48000 hz 2 ch

For the PocketDivXEncoder file:
video codec: xvid
bitrate: 483 kbps
res: 400x224
audio codec: mad
bitrate: 96 kbps
samples: 48000 hz 2 ch

They look remarkably similar, save two problems:

• Both MediaConverter and PDE claimed they had the audio bitrate set at 128 kbps, while mplayer reports them at 32 and 96 kbps respectively;
• the video bitrates were supposed to be 512 kbps according to the transcoders, but again mplayer shows a difference.

I don't know whether this discrepancy is mplayer's "fault" or that the transcoders are off, but it is telling that the file with the lowest audio bitrate is also the one causing playback troubles.

Re: mplayer jerkiness. My fault?
 

Okay, I'm trying to research this video playback problem with Media Player, Videocenter, Canola, mplayer and mYTube. In all of these I get stuttering in the video playback about every 5 seconds or so.

I have the latest Diablo on my N800 with two 8 GB, Class 6 SDHC cards.

Is the stuttering being cause by other software?

Other items which I have loaded which might be suspect:

advanced-backlight
large-statusbar-clock
load-applet
maemo-control
omweather

Anyone have any ideas?

Re: mplayer jerkiness. My fault?
 

I'm sorry, but personally I don't really care anymore. After the last "upgrade" f*ckup, I've decided to not invest any energy in Nokia's tablets anymore. Enough is enough. I'll keep using my crippled tablet as an ebook reader until I get my Pandora (hopefully in september), after which my N800 will become a paperweight.

The Pandora will come with the VLC player and has a (compared to the Nokias) infinitely more powerful graphics subsystem, capable of playing non-transcoded DivX and Xvid files.

I would have loved to keep the N800, but a tablet without decent HWR was a hassle to begin with. Add to that the ongoing video playback limitations and the persistent problems with system upgrades and that's me finally gone. The Pandora will be different enough that I won't have to keep comparing it to the Nokias and it has the bonus of being (to me at least) a spiritual successor to the Psion Series 3a, the pocketable computer I loved most of all (yes, even more so than the Newton!).

Re: mplayer jerkiness. My fault?
 

Well, it's not any of these.

Re: mplayer jerkiness. My fault?
 

Nevertheless I'd like to see such comparison when you lay your hands on one.

Re: mplayer jerkiness. My fault?
 

In the previous OS revision on my N800, the video playback was pretty much always smooth. It just seems like it gets the "hiccups" under Diablo. I've looked at the process listing to see if there's anything that starts demanding CPU cycles on about the same interval as the stutters, but haven't seen any suspects.

I tend to agree with Karel Jansens (post#25) that the N8x0 should be a rock-solid media-player without any special "tweaking" required if they want consumers to purchase them.

My Nokia 9300 does video quite well, though it supports only DivX codec and is a 150 MHz device.

Re: mplayer jerkiness. My fault?
 

Your Nokia has 3x smaller screen :) And i doubt you watch video on 640x200?

Re: mplayer jerkiness. My fault?
 

Responding to the question by Bundyo, yes I do watch video on my Nokia 9300. With Smart Video Converter, by Lazy Cat Games, I can keep about 6 hrs of video at 256 kbps (15 fps) with stereo audio (22050 Hz) on my 1 GB MMC card.

Normal video is displayed at 400x200, but I can convert a 16:9 aspect ratio widescreen video from DVD and see it in widescreen on my display without noticable distortion.

I have converted both normal and PAL video with it. It's great to carry on flights with you.

Re: mplayer jerkiness. My fault?
 

Getting back on topic...

I've done some experimenting...it seems that the problem is how other players (Canola, mYTube) call mplayer. I run into stuttering or speed-up/halt problem after using these other players for a while (10+ minutes), but when I use mplayer by itself on the root video it plays just fine.

Could it be that when one of these other players calls mplayer to do its processing for a single video, that some tuning variables don't get reset between different videos?

So far everything that I've tested is an .flv file.

It might be that the reason that I had not seen this problem before is that previously I was watching .avi's which use the internal media player engine.

Re: mplayer jerkiness. My fault?
 

Hey Karl,
I'm sure that many us "feel your pain." Or rather, we're feeling the same pain!!!
Anyway, as I notice many of the old-timers dropping out of the forum one by one, I just wanted to say how I've enjoyed and appreciated your posts and contributions over the years.

Re: mplayer jerkiness. My fault?
 

I'm new to this thread, sorry. But, if you install the load applet, start what stutters then look at the desktop to see the load meter, you'll find the CPU load all the way to the top. It's only a 400 Mhz processor and we're loading it all up with servicing Canola and the other monster app handlers. All that glitz simply eats the available CPU cycles. Dump the glitz and boot mplayer with its simple handler and the meter is no longer maxed out and the movie plays fine. All that graphic glitz simply eats too much computer on the simple machine.

The simple media player, if it has a codec, is faster because its osso is already loaded if you look at the processes running on the load applet, so there's less load with it than with raw mplayer.