Bit rate investigation

[1%]

Change gop size in "CBR" menu where you would go to change qscale/cbr ,etc. Slice doesn't work for you yet. I didn't prune the menus. All I is 1. That is the critical part. Make sure gop changes. Otherwise you'll just get buffer overruns as it tries to hold like 12+ frames in the buffer.

[unity2k]

On previous tests I had set GOP in the CBR menu to 3.

With your tip I set it to 1 with all encoder values at 3.0x. On the Pretec card I recorded 29 seconds at 104,813kbps with only about 15% buffer fill, mostly less. A second longer test of 46 seconds was 98,612kbps. Both videos are of leaves in a strong wind.

On the SanDisk I'm getting similar bitrates, but I also had a few Error 70's and the buffer was quickly moving up just before the crashes.

3 log files were created, here's a part of the first one:

Tue Sep 25 15:37:38 2012
  37965: 14643.497 [MR] 1 : W=0x4a9b7120, E=0xfa0340, W=0x4a079a50, E=0x536650
  37966: 14661.078 [MR] mvrExpStarted
  37968: 14663.853 [MR_MOV] AddVideo : (0x4a9b7120,0x81934,0x00000000,0x0,1)
  37969: 14663.914 [MR] mvrFrameWrite (Size = 0x81934, Next = 0x4aa38a54)
  37970: 14663.956 [MR] mvrEncodeDone (Size = 0x81934, Next = 0x4aa38a54)
  37976: 14675.570 [LV] PCLV JPEG SIZE (1056 704)
  37977: 14685.342 [MR] mvrEncode (Addr = 0x46000080)
  37978: 14685.418 [MR] 1 : W=0x4aa38a54, E=0xf1ea0c, W=0x4a079a50, E=0x536650
  37979: 14692.497 [MR] mvrWriteDone2 (Size = 0x102cb0, Next = 0x4a6b2d50)
  37981: 14692.650 [MR_MOV] RequestWrite : End(32)
  37982: 14692.756 [MR_MOV] RequestWrite : Start(33)
  37984: 14692.826 [MR_MOV] WriteSampleData : #1 - Buf=0x4a6b2d50, Size=0x103570
  37985: 14702.432 [MR] mvrExpStarted
  37987: 14705.981 [MR] mvrFrameWrite : Frame = 72, Pad1 = 8
  37988: 14706.056 [MR_MOV] AddVideo : (0x4aa38a54,0x76bec,0x00000000,0x0,1)
  37989: 14706.168 [MR] mvrFrameWrite (Size = 0x76be4, Next = 0x4aaaf640)
  37990: 14706.212 [MR] mvrEncodeDone (Size = 0x76be4, Next = 0x4aaaf640)
  37991: 14706.327 [MR] mvrEncodeDone (Sec = 3, Frame = 72)
  37993: 14706.451 [MR] mvrEncodeDone (Pack = 36, 0xb507f0, 0x22949d8 - 0x238cef0)
  37994: 14706.478 [MR] mvrGetBufferUsage : Frame=8, Sound=0
  38000: 14707.252 [MR] mvrDecideAndAddStorageCBR (0xb507f0)
  38004: 14708.728 [LV] PCLV JPEG SIZE (1056 704)
  38005: 14710.734 [LV] lvAEResult
  38006: 14710.820 [LV] Release FaceAEL and FaceALOLock 9385
  38010: 14718.370 [LV] PROP_LV_EMD_DRIVE_RESULT AfState:0
  38011: 14726.839 [MR] mvrEncode (Addr = 0x44000080)
  38012: 14726.915 [MR] 1 : W=0x4aaaf640, E=0xea7e20, W=0x4a079a50, E=0x639300
  38014: 14734.950 [LVFD] LVCPF_SortPrimaryFace( Input Num = 0 )
  38015: 14735.064 [LVFD] OutputFace( ID=593, (240, 165), Size=25, Num=0 )
  38016: 14744.147 [MR] mvrExpStarted
  38018: 14747.800 [MR_MOV] AddVideo : (0x4aaaf640,0x824e8,0x00000000,0x0,1)
  38019: 14747.861 [MR] mvrFrameWrite (Size = 0x824e8, Next = 0x4ab31b28)
  38020: 14747.905 [MR] mvrEncodeDone (Size = 0x824e8, Next = 0x4ab31b28)
  38024: 14752.328 [LVCAE] lvcaeGetAllWbGain(sync)(10)
  38025: 14752.633 [LV] ====== lvCompleteALOGetSeed [0x408cd840]
  38027: 14753.790 [LVCLR] Out = (0, -1, -1, 0, 0, -1, -1)[0]
  38030: 14759.003 [LV] PCLV JPEG SIZE (1056 704)
 

[1%]

Does the movie come out at gop3 though? or gop 1?

[unity2k]

How can I tell if it is GOP 1 or 3? The video's I recorded at 3 work fine as do the one's I set at GOP 1, or is there something I'm missing?

[1%]

Mediainfo will tell you N=1 or N=3 or N=12/15 that is gop. Also can count distance between I frames in bit rate viewer.

[unity2k]

N=1! 103Mbps 23.976fps

[JasonATL]

Andy600 - I don't see the problem that you indicated, so I'm guessing that it is the suspected card problem.

Here are my results (all at GOP=3):
The buffer save function has worked flawlessly in real conditions. I was able to overflow the buffer by using TV static and moving the camera to a blank wall and then quickly to the static at 60% warning. I could not overflow it at 50% warning. In short, the save function seems much more robust than before.

Here are two comparison shots.
Full: https://picasaweb.google.com/lh/photo/8AgT16svWHKXAOzcNPd8BxfNx8dP82C1K8bmBL14X3k?feat=directlink
Zoomed 300%: https://picasaweb.google.com/lh/photo/I38AfErPsBMBzwdyzCZJbBfNx8dP82C1K8bmBL14X3k?feat=directlink

On these images from left to right:
Left is when the bitrate (and QS) is high (wind wasn't blowing much). BR avg=160 Mbps; peak=250 Mbps Slice=87
Middle is when the bitrate was dropped (but after wind has calmed a bit). BR avg=90 Mbps; peak=129 Mbps Slice=127
Right is Canon FW: BR avg=40 Mbps; peak=155 Mbps
Note that Left and Middle are from the same clip, just at different points based on the bitrate.

To me, the Canon FW is clearly inferior at full resolution (I think it was reporting Q-01 or Q+00). I can barely make out the difference between the other two. The difference between the middle and left is apparent in the 300% zoom of the footage, but the middle is still superior to the Canon FW.

In playing the video, I still cannot tell by watching when the buffer save function kicks in or lets up.

An oddity: Slice nearly always goes to 126 or 127. I had it go to -127 a few times. Also, when changing slice, I only had it stop at something other than 126 or 127 on the way down. I wonder If it is always going to 127 anyway, then why not just jump it there in the first place? Also, could there be a user setting for the min slice (or max QS)? This might allow the user to set it to a level that is less likely to get to the overflow (and perhaps might make it more workable for slower cards?). Given the frame captures above, I'd wonder if I could tell the difference between slice=120 and slice=87? And, if slice=120 saved me from getting to 127, all the better? I'd bet that 190 Mbps I frames would be nearly indistinguishable from 250 Mbps, but I could be wrong. Edit: I take that back, I want 250 Mbps when I can get it .

[1%]

-128 is the next step down, took it out and it was too low. Now it only comes up till you get to 115mbps and that isn't necesarily slice 87.

You can see what slice is set for CBR mode if you set jp slice to 0 and reboot. Then turn on debug and start recording. After the first time it will start hacking cache if debug is set on so you have to reboot to see again. Doesn't change if you're just using CBR.

[KahL]

I know I'm a complete newb to this topic, but I've been reading off and on for the past few weeks.
How can I get a copy of this latest ML build to test out on my end? I'm really excited about the potential quality jump this has, especially for post work.

[1%]

Bins are in my repo. should be links throughout the thread.

[bart]

Great work!
Maybe an idea is to make a script that switches settings every half second and tries all settings at big value intervals. Then point it to windy leaves or water or high detailed landscapes like forests with wind. Publish resulting video and let people decide what looks best.

Also if you need a frontpage article just let me know.

[1%]

I'd hope to eventually get some of this stuff into ML tree with better coders getting on it. 550D gop changed so can implement some of the stuff into that too, just need FW locations. Andy's tests already show its better than CBR in terms of Q..  way worse for size.

[unity2k]

1% So my testing shows great bitrates for busy scenes, what I don't know how to do yet is get increased bitrates when filming more static shots. For example, filming a greenscreen shot with little action, the bitrate between regular fw and GOP3 are nearly identical. I understand this may just be efficiency of compression and uniformity of elements in the image, but the edge artifacts in busy shots using GOP3 are so clean, I would expect that I could get cleaner edges in non-busy shots too, but they are about the same.

I'll be the first to admit I may be a bit dense here and this is exactly what should be happening, but also think, maybe I'm missing something. Any advice?

[1%]

550D is missing the quality settings. With that you'll get higher BR. Right now you're mainly getting buffer benefits but CBR is still doing the Q setting.

Heh, before its all good to go, need to fix the audio sync issue. Then we have a 100mbps source w stereo audio and sync. Then see which cameras work this way and make the cache hacks for them.

[AriLG]

What is to be "lost" (feature wise in regard to bitrate control) with the 550D (comparing with the 600D) ?

[1%]

Control of slice, which is basically 1/2 of it.

[AriLG]

So that makes it camera specific ... 

[1%]

Pretty much and 550D build has asserts disabled so its not proper.

[Leon]

@ 1% :  What confuses me is the difference between Q-value (which I'm assuming is effectively the same thing as quantiser value in x264) and this new "slice" value, which doesn't seem to exist in x264, or at least not as a user-settable value.  Can you explain the difference and why both values exist?  Can you change one without changing the other?

If slice is like Q-value, could we establish a "safe" value for a certain GOP, e.g. by incrementing the slice quality value and record TV static noise until it can't cope reliably, then using a value that was safe?  Of course this wouldn't give you the "best" quality for low-complexity scenes (since you could have pushed slice harder then), but I'm guessing they'd still look better than the firmware default, and you'd still have "best" quality for high-complexity scenes, where you most need it.  It would also give you your upper limit (or lower limit, whichever way you look at it), which you should never want to go beyond.

(Personally, I'm ultimately hoping to see a feature where I can use something vaguely equivalent to Constant Rate Factor in x264, where very high bitrates are available for complex scenes, without overrunning the buffer, but lower bitrates can automatically be used for low-complexity scenes/frames.  Whilst super-high bitrates may be useful sometimes, I won't want to use them all the time.)

[Leon]

Also - sorry if I'm missing something - people seem to be comparing the new encoding to the original FW at CBR 1.0x, but would it not be much more appropriate to be comparing it to CBR 3.0x / 2.0x or whatever the card can manage?  (We already know that CBR 2.0x is better than CBR 1.0x.)  Can people see a difference between the new encoding and "normal" CBR 3.0x?

[JasonATL]

Also - sorry if I'm missing something - people seem to be comparing the new encoding to the original FW at CBR 1.0x, but would it not be much more appropriate to be comparing it to CBR 3.0x / 2.0x or whatever the card can manage?  (We already know that CBR 2.0x is better than CBR 1.0x.)  Can people see a difference between the new encoding and "normal" CBR 3.0x?

Leon - one problem with trying to compare CBR 3.0x with the new approach is that CBR 3.0x will fail/stop as soon as the picture becomes suitably complex - which is exactly when the high bitrate will have the most benefit. On a static (no motion), low light frame, I am confident that the new approach is at least as good as CBR 3.0x. I was never able to consistently record CBR 3.0x on a complex daylight shot. The highest reliable rate (with no sound) was around 2.3x or 2.4x for me.

So, for me, not only is this new bitrate approach getting superior picture quality - a subjective comparison to what I could get with 2.3x CBR, and objective compared to Canon FW - but, it is superior in that it is far more stable, allowing for its practical use. The video of the horse stables (link posted in a post of mine above) simply would not have been possible using CBR 3.0x and possibly not even stable at 2.3x. I shot that video without the camera/buffer ever failing in 3 hours of shooting.

Finally, I'll add that the highest average bitrate that I recall seeing with CBR 3.0x or 2.3x was around 95 Mbps. The video that I am shooting with 1%'s enhancement is averaging 120 Mbps consistently in shots that are a little complex. Indoors, I don't think it gets that high, unless you are at a very high ISO. My point is, the quality settings are driving the bitrate that high. They couldn't get that high with CBR, because it would fail.

[1%]

It goes Qscale (-16 to 16) - canon parameter then
Slice QP (several values at 1 qscale in CBR, usually 1 value at fixed qscale)
Frame QP (55-10) - depends on above. Slice from X-X is one step of QP.

Only the last one matches x264.

could we establish a "safe" value for a certain GOP

Unfortunately not really, complexity will always generate a different bit rate in different conditions. The only thing you can consistently measure is data rate/buffer. Sometimes you can push it all the way up and get 40mbps, sometimes you get down to the middle and its still 90 or 100. Also, Slice 87 is above Q-16 and rates still get higher despite Frame QP not going below 10. Its not 1:1 x264 or even H.264 spec. Picqpy/PC should technically go higher than it does and yet camera freezes if set that way. Seems like canon implemented what they could, how they could.

by incrementing the slice quality value and record TV static noise until it can't cope reliably

The problem here is that static barely gets by at low quality. Everything else will look terrible. The win with this was being able to lower quality to that point before a buffer overrun. Static is only good as a worst possible scenario.

.  Whilst super-high bitrates may be useful sometimes, I won't want to use them all the time.)

I have the same problem because the files get HUGE and fill up the card rather quickly. Kinda limits what you keep vs delete. The only other option is stock "CBR" or VBR.  If you leave debug off you can set slice to 0 and reboot. This will leave it using the X values and prediction.

Turning on debug will let you view what it does for 1 clip but then slice gets reset and next recording will have it overriden + cbr blocked. Leaving it off is just like stock ML except with higher picqpy/PC and settable deblocking filter. You can then play with the different X values and alter how it does prediction.

Also lengthening the gop increases the # of P frames which gives you more compression at the expense of keeping frames in the buffer longer and a little quality loss.

Constant Rate Factor in x264

Canon couldn't implement it and still can't. The best they did was a way more conservative version of this approach except based on frame prediction. I don't think their hardware encoder is capable of staying within X bit rate without just dumping quality till it calms down. 5DIII may be different but DigicIV doesn't seem to have CRF capability.

The profiles may be bullshit themselves too as we are super violating the baseline spec with all of these mods. The player can neither handle the higher bit rates or increased chroma/luma values... as seen by the undulating pixelated colors on playback. The higher profile on 5dIII may simply be an implementation of B frames and ability to set higher frame QP values.

Speaking of that, the only other real tweak would be to push that number past 10 but I think its set internally or by the Jpcore values which I haven't understood yet. I have seen Frame Q of 51 and its terrible, 10 is this good, 0 or 1 or 2 should be huge but perfect.

[Leon]

CBR 3.0x will fail/stop as soon as the picture becomes suitably complex

Sorry, I should have said: CBR 3.0x with GOP set at 3 or whatever GOP makes it most stable.  That would be interesting to compare, because it might not be significantly better than high CBR values with GOP, deblocking, etc, tweaked.

It goes Qscale (-16 to 16) - canon parameter then
Slice QP (several values at 1 qscale in CBR, usually 1 value at fixed qscale)
Frame QP (55-10) - depends on above. Slice from X-X is one step of QP.

So, are you saying you can adjust each of these three independently without changing the value of the other two?  I had been assuming that Qscale -16 to 16 was just part of the standard CQP 0-51 scale taken and rescaled to be over -16 to 16.  No?

0 or 1 or 2 should be huge but perfect.

lol, yeah, let's not go there.  You'd be way better off dumping raw 422 data by that point!

BTW, is A1ex's MJPEG any nearer public light?

[1%]

Mjpeg is getting there slowly.

They are all independent values but qscale sets -> sliceqpd and that determines the frame QP value. Might as well forget qscale as it can only be adjusted by 1 and is fairly limited. Direct control over frame QP would be nice or mapping slice values to frame qp. There are I think several slice values per 1 CQP, would have to test this more.

You'd be way better off dumping raw 422 data by that point!

Not feasable. any compression is good or would have been done. But I'm sure some scenes can handle values <10.

CBR 3.0x

Cbr doesn't mean anything, it just sets slice qp based on prediction, nothing else. It took 1 or 2 NOP'ed calls to neuter it completely. Slice 112 or 115 is something like Qscale -16/cbr 3.0x, etc.

Its not even that good at stopping the buffer overruns.

What I can do is make the buffer save customizeable so it stops raising quality at like X mbps and will drop 2, 3, and 4 slices at X values. Would help people with slower cards or if you want more compression/more dropping/less dropping, etc.

[1%]

New buffer save and bigger audio buffers.

https://bitbucket.org/OtherOnePercent/tragic-lantern/downloads/autoexec.bin.600D.NewBuff.BiggerAudBuffer