AN "Valkyrie", GOLGOP3-13, GOP3ZILLA, natural, Freeze-less Reliable All-round GOP3 Settings :-)

bkmcwd

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

EYESOUL

@ishvar great footage!

EYESOUL

@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!

bkmcwd

@EYESOUL

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

EYESOUL

@bkmcwd I understand.

jrd

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

karl

@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.

soru

@bkmcwd Thanks for your great work on your settings.

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

ishvar

@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: http://exposureroom.com/aca7a43a95b241079d7e0a0f5780e277/lr (hd)

http://exposureroom.com/aca7a43a95b241079d7e0a0f5780e277/ (medium)

bkmcwd

@soru

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

@ishvar

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

har_k

@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!

bkmcwd

@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.

karl

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 ?)

Ramses

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

maxmizer

@Ramses, you can put your modified pach for gf2 attached here

soru

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.

ishvar

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

bkmcwd

@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.

bkmcwd

@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.

bkmcwd

@soru

Thanks always, mate! :-)

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

karl

@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. https://docs.google.com/viewer?a=v&q=cache:yf_vIxYGiRgJ:www.cc.ntut.edu.tw/~shyang/Journal%2520Papers/H.264%2520Fast%2520Inter-Mode%2520Selection%2520Based%2520on%2520Coded%2520Block%2520Patterns%2520_final_.pdf+h.264+cbp&hl=de&gl=de&pid=bl&srcid=ADGEESil4BsBzTs_LZocsq2gJXFiAXbqzLgY6QMsInTp4ScLH1TZgDVJo2HXHzrKnyBwVVzl2_up6pb1Zfnq-lGAK8Fj3R5861FR6H82LtsR4mgUgUJ-0RY5wP7TwxVL4Wa9kFe8-Yo2&sig=AHIEtbS6ib2kncHptoXXuWxIUoEyajcX2Q )

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).

bkmcwd

@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?

karl

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:

http://git.videolan.org/?p=ffmpeg.git;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:

http://git.videolan.org/?p=ffmpeg.git;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...

bkmcwd

@karl

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

proaudio4

@ishvar

Wow! Really great job. Amazing. very clean

Howdy, Stranger!

Categories

Tags in Topic

Top Posters