Originally Posted by rs008f

I have an 23.976 fps AVI video that is non-interlace and top field first, does this mean the video is progressive?

Originally Posted by Dialhot

There is no interlaced avi. So your file can't be interlaced :-)

Originally Posted by Dialhot

There is no interlaced avi. So your file can't be interlaced :-) ?

Originally Posted by Dialhot

But... 23.976 CAN'T be interlaced (as told by inc).

Note: yes, all Divx I know so far.

Originally Posted by Hydeus

I know that this is no matter at the moment, but DivX also supports interlacing, at least in early 5.x versions.

Originally Posted by Dialhot

Not at all !
In divx you can ask to the decoder to treat the source as progressive or to deinterlace it, but you ALWAYS encode in progressive.

Originally Posted by Hydeus

Not at all ;)
I've downloaded sample movie from 100fps.com (it's not blockbuster it is a capture test sample), and it is DivX5 50fps interlaced. so?

Originally Posted by LigH

Perhaps still times somewhat in more detail (largely we discussed fully similar things e.g. in this contribution): Everything (all!) MPEG-compatible video formats (all the same whether MPEG1 -, Mpeg2 or MPEG4-kompatibel) store according to standard brightness and color difference information with the Subsampling configuration 4:2:0, (nearly) the same also by unkomprimierten YV12-AVIs one would use; others are permitted partly also, must be adjusted however separately, and are not not DVD compatible partly.

_ a unkomprimiertes Rgb24-avi needs 8 bits for each pixel in all three components (red, green, blue): 3 components * 8 bits/1 pixel = 24 bits per pixel. So far simply. Now a little more complicated: With 4:2:2-Subsampling (as with YUY2 or UYVY) each individual pixel has a brightness value Y, but two pixels each lying next to each other divide one color difference component each U and V. that means: The smallest unit, which one can store with (groups of) complete 8-bit bytes, is a group of two pixels each lying next to each other. Those need then 2 bytes for the individual y-values, and 1 byte each for the common u and CV factors - the smallest storable unit are thus 2+1+1 = 4 bytes. That makes thus * 8 bits/2 pixels = 32 for 4 bytes bits/2 pixels = on the average 16 bits per pixel. And end the conclusion still more complicated: With 4:2:0-Subsampling (as with YV12) each individual pixel has a brightness value Y, but four neighbouring pixels each lying in the square divide one color difference component each U and V. that means: The smallest unit, which one can store with (groups of) complete 8-bit bytes, is a group of four secondary and among themselves each lying pixels. Those need then 4 bytes for the individual y-values, and 1 byte each for the common u and CV factors - the smallest storable unit are thus 4+1+1 = 6 bytes. That makes thus * 8 bits/4 pixels = 48 for 6 bytes bits/4 pixels = on the average 12 bits per pixel.

__ and why now DivX announces "24 bits", while XviD announces "12 bits"? "no notion - the programmers ask!" Perhaps the DivX is somewhat inaccurate and announces as preferential decoding format "RGB24", although its natural unkomprimiertes format is most similar actually to YV12 - because practically all video processing programs can process unkomprimiertes RGB video problem-free. The XviD is there perhaps more exact; (as in the contribution specified above) each program in a the position is not only to process planar formats. Therefore the XviD codec offers itself additionally also as "codec" for YV12, in order to support such (in this regard ' unable ') programs to make and a conversion of YV12 available into the desired format. (since short DivX does that by the way also...) Or it depends on with which the DivX /XviD codec was originally fed (thus whether RGB24, YUY2 or YV12 to MPEG4 were compressed). And then it would be actually because of which was used program, and like it was adjusted (e.g. VirtualDub or Mod in the nearly Recompress or Full processing mode). In the case the question about the quality differences would be to be answered in such a way: "the fewer transformations between the formats, the better" - then would be the winner: YV12 (for YUY2 average value formations and interpolations would be necessarily, for RGB24 even a complete conversion between RGB and YUV; there much accuracy is lost!).

__ programs, which can be decoded a video compressed by a VfW codec (e.g. with DivX or XviD in the MPEG4-Format), may itself by the way of the "image Compression manager" (the technology, which exists since Windows 3.x with VfW 1.x) in a list wish, into which format they would gladly have decoded it - in the order, as would have sie's dearest. Some programs wish themselves of the ICM only RGB24; others would have gladly only YUY2 or UYVY, then RGB24; only few (like VirtualDubMod) permit also YV12. That might be connected with the fact that YUY2 and UYVY are "packed" also exactly like RGB24, while YV12 is "planar", and therefore to be completely differently treated must. Details in addition in mentioned here above the contribution...

Originally Posted by incredible

NEVER! Trust TmpgEnc and its automatic Fieldorder and Frame/Fieldbased Type recognisitions!!

Originally Posted by incredible

First if we see that whole thing "on topic" we can assume that "he" really deals with a 23.976 progressive Stream, framebased and therefore to be encoded as Progressive with ZigZag scanned DCT 8x8 Matrix.

Originally Posted by rs008f

Avisource("yourXVID.avi")
AssumeTFF() /AssumeBFF()
Separatefields()

I tried both scripts on my Xvid video. Both looks the same to me when viewed on WMP. Both scripts crunched my 4:3 video into 16:9. I'm curious why boths scripts looks identical. I don't see any jerkiness anywhere.

Originally Posted by rs008f

OK. TMPGEnc is wrong and I'll stop using it. I'll assume all 23.976 fps Xvid/Divx are Progressive.