Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
100Mbps Flow Motion v1.11 Failsafe Patch with HBR 25p & 50p modes
  • 574 Replies sorted by
  • I've uploaded new Flow Motion sample videos and frame grabs in the fourth post of this thread:

    http://www.personal-view.com./talks/discussion/2099/gh2-100mbps-flow-motion-patch-v1.0-with-50mbps-file-spanning/p1

  • Looking great @LPowell, especially the 24H.

    I'm curious, is Flow Motion at a disadvantage under very low light and underexposed any more than, say, cbrandin's 66 patch? Of course, I know that shooting under low light and underexpose stresses the codec more irrespective of the settings. But I'm wondering if Flow Motion actually is at any disadvantage in these situations? Of course, I'd never shoot anything on a real shoot in these conditions!

  • @qwerty Low light performance was exactly what I was examining with my 3-way Patch Test above. That was shot at 3-stops underexposed (ok, I'll identify it now - the middle clip was Flow Motion).

  • @Powell those sample videos look awesome. Thanks for your thorough work and your patience explaining questions... Al

  • ''it's now possible to configure the encoder for optimal P and B-frame image quality.''

    Lee, 720p and 1080i are still NOT sorted. Not on ANY patch at hi bitrate. Film a death chart on screen for more than 2 seconds (minimum really should be 30 seconds) or try a bush of death with a Panasonic 14-140 lens and this patch still fails. These are the minimum tests. Also your 24pH B frames are 'losing it' after 20 seconds.

    lpowell patch - flo mo - death chart.png
    1920 x 1224 - 667K
  • @LPowell Thanks for your hard work. 3-GOP for 1080p24 and 5-GOP for 720p60. Great!!! Looking forward to your next version after the new PTool.

  • Tweakers may try the following optimization to improve the quality and consistency of the predicted frames in Flow Motion:

    • Set 1080p encoder setting 1 to 2

    • Remove all of altered quantizer table assignments

    According to my theory, that should help. But I haven't tried it on Flow Motion.

  • @LPowell will you say that Flow Motion will produce smoother motion than quantum? @gh2hacked mentioned it and i think i see it too but i just need confirmation since i'm not sure..also why you recommend setting noise reduction to +2? i always though that increasing NR will reduce quality of details..

  • @gh2hacked Excuse me for the late answer: the first part was shot in Flowmotion, the second part in Quantum 100. On the Vimeo page I had different comments regarding fluidity of movement. I am trying to decide which one to use for my upcoming short, I hope the waiting for Quantum X will be short! :)

  • @driftwood Thanks for posting your test results. The oscillating GOP pattern occurs when you push the 24H encoder hard against the 100Mbps bitrate limit with extremely detailed, sharp-focus subject matter. What happens is that the encoder switches in and out of Fallback Mode, where its bitrate is briefly reduced by the use of coarse quantizer tables. Using the built-in quantizer tables, I was able to eliminate this syndrome for all but the most extreme cases. In fact, the biggest problem I had in filming my sample shots was finding interesting subject matter that would produce bitrates over 75Mbps!

    In upcoming versions of PTool, I'll be able to use customized quantizer tables to further improve Flow Motion performance under all conditions. Even after optimizing of the built-in quantizer tables, 720p and 1080i modes are still not quite as robust as I'd prefer.

  • We know why its happening :-) What lens did you use for your tests? Softer/faster manual lenses are much more comfortable with our patches. The truth is that most people have / like to use Panasonic lenses and a successful patch HAS to work with them. I have discarded countless 'amazing' patches to the recycle because they failed with them (and the extra pressure they put on the codec with using OIS, AFC/AFS, Etc mode, 80% mode, in combination etc...)

  • I ran my tests with the following lenses, in various combinations of f-stop, auto-focus and OIS modes. OIS really helps minimize the jitter of ETC mode, which can be quite jerky when shooting handheld without it.

    • Panasonic/Leica 25mm f1.4
    • Sigma 50mm f1.4
    • Panasonic/Leica 14-50mm f2.8-3.5 OIS
    • Panasonic 45-200mm f4-5.6 OIS
  • @LPowell: it's easy finding a subject that breaks 75mbps (even though it's not interesting). Put a torture chart on the screen and then give your lens zoom some work in and out.

  • @duartix Yes, I've probably shot well over 2000 test charts in the past couple of months. What surprised me was how challenging it was to find interesting real-life subject matter that would push the patch up to the 100Mbps limit (aside from my collection of killer bushes). Compared to other patches I've developed, Flow Motion doesn't seem to need as much bitrate to produce its results.

  • @Swiss_Boy I'd recommend trying out both patches (they're quite inexpensive, you know) and see which works best for your own needs. Both produce excellent results and evaluation of image quality is often a matter of subjective conviction.

    I don't recommend using in-camera noise reduction in GH2 full-sensor video modes. In ETC mode, however, I've found that using +2 NR can reduce video bitrate by up to 15% and make a modest improvement in the smoothness of the video image. Here's an example:

    Shot at ISO3200, 1/60 sec, with a Panasonic/Leica 25mm at f2.8. Gamma curve boosted in Premiere Pro CS5.5 to bring out the shadow noise

    Film Mode: Smooth -2 contrast, -2 sharpness, -1 saturation. For the first half of the clip, -2 noise reduction, for the second half, +2 noise reduction.

  • I downloaded the patch a couple of days ago, but hadn't had a chance to try it out. I talked my girlfriend into acting in a little dramatic scene with me so I could test the patch under normal, everyday circumstances with existing light.

    This was using the 24H settings. Some tripod, mostly handheld. Z96 LED for some fill. I'm very pleased with the original quality. The patch worked flawlessly and I was able to view all the clips on the camera while shooting. Excuse the poor acting, but we were in a hurry. Many thanks to Lpowell and Vitaly for making this all possible.

    Cheers,

    Tony

  • @tcarretti The cinematic quality is a real pleasure to watch and depth of the lighting is remarkable. Clean, concise, and compelling. Thank you for the credit!

  • @LPowell This patch really is a great balance between very high quality, economy of storage, and reliability.

    Thank you sir! Can't wait to see what you can come up with after Vitaly figures out 1.1.

  • @tcarretti Yeah, this patch in 25p and i will be quite happy. Your absolute right. The balance is just fine. Thanks to LPowell. Hope it will work with 1.1 then.

    And of cause, this kind of "test" i like much more then flowers, trees or "whatsinsidemyroom"-stuff. Well done!

  • hey @lpowell, I just wanted to say thanks for this patch. The motion rendering is fantastic and file sizes, while still large, are much more manageable than the various "intra" patches. It's also great to have all the GH2 modes working within one patch. I look forward to fine-tuning tweaks and v1.1!

  • @lpowell : Have you tested using just I/P instead of I/B? In most of the graphs I see posted here, the B-Frames seem a bit pricey, as pricey as P. Beware of B-Frames, in my timelapses tests they were ~2.5x bigger than P. @cbrandin 's new StreamParser now gives very detailed information about I/P/B frame size.

  • @duartix Since P-frames are not as flexible as B-frames, they tend to be less efficient. The reason that Flow Motion produces larger B-frames than other patches is because it uses much finer quantizer tables in order to match B-frame image quality to that of I-frames. That's one of the main factors that produces high frame-to-frame edge continuity in Flow Motion videos.

  • @Lpowell : I'm sure they are more flexible and are a boon when you are transmitting and need to drop frames, but they surely are bigger to support the more complex addressing schema to account for future/past frames - and I know that because I observed it in the very controlled test that are timelapses.

    In the end I wonder if they really make up for it in efficiency: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Features The reason I'm asking whether you tested P vs B is just because they visually don't look all that small and because IIUC you are still working on ways to get them even less quantized.

    Another thing we don't know is how much more computationally complex they are and whether their savings/complexity have a positive/negative effect on the battery. Don't get me wrong, I'm not advocating against them, I'm just curious on how pure I/B performs vs pure I/P.

  • I need to stop following this thread as it's making me impatient for the V1.1 PTool. :)

  • @tcarretti @bdegazio @SuperSet

    I'm just as eager as everyone else!