/usr/share/doc/libdv4/README.encoder is in libdv4 1.0.0-6.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | 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.
|