AVC and HDTV formats [Archive]

View Full Version : AVC and HDTV formats

theAlchemist

15th February 2006, 14:52

H.264 requires each frame to divide into MacroBlocks of 16x16. Hence the frame width and height must divide by 16. On the other hand the most popular HDTV format is 1920x1080 which does not divide into 16. How this problem is best solved? Grooming will generate a result that is not the right format and loose information. Padding costs in bits and hamper image border quality.

Also most HD content is still interlaced. What is the best way to deal with interlaced content when using H.264?

Appreciate your wisdom.

cuban

15th February 2006, 15:15

If I remember correctly HDTV streams in 1080p are encoded @ 1920x1088 (with black bar on the bottom).

The best way to deal with interlaced HD material is to keep it interlaced. H264 can handle interlaced streams. The problem is that x264 (an implementation of h264) does not support interlaced content (yet).

Sharktooth

15th February 2006, 18:17

well only the "i" modes are interlaced. However IMHO bob deinterlacing is still a valid method...

Revgen

15th February 2006, 19:01

I made a 1920x1088 60p video from a 1080i HDTV transport stream with x264 and it's really slow even with the CoreAVC decoder. It decodes at about 28-30 FPS.

Perhaps with Dual-Core support and more optimizations, 60p will be possible with CoreAVC.

Otherwise we'll have to wait until x264 supports interlacing or use another encoder.

bond

15th February 2006, 20:15

where did you get a 60fps hdtv stream from? what channel broadcasts these?

btw signalling "60" in the SPS doesnt mean its 60fps but 30fps

Revgen

15th February 2006, 20:38

The original 1080i stream was 29.97i (or 59.94i, or whatever you call it), so I just bobbed it with EEDI2 and TDeint.

This was the only way I could encode it with x264 while still retaining smooth motion.

I'm sorry my previous post wasn't clear.

EDIT:

AFAIK the only country broadcasting 1080p material is Japan. But it's very scarce.

1080p TV's are starting to be sold here in the US, but I've yet to hear of any 1080p programming.

SeeMoreDigital

15th February 2006, 21:37

Actually, most 720p MPEG-2 NTSC transmissions are at 60 frames per second.

I'm not quite sure yet how 720p MPEG-4 AVC PAL will be broadcast, ie: whether they will be at 50 frames per second or at 25 frames per second ;)

Cheers

asdfsauce

15th February 2006, 22:29

where did you get a 60fps hdtv stream from? what channel broadcasts these?

btw signalling "60" in the SPS doesnt mean its 60fps but 30fps

ABC broadcasts at 60FPS, or were just talking about 1080 streams?

hworldjj

16th February 2006, 04:38

SeeMoreDigital

16th February 2006, 09:51

I forgot to mention....

Over in Australia you can find 720x576 "progressive" MPEG-2 PAL transmissions, which run at 50 frames per second ;)

Cheers

theAlchemist

16th February 2006, 09:54

The best way to deal with interlaced HD material is to keep it interlaced. H264 can handle interlaced streams. The problem is that x264 (an implementation of h264) does not support interlaced content (yet).

Can you elaborate on the way H.264 handles interlaced video? (Maybe I should ask about the way x.264 is going to handle interlaced content) From my short experience, submitting interlaced content as is to the encoder results inferior quality and larger files then if I first deinterlace the content (using methods that preserve the frame rate).
Is there a way to instruct the encoder to encode fields rather then frames?

Encoding odd/even fields separately is not ideal because it gives away the temporal redundancy between the fields and in high motion scenes the motion compensation algorithm may be completely confused as the odd/even field rate is half and high speed objects may get out of the search area in such long interval.

I'm sure someone paid attention to this practical problem.

bkman

16th February 2006, 12:02

Why not IVTC interlaced 1080i (if possible)? Better than bobbing or keeping it interlaced.

cuban

16th February 2006, 14:52

Can you elaborate on the way H.264 handles interlaced video? (Maybe I should ask about the way x.264 is going to handle interlaced content)

I don't know all the technical stuff, but support for interlaced content is part of the h264 specifications. x264 is probably not going to support interlaced content (in near future at least) becouse the developers of x264 have other priorities. There are already h264 implementations that support interlaced encoding. (correct me if i'm wrong)

From my short experience, submitting interlaced content as is to the encoder results inferior quality and larger files then if I first deinterlace the content (using methods that preserve the frame rate).
Is there a way to instruct the encoder to encode fields rather then frames?

Are You talking about feeding progressive encoder with interlaced video? This is not a good idea at all. In this case deinterlacing (or IVTC) is needed before encoding. If You have encoder that supports interlaced encoding (x264 is not) than there should be an option to tell that the input material is interlaced.

Encoding odd/even fields separately is not ideal because it gives away the temporal redundancy between the fields and in high motion scenes the motion compensation algorithm may be completely confused as the odd/even field rate is half and high speed objects may get out of the search area in such long interval.

Yes, and thats why progressive encoders are not good for interlaced content.

If You deinterlace material (exept IVTC) You loose quality. If You plan to watch Your HDTV (interlaced) reencodes on HDTV display, than keeping them interlaced is the best option 'cause hardware deinterlacers will probably do a better job, than slow software ones. Otherwise, if You only going to play the reencoded files only on computer screen You can safly deinterlace before encoding.

Why not IVTC interlaced 1080i (if possible)? Better than bobbing or keeping it interlaced.

If IVTC is possible than it's the BEST option, but sometimes video is purly interlaced and then no IVTC is possible.

theAlchemist

16th February 2006, 15:34

Thank you Cuban. Understood!

What is the difference between IVTC and Force Film? which one is better for deinterlacing?

SeeMoreDigital

16th February 2006, 16:08

Thank you Cuban. Understood!

What is the difference between IVTC and Force Film? which one is better for deinterlacing?Not all 1080i content contains progressive (progressively flagged) frames!

Mutant_Fruit

16th February 2006, 19:43

H.264 requires each frame to divide into MacroBlocks of 16x16 Macroblocks of size: 16x8, 8x16, 8x8, 8x4, 4x8 and 4x4 are also permitted amazingly enough :P

SeeMoreDigital

16th February 2006, 19:56

Macroblocks of size: 16x8, 8x16, 8x8, 8x4, 4x8 and 4x4 are also permitted amazingly enough :PIndeed...

Technically MPEG-4 SP/ASP permits macroblocks of 16x16 and 8x8.

Cheers

theAlchemist

17th February 2006, 00:13

No I think you are confusing different things. H.264 MB is 16x16 ONLY!
H.264 permits different ways of subdividing the MB for example intra encoding allows MB to be subdivided into 4x4 pixels sub-blocks. For inter encoding a MB may be divided into 9!!! different combinations of sub blocks. However all this is done at the MB level. The frame MUST divide into MB nicely hence the format must divide by 16 on each axis.

If any developer of X.264 can shed light on the way the standard proposes to deal with interlaced content I'd appreciate it.

SeeMoreDigital

17th February 2006, 00:21

Have you seen this: -

http://img297.echo.cx/img297/8742/compchart2fa.png

Cheers

xyloy

17th February 2006, 00:45

No I think you are confusing different things. H.264 MB is 16x16 ONLY!
http://en.wikipedia.org/wiki/H.264
This article confirms the picture above:
Variable block-size motion compensation (VBSMC) with block sizes as large as 16×16 and as small as 4×4, enabling very precise segmentation of moving regions.

16*16 MB only applies to MPEG-1 and MPEG-2...
Pretty much "outdated" compared to H.264/AVC, isn't it ? ;)

puffpio

17th February 2006, 11:59

there is a difference between a macroblock and a motion block

BetaBoy

17th February 2006, 19:59

/me thinks that the graph needs to be updated.

SeeMoreDigital

17th February 2006, 20:43

/me thinks that the graph needs to be updated.Will not the lowest motion-block size be the same size as the macro-block size?

Cheers

xyloy

18th February 2006, 00:12

there is a difference between a macroblock and a motion block
As far as I search on the Web, it seemes to be two names for the same thing.
(the different descriptions I've found so far are not very helpful neither...)

If you know the difference, I'm very curious about it. ^^

BetaBoy

18th February 2006, 17:06

What I was referring to was the graph needs to be updated with profiles..... btw... it looks like some just did this on wikipedia... and it looks great!!
http://en.wikipedia.org/wiki/H.264#Profiles

theAlchemist

20th February 2006, 21:49

Will not the lowest motion-block size be the same size as the macro-block size?

As far as I search on the Web, it seemes to be two names for the same thing.

MB in H.264 is 16x16.
MB may be divided into sub blocks of 16x8, 8x16, 8x8, 8x4, 4x8, 4x4... for better granularity of motion estimation.
For intra compression it may be subdivided into 4x4 sub blocks.

SeeMoreDigital

20th February 2006, 21:56

MB in H.264 is 16x16.
MB may be divided into sub blocks of 16x8, 8x16, 8x8, 8x4, 4x8, 4x4... for better granularity of motion estimation.
For intra compression it may be subdivided into 4x4 sub blocks.And "MB" stands for....?

Sharktooth

20th February 2006, 22:03

macro block