More or less, can't tell if it's exactly as bad/good, but these results do not surprise met at all. I have some difficult footage as well, a swan in water, if I have some time I'll upload it. In the meantime you can look at some edgy footage I've uploaded for an other topic, captured with FCP: http://www.vincentrozenberg.com/files/tree.zip

Nate speaks the truth. I've seen broadcast HD break down worse than I've ever seen HDV fail, and I've pushed HDV harder than just about anyone.

Tim, did you see this picture (same link as above), there is no clipping light here. but the blocks are there anyway.
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.

Broadcast and what you get at your tape from your own cam is not the same thing.

It's not the brightness level that causes the problem with MPEG-2 and flash bulbs.

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.

It's affected by the same principles though. HDV has more resiliency to artifacting than broadcast television does because it has more bandwidth per pixel allocated to it. Broadcast HD sends 19 megabits of 1080i; HDV uses 25 megabits for 1080i, so more bits = more resiliency.

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.

You mean, why didn't Sony, JVC, and Canon think of this. It is low-bit rate MPEG-2 that can cause this. But, you should consider what folks are saying about your camcorder.

Depends on what question you're asking. If you're asking "is my camera defective and does it need service?" then the answer is good news: no your camera is not defective, it doesn't need service, it's performing like all the other HD100s would.

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?

Steve is correct. Furthermore, I have found the JVC to be more resilient to artifacting than the Sony or Canon implementations. You should try that same shot on a Sony or 1080/60i Canon, you'll see that the JVC is controlling the artifacting better.

Don't know about 1080/24F Canon; I suspect that it will perform more robustly than the 1080/60i version would.

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?

I would say you can see it, at least it looks diferent than without the blocks. The blocks is simply creating another picture, and it is definitly not better. If you have moving clouds in the picture as well the artifact gets wery obvius, becouse they are esyer to display in the clouds.

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

Unless I'm missing something the shots with detail at minimum are dramatically better... so leave the sharpening to post?

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

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.