| Author |
Message |
Penster
Guest
|
 Posted:
Sat Oct 16, 2004 12:55 pm Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Billy Joe
I'll try that out.
I use a Palm Tungsten T3 which has a 480x320 3.5inch screen. The picture is
bright and of surprisingly good quality. The limiting issue is processor
power so the general advice is to decimate the framerate (halving PAL to
12.5) and to record audio in mono.
On the train, car, plane, gym, I can carry 4 hours of TV on a 512Mb SD card.
In this environment, with a set of noise cancelling earbuds, you get very
watchable TV. I am interested to squeeze every ounce of quality out of the
small bitrate.
Mick
"Billy Joe" <see.sig@invalid.org> wrote in message
news:dPmdnQGrC5B5m-3cRVn-qg@adelphia.com...
| Quote: | Penster wrote:
Billy Joe
I have used the method you have written down The settings you
use seem broadly similar to mine except I set the cropping
and resolution in divx rather than using filters and I don't
deinterlace. I have just made a short avi with and without
deinterlace and using 1pass (250kbps) and 2pass (2000 and 250)
A divx for palm is for a 3.5 inch screen, and 1pass and 2pass
look identical. When I blow up the avi on my PC monitor to
full screen, 1 pass is fractionally better than 2 pass.
I'm surprised. Is 2 pass only superior at higher bitrates?
Mick
snip
Beats me ;-0) As stated earlier, I've never encoded below 1000 kbps
video.
Since your screen is small, you might try deinterlacing (in either one
or two pass mode) using the VDub deinterlace filter and choose discard
(frame 1 or 2)
Or perhaps better, ignore interlace entirely and use the 2:1 reduction
filter, which actually provides more interpretive bits per frame at
the same video bit rate. Effectively, this filter throws away one
interlace field, keeping the width and halving the height. Visually,
you'll not notice that but you should see an improvement in display
quality.
BJ
|
|
|
| Back to top |
|
 |
Penster
Guest
|
| Posted:
Sat Oct 16, 2004 1:14 pm Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Billy Joe
I don't use profiles. My current settings are:
capture MPEG2 720x576 from an analog source
Virtualdub MPEG2
framrate decimate by 2 (PAL=12.5)
full processing mode
resize 480x320 bilinear
(resize & crop in divx)
no filters
encoding bitrate 250kbps
performance/quality standard
psychovisual enhancements fast
pre-processing source (checked) normal
encode as progressive
deblocking & deringing & film effect set at medium setting
audio mpeg layer 32kbit/22,050 mono
I am getting good quality from this setup. I could also use 240x160 and a
higher framerate and magnify by 2 on the palm but I have not tried this yet.
Any suggestions for improving the quality gratefully received.
Mick
"Billy Joe" <see.sig@invalid.org> wrote in message
news:x7udndt7-_NssO3cRVn-iQ@adelphia.com...
| Quote: | Jason Sperry wrote:
On Fri, 15 Oct 2004 16:54:17 GMT, Penster wrote:
Billy Joe
I have used the method you have written down The settings
you use seem broadly similar to mine except I set the
cropping and resolution in divx rather than using filters
and I don't deinterlace. I have just made a short avi with
and without deinterlace and using 1pass (250kbps) and 2pass
(2000 and 250)
If bitrate matters for the first pass then you should use the
same for 2nd pass. Further Billy said to save deinterlace
(and similar filters that change video content) for 2nd pass
which is wrong. You have to use all filters that change the
video content in both passes, otherwise the 1st
pass will work with differnet video content than the 2nd pass.
Jason,
The actual quote from my post is: "Also, you can speed up the
conversion process slightly in VirtualDub by not doing anything
unnecessary in the first pass."
Using the profiles of Divx 5.*, I'd agree with the idea that the bit
rate, tho present in the first pass parameters, is probably ignored by
Divx. In which case, only the value entered into the nth pass params
would be used. And, in fact, employing profiles, I'd suggest that the
user make no alteration to the entry for bit rate.
As the OP is targeting 250kpbs (not the profile standard of 200 for
hand-held) I figure he is, as I am, not using a profile. My
interpretation of Divx's encoding bit rate, tho neither specified nor
referenced in their docs, is that first pass kbps is used as a guide
in the phase one analysis - otherwise, the box would be inaccessible
as it is in Xvid. If it is of no value, then having changed it
would/should mean nothing, right?
Opinions at Divx forums largely favor leaving both kbps set the same,
some suggest leaving ALL settings the same. I recently saw a reply
from a Divx manager stating that the settings should be different, but
I'm unable to find that ref at the moment. If I do, I'll post it.
Also, in ref to VDub settings, it most assuredly is worthless to
encode the audio in both passes, as the .AVI file produced will be
over-written in the second pass. And, of course, I disagree regarding
deinterlacing (the only other filter I mentioned) as the analysis
phase (if it cares at all, per the above) should have access to all of
the video before the actual encoding pass(es) ensue. You will
notice, in my example, that the cropping filter is called in both
passes.
BJ
|
|
|
| Back to top |
|
|
Billy Joe
Guest
|
| Posted:
Sun Oct 17, 2004 3:15 am Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Penster wrote:
| Quote: | Billy Joe
I don't use profiles. My current settings are:
capture MPEG2 720x576 from an analog source
Virtualdub MPEG2
framrate decimate by 2 (PAL=12.5)
|
Interesting choice of words by the VDub author, eh? As decimate means
one in ten, not one in two. Never-the-less, we get the idea ;-0)
| Quote: | full processing mode
resize 480x320 bilinear
(resize & crop in divx)
no filters
encoding bitrate 250kbps
performance/quality standard
psychovisual enhancements fast
pre-processing source (checked) normal
encode as progressive
deblocking & deringing & film effect set at medium setting
audio mpeg layer 32kbit/22,050 mono
I am getting good quality from this setup. I could also use
240x160 and a higher framerate and magnify by 2 on the palm
but I have not tried this yet. Any suggestions for improving
the quality gratefully received.
Mick
|
The stuff I experimented with yesterday was low bit rate VOB of old TV
shows. I ran some new tests today with current NTSC MPEG2 captures at
12 mbps CBR.
A very interesting project, thanks for posting your original question
;-)
Some common misunderstandings about file size: bit rate * play time /
8 = file size. It does not matter what frame size or fps you use,
ONLY varying the bit rate (or, as seen below the Qpel option) varies
the file size for a given play time.
I'm curious why you've chosen to resize to 480x320? If you use the
VDub 2:1 quality reduction you should get 360x288, which your hand
held should then properly expand to fill its screen. The 2:1
reduction requires far less compute power than 480x320 from 720x576 -
think about it. Plus display soft/firm ware is designed to rescale on
the fly. Note too, that a smaller frame size packs more video info
per frame because the bit rates remain the same in either case.
If you use the VDub 2:1 reduction filter, rather than resizing in the
codec, there will be no interlace from the source! And note too that
the interlace pull down does not relate to the encoding but to the
source!!
OK, what I did today was:
from a source file that is 208,545,728 bytes and 2 minutes 10 seconds
of play time, captured at 12 mbps, 29.97 fps in a 720x480 MPEG2 frame,
of which 640x480 is TV video,
I created the following AVIs using 64 kbps 48kHz mono audio
(sorry about that, the audio length in bytes for each file is:
1,040,000 vs. 520,000 at the rate you use). Irrelevant for the video
testing tho.
1) 320x240 29.97 fps (non-interlaced) Qpel turned on
file size 5,324,800
2) 320x240 1/2 frame speed (non-interlaced) Qpel & GMC turned on
file size 5,238,784
3) 320x240 1/2 frame speed (non-interlaced)
file size 5,150,720
Note: the subtle differences in file size are because of the Qpel &
GMC options, not the fps.
I then displayed the vids in a 480x320 window.
Subjective, but to my eye the best picture was 29.97 Qpel
Reason being that motion was smooth, whereas in the ~15 fps versions
horizontal motion was jerky.
Considering the bit rate (a 50:1 reduction) and the size of the
viewer, the pictures were quite watchable.
Some other notes:
During these conversions I placed arbitrary values in the bit rate for
pass one, as there was no variation in the time for pass one, I assume
that the Divx codec simply ignores the field altogether. Also, all
codec option were off in pass one except for those options which have
no off state (viz. Interlacing, Quantization, and keyframe interval).
The only options enabled were chosen in pass 2.
I have both a LiteOn & Philips divx capable stand-alone player. Well
know that these devices do not handle xvid Qpel encoding, I now know
the do not handle Divx Qpel encoding (at least when the coding is
outside the provided profiles).
BJ |
|
| Back to top |
|
|
Penster
Guest
|
| Posted:
Sun Oct 17, 2004 7:13 pm Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Billy Joe
Thanks for the chance to pick your brains on the subject of bitrate,
resolution & frame rate. Feel free to ignore all of the following, but any
tips are welcome.
I choose the 480x320 because that is the pixel size of the palm T3 screen
and so it is an exact fit. The aspect ratio is therefore 1.5:1. If I use a
2:1 reduction, the new resolution would be 360x288 with a ratio of 1.25:1.
The picture would therefore not fit the palm screen (I would guess). PC
processing speed is not an issue to me, since I have a fast PC and I can run
the conversion in batches. The main issue is to exactly fill the small Palm
screen.
With regard to resolution, the manual for the Palm player software (which is
called MMPlayer) states:
"In most situations, the mode with no zoom applied (1x), would be the
fastest of the available zoom modes. This is not the case in MMPlayer
however. For various reasons, the zooming is applied by a function that
needs to be executed for every frame. So, the limiting factor is actually
the number of bytes that needs to be read from memory and then written to
the screen buffer. Given this limiting factor, the fastest of the modes is
actually the 2x zoom mode because that mode only reads ¼ as many bytes as
the 1x mode. To summarize, if high frame rates are desired, you may decrease
the video resolution when encoding the video and use a suitable zoom mode to
increase it to fullscreen when playing."
I understand that a 2x increase in screen size is actually an x4 increase in
screen area.
I recognise what you say that the factor determining filesize is bitrate.
The limiting factor on a Palm is 'the number of bytes that needs to be read
from memory and then written to the screen buffer'. I have chosen 250 kbps
for TV conversion because it gives a good quality video with a total
filesize of approx 125MB per hour of viewing. Thus you can pack a lot of TV
on an SD card. If you go too high on the bitrate, the MMplayer begins to
lock with warnings about resolution/bitrate being too high. I have encoded
films with a bitrate of 350 kbps but it is a pain when the palm locks and
has to be reset, so I try to keep the bitrate within the palm's performance.
I assume that 'quality' of video is a tradeoff of resolution, framerate and
bits per frame. If I cut framerate, I assume that it packs more 'quality'
into each frame. The trade is that it is more jagged on pans and action
scenes. Most of the content off TV (documentaries, interviews and comedy
shows) does not have a high action content so I accept a little jaggedness.
I guess the way to work it out is to encode the same content with different
frame rates until I find the best compromise.
I have tried to understand the detail of the tradeoff of resolution and bits
per frame. It seems to be quite complex. It appears that MMplayer may
produce better results with 240x160 magnified x2 by the player, and more
bits per frame. Once again, I guess I have to experiment.
MMplayer does not support Qpel (as far as I know) it crashes when Qpel is
used in the encode.
One last issue is Bframes. The MMplayer manual states:
"MMPlayer may skip frames in order to keep up with the audio stream if the
video size is too large. On a slower device...it skips B-frames for larger
video sizes. So, when you encode a video, you can either encode the video
using B-frames or you may set the frame rate by yourself..."
Is it correct that you have to enable profiles and bidirectional encoding to
enable Bframes or is there any other way to do it?
Thanks for any advice & tips.
Mick
"Billy Joe" <see.sig@invalid.org> wrote in message
news:pvidnftVkeoMNuzcRVn-hQ@adelphia.com...
| Quote: | Penster wrote:
Billy Joe
I don't use profiles. My current settings are:
capture MPEG2 720x576 from an analog source
Virtualdub MPEG2
framrate decimate by 2 (PAL=12.5)
Interesting choice of words by the VDub author, eh? As decimate means
one in ten, not one in two. Never-the-less, we get the idea ;-0)
full processing mode
resize 480x320 bilinear
(resize & crop in divx)
no filters
encoding bitrate 250kbps
performance/quality standard
psychovisual enhancements fast
pre-processing source (checked) normal
encode as progressive
deblocking & deringing & film effect set at medium setting
audio mpeg layer 32kbit/22,050 mono
I am getting good quality from this setup. I could also use
240x160 and a higher framerate and magnify by 2 on the palm
but I have not tried this yet. Any suggestions for improving
the quality gratefully received.
Mick
The stuff I experimented with yesterday was low bit rate VOB of old TV
shows. I ran some new tests today with current NTSC MPEG2 captures at
12 mbps CBR.
A very interesting project, thanks for posting your original question
;-)
Some common misunderstandings about file size: bit rate * play time /
8 = file size. It does not matter what frame size or fps you use,
ONLY varying the bit rate (or, as seen below the Qpel option) varies
the file size for a given play time.
I'm curious why you've chosen to resize to 480x320? If you use the
VDub 2:1 quality reduction you should get 360x288, which your hand
held should then properly expand to fill its screen. The 2:1
reduction requires far less compute power than 480x320 from 720x576 -
think about it. Plus display soft/firm ware is designed to rescale on
the fly. Note too, that a smaller frame size packs more video info
per frame because the bit rates remain the same in either case.
If you use the VDub 2:1 reduction filter, rather than resizing in the
codec, there will be no interlace from the source! And note too that
the interlace pull down does not relate to the encoding but to the
source!!
OK, what I did today was:
from a source file that is 208,545,728 bytes and 2 minutes 10 seconds
of play time, captured at 12 mbps, 29.97 fps in a 720x480 MPEG2 frame,
of which 640x480 is TV video,
I created the following AVIs using 64 kbps 48kHz mono audio
(sorry about that, the audio length in bytes for each file is:
1,040,000 vs. 520,000 at the rate you use). Irrelevant for the video
testing tho.
1) 320x240 29.97 fps (non-interlaced) Qpel turned on
file size 5,324,800
2) 320x240 1/2 frame speed (non-interlaced) Qpel & GMC turned on
file size 5,238,784
3) 320x240 1/2 frame speed (non-interlaced)
file size 5,150,720
Note: the subtle differences in file size are because of the Qpel &
GMC options, not the fps.
I then displayed the vids in a 480x320 window.
Subjective, but to my eye the best picture was 29.97 Qpel
Reason being that motion was smooth, whereas in the ~15 fps versions
horizontal motion was jerky.
Considering the bit rate (a 50:1 reduction) and the size of the
viewer, the pictures were quite watchable.
Some other notes:
During these conversions I placed arbitrary values in the bit rate for
pass one, as there was no variation in the time for pass one, I assume
that the Divx codec simply ignores the field altogether. Also, all
codec option were off in pass one except for those options which have
no off state (viz. Interlacing, Quantization, and keyframe interval).
The only options enabled were chosen in pass 2.
I have both a LiteOn & Philips divx capable stand-alone player. Well
know that these devices do not handle xvid Qpel encoding, I now know
the do not handle Divx Qpel encoding (at least when the coding is
outside the provided profiles).
BJ
|
|
|
| Back to top |
|
|
Billy Joe
Guest
|
| Posted:
Sun Oct 17, 2004 9:01 pm Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Penster wrote:
I'm answering in-line and some comments are expanded or modified as
more info is read ;-0)
| Quote: | Billy Joe
Thanks for the chance to pick your brains on the subject of
bitrate, resolution & frame rate. Feel free to ignore all of
the following, but any tips are welcome.
I choose the 480x320 because that is the pixel size of the
palm T3 screen and so it is an exact fit. The aspect ratio is
therefore 1.5:1. If I use a 2:1 reduction, the new resolution
would be 360x288 with a ratio of 1.25:1. The picture would
therefore not fit the palm screen (I would guess).
|
Yes, it's true 1.25:1 is not equal to 1.5:1. And the subtle change in
aspect ratio may not be noticeable or distracting to you personally.
Most (no make than many) players will optionally retain aspect or
relax aspect when selecting full screen display. So strictly as a
personal preference, I opt for retaining the original aspect when
converting and leaving the task of screen fitting up to the player
software.
| Quote: | PC
processing speed is not an issue to me, since I have a fast
PC and I can run the conversion in batches. The main issue is
to exactly fill the small Palm screen.
With regard to resolution, the manual for the Palm player
software (which is called MMPlayer) states:
"In most situations, the mode with no zoom applied (1x),
would be the fastest of the available zoom modes. This is not
the case in MMPlayer however. For various reasons, the
zooming is applied by a function that needs to be executed
for every frame.
|
Now there's a possible rationale for choosing a precise fit!
Most TVs or monitors are larger than the material being presented,
for example my Toshiba TV is 1024 x 768 and my MAG monitor is 1280 x
1024, so even a DVD playing at 1x needs to be "zoomed" by the player
or receiver to fit one dimension of the screen. Your device guide
reads as if it is indeed better, if you intend to alter aspect, to do
so in the conversion.
| Quote: | So, the limiting factor is actually the
number of bytes that needs to be read from memory and then
written to the screen buffer. Given this limiting factor, the
fastest of the modes is actually the 2x zoom mode because
that mode only reads ¼ as many bytes as the 1x mode. To
summarize, if high frame rates are desired, you may decrease
the video resolution when encoding the video and use a
suitable zoom mode to increase it to fullscreen when
playing."
|
However, forgive my astonishment at the above!!! I seriously doubt
that only 1/4 of the data is read to create twice the picture area???
I think this may be a flaw in translation?
| Quote: | I understand that a 2x increase in screen size is actually an
x4 increase in screen area.
|
Semantics, which also causes a lot of confusion. A 2x increase and a
4x increase are precisely what they say they are. 2x does not mean
doubling both H & V, which is 4x. Whereas, a 2:1 reduction filter
will in fact halve both legs, resulting in a picture that is 1/4 the
unfiltered size.
The facts of the stated 1x zoom, is that if one leg of the source must
be expanded (or contracted) to fit the same leg of the display, the
other leg of the source is then scaled in aspect, either leaving black
bars or co-incidentally filling the screen. This sort of machination
is mathematically more difficult than simple steps like 2x, 3x, etc.
| Quote: | I recognise what you say that the factor determining filesize
is bitrate. The limiting factor on a Palm is 'the number of
bytes that needs to be read from memory and then written to
the screen buffer'. I have chosen 250 kbps for TV conversion
because it gives a good quality video with a total filesize
of approx 125MB per hour of viewing.
|
I have no argument with your choice of bit rate - I merely wanted to
point out that it is the ONLY choice made which influences file size.
With that as a constant, varying the frame size increases or decreases
the bits per frame (or the info content, if you prefer).
As frame size increases, bit content decreases.
| Quote: | Thus you can pack a lot
of TV on an SD card.
|
BTW, as I'm sure you know, 282 kbps (a + v) will produce exactly the
same file size per hour regardless of where the file will be displayed
or how it will be stored.
| Quote: | If you go too high on the bitrate, the
MMplayer begins to lock with warnings about
resolution/bitrate being too high. I have encoded films with
a bitrate of 350 kbps but it is a pain when the palm locks
and has to be reset, so I try to keep the bitrate within the
palm's performance.
|
You are dissuading me from ever considering a palm pc for such viewing
;-0)
| Quote: | I assume that 'quality' of video is a tradeoff of resolution,
framerate and bits per frame. If I cut framerate, I assume
that it packs more 'quality' into each frame. The trade is
that it is more jagged on pans and action scenes. Most of the
content off TV (documentaries, interviews and comedy shows)
does not have a high action content so I accept a little
jaggedness. I guess the way to work it out is to encode the
same content with different frame rates until I find the best
compromise.
|
I understand your assumption and I agree that fewer frames per second
will result in more bits per frame at the same bit-rate. The same
argument, mentioned above, applies to frame size. I think here the
definition of quality is double edged. Superior frames shown in an
inferior fashion (at least in my simple test of only a single source)
did not appear superior in any way at all. Of course, if the video
was virtually motionless, then I expect the perceived picture quality
could be much better, but even that would have to be tested, as Divx
has very little, or nothing, to do in frames when no motion or shading
changes occur - the whole premise of MPEG4 encoding is I-frame
based. The bit rate for an I-frame can be significantly higher than
the average bit rate of the file. It is content heavy. The info
change frames which apply to the I-frame can be quite content skimpy.
File bit rate and video quality increase as the number and content of
I-frames increases. I'm not exactly sure what ratio could be
attributed to a frame rate reduction, surely not 1:1?
| Quote: | I have tried to understand the detail of the tradeoff of
resolution and bits per frame. It seems to be quite complex.
It appears that MMplayer may produce better results with
240x160 magnified x2 by the player, and more bits per frame.
Once again, I guess I have to experiment.
|
I would leap to this same conclusion, after reading your quoted text
from the manual. I strongly suspect the manual is in error.
Some testing might help?
| Quote: | MMplayer does not support Qpel (as far as I know) it crashes
when Qpel is used in the encode.
|
Ah, too bad. My Divx stand-alone players do not support it either. I
felt there was a noticeable improvement in the picture using it.
| Quote: | One last issue is Bframes. The MMplayer manual states:
"MMPlayer may skip frames in order to keep up with the audio
stream if the video size is too large. On a slower
device...it skips B-frames for larger video sizes. So, when
you encode a video, you can either encode the video using
B-frames or you may set the frame rate by yourself..."
Is it correct that you have to enable profiles and
bidirectional encoding to enable Bframes or is there any
other way to do it?
|
You can enable bidirect with profiles off. It's on the second page of
profile options (I believe it's on by default). I had it on for my
tests and did not try any compilations with it off. In 5.2 Divx
changed from the check boxes for bi-dir, to a pull down with adaptive
single/multiple choices - read up on these options in the 5.2 guide.
http://www.divx.com/divx/divxpro/guides/
| Quote: | Thanks for any advice & tips.
Mick
snip |
|
|
| Back to top |
|
|
Penster
Guest
|
| Posted:
Sun Oct 17, 2004 10:04 pm Post subject:
Re: Understand Divx encoder settings (5.2.0)? |
|
|
Billy Joe
Many thanks. You have clarified many of the things I didn't understand. I
agree that Qpel markedly improves video quality at low framerates. It is a
pity that MMplayer does not support it.
It sounds like the way forward is to encode the same piece of content at
different framerates, resolutions etc and see which comes out best. I'll let
you know.
Mick
PS "You are dissuading me from ever considering a palm pc for such viewing".
The technology is still not quite there. The screen is good enough, the
audio is good enough with headphones, the storage media is catching up (a
1gb SD card will be my next purchase), the battery life issue is not bad.
The main issue is still that the CPU is not sufficiently powerful. I reckon
it'll be another year...
"Billy Joe" <see.sig@invalid.org> wrote in message
news:2e6dnWlGX8bWOO_cRVn-vA@adelphia.com...
| Quote: | Penster wrote:
I'm answering in-line and some comments are expanded or modified as
more info is read ;-0)
Billy Joe
Thanks for the chance to pick your brains on the subject of
bitrate, resolution & frame rate. Feel free to ignore all of
the following, but any tips are welcome.
I choose the 480x320 because that is the pixel size of the
palm T3 screen and so it is an exact fit. The aspect ratio is
therefore 1.5:1. If I use a 2:1 reduction, the new resolution
would be 360x288 with a ratio of 1.25:1. The picture would
therefore not fit the palm screen (I would guess).
Yes, it's true 1.25:1 is not equal to 1.5:1. And the subtle change in
aspect ratio may not be noticeable or distracting to you personally.
Most (no make than many) players will optionally retain aspect or
relax aspect when selecting full screen display. So strictly as a
personal preference, I opt for retaining the original aspect when
converting and leaving the task of screen fitting up to the player
software.
PC
processing speed is not an issue to me, since I have a fast
PC and I can run the conversion in batches. The main issue is
to exactly fill the small Palm screen.
With regard to resolution, the manual for the Palm player
software (which is called MMPlayer) states:
"In most situations, the mode with no zoom applied (1x),
would be the fastest of the available zoom modes. This is not
the case in MMPlayer however. For various reasons, the
zooming is applied by a function that needs to be executed
for every frame.
Now there's a possible rationale for choosing a precise fit!
Most TVs or monitors are larger than the material being presented,
for example my Toshiba TV is 1024 x 768 and my MAG monitor is 1280 x
1024, so even a DVD playing at 1x needs to be "zoomed" by the player
or receiver to fit one dimension of the screen. Your device guide
reads as if it is indeed better, if you intend to alter aspect, to do
so in the conversion.
So, the limiting factor is actually the
number of bytes that needs to be read from memory and then
written to the screen buffer. Given this limiting factor, the
fastest of the modes is actually the 2x zoom mode because
that mode only reads ¼ as many bytes as the 1x mode. To
summarize, if high frame rates are desired, you may decrease
the video resolution when encoding the video and use a
suitable zoom mode to increase it to fullscreen when
playing."
However, forgive my astonishment at the above!!! I seriously doubt
that only 1/4 of the data is read to create twice the picture area???
I think this may be a flaw in translation?
I understand that a 2x increase in screen size is actually an
x4 increase in screen area.
Semantics, which also causes a lot of confusion. A 2x increase and a
4x increase are precisely what they say they are. 2x does not mean
doubling both H & V, which is 4x. Whereas, a 2:1 reduction filter
will in fact halve both legs, resulting in a picture that is 1/4 the
unfiltered size.
The facts of the stated 1x zoom, is that if one leg of the source must
be expanded (or contracted) to fit the same leg of the display, the
other leg of the source is then scaled in aspect, either leaving black
bars or co-incidentally filling the screen. This sort of machination
is mathematically more difficult than simple steps like 2x, 3x, etc.
I recognise what you say that the factor determining filesize
is bitrate. The limiting factor on a Palm is 'the number of
bytes that needs to be read from memory and then written to
the screen buffer'. I have chosen 250 kbps for TV conversion
because it gives a good quality video with a total filesize
of approx 125MB per hour of viewing.
I have no argument with your choice of bit rate - I merely wanted to
point out that it is the ONLY choice made which influences file size.
With that as a constant, varying the frame size increases or decreases
the bits per frame (or the info content, if you prefer).
As frame size increases, bit content decreases.
Thus you can pack a lot
of TV on an SD card.
BTW, as I'm sure you know, 282 kbps (a + v) will produce exactly the
same file size per hour regardless of where the file will be displayed
or how it will be stored.
If you go too high on the bitrate, the
MMplayer begins to lock with warnings about
resolution/bitrate being too high. I have encoded films with
a bitrate of 350 kbps but it is a pain when the palm locks
and has to be reset, so I try to keep the bitrate within the
palm's performance.
You are dissuading me from ever considering a palm pc for such viewing
;-0)
I assume that 'quality' of video is a tradeoff of resolution,
framerate and bits per frame. If I cut framerate, I assume
that it packs more 'quality' into each frame. The trade is
that it is more jagged on pans and action scenes. Most of the
content off TV (documentaries, interviews and comedy shows)
does not have a high action content so I accept a little
jaggedness. I guess the way to work it out is to encode the
same content with different frame rates until I find the best
compromise.
I understand your assumption and I agree that fewer frames per second
will result in more bits per frame at the same bit-rate. The same
argument, mentioned above, applies to frame size. I think here the
definition of quality is double edged. Superior frames shown in an
inferior fashion (at least in my simple test of only a single source)
did not appear superior in any way at all. Of course, if the video
was virtually motionless, then I expect the perceived picture quality
could be much better, but even that would have to be tested, as Divx
has very little, or nothing, to do in frames when no motion or shading
changes occur - the whole premise of MPEG4 encoding is I-frame
based. The bit rate for an I-frame can be significantly higher than
the average bit rate of the file. It is content heavy. The info
change frames which apply to the I-frame can be quite content skimpy.
File bit rate and video quality increase as the number and content of
I-frames increases. I'm not exactly sure what ratio could be
attributed to a frame rate reduction, surely not 1:1?
I have tried to understand the detail of the tradeoff of
resolution and bits per frame. It seems to be quite complex.
It appears that MMplayer may produce better results with
240x160 magnified x2 by the player, and more bits per frame.
Once again, I guess I have to experiment.
I would leap to this same conclusion, after reading your quoted text
from the manual. I strongly suspect the manual is in error.
Some testing might help?
MMplayer does not support Qpel (as far as I know) it crashes
when Qpel is used in the encode.
Ah, too bad. My Divx stand-alone players do not support it either. I
felt there was a noticeable improvement in the picture using it.
One last issue is Bframes. The MMplayer manual states:
"MMPlayer may skip frames in order to keep up with the audio
stream if the video size is too large. On a slower
device...it skips B-frames for larger video sizes. So, when
you encode a video, you can either encode the video using
B-frames or you may set the frame rate by yourself..."
Is it correct that you have to enable profiles and
bidirectional encoding to enable Bframes or is there any
other way to do it?
You can enable bidirect with profiles off. It's on the second page of
profile options (I believe it's on by default). I had it on for my
tests and did not try any compilations with it off. In 5.2 Divx
changed from the check boxes for bi-dir, to a pull down with adaptive
single/multiple choices - read up on these options in the 5.2 guide.
http://www.divx.com/divx/divxpro/guides/
Thanks for any advice & tips.
Mick
snip
|
|
|
| Back to top |
|
|
|
|
|
|
Profile
Log in to check your private messages
Log in