tablet-encode video encoding -- Larger files?

[VulcanRidr]

I was wondering about the performance of tablet-encode. Since I am about to start commuting by train, I decided to convert a bunch of videos. My basic command line was:


tablet-encode -o -q -p good <infile.avi> <outfile.avi>


First, there seems to be very little difference in output size between good, best and mplayer. Secondly and more importantly, there seems to be very little difference between the original file size and the output file size, and in a couple of cases, the output file for the Nokia is actually considerably larger than the original file.

All of my original files are in .avi [divx] format, some from DVD with a size of 624x256 and others from TV capture (640x480). The output is in FMP4.

The first three movies are from DVD:

Original/N810
700M/782M
700M/579M
711M/597M

The TV captures:

695M/604M
695M/569M
694M/732M

Is this normal behavior for re-encoding video? Is there a way to get the files significantly smaller? Because at this point, it does not appear that re-encoding them is worth the CPU time. Several of the files are larger than the originals, and the others are within 10% of the same size.

Can someone advise me?

Thanks,
--vr

[Jaffa]

If you're re-encoding DivX files, tablet-encode calculates the "bitrate per pixel" of the original video and ensures that it doesn't exceed that (within a margin of error) based on the profile selected.

That's why you're not seeing much difference between the high-level presets. At the resolutions the video is being scaled to, the bitrates for those presets are far too high: it'd just end up encoding existing encoding artifacts, rather than the video.

The heuristic for determining the resultant bitrate seems to be erring too much on the side of caution in your case, though.

Hope that helps,

Andrew

[VulcanRidr]

If you're re-encoding DivX files, tablet-encode calculates the "bitrate per pixel" of the original video and ensures that it doesn't exceed that (within a margin of error) based on the profile selected.

That's why you're not seeing much difference between the high-level presets. At the resolutions the video is being scaled to, the bitrates for those presets are far too high: it'd just end up encoding existing encoding artifacts, rather than the video.

The heuristic for determining the resultant bitrate seems to be erring too much on the side of caution in your case, though.

Hope that helps,

Andrew

Thanks Andrew.

Is there a way to fix this? I copied the original file over and playback is very choppy. The one made using tablet-encode was smooth.

Dropping it down to average dropped the output file from 604MB to 579MB. Compare to some other videos which I did on a laptop (that I do not have any longer) which made a 101 MB original file size into a 51MB file for the NIT, and that was, as I recall, encoded with the mplayer preset.

[grog]

For myself I usually use the small preset. It provides the good size reduction & I find the quality good enough. If I wanted higher quality, I'd stay home & watch it on my high-def tv :). HTH

[Jaffa]

Is there a way to fix this? I copied the original file over and playback is very choppy. The one made using tablet-encode was smooth.

You have two options, and I'd be very interested to know which works best for you:


Create a new preset, with a bitrate of about 512kbps video, 192kbps audio and maybe 400x240 resolution. You could even try with the native resolution of your videos.
Fiddle with the "fudge factor""margin of error" - line 294 currently says:
* 1.1
...which means a 10% addition on the calculated bitrate. You could change this to 1.0, or even 0.9 to guarantee files wouldn't be any larger.


Compare to some other videos which I did on a laptop (that I do not have any longer) which made a 101 MB original file size into a 51MB file for the NIT, and that was, as I recall, encoded with the mplayer preset.

I would guess, in that circumstance, it wasn't something that tablet-encode recognised as a DivX file; and so used the absolute bitrate defined on the preset.

[mrklaw]

at this point, it does not appear that re-encoding them is worth the CPU time. Several of the files are larger than the originals, and the others are within 10% of the same size.

I run all my videos through tablet-encode simply because they play better on the tablet when I do. Video and audio stay in sync and the video isn't choppy when I've re-encoded it.

When I re-encode mpeg4 videos that are intended to be played on an ipod, they tend to be much larger afterward but they play well on my tablet.