Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Official Low GOP topic
  • 1003 Replies sorted by
  • @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?
  • Question:

    What's the theoretical reason of every frame being an I-Frame gives better shadow quality?

    Is it because the B-P frame compressor decides to discard shadow detail, for some perceptual reason?
  • @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.
  • You cant do GOP1 without a high bitrate on the gh2 - whether you do it with the simple equation of bitrate to buffer ratios or manually tuned - you'll still eventually arrive at a similar bitrate - the vbr codec is just doing the calculations - its job! GOP1 won't be stable, and even 220M wont give you complete stability in very high detail (ie high shutter/hi iso/trees of death/pappas, etc...). However, there's been tremendous results f rom it in darker shots and, where detail is not as important as that motion effect of GOP1! :-) I get less (hardly anyhting really) in terms of macroblocking in the shadows with GOP1 but I do when I use a lower bitrate / GOP for the same shot.

    Its a setting you can use now and again - for those effectual shots.
  • @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.
  • Best GOP1 chart I ever saw!!! v frames :-)
    132 gop1 aq0 fb limit x 1 + 3rd.png
    1298 x 687 - 88K
  • what iz these v frames? are they like two I frames leaned to either side and touching at the bottom?
  • One I-frame then 1 P-frame then......a ton of V-frames?....what@!!!!
  • 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
  • I'll soon close this topic (upon reacing 1000 posts) to make new part.
  • @Vitaliy
    There's no new Patches announcements yet?
    Sorry for the offtopic.
  • >There's no new Patches announcements yet?

    I am working slowly on this.
    I made few patches for specific things, but all of them need refinement and testing.
  • Thank you Vitaliy
  • it goes to v frames when you start toying with the frame limits.

    I have found that you shouldnt do mulitipliers on the frame limits. The only way to lift the limits is in very small increments in byte sizes. For example if you go 1.3 x the fb limit you get the v frames. THe frame limits as found by Panny for the defaults are very close to nice stability. However, if you change the video buffer you will notice you can say go upto 5% increase in bit size to the existing frame limit to increase the reference frames. Alternatively, if you want safety on a setting (ie limit the errors on high shutter etc...) you can limit the reference frame by SUBTRACTING very slightly so if they go over, it wont fail. The streamparser chart may look flatter on the graph (but still high i frames) however the vbr codec still appears to be doing its job - you'll just lose a little detail. Therefore when subtracting only go in small subtractions of bit size off the current defrault setting until you resolve perfect recordings without errors according to whatever you set in bitrate, video buffer and AQ.

    So for anyone testing, keep things simple. Keep FB buffers unchecked / hitoplowtops etc unchecked and test with just bitrate, video buffer, gop, aq, and the 3 frame limits.

    Example: I was trying GOP1 at 220M and just raised the default frame limit to just over the 8000000 mark (i think the default was summit like 78xxxxxx or summit - Im on a Mac at moment so I cant check) and I reached higher i frames with no v frames. If I lifted it to 8200000+ it gave me v frames and obvious buffer errors. :-)

    Hope this helps. Chris @cbrandin can you confirm this?
  • If you try GOP1 on 720p you get simply iframes. NO spurious P frame at the beginning. :-)
  • @driftwood

    It looks like the muxer in the codec just goes crazy with those parameters - it looks like there was simply an overrun. On the frame limit issue I think you are correct - there is no need for a bitrate based multiplier. I've been playing with a 1.2x multiplier (for all settings) and that seems to work.
  • @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.
  • Chris, I'm sorry I'm missing the point here, but could you elaborate on "1.2x multiplier (for all settings)"?

    I'd like to find a setting for 88M AQ3 and also 88M AQ2 for comparison.
  • @proaudio4 take a look at Chris's 44M/66M settings and you'll see theyve beeen tuned to 1.2 mulitplier or thereabouts.
  • @cbrandin Yes. You are indeed correct. When looking at the buffer analysis there are buffer underruns and overruns throughout if you take the frame limit OVER the default too much.
  • Thanks drift.
    understood.
  • Well, actually in those settings they are more. Lately, I've been simply multiplying frame (FB2) buffer limits 1.24x. I've never seen a frame go over 1.180MB with 24H, no matter what you set frame buffers to. The default limit is slightly below 1MB.
  • OK, thanks Chris.
  • *** NEW *** GOP1 220M AQ1 Reference frames on a limiter! This is to get long recordings at decent quality using short GOP 1. This is a particularly nice patch for motion recording and it still retains good detail. You'll get 1min 10 secs recording per 1 Gb using this setting. Try it out and let me know - I'm looking to see how well it copes with high details like trees etc under motion conditions.

    This was tested under duress using high shutters/high isos galore on the death chart.

    Note: Look how rock steady the buffer is on Pappas Death Chart!!! (we have to use high bitrates sorry!) Don't worry about the constant graph on streamparser - thats on purpose - the average frames is great. Check the quality of your recordings. Its taken an age to get to this setting but hopefully people will choose to try it for motion recordings. I think its pretty impressive on my limited testing so far.

    Please note: Before you try, this will not work on ANY other buffer setting but 0x36000000. You won't get a higher setting on GOP1 than this as anything over 220M refuses to even record. Anything lower is pants.
    Note: Before you ask, I tried this at AQ2 with marginal improvements but recordings will die at around 1 minute if you leave your camera trained on a static shot. :-)
    Driftwood GOP1 AQ1 220M Hi Quality Limiter For Motion - setc.zip
    470B
    GOP1 AQ1 220M Rock Steady Constant Quality Recording with a Frame limiter of 5100000 - Streamparser on Death Chart.png
    1295 x 682 - 85K
    GOP1 AQ1 220M Rock Steady Constant Quality Recording - Buffer Analysis elecard.png
    1681 x 686 - 66K
  • 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
This topic is closed.
← All Discussions