Issues with Canon AVCHD Camcorder PsF format

[WorBry]

Is it possible to change, remove or otherwise override the interlace flags in an H264 stream or its container without re-encoding?

The reason I ask is that I have just acquired a Canon AVCHD camcorder (HF-G10) that records 1080/30p (24 Mbps) video (technically 29.97) as 'Progressive Segmented Frames' (30PsF) - that is to say, that the image is captured as progressive but encoded as interlaced fields. The accepted explanation is that Canon originally adopted this format to ensure broadcast compliance. Native (progressive frame) 24p is available on these camcorders, but the 30PsF format has been perpetuated in successive models. Only now, on the most recent 'flagship' high-end consumer model (HF-G30), has native 1080/30p, along with 1080/60p, been made available in MP4 format.

Recovering the progressive frame content from the PsF MTS files is not an issue with a frame-serving decoder that ignores, or can be set to ignore the interlace flags – and for AVISynth, several options exist, including FFMS2, DGDecNV and the now, very excellent (as yet Beta) DGDecIM

However, on playback (soft and hardware) platforms that blindly respect the interlace flags, or rather cannot distinguish PsF from ‘true’ interlaced (and so ignore the flags), there are issues - the most conspicuous of which is aliasing – vertical, horizontal, edge “jaggies/quilting", moiré – the whole gambit. Granted some aliasing artifacts do persist after conversion to progressive streams, and to a degree similar to that seen in native 24p MTS files – so clearly there are other contributing factors at play that go beyond the manner in which the images are encoded – direct streaming from the HF-G10 over HDMI to my plasma HDTV (Panasonic Vierra) also reveals a fair amount of aliasing with the camcorder set in 30PsF or native 24P modes

Ironically, native HDV (1440 x 1080, 25Mbps) files recorded in 30PsF format on my older Canon HDV camcorder show very little aliasing by comparison and when streamed over HDMI to HDTV the video is remarkably clean. Then again, these newer Canon AVCHD camcorders are capable of much higher resolution and so present greater challenges for in-camera image processing and the anti-aliasing treatments that are applied.

Another implication of the PsF format, dear to my own heart, concerns “native smart editing” - something that a number of NLE’s claim to do, but which few have perfected. One such editor is TMPGenc (Pegasys) Smart Renderer 4 (SR4). Prior to acquiring the HF-G10, I had started to use SR4 for native editing of HDV recordings and was very impressed with the results. Although SR4 offers little in the way of editing ‘effects’ (limited to titles and transitions), it is capable of true ‘frame-accurate’ smart-editing, wherein only the frames affected by a splice, cut or effect are re-encoded to maintain/re-construct GOP integrity. With HDV sources, the re-encoded segments are, to my eyes, indistinguishable from the source and the rendered streams play smoothly without any issues. I had also tested sample native AVCHD clips from several camcorders, with similarly impressive results, but unfortunately the only native clip I could source from a Canon (HF-S20) camcorder was 1080/60i.

Now that I have come to test 30PsF clips from the HF-G10, the results are not so impressive. Although the rendered edits play smoothly, the image quality of the re-encoded segments is seriously deteriorated – fuzzy to say the least, with whopping ringing artifacts, despite being set to the best possible quality. Curiously, 30PsF HDV does not appear to suffer from this. However, given the higher complexity of H264, I suspect that the program (which uses x264 for re-encoding) in seeking to match the format and bitrate of the source, is being thoroughly confused by the “progressive-flagged-as interlaced” formatting. Unfortunately, the program reveals nothing about the x264 encoding parameters that are applied – there is no custom settings option, only options to set the (depth) quality of the analysis (on a scale of +1 to +3) and encode quality (up to 100%).

Which leads me (finally) back to the subject of my inquiry – I have the notion that if were possible to change, remove or otherwise over-ride/mask the interlace flags in a way that could fool (or un-fool) SR4 into identifying these PsF files as progressive, the outcome might be different. And by extension, it might then be possible to play the smart-edited clips (on media players that respect these flags) in a way that avoids aliasing caused by the interlace flagging.

Certainly it is possible to change the interlace flags in MPEG-2 m2v streams to progressive using the very neat Restream utility. Tried that with my HV30 30PsF HDV clips and it works perfectly

If it is just not possible with H264 streams and the only option is to re-encode as progressive, then so be it and I will abandon the notion of native editing my AVCHD 30PsF clips with SR4. But if it is, however remotely, possible, I’d be pleased to know how.

Cheers.

[Guest]

Please post a sample file and tell us a source filter that has the issues you discuss, so that we can duplicate it and experiment.

You are making lots of assumptions that a video expert might view as a bit dodgy. For example, if a stream is encoded with field structure you cannot just change some flags to make it appear to be frame structure. Best to give a sample and say how to see the problem. Then let the experts weigh in. IMHO.

Can SR4 accept an Avisynth script as input? Have you sought support from Pegasus or checked related forums?

[WorBry]

Please post a sample file and tell us a source filter that has the issues you discuss, so that we can duplicate it and experiment.

Sure, I’m not home just now, but I'll put up sample native 30PsF clip as soon as I can, along with an SR4 edit.

I didn't think I was making any assumptions - just what I'm seeing. Sorry if it came across that way.

The aliasing that is said to be a byproduct of the PsF encoding format (60i-wrapped 30p) on these Canon AVCHD camcorders is well reported - I just didn't expect it to be so conspicuous. I’d have to dig around in my Firefox bookmarks when I’m home to find the links. Most of them were like observations made by other Canon camcorder users in other forums; I recall there being one review of the HF-G10 that commented on this also.

I haven't had any issues with the AVISynth source filters I've used - FFMS2 and DGDecIM. Both behave as expected in decoding the 30PsF clips to progressive frame streams. I can't use DGDecNV because I don't use an Nvidia graphics card.

The issues arise when playing the native 30PsF MTS clips on media players like MPC-HC (which uses the LAV filters) and Windows Media Player. MPC-HC reports the frame rate during playback as 59.94, as would be expected with a bobbed 60i stream, and stepping through the frames, one sees that each frame is repeated in a 2:2 pull-down fashion. It is then that the aliasing I was referring to is most conspicuous. Play the same clips in VLC player (with deinterlacing turned off) and most of that aliasing disappears, and what little does persist is akin to that seen in recordings (of the same scene) shot on the same camcorder in native (true) 24p mode. I'd use VLC player were it not it struggles a bit with AVCHD files on my PC.

I’m pretty sure it’s not my PC LCD monitor that’s causing it. I’ve examined high resolution HD progressive footage from other camcorders without any such problems. I'd be only delighted if it was my LCD screen.

But I am seeing the same issues when playing back these clips directly from the HF-G10 camcorder over HDMI on my HDTV (NTSC); quite noticeable aliasing and twitter-like artifacts with the 30PsF clips and some, but substantially less aliasing with the 24p clips. I don’t have a Bluray player and so am unable to see how these clips look when played in BD format.

...For example, if a stream is encoded with field structure you cannot just change some flags to make it appear to be frame structure.
That's what and all I was asking really. Like I said, with 30PsF HDV clips from my HV30 camcorder, it is possible, using Restream, to change in flags in the m2v stream from interlaced (field based) to progressive (frame based). MediaInfo identifies them as such, as does DGIndex, SR4 and the clips play in MPC-HC as though they were ‘true’ 30p (with no frame repeating). I was really just asking if something similar is possible with these 30PsF AVCHD clips. The rest of my diatribe (I do go on a bit) was only to explain why I would want to do so. Clearly then, this is not possible with H264 streams (irrespective of the container) because the interlace (field based) and progressive (Picture/Frame based) ‘flags’ are hard coded in the encoded stream. OK, I'm clear on that. :)

Just means that, as it stands, I can't see anything to be gained by using SR4 for editing these native 30PsF clips. The whole point of smart-editing is that it preserves, as much as possible the quality of the source. Probably where I was assuming too much was in my 'strong suspicion' that the quality deterioration (of the re-encoded segments) was a result of SR4 being 'confused' by the PsF formatting - which I realize now is a ludicrous notion. I should perhaps, as you commented, contact Pegasys and see what they say about that.

Can SR4 accept an Avisynth script as input?

No, unfortunately. I wondered about that also.

http://tmpgenc.pegasys-inc.com/en/product/tmsr4_spec.html

I know older versions of TMPGenc used to accept AVISynth feeds, but I'm not sure if the current version (now called Video Mastering Works 5) still does and WMW5 doesn't offer 'frame accurate' smart editing anyway - only key-frame cutting of source files before transcoding.

Again, sorry for any misunderstandings.

[WorBry]

And then you see something like this:

https://discussions.apple.com/thread/3584352

with statements like....

"Solution 2 for Canon PF30 - Malignant PsF- Use ClipWrap to pre-wrap the .MTS files and FCP X will recognize them as Progressive".

but then:

"If the raw AVCHD footage is 25PsF or 29.97PsF (benign or malignant), ClipWrap will create a true 25p or 29.97p H.264 file with a .mov extension, which will be properly recognized as progressive by your editing program"

[Guest]

If you give a stream and instructions to reproduce the issue, I can give you my analysis. If you are just interested in talking about it, maybe other members will be interested in the discussion.

You haven't even given us a screenshot to show the claimed aliasing, etc.

This talk of "benign" versus "malignant" PsF is a good example of the dodgy concepts I referred to.

[WorBry]

No, I'm not interested in just talking about it. Like I said, I'm away from home just now - at the in-laws for the Easter hols, and only have my older HV30 HDV camcorder with me. I'll put up an AVCHD clip when I'm back and have access to my PC.


This talk of "benign" versus "malignant" PsF is a good example of the dodgy concepts I referred to.

That's why I referred to it. Only came across this one today while browsing so it's not something I had based my initial comments on. But I can see how anyone reading those statements could be led to believe that converting from PsF to progressive is a matter of changing something in the 'wrapping'.

Anyhow, 'nuff said.

[Guest]

Sorry, I assumed you had reached home. I'm so impatient, I need to work on that. :)

[WorBry]

And I have nothing better to do at the in-laws than browse and write tedious posts on Doom9 forum ;)

[WorBry]

Back from the out-laws ....I mean the in-laws.

OK, I’ve put up some native clips (567MB zip file) from the Canon HF-G10 for your scrunity.

http://www.filedropper.com/hfg10aliasingtestclips

When I came to look at the footage I had (only had the camcorder a few days) most of the interesting shots were part of longer segments, so I would have had to trim them down -i.e. no longer native.

So, I recorded a series of short clips this morning, under more controlled conditions. All straight from the camcorder - just renamed. Each scene was recorded in 30PsF, 24p (native) and 60i modes. All shot at the maximum AVCHD bitrate available on the HF-G10 - 24Mbps.

Pretty unexciting subject matter, but illustrating the aliasing....where I see it. The three indoor shots (Zebra, Haiti, WotNot) were shot with a tripod, to minimize potential interference of shake, autofocus adjust (although lightening-fast on this camcorder) and motion blur. Just some slight intentional lateral movement at full wide-angle and then a slow zoom to 10x. Purely ambient window light - so no potential frequency interference from artificial lighting. The camcorder was set in automatic exposure (Program AE) mode - but under these conditions it would likely be at fully open aperture (F1.8) and therefore giving the shallowest depth of field.

I’ve also included one brief outdoor scene (Shed-Wire) that I had recorded (handheld) in both 30PsF and 24p. There, the main point of interest would be the telegraph wire over the shed. On my PC, that wire shows classic striated aliasing when the native clip played in MPC-HC, which disappears after the clip has been converted to a frame-based progressive stream with DGDecIM. The native 24p clip shows no aliasing. That’s the type of aliasing I am referring to that would appear to be associated with the PSF interlace formatting.

Darn fine camcorder though, with superb dynamic range for a consumer-class camcorder.

Anyhow, see what you think.

Cheers.

P.S. As for the quality deterioration I had observed with the SmartRenderer4 edited 30PsF AVCHD edits. Well, referring back to the User Guide (always a good policy) there some indication that setting for “100% quality”, may not always produce the ‘best quality’. Plus, I had only tested these files in VBR (Constant Quality) mode. So it might pay to do some further testing, and then, if needs be, address the issue with Pegasys at this point.

[Guest]

It's just progressive encoded as interlaced. Nothing special.

MPC-HC does not show aliasing if you turn off the deinterlacing, as I would expect.

[WorBry]

OK, thanks. So, no surprises then.

[WorBry]

....As for the quality deterioration I had observed with the SmartRenderer4 edited 30PsF AVCHD edits. Well, referring back to the User Guide (always a good policy) there some indication that setting for “100% quality”, may not always produce the ‘best quality’. Plus, I had only tested these files in VBR (Constant Quality) mode. So it might pay to do some further testing, and then, if needs be, address the issue with Pegasys at this point.

Just for the record; without contacting Pegasys, I've concluded that SmartRender4 is not at all to blame for the 'quality deterioration' I had mentioned. It's in the original footage. These camcorders generate a separate mts clip for each recording episode and it would appear that the first few frames of each clip (sometimes, depending on the content extending over the entire first GOP) invariably display a higher degree of artifacts.

Here's an example of it - after opening the link, click on the 'enlarge' button (bottom right corner of image) twice to display the image at original 1920 x 1080 resolution.

http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFrame_zps9caffc1a.png~original

Reading around, I learn that these 'bad' or 'corrupt' start frames are well known (by those that care to examine clips at the frame level) in AVCHD camcorder recordings, and not just Canon models. Whether it's occurring at the imaging or encoding level, I'm not sure.

I'm pretty sure it's nothing to do with the decoder. Both DGDecIM and ffms2 (after re-muxing to mkv) show the same thing. The only difference I've noted between the two is that (when the AVISynth-loaded file is opened in VDub), ffms2 appears to duplicate the first frame (i.e. frames 0 and 1 are identical) - that's after setting the ffms2 frame rate determinants (fpsden and fpsnum) to convert from 'double rate' (as FFMPEG does) back to 29.970 fps, if left at 'double rate', the first four frames are replicated. Just why this minor difference is beyond my knowledge. Maybe something to do with how the header is read and what is deemed to be the first display frame? When the native 30PF mts clips are opened in SR4, the 'key-frame' edit panel indicates that the first GOP has 17 frames, instead of the regular 15 frames per GOP in the rest of the stream. So does DGDecIM maybe see frame 2 as the first display frame? I dunno. Perhaps Neuron2 could explain the difference?

Anyhow, the main point is that SmartRender4 is not the source of the 'bad' start frames, as I had first intimated. SR4 always re-encodes (at least) the last and first GOP's around a splice-point. And so, when clips are merely joined, of course the 'bad' frames will be re-encoded as such. After excising the "offending"" start GOP before joining clips, I can see no such 'quality deterioration' in the re-encoded frames around the splice points - they look indistinguishable from the original frames.

So that has now become my practice - to (whenever possible) excise at least the first GOP of each clip when joining and cut-editing with SR4. Just means being mindful of that when shooting video and ideally allowing a second or two for 'trimming' at the start of each recording.

Edit: If anyone is interested, here is a short segment of the clip from which the above linked frame shot was taken. It was trimmed down from the end with SR4 (key-frame cut), and SR4 elected to re-encode the last GOP, but the 'original' leading GOP was not affected (i.e. was just copied)

http://www.filedropper.com/hfg1030pfbadstartframesclip

[Guest]

So does DGDecIM maybe see frame 2 as the first display frame? I dunno. Perhaps Neuron2 could explain the difference? You'd have to give me a sample with the start intact for me to be able to definitively answer that.

In general, orphaned leading B frames in display order at the start of the stream are replaced by the first decodable frame.

[WorBry]

You read my mind as I was anticipating yours - link for sample clip added to my last post.

[Guest]

All kosher with that one. There are no leading B frames.

Also, I don't see any degradation of the leading frame when serving with DGDecodeNV.

[WorBry]

Also, I don't see any degradation of the leading frame when serving with DGDecodeNV.

It goes without saying that I have absolutely no idea why that would be. SR4 does in fact offer the option for both NVidia CUDA and Intel QSV hardware AVCHD decoding, neither of which are available to me (AMD CPU and ATI graphics). As it stands, I have the option of using the 'Standard' internal decoder (whatever that might be), a 'high-speed' (but potentially less stable) version of the same or the Intel Media SDK Software decoder, which, if I'm not mistaken, is what DGDecIM is using on my PC.

Actually, looking at that clip again in SR4; although the degradation/artifacting is worst in the first few frames, it actually persists until frame 64, and then at frame 65 the quality abruptly improves. According to SR4, the I frame intervals in this clip are at frames 0, 30, 59 and 65.

So, with DGDecodeNV were you seeing no degradation over the first 64 frames also?

[Guest]

So, with DGDecodeNV were you seeing no degradation over the first 64 frames also? I don't see anything like that.

[WorBry]

Well since I'd already uploaded the file, here's what I'm seeing - first 70 frames of the same clip decoded with DGDecIM and saved as HuffYUV-YV12 (FFDShow)

http://www.filedropper.com/hfg1030pfdgdecimyv12first70frames

Again, a marked improvement in quality from frame 65.

[WorBry]

Just some further thoughts:

Well if the only satisfactory solution for this is to change my ATI Radeon GPU out for a NVidia card, for the CUDA decoding, I guess I'll have to bite that bullet; NVidia and I parted ways after a defect in one of their MB integrated chips trashed my laptop. Still waiting for the outcome of a compensation claim made through a Canadian Class Action on that.

I'm also waiting to see what Pegasys's Technical Support say about the way SmartRenderer4 handles these Canon PsF AVCHD files. Sent them a requested sample clip to examine. Although SR4 has its own internal H264 decoder, and an option to use the Intel QSV hardware and software decoders, it is advertized as being 'designed for NVidia CUDA'. Anyhow, I'll see what they advise.

Just out of interest though I opened up that same clip in AVISynth with DGAVCDec. I know DGAVCDec was abandoned years ago in favor of DGDecodeNV, but MeGUI still includes the DGAVCIndex package (v1.09.1) in its provided filter set and offers it as an option (to ffms2) for H264 file indexing. What's interesting is that the DGAVCDec output from that clip shows very obvious motion interlace combing on every other (odd) frame, but only up to frame 63; from frame 65 onwards there is no combing. Same kind of thing in other 30PF clips I've looked at.

So there is clearly something very different about the H264 coding in those first affected PsF frames, and it's not just a question of 'lower image quality' (quantizers or whatever).

So, what is so different about the NVidia CUDA decoding that 'gets it right' where the FFMPEG and Intel decoders (still) get it wrong? Interesting that I didn't have any such problems with 30PF HDV footage from my old Canon HV30 camcorder. I regret selling it now.

[Guest]

Just out of interest though I opened up that same clip in AVISynth with DGAVCDec. I know DGAVCDec was abandoned years ago in favor of DGDecodeNV, but MeGUI still includes the DGAVCIndex package (v1.09.1) in its provided filter set and offers it as an option (to ffms2) for H264 file indexing. What's interesting is that the DGAVCDec output from that clip shows very obvious motion interlace combing on every other (odd) frame, but only up to frame 63; from frame 65 onwards there is no combing. Same kind of thing in other 30PF clips I've looked at. Those artifacts are just due to the well-known PAFF bugs in the version of libavcodec used.

I'll have a look with DGDecIM...

[Guest]

I don't see any "degradation" with DGDecIM also.

Can you open your script in VirtualDub and take screenshots of two frames that show the difference and tell me what frame numbers they are?

[WorBry]

Really - well that's encouraging, in some respects.

Here are four VDub screen shots. This was using DGDecIM_b20.

LoadPlugin("V:\AVISynth Templates\DGDecIM\DGDecodeIM.dll")
dgsourceim("V:\HFG1030PFbadstartframesclip.ts", engine=0)

Frame 0 - the worst case of the degradation/artifacts:
http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame0_zpscbe50b4b.png~original

Frame 59 - still quite "bad":
http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame59_zps33f918ad.png~original

Frame 65 - the first "good" frame:
http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame65_zps8f087957.png~original

Frame 78 - another "good" frame:
http://i1276.photobucket.com/albums/y475/WorBry/HFG1030PFBadStartFramesDGIMDecFrame78_zps39d4228c.png~original

[Guest]

I see some motion blur but that's it. Can you mark the artifacts you are talking about?

[WorBry]

I'll have a go, but are you looking at the frame grabs at original full 1920 x 1080 res ? i.e. after opening the image from the link, click on the enlarge symbol (bottom right corner of image), and then again.

The artifacts/corruption should be more than visible on those two frames (0,59) at full res - furry/ringing-like edge artifacts, for example, around the boys glasses and the red wire on the table; blotchy smeared blocks on the chair behind the boy and on the book; quilting/jaggies on straight edges - like the counter-top.

[Guest]

Nope, can't see it. As I said all I see is motion blur due to the camera movement. Maybe someone else can help.

[Asmodian]

Do you have an example of a good version of 'HFG10 30PF BadStartFrames DGIMDec Frame 0'? Those artifacts look so much like normal compression/camera artifacts it would be nice to have the clean image to compare it to.

[zerowalker]

I looked at the images, not really sure what to look for, but i made an image from what i could grasp as "good/bad", this is cut from:

Frame 59 - still quite "bad"
Frame 65 - the first "good" frame

https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNeWhVeTdocUpfdnM

As you can see Good is clearer, but that's is something i would say is, as neuron2 said, Motion Blur. Even though the image overall doesn't seem to be affected which makes it a bit skeptical, but it all comes down to how it handles movements, Texts (small sharp details) or most likely the first thing to go in any movement.

[WorBry]

Do you have an example of a good version of 'HFG10 30PF BadStartFrames DGIMDec Frame 0'? Those artifacts look so much like normal compression/camera artifacts it would be nice to have the clean image to compare it to.

Unfortunately not. The decoders I've tried - ffms2 and DGIMDec in Avisynth, and ffmpeg separately - all produce the same result. And as I said earlier, the same is seen in SmartRenderer4, using both their 'internal' H264 decoder and the Intel SDK Software decoder.

The only 'clean' images in that clip are when, as I see it, there is an abrupt improvement in quality (i.e. marked reduction in artifacts) at frame 65. Granted the clip was shot with the camera handheld, but it was fairly static, with a little zoom in towards the end. So, yes, there is some motion blur in parts - around the boys hands for example, but that's not what I'm referring to.

If these are just 'normal' compression artifacts, wouldn't it be expected that they would persist throughout the clip. I've observed the same pattern in other clips (static tripod shots included) so this isn't just a one-off. Frankly, if all the footage was of that quality (which it is not) I'd be looking to change camcorder.

The file I put-up in post #18 - the first 70 frames decoded with DGIMDec, and saved as HuffYuv-YV12 (FFDShow) - is perhaps the best representation of what I am seeing. Any of the frames from 65-75, I'd consider to be 'clean' by comparison. Anyhow, if others can't see it/the same it's obviously a difficult point to get across.

[WorBry]

https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNeWhVeTdocUpfdnM
As you can see Good is clearer, but that's is something i would say is, as neuron2 said, Motion Blur. Even though the image overall doesn't seem to be affected which makes it a bit skeptical, but it all comes down to how it handles movements, Texts (small sharp details) or most likely the first thing to go in any movement.

Yes, that's some of what I'm referring to, along with this:

BAD Frame 59 (cropped/mag x2):

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

GOOD Frame 65 (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)

So you are saying that's all motion blur of detail?

Yet there's movement at other parts of the clip (after frame 64) where I don't see that. Here for example, at frame 101 - that looks like a fairly clean motion blur to me

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

Edit: Here's a longer section of the clip (frames 0-150) decoded with DGIMDec and saved as HuffYUV-YV12:

http://www.filedropper.com/hfg1030pfdgdecimyv12frames0-150

[Asmodian]

If everything decodes it the same way, even the software provided by the manufacturer, I expect it is not a problem in the decoding but in the encoding. I wonder if their encoder tunes itself somehow with the first 65 frames.

Those artifacts are just due to the well-known PAFF bugs in the version of libavcodec used.

Given that these artifacts went away at the same time it makes me think the encoder switched modes at that point.

[Guest]

Looks like there is some IDR/I frame popping. That may be what you are seeing.

[WorBry]

If everything decodes it the same way, even the software provided by the manufacturer, I expect it is not a problem in the decoding but in the encoding. I wonder if their encoder tunes itself somehow with the first 65 frames.

Funny you should say that. When I was searching around on the subject, I came across this thread on what appears to be a similar issue, in this case with AVCHD video captured on a Panasonic GH2 DSLR camera.

http://www.personal-view.com/talks/discussion/621/removing-the-corrupted-start-up-gh2-avchd-frames./p1

Some of the assertions could likely be viewed as what Neuron2 referred to earlier as 'dodgy', but one comment (by cbrandin, 5th post from the last on that page) caught my attention:

"The "blip" will never entirely go away. The codec needs the first GOP to optimize itself. The best we can hope for is that the first second will suck less. Even the factory, unmodified firmware settings exhibit lower quality for the first GOP than subsequent ones."

Is feasible that that could be the case?

Given that these artifacts went away at the same time it makes me think the encoder switched modes at that point.


Again, you have to wonder. Or maybe something to do with the way it reads from the image data buffer - who knows?

[WorBry]

Looks like there is some IDR/I frame popping. That may be what you are seeing.

Can't say I understand what that is - but if that were the case, is that something that could be corrected/circumvented at the decode level, or just the way it is - leaving the options of either putting up with it or cutting it out.

The HF-G10 does actually have a pre-record feature that records the 3 seconds captured (and stored in memory) before the record button is activated. Haven't used it as yet, but it could be useful if 'excision' is the only choice.

[WorBry]

Can't say I understand what that is -

OK, I do now.....I think:

http://forum.doom9.org/showthread.php?t=167830

[vivan]

Bitrate viewer shows that first two seconds have twice lower bitrate than the rest of the video.
http://i.imgur.com/es1gTOX.png

That why first 2 seconds have much lower quality.

[Guest]

Ah, vivan...brings some clarity to the situation. Bravo.

[WorBry]

Yes, thanks for that.

I was actually in the process of running some clips through Elecard's StreamEye analyser (trial version) to see what I could glean. And it confirms the same thing. Here's the analysis for that particular clip

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

Turns out all of the frame shots I put up were actually I frames (0, 59, 65 and 78)

When I examined other 'affected' clips, it was clear that this one was particularly severe. In most other clips it is limited to the first GOP and affects primarily the first series of alternate P and B frames; the starting I-frame is rather less affected.

So there we have it. Maybe there is some credence then to this notion that the camcorder encoder needs to put a little 'rubber to the road' to tune/optimize the H264 encoding. Excising the affected GOP(s) would seem the logical, and perhaps only remedy, and I'd say SmartRenderer4 is an ideal tool for that. Provided the cut is made at an I-Frame nothing is re-encoded. It's only when files/segments are joined that it re-encodes the GOP's on either side of the splice point.

[WorBry]

When I examined other 'affected' clips, it was clear that this one was particularly severe. In most other clips it is limited to the first GOP and affects primarily the first sequence of alternate B and B frames; the starting I-frame is rather less affected.

BTW - I'm seeing the same thing with 60i and (native) 24p clips also, so it's not just a PsF related thing.