Best video quality supported by N800 and N810 via mplayer

[karatchov]

Hello,
I've been testing video players in my N800, and mplayer is by far the fastest video player in this tablet.

Now, I'm looking for the best video quality that mplayer can run smoothly in the tablet.

Most of the topics in this forum discussing video encoding for N8x0 are old or are based on the build-in video player.

So far, what I've found, is that I can play 640*360 without any lags.

Container: AVI
Width 640
Height 640/Aspect Ratio
Video Codec: Xvid (with 1 pass)
Video bitrate: 800
Audio Codec: MP3
Audio Bitrate: 128

This works like a charm for 16x9 videos, even with subtitles, I'm looking forward to see what can you get from the N8x0 processor.

EDIT:
Finally, here is what I think the best quality mplayer (MPlayer 1.0rc1-maemo.29.n8x0) can play on N8x0:
Container: AVI
Width: 480 for 4/3, and 640 for 16/9
Height: 360
Video Codec: Xvid (with 1 pass only)
Video Bitrate: 800
Framerate: 24 f/s
Audio Codec: MP3
Audio bitrate: 128
SampleRate: 44.1 Khz

Encoder used: HandBrake

Again, these values are based on my experience, If you think they should be corrected, feel free to post.

[Karel Jansens]

Hello,
I've been testing video players in my N800, and mplayer is by far the fastest video player in this tablet.

Now, I'm looking for the best video quality that mplayer can run smoothly in the tablet.

Most of the topics in this forum discussing video encoding for N8x0 are old or are based on the build-in video player.

So far, what I've found, is that I can play 640*450 without any lags.

Container: AVI
Width 640
Height 640/Aspect Ratio
Video Codec: Xvid (with 1 pass)
Video bitrate: 800
Audio Codec: MP3
Audio Bitrate: 128

This works like a charm even with subtitles, I'm looking forward to see what can you get from the N8x0 processor.
Do you encode those at full frame rate? I've never managed to get any video player on the N800 play smoothly at that resolution and bitrate, unless I dropped quite a few frames per second(something I intensely dislike).

Also, why only one pass?

I'm going to give it a try with PocketDivxEncoder. I'll let you know how it fared.

[nikolajhendel]

Container: AVI
Width 640
Height 640/Aspect Ratio
Video Codec: Xvid (with 1 pass)
Video bitrate: 800
Audio Codec: MP3
Audio Bitrate: 128



I use
avi
width 400 (with widescreen source) - variable on 4x3 source
height variable on widescreen source - 240 on 4x3 source
video codec xvid, 1000 kbps
audio codec mp3 - 128 kbps, stereo

no skipping when using mplayer

[karatchov]

*I'm using 24 f/s

*I choosed 1 pass to get a constant video bitrate (I'm not sure, I may be wrong) because I remember reading that mplayer in N8x0 performs correctly when the bitrate is equal or lower than 800.

I remember also reading in this forum that it's possible to play 800*480 video at full framerate when the video is encoded in mpeg1, but hadn't the chance to test that.
-------
Again, this is all based on simple experiences, that's why I created this thread, so that you can report you own experience, and ultimatly get the best of the Tablet.

[GeneralAntilles]

http://wiki.maemo.org/Video_encoding

[karatchov]

After some tests, I find that 640*480 and 640*450 doesent play smoothly.

Although,
640*360 seems to work perfectly(I can upload a video)
680*382 looks also fine, but I cant really say it is perfect.
700*394 it starts to lag ....

So, for 16x9 sources 640*360 should be ok .
for 3*4 ... I'm still looking

[karatchov]

http://wiki.maemo.org/Video_encoding
Thanks ...


MPlayer for Maemo is not as limited as the built-in Media player, and recommended over the built-in player for all users. More video codecs are supported, higher video bitrates and resolutions will play without framedrop, and external subtitles are supported.

So the Media player limitations in this wiki page are not the MPlayer limitations. Someone will have to set the new limits :D

[Justjoe]

Also, it depends on the scene, so some vids will look/ run better than others, despite the same settings; a dialogue-based movie look better than a fight scene which will look better than an action-based sci-fi movie with tons of camera pans and odd backgrounds. A camera pan across a cluttered room seems to be the toughest to handle, whereas a boxing match might run smoothly at the same setting since there's less work being done.

Frankly 400:240 500/96 kbps is very good for everything I've watched on the N800, and 480x360 at 600/ 128 kbps is better than I've seen a "need" for, though of course quality is subjective, and tastes vary. Remember, of course, that we're viewing on a sub-5-inch screen and following from that, probably less-than-perfect audio situation, so there's no need for "perfect," but of course that shouldn't stop us from finding a set of "best." If someone can either recommend or email me a clip where I will notice a benefit of going from 480 to 600+ in resolution, I'd appreciate it, because so far I haven't been able to detect much of a difference.

In the "probably more info than you wanted" department:

At the moment, I'm playing with this cli statement, refined (and still refining) for my personal taste from the original which I saw on raiden's site, <http://www.raiden.net/?cat=2&aid=515> :

mencoder -oac mp3lame -lameopts cbr:preset=96 -ovc xvid -vf scale=480:360 -xvidencopts bitrate=800:pass=2 -o outFile.avi inFile.VOB

...on a pre-ripped DVD.

It seems to ignore the 800 video bitrate and the pass=2, and seems to set the bitrate by the scale setting, meaning 480:360 gets a higher bitrate than 400:240 no matter what setting of bitrate=XXX. Also, a different audio bitrate seems to change the video bitrate inversely; a higher cbr:preset=XXX means a slightly lower video bitrate, while vid bitrate seems to have no effect on audio bitrate. Audio bitrate seems to be pretty stable, staying near whatever I set it to.

So yesterday with this statement I ended up with "ST:Voyager Endgame" at 87 minutes, 416M, 480x360, 557/ 96 kbit, while "Time Bandits" came in at 116 minutes, 714M, 480x360, 747/ 96. Why the large difference in video bitrate? I don't know, probably because the letterboxing in "Time Bandits," shrinks the screen, which I forgot about and intend to re-do later. "Endgame" runs perfectly, without a single hitch, while I have yet to view "Time Bandits," but an initial scan-through looks good.

You can set the scale to a single number and that will be the height, while the width sets "automatically," which is sometimes handy.

Next I'll be playing and looking to change to 44.1kHz from 48kHz audio, and taking suggestions if you can save me some time.

Joe

[GeneralAntilles]

So the Media player limitations in this wiki page are not the MPlayer limitations. Someone will have to set the new limits :D

No, those limitations are hardware bound.

[Serge]

No, those limitations are hardware bound.
That's a vague statement. Of course any software is limited by hardware capabilities. But reaching the real hardware bounds is possible only with really well optimized software. And mplayer/ffmpeg is not optimized well for ARM11 currently.

[karatchov]

As a reply to JustJoe asking to see "benefit of going from 480 to 600+ in resolution", I just uploaded 2 videos of the same source:
TestVideo-480-270-800bitrate.avi (http://www.mediafire.com/?dzjomyenyt1)
TestVideo-640-360-800bitrate.avi (http://www.mediafire.com/?omjml2zm4ih)

They both play correctly on my N800, I cant see any speed difference.

The scenes in this small videos are "active", and if mplayer is able to handle this video correctly, I think it should be able to handle any type of scene.(again I'm using 1 single pass, I THINK that with 2 passes the bitrate may "peak" on action scenes and cause some lag)

[Karel Jansens]

I just re-encoded an episode of 2 and a Half Men with PDXE:
624x352 at 23.976 fps (I chose not to change the original resolution)
XviD codec 2 pass (Virtualdub gives it 691 kbps) (the original was over 1,000 kbps)
MP3 sound at 128 kbps
Total file size 116 MB

Although I haven't let it run completely yet, I was surprized -- nay: stunned -- that mplayer appears to run this file without any stuttering or tearing on my N800. Clearly Serge has been doing some sneak-finetuning while I wasn't looking.

[spock]

Can you guys confirm the version of mplayer you are using? I can't get it to play smoothly regardless of what codec/bitrate/resolution I use. The built-in Nokia Media Player seems to work *FAR* better for me (mpeg4). See my thread here:

http://www.internettablettalk.com/forums/showthread.php?t=27213

Ignore the stuff about UPnP streaming -- the results are the same even if the file is played off the tablet directly.

[GeneralAntilles]

The built-in Nokia Media Player seems to work *FAR* better for me (mpeg4).

The built-in player works better with h.264/AAC than mplayer, but mplayer handles MPEG4 (part 2, not part 10)/MP3 better than the built-in player.

[karatchov]

Can you guys confirm the version of mplayer you are using? I can't get it to play smoothly regardless of what codec/bitrate/resolution I use. The built-in Nokia Media Player seems to work *FAR* better for me (mpeg4). See my thread here:

http://www.internettablettalk.com/forums/showthread.php?t=27213

Ignore the stuff about UPnP streaming -- the results are the same even if the file is played off the tablet directly.


MPlayer 1.0rc1-maemo.29.n8x0
when I try to launch a video via the terminal , it starts to lag after some seconds, while it play correctly when launched via the GUI launcher.

[Justjoe]

Thanks karatchov, for going through the trouble of encoding and uploading.

I was paying particular attention to the details in black/ shadow and mist, which I think is the weakest part of the videos that I've transcoded. I think I'll stick with 480 width, since I wasn't able to see a significant difference in quality while playing the videos you uploaded -- on the N800. Viewing them on the desktop computer showed the differences very well, but the N800 screen is small enough that I think those details get lost.

Just FYI, I'm getting better details on single pass runs, (at least on the slow sections), though file size is larger than on double pass runs. (200M original.VOB, 54M for single pass, 50M for double pass). To see the difference requires much more zooming (in) than normal viewing would allow, and of course these very small differences aren't even remotely viewable on a screen the size of a tablet screen.

Thanks again,

Joe

[attila77]

Also, it depends on the scene, so some vids will look/ run better than others, despite the same settings; a dialogue-based movie look better than a fight scene which will look better than an action-based sci-fi movie with tons of camera pans and odd backgrounds. A camera pan across a cluttered room seems to be the toughest to handle, whereas a boxing match might run smoothly at the same setting since there's less work being done.


MBWOTO Given a fixed bitrate, it doesn't really matter how dynamic a scene is, the amount of data to be pushed around is usually the same (unless it's *totally* static, of course). There are two ways around this:

a) Use 1 pass fixed bitrate. Yes, gets artifacts on intense action but hey, better blocky than choppy, right ?

b) Use a bitrate cap. If you use mencoder this is done with -lavcopts vrc_maxrate=700 not sure for other SW/codecs.

EDIT: And the oft overlooked single most playback quality killer on the NIT: 48000Hz audio streams. Conversion of those to 44100 is a must.

[Serge]

MBWOTO Given a fixed bitrate, it doesn't really matter how dynamic a scene is, the amount of data to be pushed around is usually the same (unless it's *totally* static, of course).
The amount of data may be fixed, but it does not mean that the amount of work to be done will be fixed as well when decoding video. Scenes with lots of motion or panning still take more cpu than mostly static scenes even with the same bitrate.


There are two ways around this:

a) Use 1 pass fixed bitrate. Yes, gets artifacts on intense action but hey, better blocky than choppy, right ?

b) Use a bitrate cap. If you use mencoder this is done with -lavcopts vrc_maxrate=700 not sure for other SW/codecs.

Yes, fixed bitrate single pass encoding helps to reduce cpu usage spikes and is preferable from the performance point of view.

Just one more thing, cartoon/animation is typically much easier for cpu to decode. For example, N810 just barely has enough power to be able to decode and playback 480p big buck bunny video in realtime (without sound). This of course needs some tweaks (crop filter to letterbox it from 854x480 to 800x480) in order to prevent cpu from wasting too much resources on software downscaling because the video itself is bigger than screen resolution. It should be possible to find some animation in 640x480 resolution which would play fine on the device :) And adding missing ARMv6 optimizations could help a lot for sure.

Here is the log of 480p video playback:

/media/mmc2 $ mplayer -nosound -benchmark -quiet -vf crop=800:480 -vo omapfb:tearsync=0 big_buck_bunny_480p_stereo.avi
MPlayer 1.0rc1-maemo.29.n8x0 (C) 2000-2006 MPlayer Team
CPU: ARM
Internet Tablet OS version:

[MENU] Can't open menu config file: /home/user/.mplayer/menu.conf
Menu inited: /etc/mplayer/menu.conf

Playing big_buck_bunny_480p_stereo.avi.

AVI file format detected.
AVI_NI: No audio stream found -> no sound.
VIDEO: [MP42] 854x480 24bpp 24.000 fps 1840.6 kbps (224.7 kbyte/s)
Clip info:
Software: MEncoder 2:1.0~rc2-0ubuntu13
[omapfb] Nokia N800/N810 hardware detected
[omapfb] tearsync is disabled
Opening video filter: [crop w=800 h=480]
Crop: 800 x 480, -1 ; -1
================================================== ========================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmp42] vfm: ffmpeg (FFmpeg M$ MPEG-4 v2)
================================================== ========================
Audio: no sound
Starting playback...
VDec: vo config request - 854 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [omapfb] 800x480 => 800x480 Planar YV12 [fs] [zoom]
[omapfb] ARM JIT scaler (quality=2): 800x480 YV12 => 800x480 YUV420


BENCHMARKs: VC: 466.264s VO: 120.273s A: 0.000s Sys: 4.053s = 590.590s
BENCHMARK%: VC: 78.9490% VO: 20.3648% A: 0.0000% Sys: 0.6862% = 100.0000%

Exiting... (End of file)


So decoding and showing all frames of this 596 seconds long video takes 591 seconds which is just a little bit faster than realtime. Of course playback speed is not uniform, but decoding ahead and buffering can help to solve this problem (like mplayer-xp fork or omapfbplay proof of concept demo program from beagleboard). And adding audio would be the last straw to break everything.

And of course getting such good looking results is practically impossible with any real non-animated 480p video :)

[Serge]

EDIT: And the oft overlooked single most playback quality killer on the NIT: 48000Hz audio streams. Conversion of those to 44100 is a must.

Yes, audio pipeline is a major pain on N8x0 devices. It goes through ESD daemon and ends up in DSP. It is hard to even get audio/video playback in sync, let alone be sure that no extra cpu resources are wasted on resampling somewhere.

[spock]

EDIT: And the oft overlooked single most playback quality killer on the NIT: 48000Hz audio streams. Conversion of those to 44100 is a must.

YES!! THANK YOU!! That solved my problem. Now my mediatomb on-the-fly transcoding setup works with Canola flawlessly! All it took was setting the audio to resample to 44100 (was 48k). I knew it had to be something simple.

[Jaffa]

YES!! THANK YOU!! That solved my problem. Now my mediatomb on-the-fly transcoding setup works with Canola flawlessly! All it took was setting the audio to resample to 44100 (was 48k). I knew it had to be something simple.

Which is why we have tools like tablet-encode (http://mediautils.garage.maemo.org/tablet-encode.html) et al. The people saying "just use mencoder" are missing the subtleties like this which are encountered. By centralising the workarounds in tools, the expertise can be shared more quickly and not have to be exposed to users.

[attila77]

The amount of data may be fixed, but it does not mean that the amount of work to be done will be fixed as well when decoding video. Scenes with lots of motion or panning still take more cpu than mostly static scenes even with the same bitrate.

I stand corrected. One more question for people more familiar with the NIT innards - does it make sense to make anamorphic videos from a performance standpoint ? In the 'old days' it paid off to go anamorphic as you had to multiply only vectors and not full matrices (among other benefits, with the downside of having non-square pixels).

[spock]

Which is why we have tools like tablet-encode (http://mediautils.garage.maemo.org/tablet-encode.html) et al. The people saying "just use mencoder" are missing the subtleties like this which are encountered. By centralising the workarounds in tools, the expertise can be shared more quickly and not have to be exposed to users.

Ah yes, but I am (and was) using tablet-encode. For some reason it was copying the 48kHz audio stream directly instead of downsampling to 44100. I suspect there is a bug in the script somewhere. I just patched it to always transcode audio and that fixed it for my purposes but there's probably a better general solution.

[Jaffa]

Ah yes, but I am (and was) using tablet-encode. For some reason it was copying the 48kHz audio stream directly instead of downsampling to 44100. I suspect there is a bug in the script somewhere. I just patched it to always transcode audio and that fixed it for my purposes but there's probably a better general solution.

It's probably in the "let's be clever and not do any transcoding if we don't need to" code. I'll have a look now and try and fix it, there are a couple of other bugs outstanding so a 2.21 release sounds like it's in order.

Thanks for pointing it out. I'm not sure I've got any 48kHz videos, so may ask you to do some testing of the new version, if that's OK.

Cheers,

Andrew

[Lord Raiden]

Just to throw my 2c into this conversation, even though I'm coming in a bit late (shows what I get for not paying attention. :rolls eyes:), but I use 400x240 resolution as recommended to me by another forum member at 24fps at 900kbps with 128kbps mp3 audio, and it's fine. Really, there's no need to go any higher, since you really can't see the difference in quality, or hear it for that matter, much above those settings. Only a real hard core audio or video phile would even notice.

[spock]

It's probably in the "let's be clever and not do any transcoding if we don't need to" code. I'll have a look now and try and fix it, there are a couple of other bugs outstanding so a 2.21 release sounds like it's in order.

Thanks for pointing it out. I'm not sure I've got any 48kHz videos, so may ask you to do some testing of the new version, if that's OK.

Cheers,

Andrew

Of course -- just let me know when it's ready. FWIW, here is the hack I put in to make it work:

--- usr/local/bin/tablet-encode de8aa78951ee9326ad297a1947b35c202b97bd92
+++ usr/local/bin/tablet-encode b33e39d0a98b14cb3aa12020b2a4ebf5c1827400
@@ -189,12 +189,12 @@ sub convert {

# -- Audio/video encoding...
#
- if ($options{'copy-audio'} or (($info->{aformat} || '') eq '85') && (($info->{abitrate} || 0) <= $preset->{abitrate})) {
+ if ($options{'copy-audio'} or (($info->{aformat} || '') eq '85') && (($info->{abitrate} || 0) <= $preset->{abitrate}) && 0) {
push @params, '-oac', 'copy';
$af = '';

} elsif (&mencoderSupports('oac')->{'mp3lame'}) {
- push @params, '-oac', 'mp3lame',
+ push @params, '-oac', 'mp3lame', '-af', 'resample=44100', '-srate', '44100',
'-lameopts', 'vbr=0:br='.$preset->{abitrate}.
($preset->{abitrate} < 64 ? ':mode=3' : '');
} else {


You can see that it's only comparing audio bitrate, ignoring sample rate for the decision of whether or not to copy the audio stream. I'm not sure if I had to add the "-af resample=44100 -srate 44100" flags to the mencoder command line or not, but hey, it works now :D

[wax4213]

For Windows users, I just found this (http://xoomer.virgilio.it/sepaolo/n800vc/psvc.htm#downloads) utility which is discussed in this (http://www.internettablettalk.com/forums/showthread.php?t=27217) thread. From what I've read, it also uses mencoder and mplayer. I plan on testing it during the next week, but it sounds pretty good.

[Jaffa]

Of course -- just let me know when it's ready.

Right, I've added support to check the sample rate of the video as well as the bitrate; it can be got here:

https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tablet-encode/tablet-encode?revision=89&root=mediautils

Please let me know if it works. This version also includes subtitle support and, before release, will fix the issue with two-pass encoding.

Thanks,

Andrew

[spock]

Right, I've added support to check the sample rate of the video as well as the bitrate; it can be got here:

https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tablet-encode/tablet-encode?revision=89&root=mediautils

Please let me know if it works. This version also includes subtitle support and, before release, will fix the issue with two-pass encoding.

Thanks,

Andrew

Hi Andrew,

Yes, it correctly transcodes the 48kHz audio down to 44.1 kHz. Thanks for updating the script!

Jonathan

[dchao]

It's somewhat related.

With the built-in player. I have some success in encoding and playing H264 video without stutter or tearing. The result is 300MB for 2 hours of video, extremely compact and efficient. Before you start playing the video, make sure all the background services and networking are turned off. I am also using the fastest MicroSD card I can find (8GB class-6), and a MicroSD adapter. For encoder, I use either FFmpeg from Handbrake or x264 from RipBot264.


Here are my encoder settings:
Video:
Size=400x224, 400x240, 368x240
Ave Frame Rate=256kbps
Max Frame Rate=512kbps
FPS=24
Profile=Base level 3.0
No of R-Frame=1
No of B-Frame=0
CABAC=OFF
Audio:
AAC-LC =96kbps

[seadeeare]

Many Thanks for this thread, i being a super new guy love the information here. i have one problem, after using the suggestions here i still am unable to get anything but the included n810.avi file to play on canola. i think i have tried everything including blowing out the N800 and reloading (several times). canola plays music fine but nothing i convert and load to either the internal or external sd card will play. any thoughts on what maybe wrong. the version is installed from the application manager, both cards were formatted in the N800.
thanks
cdr

[GeraldKo]

@seadeeare

Have you gone to the Canola settings and selected which cards you want scanned? Settings>>Media Library>>Media Folders>>Video Folders

[seadeeare]

YEp did that, i can see the title in the file list but when i go to play it just hangs; the time indicator at the bottom stalls at zero and the volumne bar drops by 2 . black screen and nothing.

[seadeeare]

I just tested another thing, i copied the Nokia_N810.avi vid from the device to the internal SD card and it gives me the same error. black screen no video no time. can't canola play vid from the SD cards either internal or external? could there be a problem with the SD cards i am using? they are both Transcend SDHC 8 gig cards.
thanks in advance
cdr

[GeraldKo]

Canola can play from SD cards. The specific card type you are using has a positive history (use one myself).

Maybe you need to uninstall and re-install Canola. I guess if you do that, you ought to do a regular uninstall, then download and run Canola2-cleanup (one of your installable applications), then re-install Canola. Will it fix the problem? I don't know.

Also, you (and I) probably should be pursuing this on a thread dealing with Canola problems, not video quality, such as this one (http://talk.maemo.org/showthread.php?t=26565).

[seadeeare]

Thanks for the info GeraldKo, i'll try what you suggested and i will copy the results onto the thread you suggested for the Canola Problems.
cdr

[takla]

Right, I've added support to check the sample rate of the video as well as the bitrate; it can be got here:

https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tablet-encode/tablet-encode?revision=89&root=mediautils

Please let me know if it works. This version also includes subtitle support and, before release, will fix the issue with two-pass encoding.

Thanks,

Andrew

This version works well but it often fails silently on two-pass encoding. By making the change proposed by Frank Banul in thread http://forums.internettablettalk.com/showthread.php?t=25926 this is solved, so now it downsamples to 44100 and I can use a .tablet-encode.conf containing '$options{'two-pass'} = 1;'

From Frank's post:


So I made the minimum rate zero.

':vrc_buf_size=450'.
#':vrc_minrate='.int($ovbitrate / 2).
':vrc_minrate='.int(0).
':vrc_maxrate='.max($ovbitrate * 1.25, 1000);

It looks like development on this and almost every other N8*0 project is stopped but it would be nice to see a revised version of the script released so it can be found and enjoyed easily, instead of via a myriad of google searches, chance discovery of this unreleased version (which as far as I can tell is referenced nowhere except in this thread, and is not accessible via the usual garage/project pages), and DIY corrections.

People are still buying these devices ;)

[T-unit]

I have a gaming rig my brother mostly uses but it sports a core i7 sso ripping dvds takes a few minutes. In my experience the bit rate id the video makes a big difference. I don't know that much about it. Here are my settings for decent video. BTW I use handbrake.
container: avi
Format: mpeg4
resolution: 400 x 240
video bitrate: 1500
audio: Mp3

[takla]

I have a gaming rig my brother mostly uses but it sports a core i7 sso ripping dvds takes a few minutes. In my experience the bit rate id the video makes a big difference. I don't know that much about it. Here are my settings for decent video. BTW I use handbrake.
container: avi
Format: mpeg4
resolution: 400 x 240
video bitrate: 1500
audio: Mp3

I was using Handbrake for a lot of stuff too but Handbrake is dropping support for .avi container and while it's still cross platform it is focusing very heavily on making encodes for Apple Mac, iPod, Apple TV, iPhone and so on, so this means mp4/m4v H264 and aac.

[takla]

I wasn't satisfied with the quality produced even using 'mplayer' preset. There is really excessive blockiness, which tends to be a feature of MPEG-4 anyway, but in this case it is far too apparent.

So I've been exploring different mencoder options and making some comparisons.

Anyway I've found the culprit isn't bitrate (mostly), it's the fact that various extremely important codec options are not being used, namely mbd, v4mv, and trellis, while the unsharp filter is used but offers no clear benefit. After doing some tests and timing the encodes as well as looking at the output visually and comparing the numbers I can definitely say that adding mbd=2:v4mv:trell to the codec options adds to the encode time, but using the turbo option more than makes up for that, the total two pass encode time becomes shorter overall. The bitrate dictates the filesize so that remains unchanged. The huge difference is in the quality of the output. It is transformed and looks absolutely fantastic even with very challenging scenes.

Another change that would be beneficial would be to drop constant bitrate audio and use a lame vbr preset, either fast:preset=medium or fast:preset=standard The latter gives better quality than tablet-encode currently offers and has the benefit of a slightly smaller filesize. The 'medium' option would give a significant reduction in filesize while still offering very good quality.

The standard Nokia N810 media player works absolutely fine with these changes.

Here are the differences:

Tablet-encode audio:

-lameopts vbr=0:br=192 -af volnorm

Suggested audio:

-lameopts fast:preset=standard -af volnorm=1

Tablet-encode video options:

-vf-add unsharp=c4x4:0.3:l5x5:0.5 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=<bitrate_value>:aspect=<aspect_value>:vrc_buf_size=450:vrc_minrate=0:vrc_maxrate=1000:v pass=#

Suggested video options:

-ovc lavc -lavcopts vcodec=mpeg4:mbd=2:v4mv:trell:vbitrate=<bitrate_value>:aspect=<aspect_value>:turbo:vpass=#

The options vrc_buf_size=450:vrc_minrate=0:vrc_maxrate=1000 would seem to be redundant when using lavc as it accepts the specified bitrate as a maximum anyway, and intelligently uses less if the specified rate is not required. The turbo option significantly speeds up the first pass, by over 40% sometimes, and it's fine to leave the option in on the second pass when it will be ignored, no harm done.

In summary I've found that with these changes to the video options and even using lame's preset=standard I get a slightly faster encode and slightly smaller filesize (though both these will vary from file to file) but a huge increase in quality, very noticeable even on the small N810 display. I can't find a downside.

[Jaffa]

Thanks for that takla, I'll try and get a new release out soon. Probably not before the summit, unfortunately.

tablet-encode still useful with the N900, btw for either HD video, DVB recordings etc. However an "N900" preset which targets 800x480 might be a good idea :-)

[shadowjk]

mbd, v4mv, and trellis


Also try cmp=10:subcmp=10


The options vrc_buf_size=450:vrc_minrate=0:vrc_maxrate=1000 would seem to be redundant when using lavc as it accepts the specified bitrate as a maximum anyway, and intelligently uses less if the specified rate is not required.


Not quite. Without the vrc_*, the vbitrate is interpreted as the average bitrate across the whole file. This is to say it's equivalent to vrc_maxrate=vbitrate and vrc_buf_size=vbitrate*cliplength. This allows the bitrate to become very high in short action scenes, and stay low for the rest of the clip.
The purpose of adding the vrc_* stuff has probably been to limit short-term bitrate too, in order to avoid excessive CPU use. Removing it should improve the appearance of action scenes while risking too high CPU usage decoding them, resulting in framedrop. 450 sounds kinda low though...

[takla]

Thanks for the info, nice and clearly explained.

I'm not using those options at all now for encoding for N810 and haven't encountered any ill effects. I've encoded from PAL Progressive DVD and NTSC mixed Progessive/Interlaced DVD and from a wide variety of .avi .mkv .mp4 and similar. Initially I encoded quite a few with a video bitrate max set at 1000 with vbr mp3 audio....no issues so far, though 768 seems like more sensible maximum if the compression is of high quality.

Usually if I'm watching video on the N810 I'm not doing much else with it, though typically the wifi will be on, the file manager will be open in the background and sometimes I'll be transferring a large file onto it using ssh and midnight commander. I expect some people will have more going on and the vrc_* options will be more useful, but improving the compression quality is the big one.

I'll make a few encodes with cmp=10:subcmp=10 and compare. Previously I've only been using cmp and subcmp values when encoding full size high quality from DVD.

[takla]

After a few test encodes (and only a few, definitely not exhaustive testing here) using cmp=10:subcmp=10 offers a very significant quality increase over the tablet-encode defaults and a much faster encode time (about 20% shorter) compared to the options I proposed. I think the mbd, v4mv, and trellis options do offer slightly better quality but it's not huge and when the display size is so small it's also not important. Using cmp=10:subcmp=10 instead of mbd=2:v4mv:trell does raise the bitrate and filesize a little but this is easily limited with lavc anyway, so it looks like the best option to me.

For a new version of tablet encode I think this enhancement would be a huge benefit. I guess it may require a reworking of the bitrate calculation, which anyway produces files with far lower bitrate than specified, so that is probably no bad thing...except for the author who does the work :-)

[shadowjk]

I'd recommend retaining mbd=2 atleast. *cmp=10 is a "noise preserving" feature, which makes some videos look nicer to some people. Video quality is subjective :)

[takla]

man mencoder

cmp=<0-2000>
Sets the comparison function for full pel motion estimation

subcmp=<0-2000>
Sets the comparison function for sub pel motion estimation

&

mbd=<0-2> (also see *cmp, qpel)
Macroblock decision algorithm (high quality mode), encode each macro block in all modes and choose the best.
This is slow but results in better quality and file size. When mbd is set to 1 or 2, the value of mbcmp is
ignored when comparing macroblocks (the mbcmp value is still used in other places though, in particular the
motion search algorithms). If any comparison setting (precmp, subcmp, cmp, or mbcmp) is nonzero, however, a
slower but better half-pel motion search will be used, regardless of what mbd is set to

[MountainX]

As a reply to JustJoe asking to see "benefit of going from 480 to 600+ in resolution", I just uploaded 2 videos of the same source:
TestVideo-480-270-800bitrate.avi (http://www.mediafire.com/?dzjomyenyt1)
TestVideo-640-360-800bitrate.avi (http://www.mediafire.com/?omjml2zm4ih)

They both play correctly on my N800, I cant see any speed difference.

The scenes in this small videos are "active", and if mplayer is able to handle this video correctly, I think it should be able to handle any type of scene.(again I'm using 1 single pass, I THINK that with 2 passes the bitrate may "peak" on action scenes and cause some lag)

thank you. i want to try these avi files. what do i need to play them? the built-in media player say the format is unsupported.

[Jaffa]

Right, I've released v2.30 of tablet-encode (http://maemo.org/downloads/product/PC/tablet-encode/). The mbd=2:trell:v4mv options are enabled with --hq (in my testing it was ~40% longer to encode).

Also fixed in this release are 2-pass encoding, subtitles and a new N900 preset (800x480 video @ 2Mbps video). You can get some very high-quality video on an N900 from a 720p source using:


tablet-encode -p n900 --hq 'Heroes - 4x08.720p.mkv' /media/mmc2/


I've not yet tested the cmp options suggested above.

[asys3]

Right, I've released v2.30 of tablet-encode (http://maemo.org/downloads/product/PC/tablet-encode/). The mbd=2:trell:v4mv options are enabled with --hq (in my testing it was ~40% longer to encode).

Also fixed in this release are 2-pass encoding, subtitles and a new N900 preset (800x480 video @ 2Mbps video). You can get some very high-quality video on an N900 from a 720p source using:


tablet-encode -p n900 --hq 'Heroes - 4x08.720p.mkv' /media/mmc2/




Jaffa, tried this with my N900.
But still have some mplayer problems when playing such a file (sound is timeshifted according to the video stream).
Kmplayer says nothing, The buit-in mediaplayer denies to play the file at all.

Could you or anyone else post the correct settings for mplayer on the N900 to play videos created with tablet-encode?

That would help me (the newbie in video encoding).

Thanks a lot so far!
asys3

[Jaffa]

Jaffa, tried this with my N900.
But still have some mplayer problems when playing such a file (sound is timeshifted according to the video stream).

I haven't yet done any testing with mplayer on Maemo 5.

The buit-in mediaplayer denies to play the file at all.

Hmm, odd. That is, literally, the command I used with a 720p H264/AC3-sound video downloaded (http://ezrss.it/search/index.php?show_name=Heroes&date=&quality=720P|HDTV&release_group=&mode=simple) from the Internet.

It then played in the built-in Media Player without any problems.

Could you or anyone else post the correct settings for mplayer on the N900 to play videos created with tablet-encode?

AIUI, playing tablet-encode videos on any version of Maemo should simply be a matter of using your favourite front-end, or doing:

mplayer <file>