Messages

I havent forgotten this thread. I hope to have a MKIII in my hands v soon to test.

Together with testing out the new GH3 (love it!) I'm analysing 5dmkiii mov files to rip out SPS, etc... report back here soon.

Good work Marvin:

Can you experiment with the two patches ratecontrol= in ciombination with maxbitrate / minbitrate ?

Change ratecontrol value to =1 then =0 together with entering values into min/max bitrate.

I'm still looking for a value for cpb ncoded picture buffer/dpb. Maybe Maxbitrate is like GH2's Top settings (declared bitrate) and Minbitrate could be a reinterpret of 'Bottom' settings which we worked out to be the CPB size.

We need higher coded picture buffer settings for adjusting the bitrate higher - ie they work in unison.

Failing this, somewhere there must be something in the code that declares a cpb. We need to find it.

ok thanks

Not yet  - do you have my correct email? Link me. Itd be easier.

You can always upload to a file share site or use dropbox to share sample files.

[Level 5 mode:]

Yes, its Driftwood from GH2 settings, anyone gotta problem with that!?

Yeah, judging by baseline 66 work I did on the GX1 camera there's not much one can do with any of the canons prior to the 5DmkIII - sure you can get higher bitrates and change GOP but most baseline profiles are constrained. See constrain flags in the h264 SPS set.

So the 5Dmk3 has distinct possibilities: Gonna have to sell the other canons to buy one ;-)


Level 5 mode:

I would perhaps leave the initial QPs alone - anything lower than 16 causes problems. There is also minimum QP for each P_slice type at 10 - the GH3 has something similar I believe. Subsequently, in these recording modes a scaling matrix is not being used/implemented. As a whole Scalers work best at coding the luma frequencies better - ring artefacts etc... but Canon's encoder interp. probably deems them unneccesary. Are the recordings when analysed in SPS/PPS using QP_delta offsets like =0 (no change in QP from previous prediction) or other values (e.g.-4, -6, -8, -10) that indicate a change of QP?

QpOffsetForB = 0 For B frames no QP offset variation is being employed?


Transform8x8Flag = 2 probably means adaptive 8x8/4x4 transform on residuals - ie most of the picture is coded with 8x8 and some of the luma residuals are receiving 4x4. My 'hunch' is if it were =0 all luma residual samples are receiving 4x4 block transform, or =1 are luma samples are in residual 8x8 block transform. I would leave that alone if this was confirmed as the case. A quick check with stream analysis will confirm transform being used.

EntropyCodingMode = 0
You need to establish the order of the setting e.g. does = 0 mean cavlc, 1= cabac, 3= Exp Golomb vlc - one or the other. (therefore probably 0, 1 or 2 are the available settings)

RateControlEnable = 2 - needs experimenting (first with =0, then =1) Could be some sort of adaptive rate control schemes. Could be any of the following:-

=0 - Original quadratic rate control scheme based on JVT spec
=1 - Extension of quadratic scheme for all Intra and IBsBsBs... coding.
=2 - Basic extension of quadratic scheme to better support hierarchical codingstructures
=3 - Extension of quadratic scheme with slice type separation

-------
Level: 4.1 modes:

IntraPicInitQP = 28
InterPicInitQP = 28

I see no reason why these cant be improved (changed to =20 as a starting point )  with tests on added bitrate to correct rate control.

I really need the developer to find a patch in their firmware/ROM/RAM loadables for coded picture buffer (surely there's something in there?) as just adding bitrate requires more buffer bitrate (whats the ceiling?) In the GH2 ptools we have it as a 'bottom' setting, 'Top' setting being bitrate. Also anything regarding Frame buffers (and sizes), and frame size in bits?

Can someone load up a 5dmk3 PPS produced from elecard or any other h264 stream analysis software?
And can someone please email me a few small sized original .mov recordings from the mk3?

more to come...

Seems to be some good work going on here. Where are we at in terms of encoder patching? I could be of some help - haven't ML'd my 5DmkII , 7D or 60D yet but you never know...

The 5DMKII, 7D 60D are h264 Profile IDC baseline level 5 which isn't a brilliant starting point... but according to the spec allows a maximum video bitrate of 135,000. Max decoded picture buffer of 110,400 at 1920x1080. (Having said that, if you look at the h264 stream / PPS there could the usual baseline 66 constraints on these three cameras)

Have you found a way of raising the decoder picture buffer yet (dpb/cpb)? Youve got to stop the buffer underuns/overruns and tests need to be done on buffer analysis / stream analaysis software (like elecard or CodecVisa, etc...)

Have any Quantisation scaling matrices been found ? Are they being employed?

With the 5DMKIII being level 5.1 High profile (thats slightly higher than the new Pany GH3 you should be able to do something. You've got adaptive 8x8/4x4 transform, scaling tables, cabac or cavlc, in-loop deb locking etc...

Here's the stock bitrates of the GH3 in ALL-I 72Mbps .mov mode.

Bit Rate = 71680000 (69999 = bit_rate_value_minus1/SchedSelIdx/*0*...)
CPB Size (the coded picture buffer) = 64512000 (62999 = cpb_size_value_minus1(SchedSelIdx/*0*...)

Intitial QP=20/ QP=20...

Actually, someone email me a very small All-I file / dropbox me. [email protected]

Hmmm... need to get hold of a MKIII.