Personal View site logo
AN "Valkyrie", GOLGOP3-13, GOP3ZILLA, natural, Freeze-less Reliable All-round GOP3 Settings :-)
  • 1001 Replies sorted by

    I got it. Since I love jazz, I was interested also in sound... :-)

  • @ishvar great footage!

  • @bkmcwd the sound was so awful from that recording,I just couldn't burden your ears with it..keep up the great work with your settings!


    OK. Since I wanted to also hear the comment of Pasadena_Pulse_Audio, please tell the following opportunity. Thanks! :-)

  • @bkmcwd I understand.

  • Do users of these various gop3 settings find native editing to be fast and responsive? If so, what platform? Thanks.

  • @jrd: I'm editing the video using kdenlive under Linux, and that works for me just as well and smooth as with any recording I took before I applied the hack.

  • @bkmcwd Thanks for your great work on your settings.

    @ishvar feel nice atomosphere. very sharp images for nature scene.

  • @eyesoul and @soru: Thanks for your kind comments! Live music videoshot (Tom Jones's "sexbomb" cover by friend/musician Peter Rip) with @bkmcwd's latest bkmcwd GOLGOP3-13_V4.3_BETA3 patch, 14-42mm X lens and the la7200 anamorphic lensadapter: (hd) (medium)

  • @soru

    I am looking forward to nice footage shot during holidays, mate. :-)


    Thanks again. The light extended horizontally is cool! :-)

  • @bkmcwd, Thanks for your new settings.

    I used "GOLGOP3-13_V4.14_BETA2" and shot at FSH, HBR and SH mode.

    Static scenes look very nice and good image quality. When using GOP9 720p60(SH), camera freezed once. FSH and HBR was no problem. (SANDISK Extreme Pro SDXC 64GB)

    *Bitrate around about 40-60Mbps

    *FSH not spanned, HBR spanned (very high detailed scene)

    Thanks for your hard work!

    1356 x 631 - 177K
    1280 x 720 - 228K
  • @har_k

    Many thanks for feedback always, mate! :-)

    "When using GOP9 720p60(SH), camera freezed once."

    OK, I will change the GOP table of 60p tomorrow.

  • I tried golgop3-13_v4.3_beta3 today.

    24H video looked very good, rate was between 80MBit/s and 90MBit/s. Spanning worked fine on a SanDisk Extreme Pro 64GB 95MB/s.

    720p60(SH) also looked good (rate was ~ 40MBit/s), but there was a glitch where 3 consecutive frames contained some garbage in the lower third of the screen.

    HBR was recording at a rate much lower than 24H - is that intenional? (I would imagine that since HBR is the only 1080p30 mode available, it could also benefit a lot from a bitrate >= 80MBit/s ?)

  • GOLGOP3-13 w/Sedna AQ1 IPB scaling and other custom GF2 settings. Some AAV ColorLab

    1920 x 1080 - 278K
    750 x 402 - 36K
  • @Ramses, you can put your modified pach for gf2 attached here

  • Hi. I tried GOLGOP3-13 SednaAQ1C v2.1 on 720p and made a slow motion footage.

    all movies have around 20~40Mbps. first, the water scenes have rather lower bitrates (around 22) and higher QP like over 30. then next, the highly detailed nature scenes or geometric floor scenes have rather higher bitrates(around 30) and middle QP(20-27). the most interesting for me is that if there is a human ,and however small the subject size is in the resolution, then the QP of the frames becomes lower even in highly detailed scene.

  • @soru Beautifull slo-mo material! Keepup the good work!

  • @karl

    Thanks for testing my setting and feedback! :-)

    "720p60(SH) also looked good (rate was ~ 40MBit/s), but there was a glitch where 3 consecutive frames contained some garbage in the lower third of the screen."

    Would you explain with a screen grab what kind of problem there was concretely?

    "HBR was recording at a rate much lower than 24H - is that intenional?"

    In 30p or 60i, it turns out that the bit rate goes up neither 25p nor 50i at least with 3GOP. Of course, naturally in this setting, the bit rate does not go up on a par with 24H.

    The reason for having set the pretext as 80M is stabilized if this value is made higher than the real bit rate.

  • @Ramses

    Thanks for testingmy setting in GF2! :-) Since I do not have GF2, I have not tried by myself. I would also like to look at the setting which you combined.

  • @soru

    Thanks always, mate! :-)

    60p is under improvement now in 9GOP. Please also try the following high version.

  • @bkmcwd: It's good that you asked, because now that I took a more detailed look at the 720p60 clip with the "glitch" I noticed that this glitch is not exhibited by every player software - VLC and kdenlive do not show it, while mplayer does. Mplayer emits the following message when it comes to the point of the video where the glitch is:

    [h264 @ 0xfd6920]cbp too large (57) at 73 34 [h264 @ 0xfd6920]error while decoding MB 73 34 [h264 @ 0xfd6920]concealing 856 DC, 856 AC, 856 MV errors

    ("cbp" here means "coded block pattern", as explained in e.g. )

    Since VLC and kdenlive under the hood use the same ffmpeg library that mplayer uses to decode the H.264 stream, I assume they just a more bug-tolerant parameter setting while using ffmpeg.

    The glitch is also visible when using hardware-accelerated decoding (using vdpau on a NVidia GFX hardware).

    1280 x 296 - 34K
  • @karl

    Thanks for detailed report! :-) I also often look at "glitch" in MediaPlayer, especially in HBR. In VLC, not seeing is also the same of you. If it is such a thing, it is not a problem of the setting itself?

  • Good question. I've taken a look into the source code of ffmpeg, and it seems that the maximum valid sizes for cbp do not depend on any encoding parameter, the limit is coded in the source, see:;a=blob;f=libavcodec/h264_cavlc.c;h=a4debade2e01cabc197171613a3379641179a2ab;hb=HEAD#l1060

    The comparison has been in there for almost a decade, the "cbp > 47" check was introduced into the code in 2003 here:;a=blob;f=libavcodec/h264.c;h=757400b3372243c3e0eeb23dae5d8317ca42c235;hb=0da71265d84b587c7159cd82708ca60ad050dd4c#l3511

    Alas, my knowledge of H.264 is not detailed enough to know whether this limit check is correct, but given the many regression tests ffmpeg has gone through, I would be surprised if this was a 10 year old bug in ffmpeg...

  • @karl

    Although I am not detailed at all about ffmpeg, I am very interesting. :-)

  • @ishvar

    Wow! Really great job. Amazing. very clean

This topic is closed.
← All Discussions
Start New Topic

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

Sign In Register as New User

Tags in Topic

Top Posters