Personal View site logo
Official Low GOP topic, series 2
  • 1022 Replies sorted by
  • What are people experiencing with record times on 16 / 32 gig cards under the 176M patch?
  • @Stray
    @proaudio4

    Good morning! Since I live in the other side of the earth. :-)
    Since many comments were got, please point out, if there is a point from which it has escaped in my comment.

    @Stray, I appreciate that you did the wonderful test first of all.
    I will be glad if you take to 3GOP taking advantage of this.
    In order to keep the bit rate from falling at the time of lowlight, I have adopted AQ3, as you understand.

    About Iframe size, probably, I enlarged to a slight degree, if you did not make a new crazy test chart.
    In fact, in the test of Pappas, even if large to a slight degree, it had cleared.
    If you can do it larger, I want you to change by all means.
    Although I am also trying hard, I cannot clear extream stress test easily. :-(

    After opening a patch to 1 page of this thread, of course, I continued testing AQ2.
    Although frame size was able to be enlarged a little, I give priority to frame size not falling at the time of lowlight, and am making it AQ3.
    Should it be used properly by personal liking about these AQs?

    @proaudio4, I appreciate to having evaluated my patch and testing after this.

    I also made 88M3GOP,AQ3 of the practical level.
    Although Pappas test was also cleared, since a new Stray's chart test is unclearable, 66M is used reluctantly.
    I also hope to realize 88M3GOP,AQ3.

    As follow to the information from Chris, I have looked for the sweet spot, after understanding it in advance.
    However, if I say honestly, I think that this patch will not pass your extream stress test, although an error cannot come out in practical setup.
    In fact, my friend is using this patch at work satisfactorily, and I have not felt dissatisfaction, either.
    Since I do not know to give how much stress tolerance to these settings well, in order to understand this standard, I am looking forward to the result of your test.

    And I am looking forward to the direction as a result of a lowlight test rather than the stress test.
    Because therefore I chose AQ3... :-)

    P.S:Please point out, if there is a strange place of my English.
  • @driftwood

    Thanks for good info!
    I try instantly! :-)
  • @driftwood you are great, you're the savior of the GH2, hahaha:)
    accept all respect from me.
  • driftwood!

    LOL... You've gotta act for comming up with good names!
    First there was smoothasfuck now we have QuantMeBaby!
  • @bkmcwd,

    Thanks.
    I will test your settings tomorrow. Yes, I agree on your choice for AQ3.
  • @driftwood

    When using "Encoder setting 1 1080i/p=2" instantly now, it was set to Pframe instead of Bframe.
    Since this is interesting, I would like to improve a few.
    I always appreciate your wonderful hint!
    66_50M3GOPAQ3FBx3.6FLx1.0TBx8.8VB2.8es1=2_24H.JPG
    1295 x 634 - 192K
  • Wow... WTF, looks cool though! LOL
  • @bkmcwd cool man, may I share your settings to us all?
  • @bkmcwd The patch is breaking the maximum bitrate on any shot with a reasonable amount of detail, so it is pretty unusable as something very odd is then happening to the framerate. Take a high detail shot, record what the shot length was, then look at the frame count. The frame count is off (wrong) from what it should be, and by a lot too in some cases. Now I do have some shots that are fine, shots with low detail that didn't break the bitrate limit. So maybe shooting in lowlight and with low detail you may get away with it, but it's way too unpredictable.

    What is very interesting about this patch is it does not exhibit the cadence problem when it breaks the bitrate limit, but sort of skips frames, changes its frame rate, it does something odd anyroad. This has led me to an epiphany about just what the hell we're doing here. Well, that and the last several hours of tweaking settings too.

    We set a bitrate, then behind the scenes a number of other parameters are being set, and we do have some of these parameters available to us in the testers section so we can override them. But I don't know if we have access to all of the parameters, or functional adaptations resulting from a bitrate change. For me, to use a data analysis saying, 'All the numbers aren't on the table' ;). As in we don't know enough, but I think we do probably know enough to say now that the balancing act required to get a GOP3 at a bitrate below 132Mbps is probably never going to happen. That could be a limitation of this ptool version, or it could be something we can never overcome. Dunno.

    This is not a simple matter of change a parameter, and then see a direct correlation to the change within the result ('all the numbers...' etc). It could be that some of the relationships are non-linear, they are definitely adaptive. Soo.. think about what we know, setting the frame limit most definitely puts a clamp on the frame sizes. Setting AQ affects the quantizer values it uses (the range of them) this affects (to put it horribly simply) how much compression is done, thereby affecting the encoded frame size. How does the frame limit affect its compression strategy in relation to the AQ you've set ? Does it know that its going to have to switch to a lower QP from its range to fit a frame within the limit, and does it do so effectively and elegantly ? As in, does it choose a 'best' QP from the basis of the frame limit against what is in the available range of QPs given by the AQ setting ? Is that even possible ? I don't have the answers to any of that. Now add to that the fact that while we're tweaking FB1 + FB2 we are either shrinking or extending its range of QPs, its available compression strategies. Then we have the top/bottom settings which IIRC (although I may have missed a change in the theory) also effect the possible max frame size in someway (though I don't think we have a good explanation of their function to go on on here yet). What your patch has shown is that it is possible just by changing these parameters to create a stream that breaks the maximum bitrate we've set. This is serious shit if you think about it. Changing parameters such as lowering the frame limit does not solve the problem, as there are other things, adaptive changes that happen which cause other problems (cadence) and in the case of your patch don't actually lower the frame size. Soo.. thats likely down to the larger top/bottom settings you've set. Turning them off incidentally just causes cadence problems instead, but the frame rate is right at least. Also, upping the maximum bitrate to cope with the larger bitrates the patch is generating doesn't solve the problem either, as other adaptive changes get made that throw something else out of whack.

    I'm not saying that its impossible to build a GOP3 at lower bitrates, just that it is going to involve a hellish amount of very, very small tweaking. Maybe it all goes back to what @vitaliy said many weeks ago, that this codec is built for GOP12 and more changes need to be made for it to be possible to effectively lower the GOP. It is logical that a lower GOP means a higher bitrate as you'll have more I-Frames, it needs more headspace. Driftwood has created low GOPs that seem to be quite stable. To do this he has clamped the frame size quite a bit. This is because I-frames are the largest frames, and a stream of just I-frames is going to eat your bitrate, therefore the I-Frames are going to have to be smaller than they would be in a longer GOP setting. Also because of the headspace he's had to give it in terms of the max bitrate, you can under certain conditions make it break when it actually tries to hit that max bitrate. If it was possible to create a GOP3 at 66M or 88M I feel the frame size would have to be so low, and/or the QPs so limited and high, as to make it not worth it in terms of image quality. So, I'm personally jumping off the low GOP train for a while. Heh, got to let the full horror of my realisation, and the tests I've done in these small hours sink in properly. @vitaliy @cbrandin If I'm completely wrong in any of this please correct me.

  • @bkmcwd. yes, forgot to say changing the encoder setting causes P-Frames, changing it to either 1 or 2 does that. Oh yeah and cadence gets really odd too.

    Edit : To put it all simply, as far as I can see: Long GOP or shorter GOP its the same amount of data being used/stored/generated differently. The parameters that control this used/stored/generated are all entwined in strange ways that can dramatically effect stability. The effects seem way unpredictable to me at Low GOPS cos I can't personally work out the missing numbers/functions.
  • @proaudio4
    @MbhuyKo
    Thanks!
    Since I am improving now, if I can do it, of course, I will share.
  • @bkmcwd I think (guess really) that not taking a max variation approach is going to be the best bet. Limit what its compression options are, and drop the top/bottom settings in favour of using the 24p framelimit. Force the codec down a limited path. I think you'll have more of a chance of finding a stable path at a low bitrate that way, if there is one.
  • @chenopup Im getting 4 1/2 mins on my 8gb Extreme
  • @Stray
    I always appreciate that you explain very carefully.
    Your explanation is always consulted very much for me.
    In order for me to understand correctly what you have described, there is also a problem of language, and time is taken, but most can still be understood.
    I also understand generally the relation of each parameters which you have described.

    After understanding them, since the useful extream setting which I aim at is realized using "outlaw" approach, I have challenged.
    It is because driftwood, Chris, and you show the wonderful result as the mainstream.

    Regarding the top/bottom settings, I tryed repeatedly so that might be low, but unless it is as large as this in case of this setting, it is not stabilized at the time of high stress...

    Of course, I think that I will look for good setting from now on.
    Thank you always. :-)
  • Stray..
    Wow, thanks for your post.

    I hear you regarding bitrates under 88Mb/s with shorter GOP leading to smaller i-frames. Hmm....
    So in that range (88M), maybe GOP6 could be maximized.

    But, it sounds like you're off low GOP.

    Have you been able to stabilize 88M AQ3 GOP12? Either standard or max variation for buffer settings?

    I have not tried your 88M AQ2 GOP12 (MAX VAR) with your new extreme dense chart. I bet is passes.
    If we could get an AQ3 version, this would make a great comparision. I know bkmcwd has been working on the GOP3 AQ3, but as you know is having issues with the average exceeding the max bitrate.
  • i try "QuantMeBaby"

    sometimes stopped at 7 seconds and then I change it to record 2 seconds FSH returned to 24H and then record again to record all back to normal again.

    *test image is an image having to stop recording and normal test is a stable

    you are experiencing the same with me?
    TES.JPG
    1301 x 686 - 164K
    tes normal.JPG
    1298 x 686 - 175K
  • @proaudio4
    @MbhuyKo
    I stick what was converted simply once.
    However, I do not know whether this is worthy.
    Since it is Q=18, naturally at the time of lowlight, frame size becomes small.
    So, I like 3GOP AQ3 stuck previously.
    66_50M3GOPQ18FBx3.6FLx1.0TBx8.8VB2.8es1=1_24H.JPG
    1296 x 633 - 183K
    sete.zip
    564B
  • @bkmcwd I believe that B-Frames are preferable to P-Frames, they compress more data being bidirectional (using data from the next as well as the previous frame), P-frames can only use data from the previous frame. For efficiency, so you have more bitrate available for the I-Frames, it would be better to have B-Frames back and that rogue P-Frame. Also its still breaking the bitrate according to that graph. so the frame rate is going to go slightly off.

    @proaudio4 I've thought of a couple more things to try so I'll give low GOP a couple more shots in a bit, but I'm not holding out hope of getting good image quality and stability. IIRC the GOP12 88Mbps ran okay at AQ3, but I'll go back to it in a bit. I have a nagging doubt that it has the same problems as this patch regarding bitrate.
  • @Stray
    Thanks for your advice.
    Since I am also the same idea as you fundamentally, I am not going to advance this setting full of P frames any more.

    Although I was still adjusted 3GOP AQ3 this way and that, if preparing it as a theory, I cannot make it surely stabilized...
    Although there is a place where my 3GOP AQ3 is strange, the recording itself is very stable and there is no problem.
    What should do what with where ...
  • @driftwood 176M GOP 1 Intra with Slight QP .
    Panasonic 14-140, f-11,shutter-200 , ISO 160.
    100% view frame grab at important stream points.
    streamparser.JPG
    1336 x 672 - 166K
    15 frame.jpg
    1920 x 1080 - 390K
    120 frame.jpg
    1920 x 1080 - 337K
    318 frame.jpg
    1920 x 1080 - 263K
    454 frame.JPG
    1920 x 1080 - 141K
    522 frame.jpg
    1920 x 1080 - 396K
  • @bkmcwd I'm not sure at the moment, Thinking more about it, it isn't breaking the bitrate by much, so it could be okay. Even Chris's stable patches can go up to 1 or 2M over the max and seem to be fine.
  • Just for information. This patch is not usable.

    I'm working with a 66M AQ2 GOP3 setting at the moment, I accidentally created a patch with an FB2 thats very large. Anyway the graphs are interesting I think, in that it takes a long time to settle down, but when it does it looks perfect, (too perfect, frighteningly low size B-frames for even a static shot). Untill... something odd happened later on, and no the camera wasn't nudged. Playback of that later section looks like a small ripple effect accross the lines.

    Edit : sorry uploaded the wrong patch, the actual patch was the same but the FB2 was 3936092.
    66M AQ2 GOP3 large FB2 start .png
    1297 x 683 - 504K
    66M AQ2 GOP3 large FB2 end.png
    1297 x 683 - 475K
    seta.zip
    394B
  • @Stray
    I also tried instantly.
    If many hours are spent in my "outlaw" approach, although it may be stabilized... I'm not sure.
    When I can take time, I also tamper with many things based on this for study.
    If a model answer comes out, please let me know!
    stray's3gop.JPG
    1302 x 639 - 187K
  • @bkmcwd "If a model answer comes out, please let me know! " Don't worry I will if I find it, its a shame that its patchy. I think it might be worth restarting with a 66M GOP3 with an AQ of 0 just to try and get a stable GOP3 at that bit rate using only framelimit and top/bottom. Don't lift top/bottom much higher than 3x (if at all) as that has a strong effect on the bitrate. Also I'd say fix the FB1 (x1) and FB2 (x3) and not alter them until there is a stable AQ0 version (if there isn't then we're wasting our time entirely I think, haha, I should have tried that first) . Have you seen how low the framelimit is on Driftwoods 176M intra ? Its an idea but probably no need to go that low. Then I guess bring up the AQ in stages and alter the FB2 down maybe, and the frame limit. I don't think its worth altering the top/bottom to get stability as it just ramps the bitrate right up along with frame size.

    I can't do anymore today, but will have another stab at it all tomorrow.
This topic is closed.
← All Discussions