2007-12-29
Ten Canoes and 16 Pixels
I was watching the feature film Ten Canoes on DVD with a friend. It's a fantastic movie, very unusual. It won a prize at the prestigious Cannes Festival. However, the picture quality of the DVD leaves something to be desired. I can't be absolutely sure, but I think it was encoded on a PC.

The problem in the encoding is pretty simple. The motion vector search range used during the encoding was set to a window of 16 pixels. In MegaPEG, you'd get a search window this size if you slide the Motion slider all the way to the top (very low motion).

The problem is, that although this feature does not have a lot of action in it, it does have motion. Camera motion, closeups with peoples heads moving through the frame. That kind of thing.

Here are three screen shots from the MPressionist analysis of the title. The first two show the two pages of motion vectors. Blue and green represent motion vectors that are pointed forward and backward in time. As you can see, no motion vector exceeds the 16 pixel maximum used during the encoding.

The encoder used on this job, handcuffed by the small motion vector search window, had to resort to other techniques to get the video into the required bitrate. Encoder theory predicts that in order to get higher motion passages to encode, more compression will be required. In this case, extreme amounts of compression (indicated by peaks in the third picture).

I have no doubt the encoder used on this job was capable of getting the picture quality right. Although the content is highly textured, they used an 8.6 Mbits/s bitrate ceiling, plenty of bits for something like this. Instead, the difficulties here are the result of "not knowing" what the encoder did. Without that crucial feedback, it's easy to miss the artifacts in this title, which appear only during high motion scenes and do not quite get blocky. Instead, high motion areas end up kind of a blurry mess.

Don't take my word for it. Rent it and watch it.

Blogged by MPressionist under Ten Canoes and 16 Pixels 0 comments

2007-10-12
DVD Encoding PQA
A friend and I were watching a standard def DVD (The Lucky Seven), and as we were watching my jaw dropped. "Did you see that?", I said, and we hit review on the remote and watched the scene again. I could not believe my eyes, the image had been crushed completely. It looked to me like an encoding problem and so I fired up MPressionist and took a look at the disc.

Sure enough, without even needing to scan the feature to find the timecode of the problematic scene, the compression overview graph showed an out-of-place compression peak about 25% of the way through. I moved the playback to that spot, let it run and the problem became more obvious. The encoder used in this sequence had run into a problem with a time-lapse section. The result was that an entire GOP ran at maximum compression, resulting in the blockiness shown in these images.

It is possible that the encoder they employed could not be adjusted to correct this problem. However, using MPressionist to review the charts for the disc could have saved replicating and distributing this disc, and potential embarrassment with the client.

Blogged by MPressionist under DVD Encoding PQA 1 comments

2007-10-02
DIRECTV HD PQA
If you're a DIRECTV viewer, don't beat up the ATSC HDTV channels for picture quality - the current state of picture quality in high-definition television is driven by commercial interests, primarily. Given the spectrum/bandwidth, broadcasters are looking to maximize the number of channels they can send, which means dividing up a 30 mbs pipe into as many chunks as possible. It looks to me like they are doing VBR encoding and crossing their fingers that the statmux won't experience two bitrate peaks at the same time.

Nevertheless, there is one thing that all the HD broadcasters are guilty of, which would make a significant impact in picture quality on most dramatic television. Currently, many HDTV shows which originate on 35mm film are broadcast in 1080i with the pulldown still present in the source material. This footage should be going through an inverse telecine prior to ingest. The reasons for this are both aesthetic and financial. Using inverse telecine at 1080i results in at least a 25-40% reduction in bandwidth. This is a real reduction. Instead of encoding 29.97 interlaced frames per second, only 24 progressive frames are sent (the original frames from film). There are rare instances where cuts done on the Avid will produce a short 2 or 3 frame sequence that is truly interlaced (pulldown sync lost during edit).

The impact on both picture quality and bandwidth would be startling. Personally, I think true interlacing in HDTV should be deprecated. Interlacing is an artifact from an era where we watched material on interlaced devices. It was a compromise based on technological constraints. A large number of HDTV screens now are LCD based. Interlaced content looks terrible on LCD screens. And many of the HDTV screens that are interlaced at 1080i do not implement 1080p correctly. Those latter manufacturers should be penalized by the consumer for failing to support the standard, and 1080p should be king of both content and display. 1080i, given the bandwidth allocation chosen by broadcasters is a complete wash. In low motion scenes, where there is no advantage to interlacing on a true HDTV, 1080p would be better looking than 1080i, and in high-motion scenes, the added complexity of encoding interlacing and an extra 6fps means that the temporal resolution promised by 1080i is in fact, transmuted into a blocky mess by the channel constraints/encoder.

If temporal resolution is what is needed (live football, soccer etc), 720p at 60fps is the way to go.

Blogged by MPressionist under DIRECTV HD PQA 0 comments

 

 
 
 

 Digigami   
 News   
 Contact   
 MegaPEG   
 MegaPEG Blog   
 MPressionist   
 MPressionist Blog   
 MoviesForMyPod   
 download(s)   
 [Site Map]   
 


Copyright © 1994-2008
All Rights Reserved
Digigami