7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)

[feureau]

They are however making pretty good strides in MJPEG, looks like the 7D can take 1056x704 4:2:2 JPEGs from the buffer and record them to the card without needing to be connected to the EOS Utility through USB

That's such a weird resolution... the 4:2:2 part is great though. I wonder if there'd be a way to record raw like this. There's a lot of buffer space for SRAW on the 7D.

[g3gg0]

updated my previous post, forgot to add the link...

[P337]

here is another experimental build.

i set GOP to 4 and enabled VBR/CBR selection.

Awesome, thanks g3gg0!

So in this build everything is GOP=4 even at low bitrates?

Thanks again, checking it out now

[P337]

So, I may not be using this right yet but I unfortunately do not see a difference in bitrate with CBR vs VBR(FW default) :/

I got a scene giving me about 40-46Mbps under FW default and CBR 1.0x, I tried the same scene all the way up to CBR 10.0x but they all still read the same 40-46Mbps range (using "display bitrate", haven't analyzed the clips yet).  I'm assuming CBR should keep the bitrate at its maximum even with low detail scenes, like CBR 1.0x = 48Mbps and CBR 2.0x = 96Mbps, if that's not the case then maybe it's working as intended and I just don't understand what it's supposed to do.

Just tried the scene again with different exposure settings to give me 22-29Mbps and got the same results (every CBR setting was still only giving 22-29Mbps).

This may be unrelated and I assume just a display bug but every now and again when I first start recording the Bitrate display will start in the 700Mbps or 500Mbps range for the first frame then just drop straight down to the 20Mbps or 40Mbps range.  Once, when scaling up the CBR quickly to CBR 10.0x, it started at 528Mbps then my camera immediately rebooted itself and ML had to be reinstalled, it didn't record anything but everything still works fine and when I tried again it recorded fine and started in the 22-29Mbps range.

[1%]

What you're experiencing is normal. Sometimes the first rate is all crazy, it isn't real.

As for no difference between cbr 10x and 20x or whatever... some scenes just encode to X rate even at 100% quality from the camera.

Tip: Go outside... indoors it doesn't get so high (not enough complexity/light), except in crop mode which 7D doesn't have.

You shouldn't have to use CBR only, set qscale to max (do you guys have that yet?) and then camera records at fixed quality. All frames will be QP10.

There is no such thing as real CBR on canon anyways. Its all VBR just with constraints via quality/qp H264 parameters. You're not directly controlling the rate, you're just telling the camera "even if frame size is *friggin huge* pick a high QP for the next frame.

[P337]

oooh, 422 (M)JPEG  and 422 Uncompressed seems to work though ;-D

I enabled Jpeg A: and recorded 24 jpgs per second for one minute on my card (some dropped frames though).

also tried 422 A: but haven't counted the frames yet, I assume they're the same.

Jpgs are 98KB-623KB each (assumed 5:1 compression of 4:2:2) and .422s are 1.5MB each (1:1 uncompressed 422!)

[P337]

Thanks 1%

As for no difference between cbr 10x and 20x or whatever... some scenes just encode to X rate even at 100% quality from the camera.

Does that mean a static scene may just ignore "CBR" settings and base it off the first frame's complexity?

Tip: Go outside... indoors it doesn't get so high (not enough complexity/light), except in crop mode which 7D doesn't have.

Well I don't have a problem maxing out the bitrate indoors, by underexposing with ISO set to 128000, which get my card's full 160Mbps but it's too noisy so I'm trying to get that max bitrate with proper exposure.

You shouldn't have to use CBR only, set qscale to max (do you guys have that yet?) and then camera records at fixed quality. All frames will be QP10.

We just got Qscale, its default to -8 but says "very risky" so I won't play with it until I better understand what it's doing.  All I know is -16 = highest quality and 16 = lowest quality.  Since I don't see -26 on the scale I assume it's relatively safe but I'm still not sure what to look out for.  Recording stopping? Overheating?

[1%]

Recording stopping. Can't be any worse than CBR, it sets a Qscale of -16 too.

Its compressing a YUV scene to H.264. The more data in the YUV the higher the bit rate at X quality. So ISO 80 might not generate a lot of data but if CBR is higher it will compress it at QP 10. After that no magic way to increase bit rate.

[P337]

Is Qscale 10 the same as QP 10?

[mimiloveyou]

How do I use MJpeg 422 ?

Thank's.

[1%]

No, Qscale -16 is 10 I think.

They're continuous silent pics so press and release the shutter in jpeg or 422.

[P337]

Been playing with Canon's bitrates and I think I understand it better now.

"VBR (Qscale) mode" in 7D seems to be used kinda like constant bitrates or rather "limited range bitrates".  For example, recording the same scene with the same exposure settings on Qscale(+16) recorded at 1-2Mbps, (+15) was 1-3Mbps, (+14) 2-3Mbps, (+13) 2-4Mbps and all the way up to 42-76Mbps for Qscale(+16).  It's like limiting the entire VBR spectrum to a smaller range, then Qscale sets that range high, low or somewhere in between. The range gets wider with higher quality settings (lower number) but the important thing is that it brings the lowest possible bitrate up.

"CBR mode" I assumed takes the bitrate "range" that is set by Qscale then multiplies it by a number of your choice (2.0x, 3.0x, etc.).  CBR mode also tries to automatically set the highest Qscale it can (which is -16) but if your card or buffer is too slow is starts to scale it back, I got Qscale(-16 to -10) in CBR mode with a FlushRate of 4 but a constant Qscale(-16) with a FlushRate of 2.  But what I still didn't understand is why are my bitrates in "VBR mode" with Qscale(-16) the same as "CBR mode" with Qscale(-16) set to 20.0x? 

I've recorded with this card at an avg 160Mbps so I know it's not a hardware limitation. 
So does "CBR mode" not multiply Qscale, does it just increase the selected Qscale's range upward?
Is most of that right so far?  Thanks for everyone's work and help here

[P337]

How do I use MJpeg 422 ?

Thank's.

Right now it's in the "Debug" Menu called "LV Dumping". 
Scroll to it and press the "set button"; there are 7 choices: "Disabled", "A:/.JPEG", "B:/.JPEG", "A:/.422", "B:/.422", "A:/.JPEG/.422" and "B:/.JPEG/.422"

The second you select one it starts saving (note the red "busy" LED) your LiveView buffer as .jpgs or .422(or both).  The choices with "A:" saves them to your card, I'm not sure where "B:" is but I heard that maybe for dual card cameras.

Once you plug the card into your computer you'll find all the jpgs or 422 files in your DCIM folder.  Then you need to make them into an mov file, like a timelapse.

[akshayverma1]

I was getting higher bitrates with the previous port. But with the new port's CBR there's very few artifacts. Noise reduction works so well VBR with Qscale -16 is almost as good as CBR at 20x. Can CBR be pushed to more than 20x? Also, which is better, jpeg or 422?

[P337]

I was getting higher bitrates with the previous port. But with the new port's CBR there's very few artifacts. Noise reduction works so well VBR with Qscale -16 is almost as good as CBR at 20x. Can CBR be pushed to more than 20x? Also, which is better, jpeg or 422?

I think the last build was All-I, which pushed bitrates higher but also needs a lot to avoid compression artifacts; if your card isn't fast enough you're likely to get compression artifacts.  What bitrates were you getting and what's your card benchmarking at?

.422 seems to be uncompressed 4:2:2 frames while the jpegs are 4:2:2 compressed.

My jpeg files were 98-623KB, which are 15:1 to 2.5:1 compression ratios of the 1.5MB .422 files.  Those compression ratios are JPEG's "Highest" and "High" Quality compression standards, so they should be clean from compression and motion artifacts ;-D  Which only leaves line skipping and an 8bit color depth to worry about right? 

They're good clean quality, except they are only 1056x704 so they need resizing to 1290x720(about 25% increase) or 1920x1080(almost 3x larger) so clear overlay HDMI out with external recorder will still have better quality but that requires having an external recorder :/

[Shizuka]

Those compression ratios are JPEG's "Highest" and "High" Quality compression standards, so they should be clean from compression and motion artifacts ;-D  Which only leaves line skipping and an 8bit color depth to worry about right? 

Hardly, you will see more blocking from jpeg compared to h264, as jpeg lacks in-loop deblocking. You will likely see more motion artifacts from jpeg as it does no sort of motion compensation. It would be better if the h264 engine could be used in place of jpeg, but it's probably impossible due to the h264 encoder's fixed input sizes.

[mimiloveyou]

 I can not read a .422

[feureau]

Apparently audio recording works now if you set the flush rate to 24 (any other settings would just err70 as usual).

Great work, G3gg0! As always! Thanks for this update!

Looking forward when we can set this to All-I.

Speaking of audio recording, has anyone managed to record audio with Qscale at -16 or CBR factor 20.0x? All my cards crapped out at QScale-14 or -15 and CBR 16.0x-18.0x. Wondering which card can shoot max quality.

[mimiloveyou]

 YES. YES. YES !!!!!!

 Me Too.

"Great work, G3gg0! As always! Thanks for this update!"

 Thank's P337 for explanations.

[P337]

Hardly, you will see more blocking from jpeg compared to h264, as jpeg lacks in-loop deblocking. You will likely see more motion artifacts from jpeg as it does no sort of motion compensation. It would be better if the h264 engine could be used in place of jpeg, but it's probably impossible due to the h264 encoder's fixed input sizes.

aww are you sure it's that bad?  Either way this is the best JPEG could offer so I'm happy for that and if that's still not good enough there's also a full 422 option
 
I may have miss-termed "motion artifacts", what I meant was prediction errors as these are all full frames like an intra codec.
 

[P337]

I can not read a .422

Use gimp with the plugin
http://registry.gimp.org/node/27589

[Shizuka]

aww are you sure it's that bad?  Either way this is the best JPEG could offer so I'm happy for that and if that's still not good enough there's also a full 422 option
 
I may have miss-termed "motion artifacts", what I meant was prediction errors as these are all full frames like an intra codec.
 

Not sure what kind of prediction errors you are talking about. Predicted frames ("P frames") can also encode stationary information as intra blocks if motion can't be detected, ie. noise. Given the same amount of bits to work with, it's better to give the encoder the flexibility of choosing what's moved and what's stationary. Motion predicted blocks aren't [as] vulnerable to blocking artifacts (or the evil counterpart, deblocking) since they don't necessarily lie on block boundaries.

All-I is really meant for ease of editing (ie. seeking and splitting). You don't require an intermediate file for frame-exact splits with All-I files.

[g3gg0]

oh the .422/JPEG output was not intended in this experimental release.
consider it as an accident and do not rely on it.
it's also no MJPEG as someone called it. MJPEG is a lot more work than this hack.

about VBR/CBR
as far as i understand of what ive seen, the basic parameter is QScale. (maybe i'm wrong)
in vbr mode, QScale is constant and the output rate differs depending on scene complexity (=VBR)

if CBR mode is selected, there is a controller that varies QScale depending on current bitrate.
so the bitrate will be held at a constant average level.

QP = 26 - QScale
QP: the one displayed on screen when recording. its a codec output value (10 ... 42)
QScale: codec input parameter configured in ML menu (-16 ... +16)

[Shizuka]

Is there any reason that 422 JPEG recording makes sense?

Let's look at Canon's 1056x704 live view:
This resolution is acquired at the sensor by line skipping: every five rows are read from a sensor area of 5202x3465 (3:2).
The resulting 5202x693 RAW is demosaiced and rescaled to 1056x704 4:2:2 for live view.
A 5202x693 bayer sensor has a chroma resolution of 2601x396.
The final resolution is the minimum of every step above: 1056x693 luma resolution, and 528x396 chroma resolution. Vertical chroma resolution is limited by bayer line skipping.

5202x693 RAW Bayer -> 5202x693 Y / 2601x396 UV [assuming 2x2 superpixel required for chroma determination]
1056x704 422 YUV -> 1056x704 Y / 528x704 UV

We can also look at the 1728x792 recording live view:
This resolution is acquired at the sensor by line skipping: every three rows are read from a sensor area of 5202x2925 (16:9).
The resulting image, 5202x975, is demosaiced and rescaled to 1728x792.
A 5202x975 bayer sensor has a chroma resolution of 2601x487.
The final resolution is the minimum of every step above: 1728x792 luma resolution, and 864x487 chroma resolution. Again, line skipping limits our vertical chroma resolution.

5202x975 RAW Bayer -> 5202x975 Y / 2601x487 UV [assuming 2x2 superpixel required for chroma determination]
1728x792 422 YUV -> 1728x792 Y / 864x792 UV

If the video was saved as a 1728x792 4:2:0 H.264 video, we would actually lose vertical chroma resolution. But Canon upscales this to 1920x1080 before encoding it:
A 1920x1080 4:2:0 video frame contains a 1920x1080 Y (luma) and 960x540 UV (chroma) planes.

The final resolution available is 1728x792 Y / 864x487 UV, noticing that these values fit comfortably within the resolution limits in 1920x1080 4:2:0 video. Canon's 1080p is large enough to capture all of the detail in 1920x1080 4:2:0 as provided in the 1728x792 4:2:2 (since there are only ~480 real lines of color information).

[g3gg0]

to explain myself the way how the encoding works and what i am tuning, i made some screenshots.

consider this as source image that has to be encoded:
http://upload.g3gg0.de/pub_files/ec9400781e1b25f5ff9df7cde66b96a7/mpeg_frame_1.PNG

we are inspecting an I-frame now
the first step the encoder does, is finding some parameters that synthesize to something like this:
http://upload.g3gg0.de/pub_files/e4e39b57861be9c2558f171d845da599/mpeg_frame_2.PNG
it is a approximation of the image content, repesented with as few values as possible.

now there is still some work to do. the encoder calculates a delta between the synthesized image and the real one.
this is the remainder data:
http://upload.g3gg0.de/pub_files/5cbb6df0f2ee6bd96587df4f42288bfd/mpeg_frame_3.PNG
now this data is encoded too using some other algorithms and the frame is done.


now the next frame - its a P-Frame.
http://upload.g3gg0.de/pub_files/82e3692945b698a7ef30d1335bc3e868/mpeg_frame_5.PNG
the green blocks are predicted - they are just blindly copied from the frame before.
without any modification in the first step.
the red blocks are the intra-blocks, they are synthesized as all blocks in an I-Frame.
the resulting image is now a mix of copied portions from the previous frame and synthesized blocks.

if we now look at the remainder, there is a lot less data that is waiting for encoding again:
http://upload.g3gg0.de/pub_files/6c788470be9e8b8587b6817fc329d861/mpeg_frame_4.PNG
(compare that to frame 3)

thats the reason why I-frames eat so much bandwith without huge improvements.