Archived from groups: rec.video.desktop (
More info?)
On a sunny day (Thu, 20 May 2004 02:34:21 +0300) it happened "Jukka Aho"
<jukka.aho@iki.fi> wrote in <W7Sqc.2175$DA6.754@reader1.news.jippii.net>:
>Jan Panteltje wrote:
>
>> I dunno TempGEnc, but if it is only an encoder, then yes,
>> stay YUV.
>
>Now why are we discussing this if you do not even have a
>clear idea of what kind of a program TMPGEnc is?
>
>That is the whole problem here; TMPGEnc is a very popular,
>affordable MPEG-2 encoder which, despite its main function
>being only MPEG-2 encoding (and every other function being
>secondary to that main purpose), apparently does not allow
>me to stay in the Y'CbCr colorspace but forces an extra
>conversion step to the R'G'B' colorspace when reading in
>the source clips. (This is contrary to what could be
>expected from a stand-alone software MPEG-2 encoder, but
>that seems to be how the thing works.)
>
>TMPGEnc also features a set of rudimentary color correction,
>masking, cropping, resampling and noise reduction filters
>(which can be switched on and off) but these are only
>secondary "value-add" functions. TMPGEnc is by no means
>intended to be used as a video editor - there is no timeline,
>no editing functions (besides a separate, non-frame-accurate
>MPEG cutting tool); it is basically just a stand-alone
>MPEG-1/2 encoder with some elementary video processing
>filters thrown in.
>
>Some of the built-in filters (if you use them, that is)
>undoubtedly require a conversion into the R'G'B' colorspace
>to work their magic. However, if you never intend to use
>them, converting to R'G'B' "just in case" cannot be a very
>good design decision or clear thinking from the programmers.
>
>> However some things are easier to do in RGB.
>
>Yes, but straight encoding of prepared Y'CbCr material to
>MPEG-2 is not one of those things.
>
>> You will always be working in 8 bits space normally, so 1 /
>> 256 or about 0.4 % accuracy. Nobody can see that.
>
>It is not that simple. Color space conversion between R'G'B'
>and Y'CbCr involves clipping and out-of-gamut colors, not
>merely rounding errors. Some codecs insist on full range
>colours, others hard-clip everything to Rec. 601 range,
>some are adjustable, and yet others do some weird weighted
>scaling at the bright and dark ends, usually in an undocumented
>fashion. Codecs can also have subtle - or sometimes not so
>subtle at all! - differences in how they handle the various
>color subsampling formats, or converting from one subsampling
>format to the other.
>
>Unless you code every single component in your toolchain yourself,
>you can never be quite sure how things work out and what kind of
>algorithms were used - you can only make some educated guesses by
>running some carefully constructed test images through the process.
>That is why every unnecessary conversion step - especially those
>which clearly have no reasonable function and involve closed-source
>programs - is just plain _evil_. If I filter and construct my data
>in the Y'CbCr space and my target format is using Y'CbCr (which
>MPEG-2), I do not want and extra R'G'B' step anywhere in-between,
>without gaining anything from it. (I know my toolchain and the
>filters and programs I use, nothing there technically requires
>converting to R'G'B', it is just the encoder which is forcing
>this on me, for no good reason.)
>
>Anyhow, there are other encoders out there, some of which support
>straight Y'CbCr input (as they logically should!) so the problem
>is not _that_ big nor unsolvable. It just hit me as surprising
>that a widely-used, very popular encoder could be flawed in such
>a technically small (but operationally fundamental) way.
>
>> So again if tempgenc is only a mpeg2 coder, why should it go RGB?
>
>That's the question! I have seen a technical explanation about
>the plugin API (through which everything apparently is imported
>for the encoder to process) not supporting anything else than
>RGB24 format. I have not checked if this really is true.
>
>If it _is_ true, then it technically answers the question, but
>not philosophically: why did they choose to design a plugin
>API which only supports importing files in R'G'B' format -
>for an MPEG encoder!
>
>> Better ask those guys!
>
>"Those guys" are Japanese. It took them a long, long time to
>produce an English version of the program - I remember people
>using unofficially translated versions for a good while before
>they finally officially got someone to translate it to English.
>Getting in direct touch with any of the tech guys (those
>in-the-know) might prove somewhat more challenging than it
>usually is with most other software products... (maybe I
>should start practicing my Japanese!)
>
Hey hey, I have tempgenc (demo) on my machine, but the moment I had
to buy some upgrade to mpeg2 I think it was....WHY
I have Linux and mjpeg tools.
As for RGB to YUV I have shown the math here, there is no magic, you
must be confusing with some other process.
As to black level, there are 2 systems it seems.
In Europe there is no setup (in PAL), while the US uses a setup of a few
percent.
This can have the effect that for example mediaplayer displays too dark,
things made with no setup.
This is in the mpeg2 spec I think:
v = cv * (r - y);
v = (224.0 / 256.0) * v + 128.5; /* 16..240 */
Those modification to RGB->YUV cause confusion, this is not the same
conversion one would do to make a saturation control.
All of this shows clearly one thing:
Go open source, go Linux, get the best, see how it is done, correspond
with the program writer (get your feature implemented, I implemented
quite a few requests), and in English likely.
Big projects like Linux transcode have perhaps almost a hundred people
contributing to it.
While if you buy a windows program you are at the mercy of the company,
one that usually does not release all features (so they can sell an upgrade),
try putting a request with MS!
Or get a bug fixed even, you'd have to wait for the next windows, and
pay for it.
JP
Facebook
Twitter
Instagram