mirror of https://gitee.com/openkylin/libdv.git
73 lines
3.8 KiB
Plaintext
73 lines
3.8 KiB
Plaintext
This is a small explanation of the statistics tables generated by encodedv:
|
|
|
|
CYCLE are the cycles in the quantization loop until a matching QNO is found
|
|
(affects speed)
|
|
|
|
RUNS/CYCLE (for 3-pass VLC) : Tries to skip quantisation steps if it is
|
|
clear that a _lot_ more bits are needed. Makes things faster but
|
|
maybe quality drops a little bit. Smaller values mean better quality and
|
|
larger values mean that you gained some speed.
|
|
|
|
QNO is the quantization number. Larger values mean lesser quantization
|
|
(15=no quantization at all!) and better quality. You will notice, that
|
|
there are gaps between the values in the statistics. (Especially if
|
|
you choose "--vlc-passes=3", where qnos are most likely 15 or 8.)
|
|
This is normal behaviour since depending on the quantization CLASS
|
|
some QNOs don't gain you anything and are therefore skipped. There are
|
|
even codes, that _never_ gain you anything regardless of the chosen
|
|
classes.
|
|
|
|
CLASS is the quantization class. (Greater values mean higher quantization.)
|
|
This is used to quantizise larger AC coefficients more than smaller ones.
|
|
For now, we use the following table
|
|
|
|
max AC-value
|
|
0 - 11 | 12 - 23 | 24 - 35 | >35
|
|
-----------------------------------------
|
|
Y 0 | 1 | 2 | 3
|
|
CR 1 | 2 | 3 | 3
|
|
CB 2 | 3 | 3 | 3
|
|
|
|
from the IEC documentation (which is only given for reference.)
|
|
If you want to improve this, keep the following in mind:
|
|
* These classes are chosen with the vlc code lengths in mind.
|
|
There is one code length for codes between 0..11, for 12..23 etc.
|
|
* You _have_ to use class 3 for AC coeffs. larger than 255, since they
|
|
can't get encoded otherwise.
|
|
* It is sensible to quantizise CR and CB values more than Y values.
|
|
(a) they don't matter that much and b) their bit budget is therefore
|
|
smaller!)
|
|
* Larger classes give you finer control over the QNO.
|
|
* Smaller classes don't have necessarily better quality since you may
|
|
be encoding quantization noise. That's from the IEC document. I don't
|
|
know, why they consider picture details with extremely small
|
|
coefficients as noise, but I agree that large coefficients don't
|
|
really need all the lower bits.
|
|
VLC OVERF is the number of vlc_encoder overflows you encountered. That means
|
|
that some AC coefficients simply aren't encoded!
|
|
At best it means your picture is somewhat blurred and at worst it has
|
|
a very psychedelic touch...
|
|
This should only happen in two cases
|
|
a) if you use "--vlc-passes==1,2" and QNO 0
|
|
b) static_qno since the simple heuristic used can fail easily
|
|
|
|
DCT MODE is the DCT mode chosen. DCT248 is used for fast moving sequences,
|
|
where the two fields encoded differ a lot. DCT88 has generally better
|
|
quality. The decision is based on the accumulated differences between
|
|
the two fields that are larger than a hard coded threshold divided
|
|
by the same difference in x direction. This makes sure that spotlights
|
|
are encoded with DCT 88 and not with DCT 248.
|
|
Something like (sum_i abs(field1[i] - field2[i])) /
|
|
sum_i abs(block[i+1] - block[i])) > dct_248_limit
|
|
TODO:
|
|
- finally go to the library and get the header block specifications ;-)
|
|
- think of a better way to implement static_qno for 1,3 vlc passes
|
|
- do correct synchronisation between audio and video (synchronise
|
|
against system clock since we can't be sure, that the soundcard
|
|
clock is 100% accurate)
|
|
- skip frames correctly
|
|
- find a way to detect NTSC / PAL for video or finally add a
|
|
force-video-format option.
|
|
|
|
|