Personal View site logo
Official Low GOP topic
  • 1003 Replies sorted by
  • +1 for frustrations with the frame reordering. I'm on an old Final Cut Studio Pro with out the L&T, so I need some external program that can handle this stuff properly.
  • @driftwood - I haven't seen the info about the pulldown removal in L&T - I'll give it a whirl.

    Script is linked from vimeo.com/29237872

    Thanks!
  • @temsi Glad you like GOP1. That annoying P frame in any GOP1 24p recording just screws things up and yes it does seem to need re-ordering. Have you checked the latest patch below on re-ordering? It looks so good when you import in fcp Log & Transfer (using Prores HQ) with pulldown removal checked and placed on a 24 timeline. Seems to work great though I havent checked this one for the reordering. Let me know.

    Update: I have noticed on my 720p experiments that there is no P frame placed at the beginning - I'm messing with Frame limits at the moment on 720p. No patch as of yet but will keep you posted.

    PS I would love to try out your script.
  • 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
  • *** 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
  • OK, thanks Chris.
  • 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.
  • Thanks drift.
    understood.
  • @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.
  • @proaudio4 take a look at Chris's 44M/66M settings and you'll see theyve beeen tuned to 1.2 mulitplier or thereabouts.
  • 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.
  • @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.
  • @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.
  • If you try GOP1 on 720p you get simply iframes. NO spurious P frame at the beginning. :-)
  • 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?
  • Thank you Vitaliy
  • >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.
  • @Vitaliy
    There's no new Patches announcements yet?
    Sorry for the offtopic.
  • I'll soon close this topic (upon reacing 1000 posts) to make new part.
  • 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
  • One I-frame then 1 P-frame then......a ton of V-frames?....what@!!!!
  • what iz these v frames? are they like two I frames leaned to either side and touching at the bottom?
  • Best GOP1 chart I ever saw!!! v frames :-)
    132 gop1 aq0 fb limit x 1 + 3rd.png
    1298 x 687 - 88K
  • @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.
  • 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.
This topic is closed.
← All Discussions