|
|||||||||
|
Thread Tools | Search this Thread |
March 27th, 2006, 03:31 PM | #16 | |
Major Player
Join Date: Jan 2006
Location: Rotterdam, The Netherlands
Posts: 475
|
Quote:
|
|
March 27th, 2006, 04:00 PM | #17 | |
Barry Wan Kenobi
Join Date: Jul 2003
Location: North Carolina
Posts: 3,863
|
Quote:
|
|
March 27th, 2006, 04:00 PM | #18 | |
Regular Crew
Join Date: Mar 2005
Location: Stockholm Sweden
Posts: 73
|
Quote:
http://www.plonk.se/macroblockinghd100ecineform.jpg I must say its a litle bit surprising, its not an extrem sceen, and if you have moving clouds you will see the artifacts there as well. And the artifacts in the clouds will be musch easyer to see. |
|
March 27th, 2006, 04:06 PM | #19 | |
Regular Crew
Join Date: Mar 2005
Location: Stockholm Sweden
Posts: 73
|
Quote:
|
|
March 27th, 2006, 04:10 PM | #20 | |
Barry Wan Kenobi
Join Date: Jul 2003
Location: North Carolina
Posts: 3,863
|
Quote:
What happens is that MPEG-2 gets its efficiency from repeating duplicate information between frames. It only encodes the changes between frames. It doesn't have nearly enough bandwidth to re-encode all the frames, so it relies on the relatively-unchanged nature from frame to frame in order to get its efficiency and fit all the data within its limited bandwidth. Usually this works quite well; think of an interview setting: the background doesn't change at all, so it gets carried over frame to frame unmodified, and usually only the person's mouth and maybe their hands are changing, so the available bandwidth is allocated to compress those changes. But when a flashbulb goes off? EVERY PIXEL changes! HDV hates that. Broadcast HD hates it even more. When every pixel changes, there's no way that the MPEG-2 bandwidth can cope and keep up with all the changes, so you get macroblocking and (in worst-case scenarios) lego-blocking. And it doesn't just affect the one frame where the flashbulb went off, either -- it affects every frame in the group. HDV allocates its bandwidth across a group of six (JVC) or 15 (Canon/Sony) frames, so all the available bandwidth gets spread across those six or 15 frames. If one frame contains a flash where all the pixels change, that one frame will require a lot of the available bandwidth from the group, which means all the other frames in the group will be robbed of the bandwidth that they would otherwise need. So all 15 (or 6) frames get degraded. So a worst-case scenario for HDV would be a strobelight. Especially a strobelight that flashes more than once per group of frames, but that doesn't complete its on/off cycle within one frame. Say it ramps up to peak brightness on one frame, and dies down to dark over the course of two frames -- it would mean complete pixel changes on every pixel over the course of three frames. That will lead to massive artifacting. Rippling water is kind of the same thing -- every pixel is changing in the body of water. So HDV and MPEG-2 have a very tough time coping with it. But usually it's not so bad as the strobelight comparison, because in a rippling-water shot there'll often be skyline and shoreline that don't change, so only the portion of the frame with the rippling water will be overwhelming the codec, and the rest of the frame will be relatively static (which compresses very efficiently). So the codec has a better chance of dealing with it. But the higher the percentage of the frame that consists of rippling water, the worse off the codec will be. Also, MPEG-2 employs motion prediction -- if something is relatively unchanged, but in a different part of the frame, MPEG-2 can usually "find" that and copy it over (to grossly oversimplify the explanation!) So for a panning shot, things might be mainly unchanged but just moved; MPEG-2 is designed to cope with that. But there's no way MPEG-2 can predict rippling water, nor can it predict the effect a strobelight has, or smoke or fire or other random/unpredictable things. So those elements will seriously challenge MPEG-2/HDV. |
|
March 27th, 2006, 04:12 PM | #21 | |
Barry Wan Kenobi
Join Date: Jul 2003
Location: North Carolina
Posts: 3,863
|
Quote:
In 720 mode, broadcast uses the same 19 megabits, but it has to broadcast 60 frames per second, whereas HDV only encodes 30 or 24 frames per second, so again, there's much more bandwidth allocated per frame in HDV tape recording than there is in an HD broadcast. So even though the same factors are at work (MPEG-2's limitations), the camera originals will usually be more resilient to artifacting than the final HDTV broadcast will be. |
|
March 27th, 2006, 04:16 PM | #22 | |
HDV Cinema
Join Date: Feb 2003
Location: Las Vegas
Posts: 4,007
|
Quote:
__________________
Switcher's Quick Guide to the Avid Media Composer >>> http://home.mindspring.com/~d-v-c |
|
March 27th, 2006, 04:19 PM | #23 | |
Barry Wan Kenobi
Join Date: Jul 2003
Location: North Carolina
Posts: 3,863
|
Quote:
If you're asking "does this mean I can't shoot artifact-free water footage with this camera?", then you may consider the answer bad news. There are limits to what HDV can handle. You've run into one of them. But -- do you see the artifacting during playback? Or is it only when you examine the still frames? If you don't really notice it during full-speed playback then is it really a problem? |
|
March 27th, 2006, 04:21 PM | #24 | |
Barry Wan Kenobi
Join Date: Jul 2003
Location: North Carolina
Posts: 3,863
|
Quote:
Don't know about 1080/24F Canon; I suspect that it will perform more robustly than the 1080/60i version would. |
|
March 27th, 2006, 04:39 PM | #25 |
Regular Crew
Join Date: Mar 2005
Location: Stockholm Sweden
Posts: 73
|
I can understand the technical limitations of HDV and how it works, but I just tought my HD100 would do better in a situation like this.
As I said before, its not that extrem, a litle bit more than 1/3 of screen is coverd with water and the rest is static. The cam is not moving. How much blocks would it be if I had the cam on my shoulder and did some panning as well? |
March 27th, 2006, 04:48 PM | #26 | |
Regular Crew
Join Date: Mar 2005
Location: Stockholm Sweden
Posts: 73
|
Quote:
|
|
March 27th, 2006, 11:41 PM | #27 |
Regular Crew
Join Date: Feb 2006
Posts: 34
|
today's artifacts testing...
As promised
go to www.vidprostudios.com .... on the home page pic of JVC camera, click on the white rectangular "record indicator" ... this will take you to the page where the test photos are located note: footage was ingested via AspectHD to Premiere 2.0 - cineform intermediate codec ... exported as .tga files into photoshop where I then created the pip (at approximately 160%) exported as .png files I will put up the 30p comparison tomorrow cheers Pete |
March 28th, 2006, 12:23 AM | #28 | |
Major Player
Join Date: Jul 2004
Location: Phoenix, AZ - USA
Posts: 300
|
Quote:
|
|
March 28th, 2006, 12:43 AM | #29 |
Regular Crew
Join Date: Feb 2006
Posts: 34
|
Joel
exactly that ... I think it's apparent that in a shot like that, anything above minimum detail is going to magnify blocking artifacts I found too that keeping the exposure up near 100 helps to soften artifacts without losing actual focus ... none of those shots posted were CC ... I could have easily bumped the colors to make a richer scene without bringing in additional blocking cheers Pete |
March 28th, 2006, 12:59 AM | #30 |
Major Player
Join Date: Apr 2005
Location: Knoxville TN
Posts: 589
|
Peter, when did you first notice this? Thats a very big difference in blocking, compared to almost none! Both of these are Aspect HD ingested on what capture setting?
Also, off topic, I am using the same workflow (PPro 2 / Aspect HD) but have had a lot of people asking me if PPro 2 is as buggy as is the rumor, it's been very stable for me on our 64 machine. Have you run into anything odd? I only ask because I'm about to commit a rather large project to it and I fear you can't turn back mid project. Sorry for off topic.
__________________
Our eyes allow us to see the world - The lens allows others to see the world through our eyes. RED ONE #977 |
| ||||||
|
|