Quality: 352x576 vs. 720x576

[Malcolm]

Hello everybody,
currently, i'm thinking about using 352x576 instead of 720x576 to get 3 DVB-captures on one DVD-R. They're all 4:3 fullscreen (no black borders) and i have 2.300 kbit/s avg. bitrate available for the video-part (audio is 128 kbit/s). Btw. the video is not very sharp and slightly noisy.
i did some test encodings and it showed that the 720x576 version is as good as (or slightly better than) the 352x576 version. Although there was more mosquito-noise in the 720x576 encoding (but not noticeably), the 352x576 was - no wonder - less sharp. Blockiness was pretty equal in both (nearly no blocking).
How is your experience in using 352 instead of 720 to get more material (with the same quality) on one DVD? Is this an option at all?
I know this all depends on the material that has to be encoded (noisy or not, lot of movement or not, sharp/unsharp, etc.) and it also depends on the bitrate used. But i think this question is still worth to ask.

Greetings,
Malcolm

[wmansir]

The term for that is Half-D1 (with 720x being Full-D1), if you search for it you can find more information.

I've been using it a lot on dvd extras since DVD-RB makes it a painless option. There is definitely a loss of detail, and I also find the aliasing effect (due to the resize) to be distracting. However, I hate blocking and mosquito artifacts, and the quality loss isn't very noticeable on my 19in TV (of course it is very noticeable on my computer monitor). I also think it is especially good for interlaced material because CCE needs an ungodly high bitrate to get it to look decent at full-D1.

[Lagoon]

I usually never go as low as 352 (I hate the aliasing it creates), I use 480x576 or 544x576 when I'm short on bitrate, these are non-standard but worked on every player I tried, and the quality is between 352 and 720.

[Kika]

these are non-standard but worked on every player I tried

You did not try my players, they won't accept 544x576 or 528x576 on DVD (but they do accept 480x576).

(I hate the aliasing it creates)

Sounds like a wrong cropping/resizing.

I do use Half-D1 on interlaced Videos if i have to spare Bitrate.

[SeeMoreDigital]

Originally posted by Kika
You did not try my players, they won't accept 544x576 or 528x576 on DVD (but they do accept 480x576). Have any of you tried 576wide x 720high with Mpeg2. Can it be done with CCE?

I've done some tests using this 'severe anamorphic' frame size using Mpeg4...

Sorry to but in... I'm just interested.


Cheers

[yup]

Hi Malcolm!
How you make 352X576 resolution? Your source resolution? If use Avisynth and source 720X576 use script:
Crop(8,0,704,576)
HorizontalReducyBy2()
video will be less aliased or use internal CCE option Half Horizontal Resolution.
yup.

[Kika]

@SeeMoreDigital

Have any of you tried 576wide x 720high with Mpeg2. Can it be done with CCE?

I did not test this in CCE. It can be done with TMPGEnc but it isn't DVD-Compatible, i don't know a Standard-DVD-Player which is able to play such Videos.

@yup
or use internal CCE option Half Horizontal Resolution

Oh no, don't do this. The resulting Quality will be disgusting.
The best way is a propper cropping and a Bilinear or Bicubic Resize.

[Malcolm]

@all
is cce really so bad in encoding interlaced material? i searched the forum, but i couldn't find anything specific about this topic. is this a cce problem, or a problem with interlaced material in general. so other encoders are affected too? (more bitrate is needed)

@Lagoon
right, if you don't care for compatibility, 480,528 and 544 are options. but it's not so important for my question here if it's 352 or 480 or whatever. (sure, 480 is sharper than 352). but i want to know about the overall quality: using smaller widths to get equal quality with less space on the DVD. or: using smaller widths to get better quality while using the same space on the DVD.

@ SeeMoreDigital
i guess a width of 576 and height of 720 can be done in CCE. As far as i know, width and height only has to be multiples of 2 or 4 or so (maybe 8). But these videos aren't playable in most (if not all) dvd players. so this is pretty useless!

@yup
is your script right? I think cropping off 16 pixel and then resizing to 352 will give a stretched image if it's displayed on tv. Isn't it so that if i change a clip from 720 to something like 352/480/528/544, i really only have to resize it (and not crop it)?!!
i assume the following is right:encoded width automatic stretching-factor when displayed at 4:3 (~704)
720 -> 0.9777
704 -> 1
544 -> 1.2941
528 -> 1.3333
480 -> 1.4666
352 -> 2
that means: regardless of what width is used during encoding, it is always stretched horizontally (e.g. by the dvd player) so that the width is 4/3 of the height!

according to that: i simply use lanczosresize(352,576) to get it from 720 to 352.

Greetings,
Malcolm

[Kika]

according to that: i simply use lanczosresize(352,576) to get it from 720 to 352

But that's wrong. Half-D1 is based on 704x576 (704/2=352). Which is the only(!) true 4:3 PAL-Resolution.
720x576 ist equal to 704x576 with 16 Pixels overscan. Only on Discs with generic PAR you will have 720x576 Pixels, but generic PAR is not a propper way to get correct ARs.

If all is done alright, a Video with 720x576 has to have a Motion Area with something arround 704x576 pixels, the rest of the Picture should have black Bars at the left and/or right side.

[scharfis_brain]

when doing a 480x576 encode, do not crop away 8px per side.

just do a direct resize from 720 to 480

for getting 352, you need to crop.

[Malcolm]

@kika
Example: i have a DVB capture at 720x576 and i'd like to re-encode it (e.g. to get the bitrate down or do some noise reduction).
Assuming that you are right, then i have the following 2 options:
1. encode it at 720x576 and use letterbox() to black out 8 pixels left, right, top, bottom.
2. encode it at 704x576 by using crop() to remove 8 pixels left and right and use letterbox() to black out 8 pixel on top and bottom.
both would look exactly the same on tv! Is this right??

then i would have to change my table like this:
encoded width automatic stretching-factor when displayed at 4:3 (~704)
720 -> x1 (=720) -8 left, -8 right (=704)
704 -> x1 (=704)
544 -> x???
528 -> x1.333 (=704)
480 -> x1.5 (=720) -8 left, -8 right (=704)
352 -> x2 (=704)

@scharfis_brain
are the values for 480 right?

Greetings,
Malcolm

[Kika]

1. encode it at 720x576 and use letterbox() to black out 8 pixels left, right, top, bottom.

Only left and right. The Picture itself has to be at 704x576.

If you have a DVB-Capture at 720x576, try the followning:

Crop it to 704x576, use addborders(8,0,8,0) to get back the 720x576.
Or crop it to 704x576 and encode it at this resolution. Both ways are correct.

352x576 and 528x576 are based on 704x576
480x576 and 544x576 are based on 720x576. But at 544 there is a Trick. According to the Mod16 Rules, there is a overscan of 4 Pixels used.

[SeeMoreDigital]

Originally posted by Kika
@SeeMoreDigital

I did not test this in CCE. It can be done with TMPGEnc but it isn't DVD-Compatible, i don't know a Standard-DVD-Player which is able to play such Videos. Yes. I'm just wondering if some players might be able to spin 576w x 720h streams.

Top on the list, might be players that can play raw Mpeg2 streams (ie: not in an .vob container).

Can somebody generate and post an small clip please?


Cheers

[Malcolm]

Originally posted by SeeMoreDigital
Yes. I'm just wondering if some players might be able to spin 576w x 720h streams.

No, but every Television can. You just have to turn it 90 degrees clockwise!! Voila, perfect 576x720 display :p :p :p

Greetings,
Malcolm

[SeeMoreDigital]

Originally posted by Malcolm
No, but every Television can. You just have to turn it 90 degrees clockwise!! Voila, perfect 576x720 display :p :p :p But when I do that all the actors and scenery falls out the bottom of the TV too!


Cheers

[scharfis_brain]

But when I do that all the actors and scenery falls out the bottom of the TV too!

please do not forget, that their skin will get red or green, when turning the CRT by 90 degrees. :)

[wmansir]

Originally posted by Malcolm
@all
is cce really so bad in encoding interlaced material? i searched the forum, but i couldn't find anything specific about this topic. is this a cce problem, or a problem with interlaced material in general. so other encoders are affected too? (more bitrate is needed)


I'm the one who mentioned this, so at least I will respond. CCE can only do frame based encodes, not field based like some encoders (Procoder), so that makes it less than ideal for interlaced material. The differences is that CCE looks at the image as one whole picture, so the interlaced lines look like fine detail. A field based encoder will break the frame down into two half size field pictures (like running separatefields() in AviSynth).

It is also partly an R1/NTSC thing. Interlaced material is 30fps, where as progressive material is usually 24fps. That's 25% more frames, which is significant.

[SeeMoreDigital]

Originally posted by wmansir
It is also partly an R1/NTSC thing. Interlaced material is 30fps, where as progressive material is usually 24fps. That's 25% more frames, which is significant. That's an bit of an over simplification!

You can have progressive images at 30fps and 25fps too!

But back to the matter at hand, as a fellow PAL user, if you feel compelled to encode using less than 720 horizontal pixels. Why not use 480 instead. As this is what PAL SVCD uses and might prove more compatible with many stand-alone players.

EDIT: I forgot to ask. Can you confirm how you are capturing?


Cheers

[scharfis_brain]

I've read about this fieldbased encoding scheme of Procoder, too.
But I've also read, that those streams are not very compatible to our DVD-SAPs. Is this true?

How do the other encoders out there handle interlaced content?
(TMPGenc, mencoder, Xing .... )

[Kika]

But I've also read, that those streams are not very compatible to our DVD-SAPs. Is this true?

It's not only a player issue, some Authoring Programs do have problems with Field based encodings. But my last test was a long time ago, may be this is solved now (or with ProCoder 2.0).

TMPGEnc, Xing and most of the other Encoders are doing a Frame based encoding too.


Why not use 480 instead. As this is what PAL SVCD uses and might prove more compatible with many stand-alone players.

That's right, 480x576 is more compatible than 528/544x576, but there are still Players around with problems playing 480x576 (480x480) from a DVD.
If you want to be on the safe side, use only 352x288 MPEG1 and 352x576, 704x576 and 720x576 MPEG2.

[wmansir]

Originally posted by SeeMoreDigital
That's an bit of an over simplification!

You can have progressive images at 30fps and 25fps too!


I should have been more specific. I mentioned the different frame rates because that colored my perception of CCE's poor handling of interlaced material. In PAL land you probably have a better understanding (from general use, not just specific tests) of the quality lose that comes strictly from a source being interlaced, because you don't have to account for different framerates.

[SeeMoreDigital]

Originally posted by wmansir
... In PAL land you probably have a better understanding (from general use, not just specific tests) of the quality lose that comes strictly from a source being interlaced, because you don't have to account for different framerates. Personally I think it's a shame both NTSC and PAL adopted 24fps for Mpeg2/vob in stand alone players.

When everything (monitors, players etc) eventually becomes 'totally' digital, video will become much easier to be displayed.


Cheers

[Malcolm]

Originally posted by wmansir
CCE can only do frame based encodes, not field based like some encoders (Procoder), so that makes it less than ideal for interlaced material. The differences is that CCE looks at the image as one whole picture, so the interlaced lines look like fine detail.
This is a bad joke!!! Doing a framebased encoding on interlaced material is completely braindead!!! no wonder that the quality will suffer! i always thought that every encoder splits the image in two parts that are encoded separately! if procoder does this, then it has to be part of the MPEG-2 standard (otherwise it couldn't be played back by DVD players).
does anyone know, why this isn't used in all encoders?

Greetings,
Malcolm

[Kika]

Field based Encoding IS part of the DVD-Standards - and not even on DVD, also on SVCD and so on.
But unfortunatly, most of the Authoring-Tools arround can't handle such Streams correctly.

For interlaced Encoding in MPEG2, there are 3 Modes: Frame based, Field based and Mixed.

Frame based handles both Fields as one Frame but can use some special Methodes to increase Quality like Alternate Scan.

Field based splits the Frame into two Fields and compresses them separatly. That's very good for scenes with high Motion, but often very bad for still Frames or low motion scenes. That's why Mixed is Part of the Standard, it can combine both, Field and Frame based in one Stream. But ask the Programmers of the Encoders, why they did not implement all three Modes in their Programs. Guess it's because of the more complicated programming for this modes.

[yup]

Hi folk!
I read in manual MainConcep Encoder v 1.4
------------------------------------------------------------

Use Frame Prediction and Frame DCT: Set to 1 to have the motion estimation and DCT
(Discrete Cosine Transformation) computations done on both fields of a frame in the
same pass, set to 0 to have them done on each field independently. Normally this should
be 0 for interlaced frames and 1 for progressive frames. Setting this field to 1 will result in
slight faster encoding but will yield less quality in interlaced frames. This setting can be
specified independently for each frame type (I, B and P). See ISO/IEC 13818-2 section
6.3.10 for more information. This option is only valid for MPEG-2.
------------------------------------------------------------------
Not only Procoder make field based encoding.
yup.

[Kika]

@yup

No, this Option is the Frame based Mode with Field based DCT, like TMPGEnc or CCE are handling it.