Ask questions to Compression Engineer insider "drmpeg"

[drmpeg]

Originally Posted by shueardm

You are right Ron. Apparently the buffer should be 30000000 bits or less. I got SONIC to use their verifier and it showed these errors.

Stream Verifier, version 1.71
Copyright (C) 2005-2007, Sonic Solutions. All rights reserved.

AVC Analyzing file: D:\Assets\example_h264.264

Log generate
With BD checking.

**** New GOVU: 0 Number of frame: 1 Stream Position: 0
****BD_HDMV_ERROR: Invalid cpb_size, it should be less or equal than 30000000 bits: 93749248
****BD_HDMV_ERROR: If level_idc in SPS indicates level 4.1, each picture shall be encoded as multi-slice picture with 4 or more slices per picture, the current number of slice is: 1

**** New GOVU: 1 Number of frame: 2 Stream Position: 145720
****BD_HDMV_ERROR: Invalid cpb_size, it should be less or equal than 30000000 bits: 93749248
****BD_HDMV_ERROR: If level_idc in SPS indicates level 4.1, each picture shall be encoded as multi-slice picture with 4 or more slices per picture, the current number of slice is: 1
****BD_HDMV_ERROR: No delimiter found
****BD_HDMV_ERROR: Expecting Sequence parameters
****BD_HDMV_ERROR: Expecting VUI parameters
****BD_HDMV_Warning: Expecting HRD parameters
****BD_HDMV_ERROR: Expecting picture parameters set
etc etc

So the buffer is way over for a start, it's a surprise i could get it to author at all, I've done a few AVC discs and they look great. So sometimes it picks it up and spits it out and other times it doesn't.

Now i need to know how to change the buffer as it isn't an option unless it's the PID?

The dump is a little confusing. Would you be willing to upload a few megabytes of your clip somewhere? I do have a old style ftp site if you want to use that.

Ron

[shueardm]

Sure, that would be great.
I can't change VBV or CPB size in this encoder at all though from what i can tell.

Pm me those details if you wish.

[Penton-Man]

Originally Posted by drmpeg

To be honest, I don't have much exposure to compressionists, since my background is almost entirely in real-time encoders for broadcast applications.

Aren't you the Jerry Garcia look-a-like ?

[drmpeg]

Originally Posted by Penton-Man

Aren't you the Jerry Garcia look-a-like ?

Yes, Jerry Garcia, Tommy Chong and the guy on the cover of Zig-Zag papers.

Ron

[newt07]

drmpeg,

Was ATSC designed to accommodate future extensions like 1080p60? Also, I just don't see 1080p60 happening in the near future since broadcasters have already made investments for the digital transition. Why do you think it's going to happen sooner rather than later?

What about plans for better audio quality? ATSC limits AC-3 to 448 kbps. This is too low for an HD standard. Dolby Digital Plus would greatly increase audio quality with negligible loss in picture quality.

Of course, since VC-1 was pretty much rejected in the broadcast space, MS more or less had to create a good authoring encoder since blue laser was the last large segment they could enter.

Why was VC-1 rejected?

[drmpeg]

Originally Posted by benes

This is the greatest thread ever.

I see a lot of talk about 4:4:4 content in the future. But I have another pie-in-the-sky question for you. Do you think it will ever be feasible to deliver content to the home with INTRAframe video compression? This is what is used for D-Cinema and it basically eliminates all motion compression artifacts.

I know blu-ray doesn't support this and it would take an incredible bitrate. But maybe in the future when we all have the 100Mbps fiber connections that amir is always talking about.

There's nothing magical about intra-only encoding. It can also have artifacts, but they will be spatial in nature rather than caused by motion (or more precisely, inadequate motion estimation). With either intra or inter encoding, artifacts are still a function of bitrate.

The big problem with intra-only is that artifacts can happen even during still scenes that have large spatial complexity. Because the viewer is more sensitive to this (there's no "temporal masking"), the peak bitrate has to be really high. I believe D-Cinema goes up to 250 Mbps (although it can be VBR).

As for high bitrates to the home, I'll have to say that "that's beyond the scope of this class". My gut feel about movie downloads is that too many folks believe it's the next big thing. Usually, the truly cool next big thing is less obvious.

Ron

[drmpeg]

Originally Posted by newt07

drmpeg,

Was ATSC designed to accommodate future extensions like 1080p60? Also, I just don't see 1080p60 happening in the near future since broadcasters have already made investments for the digital transition. Why do you think it's going to happen sooner rather than later?

What about plans for better audio quality? ATSC limits AC-3 to 448 kbps. This is too low for an HD standard. Dolby Digital Plus would greatly increase audio quality with negligible loss in picture quality.

Why was VC-1 rejected?

1080p@60 will happen on satellite first. The satellite folks have the best model (captive set top boxes) to move forward and they are already up to speed with H.264 encoding.

ATSC will have a much more difficult time moving forward. But sports is the driving factor behind 1080p@60, so you'd have to think the OTA networks will want to be competitive.

Audio is not really my forté. Also, my hearing is shot (can't hear anything above 11,000 Hz), so it's difficult for me to get excited about audio codecs. However, DD+ is already in the ATSC standard, but only for E-VSB (which has never been used).

As for why VC-1 was not chosen for broadcast, the main technical reason is poor support of interlace. Everyone knew that interlace was added to VC-1 at the last minute (to get it though the SMPTE standardization process), whereas interlace is an integral part of the H.264 standard. Another concern was available room for encoder tweaking in the future. H.264 has many more avenues to pursue than VC-1, and some have even said that VC-1 encoder tweaking may have already peaked (while H.264 is expected to be good for 10 years, just like MPEG-2).

Then there are the political reasons. Aside from the obvious issue of just staying away from anything Microsoft, there was also the issue of future versions of WMV9 (WMV10,11,12......) competing against VC-1.

Ron

[newt07]

@ Microsoft.

4:2:0 cuts out a lot of chroma. Is there a large, visible difference between 4:2:2 and 4:2:0? How much more bandwidth and space does 4:2:2 require over 4:2:0?

[drmpeg]

Originally Posted by newt07

@ Microsoft.

4:2:0 cuts out a lot of chroma. Is there a large, visible difference between 4:2:2 and 4:2:0? How much more bandwidth and space does 4:2:2 require over 4:2:0?

It depends on the content. Here's a colorful sample that is fairly extreme (that is, in favor of 4:4:4).

The original 4:4:4 frame:



The 4:4:4 -> 4:2:0 -> 4:4:4 frame:



This sample is extreme because there are lots of colored edges. In typical movies, you don't have that kind of detail. The next three pics show why 4:2:0 works fairly well for typical content.

The Y channel:




The Cb channel:




The Cr channel:




As you can see, the Cb and Cr images are fairly murky (except for the hard edges). This is because the Cb and Cr channels are created by a subtractive process. The detail that's in the luma channel tends to get subtracted from the Cb and Cr channels. For typical content, things are even more murky and ghostly, so it's perfect for down-sampling.

If I had my choice between 4:4:4 or 10-bit, I would chose 10-bit.

EDIT: I've repaired the 4:4:4 -> 4:2:0 -> 4:4:4 image. Mucho better (the original had a bug where the chroma was offset to the left). You may to hit "Reload" on your browser to update the pic. Aside from the FIR filter artifacts (the colored halos around edges), the 4:4:4 -> 4:2:0 -> 4:4:4 image looks pretty good. BTW, the 4:2:0 to 4:2:2 and the 4:2:2 to 4:4:4 FIR filters are optimized for motion, not stills.

Ron

[drmpeg]

Originally Posted by shueardm

Sure, that would be great.
I can't change VBV or CPB size in this encoder at all though from what i can tell.

Pm me those details if you wish.

Your bitstream syntax doesn't look too bad. The big problem is the CPB size, which just doesn't make any sense (it's larger than even the profile limit). There are a few smaller issues.

1) It's bottom field first. All HD is top field first. The only formats that are bottom field first are analog NTSC and DV. Is this clip straight from the camera, or re-encoded?

2) Scenarist complains about the number of slices per picture (the Blu-ray specification wants four slices per picture), but your clip only has one slice per picture. I'm not sure how picky Scenarist is, but I think it will let one slice per picture be authored.

3) There's a funny value for second_chroma_qp_index_offset. EDIT: it's a bug in the parser. The actual value is -1, which is fine and the same as chroma_qp_index_offset.

h264_parse - mpeg4ip version 1.5.0.1
Nal length 6 start code 4 bytes 
 ref 0 type 9 Access unit delimeter
   primary_pic_type: 0
Nal length 45 start code 4 bytes 
 ref 3 type 7 Sequence parameter set
   profile: 100
   constaint_set0_flag: 0
   constaint_set1_flag: 0
   constaint_set2_flag: 0
   constaint_set3_flag: 0
   level_idc: 41
   seq parameter set id: 0
   chroma format idx: 1
   bit depth luma minus8: 0
   bit depth chroma minus8: 0
   Qpprime Y Zero Transform Bypass flag: 0
   Seq Scaling Matrix Present Flag: 0
   log2_max_frame_num_minus4: 4
   pic_order_cnt_type: 0
    log2_max_pic_order_cnt_lsb_minus4: 4
   num_ref_frames: 4
   gaps_in_frame_num_value_allowed_flag: 0
   pic_width_in_mbs_minus1: 119 (1920)
   pic_height_in_map_minus1: 33
   frame_mbs_only_flag: 0
     derived height: 1088
    mb_adaptive_frame_field_flag: 0
   direct_8x8_inference_flag: 1
   frame_cropping_flag: 1
     frame_crop_left_offset: 0
     frame_crop_right_offset: 0
     frame_crop_top_offset: 0
     frame_crop_bottom_offset: 2
   vui_parameters_present_flag: 1
    aspect_ratio_info_present_flag: 1
     aspect_ratio_idc:1
    overscan_info_present_flag: 0
    video_signal_info_present_flag: 1
     video_format: 1
     video_full_range_flag: 0
     colour_description_present_flag: 1
      colour_primaries: 1
      transfer_characteristics: 1
      matrix_coefficients: 1
    chroma_loc_info_present_flag: 0
    timing_info_present_flag: 1
     num_units_in_tick: 1000   <--- 50 Hz
     time_scale: 50000         <--- "  "
     fixed_frame_scale: 1
    nal_hrd_parameters_present_flag: 1
     cpb_cnt_minus1: 0
     bit_rate_scale: 3
     cpb_size_scale: 7
      bit_rate_value_minus1[0]: 58592   <--- bitrate = 29.999616 Mbps
      cpb_size_value_minus1[0]: 45775   <--- CPB = 93749248 bits (bad)
      cbr_flag[0]: 0
     initial_cpb_removal_delay_length_minus1: 31
     cpb_removal_delay_length_minus1: 17
     dpb_output_delay_length_minus1: 17
     time_offset_length: 24
    vcl_hrd_parameters_present_flag: 0
    low_delay_hrd_flag: 0
    pic_struct_present_flag: 1
    motion_vectors_over_pic_boundaries_flag: 1
    max_bytes_per_pic_denom: 0
    max_bits_per_mb_denom: 0
    log2_max_mv_length_horizontal: 10
    log2_max_mv_length_vertical: 10
    num_reorder_frames: 1
     max_dec_frame_buffering: 4
Nal length 10 start code 4 bytes 
 ref 3 type 8 Picture parameter set
   pic_parameter_set_id: 0
   seq_parameter_set_id: 0
   entropy_coding_mode_flag: 1
   pic_order_present_flag: 0
   num_slice_groups_minus1: 0
   num_ref_idx_l0_active_minus1: 7
   num_ref_idx_l1_active_minus1: 7
   weighted_pred_flag: 0
   weighted_bipred_idc: 0
   pic_init_qp_minus26: 0
   pic_init_qs_minus26: 0
   chroma_qp_index_offset: -1
   deblocking_filter_control_present_flag: 1
   constrained_intra_pred_flag: 0
   redundant_pic_cnt_present_flag: 0
   transform_8x8_mode_flag: 1
   pic_scaling_matrix_present_flag: 0
   second_chroma_qp_index_offset: 4294967295    <---- funny value (parser bug, actually -1)
Nal length 32 start code 4 bytes 
 ref 0 type 6 SEI
   payload_type: 0 buffering_period
   payload_size: 9
    0x80 0x1 0x12 0xa8 0x80 0x0 0x0 0x0
    0x40
    seq_parameter_set_id: 0
    initial_cpb_removal_delay[0]: 140625
    initial_cpb_removal_delay_offset[0]: 0
   payload_type: 1 pic_timing
   payload_size: 13
    0x0 0x0 0x0 0x0 0x22 0xd0 0x81 0x8d
    0xb1 0x0 0x0 0x0 0x10
    cpb_removal_delay: 0
    dpb_output_delay: 2
    pict_struct: 2
    clock_timestamp_flag[0]: 1
     ct_type: 2
     nuit_field_base_flag: 1
     counting_type: 1
     full_timestamp_flag: 0
     discontinuity_flag: 0
     cnt_dropped_flag: 0
     n_frame: 24
     seconds_flag: 1
     seconds_value: 45
     minutes_flag: 1
     minutes_value: 4
     hours_flag: 0
     time_offset: 0
Nal length 131815 start code 4 bytes 
 ref 3 type 5 Coded slice of an IDR picture
   first_mb_in_slice: 0
   slice_type: 7 (I)
   pic_parameter_set_id: 0
   frame_num: 0 (8 bits)
   field_pic_flag: 1
    bottom_field_flag: 1      <--- first picture is bottom field
   idr_pic_id: 0
   pic_order_cnt_lsb: 0
Nal length 6 start code 4 bytes 
 ref 0 type 9 Access unit delimeter
   primary_pic_type: 1
Nal length 21 start code 4 bytes 
 ref 0 type 6 SEI
   payload_type: 1 pic_timing
   payload_size: 13
    0x0 0x0 0x40 0x0 0x21 0xd0 0x81 0x8d
    0xb1 0x0 0x0 0x0 0x30
    cpb_removal_delay: 1
    dpb_output_delay: 2
    pict_struct: 1
    clock_timestamp_flag[0]: 1
     ct_type: 2
     nuit_field_base_flag: 1
     counting_type: 1
     full_timestamp_flag: 0
     discontinuity_flag: 0
     cnt_dropped_flag: 0
     n_frame: 24
     seconds_flag: 1
     seconds_value: 45
     minutes_flag: 1
     minutes_value: 4
     hours_flag: 0
     time_offset: 1
Nal length 26916 start code 4 bytes 
 ref 2 type 1 Coded slice of non-IDR picture
   first_mb_in_slice: 0
   slice_type: 5 (P)
   pic_parameter_set_id: 0
   frame_num: 0 (8 bits)
   field_pic_flag: 1
    bottom_field_flag: 0
   pic_order_cnt_lsb: 1
Nal length 6 start code 4 bytes 
 ref 0 type 9 Access unit delimeter
   primary_pic_type: 1
Nal length 21 start code 4 bytes 
 ref 0 type 6 SEI
   payload_type: 1 pic_timing
   payload_size: 13
    0x0 0x0 0x80 0x0 0x62 0xd0 0x80 0x2d
    0xd1 0x0 0x0 0x0 0x10
    cpb_removal_delay: 2
    dpb_output_delay: 6
    pict_struct: 2
    clock_timestamp_flag[0]: 1
     ct_type: 2
     nuit_field_base_flag: 1
     counting_type: 1
     full_timestamp_flag: 0
     discontinuity_flag: 0
     cnt_dropped_flag: 0
     n_frame: 2
     seconds_flag: 1
     seconds_value: 46
     minutes_flag: 1
     minutes_value: 4
     hours_flag: 0
     time_offset: 0
Nal length 58741 start code 4 bytes 
 ref 2 type 1 Coded slice of non-IDR picture
   first_mb_in_slice: 0
   slice_type: 5 (P)
   pic_parameter_set_id: 0
   frame_num: 1 (8 bits)
   field_pic_flag: 1
    bottom_field_flag: 1
   pic_order_cnt_lsb: 6

You can download this parser here:

http://www.w6rz.net/h264_parse.zip

Ron

[madshi]

Hey Ron,

some questions:

(1) If broadcasts may go to 1080p60 sooner or later, what will happen to movies? I mean right now there are a few displays (mainly Pioneer Plasmas) which can take 1080i60, apply IVTC and show it as 3:3 72Hz. I don't think that any current display can transform 1080p60 to 72Hz. As far as I know there exists even only one single external video processor (iScan VP50) which is capable of doing such a conversion. Not even the Gennum and Realta chips or Lumagen VPs can do that, AFAIK. So I fear that (unexpectedly) 1080p60 might be a step back for movies in some situations. What you do think?

(2) Do you see Europe going 1080p50, too?

(3) Do you generally see a chance for support of multiple framerates? E.g. could USA broadcast movies in 1080p24, NTSC video content in 1080p60 and PAL content (e.g. Planet Earth) in 1080p50? Or do you think that's not going to happen?

(4) When there are errors in the video stream, MPEG2 gets checkerboard blocks, sometimes also a line of funny colored blocks. Doesn't look pretty, but it's not in any way "scary". With the MS VC-1 decoder I'm seeing similar effects if there's minor data corruption with VC-1 anywhere. Sometimes with VC-1 if the decoder is totally confused, the whole image goes green and shows more "wild" artifacts and looks a lot less pleasing. But h264 can get outright ugly when the video stream is corrupted. I mean it's so ugly that it really actually scares me sometimes. I once watched a Blu-Ray h264 movie with my sister and my graphics card overheated a bit. So there were some artifacts once every few minutes. My sister looked at me, really scared sometimes due to the way the artifacts look. Is there any chance that this might be improved upon in the future? E.g. could decoders get more clever and just black out the screen to hide such corruption artifacts and come back on when the stream is clean again?

(5) Is there any kind of CRC in any of the video formats?

[wts]

HI,

When you watch an HD version of ie; POTC on Dish, first off it's in 16:9 and not it's original ratio - why is this?

Do the broadcast versions of these HD movies use different codecs than what is on the BR disc? IF so, is it better/worse/same PQ as the BR version?

Thanks

[theknub]

Originally Posted by wts

HI,

When you watch an HD version of ie; POTC on Dish, first off it's in 16:9 and not it's original ratio - why is this?

Do the broadcast versions of these HD movies use different codecs than what is on the BR disc? IF so, is it better/worse/same PQ as the BR version?

Thanks

Not an insider, but this is easy.

Channels like HBO, TNT, etc will crop the film to make it full screen (on a 16x9 display). This is a decision by the broadcaster and has nothing to do with the studios or a codec choice. The codec is simply a container for the data. It doesn't make the data. As for the quality, it is nowhere near Blu-ray levels. It is a bit starved broadcast.

[upnorthsox]

Actually it's worse than that, it's just widescreen with a DD soundtrack. Basically an upconverted dvd.

[benwaggoner]

Originally Posted by phloyd

This is interesting since Ben W from *cough*soft has stated a number of times that at the bitrates used for HD Media the loop filter is needed. It appears that his statement is incorrect based on these real examples - something I am happy to see (not that he was wrong, but that the loop filter is not always neeed).

Did I? I don't recall saying that specifically about H.264 and BD. If you really want to max out the bitrate and accept that reduction in runtime/extras, I agree with drmpeg that turning it off would be feasiable, and probably useful.

This isn't something we've sweated with VC-1 since ours is more focused, and so kind of fades away at higher bitrates without needed to be explicitly turned off.

Also, the loop filter isn't something that needs to be on/off for a whole movie. It can be turned on or off for different sections, at least in our VC-1 encoder.

[whippersnapper]

Originally Posted by benwaggoner

Did I? I don't recall saying that specifically about H.264 and BD. If you really want to max out the bitrate and accept that reduction in runtime/extras, I agree with drmpeg that turning it off would be feasiable, and probably useful.

This isn't something we've sweated with VC-1 since ours is more focused, and so kind of fades away at higher bitrates without needed to be explicitly turned off.

Also, the loop filter isn't something that needs to be on/off for a whole movie. It can be turned on or off for different sections, at least in our VC-1 encoder.

Welcome to Blu-ray.com Ben.

[shueardm]

Ron,

Thanks for getting back to me about the sample clip encoded with ProCoder 3. I will do what I can to get Grass Valley to look at the faults, allow the buffer size to be changed, allow multiple slices as mentioned. It's quite amazing that I have in fact authored and played beautiful HD on BD-R using this preset. 50% of the time it works, 50% it doesn't.

Oh and I can promise you that I encoded a source file Canopus HQ AVI file (which is upper filed first) into the H.264 also upper filed first. So, if in fact it is lower field first then it is Grass Valley's mistake. Mind you, there were no signs in the Blu-ray discs that i made that the field order was wrong.

Cheers
Mark.

PS, WTS (Jim) G'day. . Also, Ben, g'day, do you still work with ProCoder at all- you've gone missing for some time?

[fitprod]

drmpeg,

I curious if you have any insight with regards to the horrible encodes/transfers of Ocean's 12 & Ocean's 13. I finally had a chance to watch these discs, and to say they have issues is being kind.

Ocean's 12 is a flat out disaster. Throughout most scenes with blacks or dark brown colors, there is a constant white pulse that pops up. It is only present in those areas, so my gut instinct is to blame this on the encoding and not the transfer. (If it was the transfer, I believe the issue would have been uniform throughout the image...)

It seems like someone attempted to step on the crushed blacks or grain, and destroyed this film will DNR or some other type of filter.

Ocean's 13 also has this problem, but it does not show up as much...

I've had the opportunity over the past few years to work on DVD's and transcoding features, and I've never seen any masters that contain these artifacts. Crushed blacks, yes... White pulses in select colors? Never.

Any insight would be appreciated.
fitprod

[benwaggoner]

Originally Posted by shueardm

Also, Ben, g'day, do you still work with ProCoder at all- you've gone missing for some time?

I use Rhozet Carbon (ProCoder Pro, basically ) all the time still.

By missing do you mean missing from the forum? Yeah, now that you mention it I haven't been around there for a while. I'll try to remember to drop in. Web forums are harder for me to stay on top of than email list, since I'm so interrupt driven .

[benwaggoner]

Originally Posted by whippersnapper

Welcome to Blu-ray.com Ben.

Thanks. drmpeg posted a link to this area from AVS. Looks like he's been providing a lot of good chewy information over here.