Archived from groups: rec.video.desktop (
More info?)
On a sunny day (Thu, 24 Jun 2004 16:28:41 +0200) it happened Wilbert Dijkhof
<w.j.dijkhof@tue.nl> wrote in <40DAE519.C2D42A07@tue.nl>:
>
>
>Jan Panteltje wrote:
>>
>> On a sunny day (Thu, 24 Jun 2004 15:28:14 +0200) it happened Wilbert Dijkhof
>> <w.j.dijkhof@tue.nl> wrote in <40DAD6EE.8DB04FEB@tue.nl>:
>>
>> >Jan Panteltje wrote:
>> >>
>> >> >I assume you mean (...) or store in some RGB format, right (cause
>> >> >mpeg2/divx is YUV)? Or do you mean huffyuv/mjpeg?
>> >> mpeg2 /and DivX is not raw YUV,
>> >
>> >I know, I didn't claim otherwise. I don't see the word raw
>> >in your text above. So, I was just wondering what you meant by
>> >*some* YUV format.
>> >
>> >But, capping raw YUV is not an option, unless you have a 1 TB hard
>> >drive. I guess we have to wait a year before we can buy those

>> >
>> >> although the processing is done in YUV.
>> >> Storing raw RGB is very very space inefficient.
>> >> Normally, if you decode PAl or NTSC you get Y and U and V, because that
>> >> is the way the colors are transferred (U and V are bandwidth limited).
>> >> Converting that to RGB and storing would have no advantage, only be slower
>> >> and take more space.
>> >
>> >Yes, I agree (except for the detail that NTSC -> YIQ).
>> >
>> >Wilbert
>> Not exactly, I will try to reference your points.
>> hufyuv is also a variant of YUV, but compressed in a way (lossless).
>> But MPEG2 and DivX are atotally different beast, these have lossy compression,
>> use intermediate / predicted frames, cosine transform, motion vectors.
>> So, alhough processing is done in YUV space 9that is to say the color is
>> processed apart from the luminance), it is not really the old YUV we started
>> with anymore (and you cannot get the exact original back).
>> With huffman and raw you can.
>
>I know all that. Did I say anywhere that MPEG2/DivX/mjpeg is lossless or
>that huffyuv is lossy?
>
>> As for the 1 terabyte, this is simply not true.
>
>C'mon that was just an optimistic estimate, just to get an idea how much
>space we were talking about. I even forgot to mention the length of the
>capture, so I don't know why you said it's false.
>
>(...)
>
>> The result is the 'some YUV format' I referred to in the first post.
>> So, still YUV, and lossless compression.
>
>Why did you start talking about raw YUV then? Or was it a typo, and you
>meant lossless YUV?
>
>> Then later you can encode that to any other lossy format (MPEG2 DivX, VP6, whatever).
>> Note mjpeg is also not lossless it is simply jepg coding.
>
>I know ...
>
>Btw, DivX has no interlace option, so I wouldn't use that for capping.
>In
>that case you can better use ffvfw.
>
>Wilbert
Agreed, I should paerhaps have specifically mentioned some 'lossless' YUV
format.
I am not 100% sure what you mean 'not use DivX for capping'.
What I do is take mpeg2 from satellite, decode to yuv, add subtitles and effects,
then make DivX CDR (de-interlaced).
Also I make DVD (interlaced) directly from the digital stream, with multiple languages,
and Dutch subtitles, the subtitles are overlay in DVD so nice anti aliased
subs are possible.
The DivX subs, IF in screen, added AFTER the de-interlace, are of cause 100%
stable on a non interlaced display.
Look up my DVD page
http://ip51cf87c4.direct-adsl.nl/panteltje/dvd/
and
Linux transcode for pre and post processing of YUV perhaps
http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/
subtitler (on my subtitle page) is a plug in for transcode.
Modern DVD players, like the Philips players for example, can play DivX progressive.
JP