@driftwood I tried your GOP1 220M settings and it's really looking great, but as I'm transcoding every footage to ProRes via 5DtoRGB I got some problems with those settings. Did you have further contact to @rarevision regarding the GOP1 files?

@zincoontrin It doesn't mean entirely that shadow details get discarded at longer GOPs, in fact quality of frame is not the main reason for using GOP1. The main reason is to do with how it renders motion, motion has a different look at GOP1 (or lower GOPs in general). To put simply an I-frame contains the whole frame compressed, rather than changes since, or onto, the next I-frame Which P and B frames do. Which is why B and P frames can be smaller, they need less information. This does mean however that the lower the GOP setting the higher the bitrate you're going to need, as in the case of GOP1 your compressing and storing the entire frame every frame. If, and its quite an if, running at GOP12 you can get really good I-Frame size, and B & P frames that are large enough to maintain the quality then there should be no difference between it in terms of image quality and a GOP1 stream (maintaining the bit rate is what the AQ settings are for). However, yes, the vbr codec is going to discard shadow details first (even at GOP1).

Running a very high bitrate GOP1 kind of guarantees that your bitrate isn't going to drop substantially, meaning that your shadow detail is going to be as good as (if not better) than a comparable long GOP setting. This doesn't mean though that a longer GOP lower bitrate setting couldn't, or wouldn't have given you exactly the same image quality, and level of shadow detail. It does mean the motion in the scene however would look very different, more 'filmic' as people say here, which is understandable because the stream contains whole, singularly frames.

Edit : I've not seen anyone say that GOP1 gives better shadow detail, its wrong, the extraordinarily high bitrate probably is.

@driftwood Good to know thanks so much! I'm shooting GOP3 on the GH2 and I can notice motion difference. I only shot GOP1 with the GH1. I think I will switch to the GOP1 220M GH2 setting.

what iz these v frames? are they like two I frames leaned to either side and touching at the bottom?

StreamParser identifies frames as V frames when there is something wrong with a header and what type of video frame it is can't be identified by looking at transport stream header data.

Chris

@Vitaliy
There's no new Patches announcements yet?
Sorry for the offtopic.

Thank you Vitaliy

If you try GOP1 on 720p you get simply iframes. NO spurious P frame at the beginning. :-)

@cbrandin Chris, sorry to bug you again as I know you are still busy on other things. By trimming back reference frames ever so slightly (like the limiter does) roughly do you know apart from obvious quality issues if its still ok? If I can get average frames decent enough on a constant level I'm happy - this is leading to why: because I am trying to tame back 220M GOP1 which I love so much. It always fails after 3 seconds (about 65 frames) at current default Frame Limit settings resolving top quality pappas death chart. However, if I lower Frame limit to 5100000 for GOP1 I can get continuous recordings with no cadence. The streamparser looks constant - but I promise, it is doing its job. Here's my Frames before death (FBD test) table (hope it makes sense);-

Test run on a video buffer: 0x3600000, gop1, 220m, Aq1, tests to limit frames on pappas death chart.

This table shows the filename, the ptools Frame limit setting, the bits resolved before and after the removal of the frame, the buffer fullness at the time and the frame before death (it stopped recording):-

mts 8 7800000 f limit; 129 xxx xxx / 121 xxx xxx buffer fullness 84.6% fbd: 65
mts 12 7700000 f limit; 126 xxx xxx / 119 xxx xxx buffer fullness 83.3% fbd: 65
mts 14 7600000 f limit; 125 xxx xxx / 118 xxx xxx buffer fullness 82.4% fbd: 65
mts 17 7400000 f limit; 122 xxx xxx / 114 xxx xxx buffer fullness 80.2% fbd: 65
mts 19 7000000 f limit; 113 xxx xxx / 107 xxx xxx buffer fullness 75.9% fbd: 68
mts 22 6000000 f limit; 99 xxx xxx / 93 xxx xxx buffer fullness 65.0% fbd: 197
mts 27 5600000 f limit; 92 xxx xxx / 86 xxx xxx buffer fullness 60.6% fbd: 296
mts 29 5200000 f limit; 85 xxx xxx / 80 xxx xxx buffer fullness 56.3% fbd: 998
mts 31 5000000 f limit; 82 xxx xxx / 77 xxx xxx buffer fullness 52.1% fbd: hrd errors
mts 43 5100000 f limit; 83 xxx xxx / 78 xxx xxx buffer fullness 55% FBD: Great -no probs!

Sweet spot = 5100000 Frame Limit for 1080p24 at GOP1 220M.

Thanks.

@proaudio4 take a look at Chris's 44M/66M settings and you'll see theyve beeen tuned to 1.2 mulitplier or thereabouts.

Thanks drift.
understood.

OK, thanks Chris.

Hi guys, first time poster, long time lurker. Very impressed by the work being done here.

Does anyone have an "official" solution to the frames being out of order in the GOP1?
I LOVE driftwood's extreme GOP1 settings. Basically, it's everything I was hoping for out of the GH2 - apart from the spanning and in-camera playback issues.
But the frame order issue is really frustrating.
I don't mind the spanning or the not being able to play back in camera. I'm OK with that.
But I love how it looks.

So, I wanted to see if there was a way to fix the frame order issue.

I'd prefer having a one-stop transcode program like 5DtoRGB that could fix the frame order on the fly. But since that's not available, I figured I'd try it myself.
I found that the order is out by a fixed pattern. Every third frame is bumped forward 2 frames and the subsequent frames pushed back 1 frame each.
So, I wrote a PHP script that can fix the frame order in an image sequence.

If anyone wants to try it out, I'd love some feedback or better yet - improvements, until there's a viable solution for transcoding. I linked to everything on this sample clip I uploaded to vimeo slash 29237872 (don't know if I can post links, as this is my first post).

Thanks everyone, for your tireless work improving this little gem of a camera. I'm enjoying the fruits of your labor very much.

-T