I recently acquired a Canon HF-G10, my first AVCHD camcorder. On editing the fruits of my first recordings (in 30PF mode primarily) I noticed that the frames at the start of each recorded clip had a high degree of compression artifacts. In most cases, it affected just the first few frames, but in more severe instances it persisted up to two seconds into the clip.

Here is an example of a more severe case. These are frame grabs taken after the 30PF MTS file was decoded in AVISynth to produce YV12 output and opened in Virtual Dub. To view at original resolution - after opening the link, click the enlarge symbol (bottom, right corner of image) and then again on the enlarged image.

These two images are of the first frame, showing quite severe compression artifacts.

At original resolution:

http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame0_zpscbe50b4b.png~original (http://s1276.photobucket.com/user/WorBry/media/HFG1030PFBadStartFramesDGIMDecFrame0_zpscbe50b4b.png.html)

Cropped/mag x2

http://i1276.photobucket.com/albums/y475/WorBry/Frame0_zps2415f05c.png~original (http://s1276.photobucket.com/user/WorBry/media/Frame0_zps2415f05c.png.html)


Then at frame 65 there was an abrupt improvement in quality with a marked reduction in compression artifacts, and this continued for the rest of the clip.

At original resolution:

http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame65_zps8f087957.png~original (http://s1276.photobucket.com/user/WorBry/media/HFG1030PFBadStartFramesDGIMDecFrame65_zps8f087957.png.html)

Cropped/mag x2:

http://i1276.photobucket.com/albums/y475/WorBry/Frame65_zpsbddb48cc.png~original (http://s1276.photobucket.com/user/WorBry/media/Frame65_zpsbddb48cc.png.html)

I wondered if this was maybe a decoding issue, perhaps some quirk in the H264 encode format of the leading frames. Strange things can happen for example if the leading GOP in an H264 stream begins with a B frame.

So I ran several “affected” clips through Elecard’s Stream-Eye analyzer (Trial version....the licensed version is exorbitantly priced) to try and glean more about the GOP structure. In all of the clips, all of the GOP’s began with an I frame, so that was not the issue. What was very obvious was that all of the affected frames (whether I, P or B) were encoded with with fewer bits, and so at lower quality than those in rest of the stream. Here’s the analysis from that 30PF clip that the above images were taken from:

http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFbadstartframesclipStreamEye1_zps76e501b6.png~original (http://s1276.photobucket.com/user/WorBry/media/HFG1030PFbadstartframesclipStreamEye1_zps76e501b6.png.html)


In this particular clip also the first few GOP’s were irregular. The first two were 30 frames in length (with I frames at frames 0, 29 and 59) followed by a short (4 frame) segment, before the stream (from frame 65 on) established the regular pattern of repeating 15-frame GOP’s.

In other, less severely affected clips, these ‘sub-quality’ frames tended to be limited to the first GOP (typically 17 frames in length).

Removing the errant frames, although tedious, is not a big deal. Prior to acquiring the HF-G10, I had taken to using Pegasys (TMPGenc) SmartRenderer4 for ‘smart’ native editing of HDV material, with very impressive results. The program provides ‘frame-accurate’ (as well as ‘key-frame”) editing ; only those segments affected by a cut and/or splice are re-encoded to maintain GOP/stream integrity. With HDV MPEG-2 streams, this is usually quite minimal, with H264 streams, a little more extensive. When it came to excising these ‘sub-quality’ start frames, I found that provided the cut is made at an I-Frame, nothing is re-encoded. So, that’s one way.

An alternative, of course, is to convert the original MTS clips (separately or combined) to an intermediate intra-frame format (I use the lossless UTVideo codec or ‘visually lossless” Cineform, depending on the circumstances) which allows the ‘affected’ frames to be removed with frame-accuracy, without concern for GOP integrity etc. I’m leaning more to this approach, generally.

Reading around though, I was surprised to find little information on this subject.

This thread was possibly referring to the same thing in AVCHD clips from Sony-Nex-EA50

http://www.dvinfo.net/forum/sony-nex-ea50-all-variants/515705-corrupt-avchd-file-header.html

And there was this dialogue in another forum discussing methods for removing “corrupted” start-frames from Panasonic GH2 AVCHD footage.

Removing the Corrupted Start-up GH2 AVCHD Frames. - Personal View Talks (http://www.personal-view.com/talks/discussion/621/removing-the-corrupted-start-up-gh2-avchd-frames./p1)

But that’s all I could dig up.

One comment that struck me in that last link (5th post from the end) was that the codec needs the first GOP to optimize itself and, that, as such, the first GOP always exhibits lower quality than the subsequent ones.

This leaves pondering whether this is indeed a valid explanation for these ‘sub-quality’ start frames and then, whether this is common to all AVCHD camcorders. I guess the notion that the camcorder encoder needs to put some rubber to the road to tune itself, is not unreasonable, but is this fact or an assumption.

Granted, in those instances where only the frames in the first GOP are affected, it is not so much of an issue, but in the more severe instances where the blatant artifacting persists over several seconds, there are implications. Cut-editing in SmartRenderer4 for example, I've noticed that if these errant frames are left unchecked, when it comes to joining clips the artifacting is amplified by the re-encoding that always takes place around a splice point.

I’d be interested to hear from others on the forum who might have further insight into this phenomenon.

Hi Bryan,

I mostly shoot MP4 on the HF G30 and I have never noticed this effect, but as I always try to shoot longer clips to trim, I probably wouldn't notice it anyway.

As this only affects the first few frames, surely it is hardly significant and, if your links are right, there's nothing to be done about it anyway. My suggestion is a mental "lights, camera, action" each time you start shooting a clip.

I know it's not the answer you were looking for, no doubt someone more knowledgeable on this subject will come in, but it is practical.

Dave

Hi Dave, nice to see you here.

Well, yes, I'd agree - when it only affects that the first few fleeting frames, it's hardly an issue..... I guess. Problem is that one cannot know when the more severe and protracted form might appear. Two seconds might not seem a lot, but when you've got used to a run-and-gun, 6 seconds at a snap, style of shooting, allowing for that needs some adjustment. As you know, the HF-G's have a 3-second pre-recording feature that I could perhaps make use of in certain circumstances.

I was really more intrigued about the underlying cause of this phenomenon and whether it is common to all AVCHD camcorders (Yes, I tend to worry that I've got a defective one). Examining what little footage I’ve shot in 60i and (native) 24p, I haven’t seen the more protracted form as yet, but the transient (first GOP) type is there also. And it occurs when recording to internal memory or SD card.

You don’t see this with software-based H264 encoding, but if the mechanism of ‘on-the-fly’ hardware-mediated H264 encoding on camcorders is such that it requires an initial ‘kick-start’ GOP, to get going, I can’t imagine that it would be any different for MP4 recordings; and if it is, perhaps there is more to it.

I guess what erks me a bit, is that I didn’t encounter this type of thing with HDV footage on my (now sold) HV30. I’ve had a look back at some archived native clips and can’t see evidence of it. Allowing for the fact that H264 is a more complex beast, one wonders why in-camera mechanisms haven’t been incorporated to prevent this first ‘dud’ GOP from being appearing in the recorded clip...if indeed it is a universal characteristic of the AVCHD implementation.....and mine doesn't have a defect. And then, what is the explanation for the more protracted form that spans several GOP’s ? Is it merely an extension of the same or are there other factors at play?

Hi Dave, nice to see you here.
Thanks Bryan, nice to be here.

It was getting a bit lonely over at the other place. When I came back after two weeks in Cyprus and there were only four new posts, I realised I have been flogging someone else's dead horse. You'd think my Linux editing thread, with well over 20,000 hits to date, would have helped swell numbers. Ah well...............!

I am afraid there is too much in modern technology I don't trust, it often feels to me that we are going backwards almost as fast as we are going forwards and we, the consumers, are the guinea pigs who are doing the R&D testing and paying for the privilege. Which is why my attitude to it, as you know, is if it doesn't do what it's supposed to, then I'll get something that will.

As a younger man, you remind me of me when I had a young family, I spent countless hours fixing things that, in my case, I couldn't afford to buy, for the pleasure of using them for myself. The price was hours of frustration!

Getting back to your problem, I had a look at your frame grabs again on my higher resolution editing monitor and it looks to me like they were encoded at too low a bit rate. One thing, have you checked if you get the same effect at 60i and 24p?

Good hunting
Dave

I see it in other video cameras when I stop shooting and then do a quick restart. Sometimes there is a minimum amount of time needed from the stop to restart so the software can cycle properly. I would get pixelation and sometimes the audio would get scratchy which could also be from static build up.

As a younger man, you remind me of me when I had a young family
Funny that, I remind me of me when I was a young man also. Basically though, I'm just looking to get the best from what I have and can afford.

Just to answer your points:

I had a look at your frame grabs again on my higher resolution editing monitor and it looks to me like they were encoded at too low a bit rate.

From my first post:

So I ran several “affected” clips through Elecard’s Stream-Eye analyzer (Trial version....the licensed version is exorbitantly priced) to try and glean more about the GOP structure. In all of the clips, all of the GOP’s began with an I frame, so that was not the issue. What was very obvious was that all of the affected frames (whether I, P or B) were encoded with with fewer bits, and so at lower quality than those in rest of the stream. Here’s the analysis from that 30PF clip that the above images were taken from:

http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFbadstartframesclipStreamEye1_zps76e501b6.png~original (http://s1276.photobucket.com/user/WorBry/media/HFG1030PFbadstartframesclipStreamEye1_zps76e501b6.png.html)


The height of the columns in that analysis histogram represents the respective bits/frame.

One thing, have you checked if you get the same effect at 60i and 24p?

From my last post:
Examining what little footage I’ve shot in 60i and (native) 24p, I haven’t seen the more protracted form as yet, but the transient (first GOP) type is there also. And it occurs when recording to internal memory or SD card.


Actually, I've done some further testing using the StreamEye analyzer as a point of reference. Basically, the appearance of compression artifacts in just the first few frames of a clip (what I referred to as the 'transient' type) would indeed appear to be the norm, at least for this camcorder. I'll post again on that as it's quite revealing and there appear to be some differences in the way different decoders output those initial frames. Too late tonight.

Nick, thanks for your input. I suspect also that other factors are involved in instances where these 'sub-quality' start-frames extend beyond the first GOP. I'll look at that some more.

OK....Day Two.

So, having examined a number of clips (30PF, 24p and 60i) from the HF-G10 using the StreamEye analyzer, all show a similar pattern in the leading GOP. Here's a typical example:

http://i1276.photobucket.com/albums/y475/WorBry/StreamEye30PFnormalleadingGOPprofile_zpsc3fa1191.png~original (http://s1276.photobucket.com/user/WorBry/media/StreamEye30PFnormalleadingGOPprofile_zpsc3fa1191.png.html)

The first frame in the stream sequence, and starting each 15 frame GOP, is always an I frame (brown columns). This is followed by a repeating sequence of two B-frames (green) and a P-frame (blue). What marks the first GOP out is that the first B-frame and first P-frame (arguably the second P frame also) have proportionately lower bits/frame than subsequent B and P frames in the stream. There is clearly an adjustment process going on. It is those first two B-frames in the sequence that exhibit the most noticeable compression artifacts. Other B (and P frames) early in sequence may do also depending on the content, but the first two B-frames are the most affected.

But what happens is this. The sequence in which the frames are displayed is different. The two 'low quality' B-frames are displayed first, then the I frame, then the next pair of B-frames, followed by the first P-frame and so on - in effect, the B-frame pairs are shifted forward.; such is the nature of B-frames. So, whilst the first I frame in the stream sequence is relatively good quality, it is the two 'sub-quality' B-frames that are displayed first. Sounds a bit complicated I know; it’s easier watching the frame progression in the program.

What I’ve found though is that different decoders may output these initial frames quite differently.

DGIMDec, for example, is an AVISynth-based (indexing/decode) filter set that utilizes the Intel QSV and SDK software decoders. With DGIMDec, the output display sequence is as expected - the two ‘sub-quality’ (B-frame derived) frames are displayed first, then the I frame etc.

Using FFMPEG for decoding to (lossless YV12) however, the first frame gets duplicated, so the output stream commences with three ‘sub-quality’ frames.

Curiously, ffms2, an AVISynth-based port of FFMPEG, adds another twist. In this case, the decoded output stream starts not with the ‘sub-quality’ B-frames, but with 5 (yes 5) consecutive copies of the first (good) I frame, and then goes straight to the second pair of B-frames, which generally show much fewer artifacts. So, the worst frames are actually skipped.

How the H264 decoders used in the various high-level commercial NLE’s behave in this regard, I’m not sure. Linux (KDenLive etc) of course uses FFMPEG.

SmartRenderer4 offers the options of using it’s internal software decoder (by default), the Intel SDK software decoder, or hardware-based decoding, using the Intel QSV (requiring an Intel CPU) or CUDA (requiring NVidia GPU). Since my PC has an AMD processor and ATI Radeon graphics, neither hardware-decoding options are available to me. Using either the internal ‘standard’ decoder or Intel SDK software engine, both display the frames in the same (assumed correct) manner as DGIMDec, with the two ‘sub-quality’ B-frames first.

So, on one hand, these few ‘sub-quality’ frames in the leading GOP do appear to be a normal component of AVCHD clips from this camcorder (and possibly others). Being transient, one might question whether they are worth bothering about. To my mind they are.

Why? Well, taking first the approach of using an ‘intra-frame’ intermediate for process editing. If the chosen intermediate preserves the frames in their original 8-bit YV12 format (using say a lossless codec like UTVideo, ffvhuff, ffv1), fine, these ‘sub-quality’ frames do no ‘harm’ whilst they are untouched. Converting to a 4:2:2 (8 or 10-bit) intermediate format could feasibly help to smooth out some compression artifacts or make them worse.

Just as an example, here’s that first bad frame again (from the ‘severely affected ‘ clip) converted to some 4:2:2 formats. The frame shots were cropped and magnified (x2) to highlight the artifacts:

Original YV12
http://i1276.photobucket.com/albums/y475/WorBry/BadStartFrameDGIMDecYV12_zps192cf10d.png~original (http://s1276.photobucket.com/user/WorBry/media/BadStartFrameDGIMDecYV12_zps192cf10d.png.html)

Raw YUY2 (8-bit, progressive chroma sampling)
http://i1276.photobucket.com/albums/y475/WorBry/BadStartFrameDGIMDecYUY2_zps56216d1f.png~original (http://s1276.photobucket.com/user/WorBry/media/BadStartFrameDGIMDecYUY2_zps56216d1f.png.html)

Cineform 10-bit (Film Scan 1 quality, progressive)
http://i1276.photobucket.com/albums/y475/WorBry/BadStartFrameDGIMDecCineformFS1_zps5cf053ed.png~original (http://s1276.photobucket.com/user/WorBry/media/BadStartFrameDGIMDecCineformFS1_zps5cf053ed.png.html)

FFMPEG - DNxHD (8-bit , 220 Mbps)
http://i1276.photobucket.com/albums/y475/WorBry/BadStartFrameFFMPEGDNxHD2208-bit_zpsc9db3378.png~original (http://s1276.photobucket.com/user/WorBry/media/BadStartFrameFFMPEGDNxHD2208-bit_zpsc9db3378.png.html)

Probably not that much of difference actually.

More important is the influence these ‘sub-quality’ frames could have on applied edit effects and graphics. Not only that, but when it comes to rendering out to another inter-frame format - whether that be H264 or MPEG-2 - these sub-quality frames, and their associated artifacts, could profoundly influence the intra and inter-frame frame analysis (motion vectors included) and affect neighboring frames in the outcome. And more so if duplicated frames are added to the mix. Also if the source is interlaced and the intent is to edit or output progressive, compression artifacts and frame duplicates do not exactly make for high quality deinterlacing.

Likwise, taking the ‘smart native editing’ approach, leaving these frames un-checked again runs the risk of the artifacts being amplified when they fall in the segments that are re-encoded. This was more than evident when I merely joined two copies of the ‘severe case’ clip in SmartRenderer4.

So, yes, my inclination is to excise these ‘sub-quality’ start frames whenever possible.

I guess it’s a bit like buying a pair of smart pants with a un-cut hem. Might look OK, even go unnoticed , but sooner or later the hem will fray and unravel. I guess you could tape them up, but I don’t think anyone would find it unusual or overly fussy to have the hem properly adjusted and stitched-up by a tailor. Reasonable analogy?

As for those instances where the compression artifacts are more severe and persist beyond the first GOP; well short of testing different camcorder operations that might cause that, I’ll probably just deal with them if and when they occur.

OK, I’m done.

I see it in other video cameras when I stop shooting and then do a quick restart. Sometimes there is a minimum amount of time needed from the stop to restart so the software can cycle properly. I would get pixelation and sometimes the audio would get scratchy which could also be from static build up.

Tried various things:

Quickly re-pressing the record button - before the on-screen pause/standby symbol had chance to stop blinking.
Attempting to record immediately after powering on. It won't let you until it's read the memory.
Switching between Auto and Manual modes, and between frame rate modes (30PF, 60i, 24p), without powering off.

All the recorded test clips were normal. So, it's still a mystery

Hey Bryan

On my Saturday wedding I had a maybe 3 or 4 frames with artifacts as the bride got out of the limo. Apart from that all footage was perfect. The bridal exit from the car was probably a few seconds in so it wasn't the first few frames either to blame. My camera was in standby as I had just filmed the limo coming into the Church and it then did a turn and stopped so I stopped the recording and moved into a position next to the door and filmed the bride getting out and saw the artifacts about maybe 5 seconds into the clip.

I have no idea at all what causes the issue but it seldom happens and is easy to cut out too or cover with a second camera shot usually. This clip however just had a bunch of nasties over the bride only and never affected the clip and the NLE was also happy with the clip. I have only ever had just a couple that threw Sony Vegas for a loop and stopped a render.

Are your happening on a regular basis??? The last I had was maybe 12 months ago so for me it's rare !

Chris

I would like to raise one further point.

I often catch myself being too critical of quality on my editing monitor, when in fact what I can see there will never be seen at normal viewing distance on an HDTV e. g. I cannot get rid of the sharpening artifacts on my HF S100, even with in-camera sharpening set to minimum. It seems awful close-up on the monitor, but on the TV screen the picture looks excellent.

I know I'm not going to stop you being a pixel peeper Bryan, but I am going to try to persuade you to sit back a bit.

Dave

Are your happening on a regular basis??? The last I had was maybe 12 months ago so for me it's rare !


Thanks Chris,

Yes, I'd read reports of occasional corrupted AVCHD files (on various camcorders) that were usually attributed to a 'bad' memory card.

I've had no problem playing back or processing any of the AVCHD clips I've examined. There is no data corruption per se; it's just that 'affected' frames are always encoded at abnormally low bitrates, resulting in a higher than normal degree of compression artifacts.

The more severely affected clip, that I highlighted in my first post, where the low-bitrate artifacts persist beyond the first GOP, is the only case of that type that I have encountered so far. There again, I've only had the HF-G10 for a just over a month.

The other, what I termed 'transient' type I am less concerned about, or at least have a good understanding now of why it happens and how to deal with it. Thankfully it doesn't occur anywhere other than in the first few frames of every clip.

Although I was very impressed with SmartRenderer4 for 'native smart editing' of HDV clips, I am now more inclined to return to the practice of using an intra-frame intermediate format, in which case, it is no big deal snipping out those first few 'sub-quality' frames when editing. Since the 'affected' frames will only occur at a splice point, and effective Scene Change, I guess one could just as easily mask them with a transition, but I usually try and keep transitions to a minimum.

Using SmartRenderer4 to excise the affected frames means having to excise the entire first GOP (key frame interval) to avoid any re-encoding. But joining clips in SR4 always involves re-encoding up to several GOP's around the splice point and I'm not entirely happy with the quality of the encoding. With HDV MPEG-2 clips it was seamless and examining some of those edited clips now with the StreamEye Analyzer (a really great tool) you'd be hard pressed to see where the join is in the stream GOP profile. With H264 streams it's a bit more hit and miss; even at 'best quality' you can see compression artifacts being introduced on certain frames, for precisely the same reason - when examining the GOP profiles with StreamEye, the affected (typically B) frames are afforded an abnormally low bitrate. Which I find a bit surprising as the program uses x264 which is a very good and efficient software-based encoder. That's something I intend to address with Pegasys.

So, current practice is to load the separate MTS clips in the NLE I have long used (Corel Video Studio Pro x6) purely to join them. With the clips in the time-line (don't even set-up a Project), I just render out with the output file set to match the settings of the first clip. So nothing is re-encoded, and examining the joined files in Stream Eye there are no GOP inconsistencies around the splice points. At the same time I output a WAV audio file. I then transcode the joined files to the intermediate AVI format (with WAV audio) using AVISynth (presently the DGIMDec decoder). If any generalized processing is needed (denoising, deinterlacing if interlaced etc), I'll do that in AVISynth before transcoding. Then put the intermediate file back into Corel VS Pro, set-up the Project (to match the intermediate format), run a multi-scene scan to separate at the Scene Changes and snip out the first few 'affected' frames (where possible) whilst I'm cut-editing. I then render out the edit in the intermediate format, and use AVISynth again for again further conversions (down scaling for DVD etc) and frame-serving to the target encoder. Might seem a bit tedious, but it works well for me and is certainly the most satisfactory way of eliminating these 'sub-quality' start frames.

The only thing I'm hovering over though is whether to use lossless UTVideo or 'visually lossless' Cineform as the edit intermediate. Both edit and render like butter in Corel VS Pro on my PC (great mult-threading support). With UTVideo (YV12 variant) the stream is preserved in the original 8-bit YV12 color space, which has benefits for processing with some AVISynth filters, but the files are very large. Cineform, despite being 10bit 4:2:2 has the advantage of much smaller file size (even at Film Scan 1 quality) and, whilst not technically lossless, I am convinced (from yet more exhaustive testing) is very high quality. Theoretically, processing in YUV 4:2:2 has some advantages for greater accuracy in color transformations, graphics and general re-sizing.

The one thing I've noticed with Cineform, at least using the accessible vfw codec (from GoProStudio), is that if the left to internally convert the YV12 output from these 30PF clips, there is some evidence of what look like 'Chroma Upsampling' (CUE) line artifacts on saturated colors. I'm not sure if this is classic CUE (i.e. progressive 4:2:0 chroma up-sampled as interlaced) or some by-product of the internal 8 to 10-bit 4:2:2 upscaling and dithered output, but it definitely pays to pre-convert the YV12 to YUY2 (8-bit 4:2:2, with progressive chroma sampling) before encoding. Something I might bring up in the Cineform Showcase forum section.

Dave, if you are reading this - btw, no such issue when transcoding directly to DNxHD (8 or10 bit) with FFMPEG, or to the YUY2 variant of UT-Video.

Anyhow, as regards the 'sub-quality' start frame issue, I guess I'll just hope that the one severe case I encountered was indeed a one off, of unknown cause - maybe "GOP-Lins" !!

I would like to raise one further point.

I often catch myself being too critical of quality on my editing monitor, when in fact what I can see there will never be seen at normal viewing distance on an HDTV e. g. I cannot get rid of the sharpening artifacts on my HF S100, even with in-camera sharpening set to minimum. It seems awful close-up on the monitor, but on the TV screen the picture looks excellent.

I know I'm not going to stop you being a pixel peeper Bryan, but I am going to try to persuade you to sit back a bit.
Dave

Well, there is that perspective, and there is no doubt that when viewed on an HDTV, recordings from the HF-G10 are quite spectacular. But there again this section is devoted to discussion about the AVCHD format, so my observations and comments are not at all misplaced and are quite pertinent. And for anyone who cares to read them, I hope they might provide some insight into issues that others may have encountered and queried themselves.

Maybe some would consider that 'pixel peeping', as inferring being overly concerned with details, but quality is in the detail. Lets face it, a lot of what you see in consumer level video (I'd hazard some professional level also) that is perceived as sharp, high resolution detail is nothing more than artifact. Well if people are content with that illusion fine, but me not. And if that classes me as a 'pixel peeper', then that I am.

Take a look over at the Doom9 forum, where many video professionals, technical gear heads and mere followers (such as I) gather and you'll see what real pixel peeping is about. And when you look at the many quality applications that have come out of that 'open-source' brood that are now widely incorporated in high-level commercial video programs (x264 encoding, FFMPEG to name but a few) all that has come about through progressive refinement and the feedback of 'pixel peeping' beta testers and casual end users. So, 'pixel peeping' is important, and I am proud to be one. The rest just enjoy the fruits of that 'pixel peeping progress'.

And in between, 'pixel peeping' I do actually shoot video for sheer enjoyment and artistic content as well.

Edit: I see I've double posted somehow. Can't seem to delete either.

I would like to raise one further point.

I often catch myself being too critical of quality on my editing monitor, when in fact what I can see there will never be seen at normal viewing distance on an HDTV e. g. I cannot get rid of the sharpening artifacts on my HF S100, even with in-camera sharpening set to minimum. It seems awful close-up on the monitor, but on the TV screen the picture looks excellent.

I know I'm not going to stop you being a pixel peeper Bryan, but I am going to try to persuade you to sit back a bit.
Dave

Well, there is that perspective, and there is no doubt that when viewed on an HDTV, recordings from the HF-G10 are quite spectacular. But there again this section is devoted to discussion about the AVCHD format, so my observations and comments are not at all misplaced and are quite pertinent. And for anyone who cares to read them, I hope they might provide some insight into issues that others may have encountered and queried themselves.

Maybe some would consider that 'pixel peeping', as inferring being overly concerned with details, is not what videography is about, but quality is in the detail. Lets face it, a lot of what you see in consumer level video (I'd hazard some professional level also) that is perceived as impressively sharp, high resolution detail is nothing more than artifact. Fact. Well if people are happy with that illusion fine, but me not. And if that classes me as a 'pixel peeper', then that I am.

Take a look over at the Doom9 forum, where many video professionals, technical gear heads and mere followers (such as I) gather and you'll see what real pixel peeping is about. And when you look at the many quality applications that have come out of that 'open-source' brood that are now widely incorporated in high-level commercial video programs (x264 encoding, FFMPEG to name but a few) all that has come about through progressive refinement, including the feedback of 'pixel peeping' beta testers and casual end users. So, 'pixel peeping' is important, and I am proud to be one. The rest just enjoy the fruits of that 'pixel picking progress'.

And in between 'pixel peeping' I do actually shoot video for sheer enjoyment and the artistic content as well.