Are 720x486 Dimensions Ever Valid for MPEG2?

[Pookie]

I have a client who wants his file encoded to these specs. Since the height isn't a multiple of 16, it isn't supported (so I claim).

I even found an encoder that didn't balk at the odd dimensions. The resulting Mpeg was macroblock city.

Guys, am I right ?

[foxyshadis]

Almost any resolution is valid in mpeg2; you can specify a display size that differs from the encoded size, like mpeg4. It's the DVD (or DVB) specs you probably need to worry about, though, and you only have a handful of resoluton choices there.

[Inc]

If u got your source at i.E. 720x480 be aware that you only have to addBorders of 3px each (top/bottom). 720x486 is the full active NTSC scanline range. 720x480 is just a cropped spec.
If u got a such professional client, for providing you should use in mpeg2 I-Frame only and use highest Bitrate at CBR (9800kbit)

[Pookie]

Thanks. Looks like I'm having crow for dinner :(

[Mug Funky]

additionally, adding 3 pix to top and bottom will reverse the field order...

you might want to ask for expanded specifications from your client. it's possible they really mean 480 but are used to working with blackmagic or something similar.

i'd ask them exactly what they want - data rate, gop structure, colour sampling (4:2:2 or 4:2:0) and see what you can do.

[Pookie]

Mug Funky, I think you hit the nail on the head, they are a Black Magic house.

I just can't seem to be able to make an Mpeg2 file at 720x486 without severe macroblocking, even at 8500 bitrate. So it doesn't have to be a multiple of 16 for Mpeg2? I've tried most of the encoders - several of them flat-out refuse to do 486, and others will automatically set the number back to 480. Quenc was one of the few that didn't reject the dimensions, but still created the macroblocks.

[dragongodz]

a multiple of 8 would be better IMHO but you could see if a multiple of 4 helps aswell.

[Inc]

additionally, adding 3 pix to top and bottom will reverse the field order...You bet it.
So maybe 2 at top and 4 at bottom.
I think that macroblocking issue i due the encoded content. For some Scenes like sparkles on a watersurface or heavy rain even 9800kbit sometimes is not enough. Thats why editing streams @ Mpeg2 MainProfile/HighLevel go up to 80Mbps.
http://viswiz.gmd.de/DVP/Public/deliv/deliv.211/mpeg/pr@lv01.htm

What about TmpgEnc? Does it refuse to encode 486?

[Mug Funky]

hehe... if all else fails, give them 2Vuy movs on a hard disk. it'd be easier for them to edit anyway (you can go straight out to a deck without recompression. this saves buckets of time, though they'd need a lot of disk space). QToutput can do this directly from avisynth, though i haven't successfully got it to play out to NTSC digibeta (most probably my fault - i only tried it once). PAL plays out fine, and no doubt NTSC will if one interprets the footage correctly in FCP.

otherwise you could politely inform them that mpeg-2 doesn't actually do 486.

though before you give them anything, verify your field order. 486 lines i believe should be bottom-field-first, but that always depends on how the crop to 480 was done...

[Pookie]

Thanks, all. I'll try out all of your suggestions. Inc, I haven't tried Tmpgenc for this, but I will. Interesting how 720x480 looks perfect, but 720x486 looks horrible.

I'm guessing 720x488 would be the next "legal" dimension, but hey, that's why this stuff is so cool - you learn something new every day.

EDIT - Spoke to the client "Did my request say 486? I meant 480 !":rolleyes:

[Mug Funky]

EDIT - Spoke to the client "Did my request say 486? I meant 480 !"

LOL! big, steaming piles of lol! :)