Bit rate investigation

Started by Audionut, July 19, 2012, 04:54:03 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Chucho

Quote from: simonrfenton on August 30, 2012, 02:38:09 PM
Is there a way to load in a RAW file off SDCARD into RAM, pass this through the encoder at various compression settings, then measure the resulting difference between these clips with the MSU tool? This would give a repeatable starting point.
If you look at the deleted files in your SD card you will notice a MVIxxxx.DAT file for every MVIxxxx.MOV file. The camera first writes this .DAT file before it adds the headers, tags and atoms, it then renames it to .MOV and delete the .DAT file. This code is somewhere at the end of the main firmware look for the .DAT and .MOV strings. This is the only time I've seen that the camera loads a file of the SD card for a movie fuction. I've never been able to recover the .DAT file from the SD card but it's always the same size as the .MOV file so it's after compression. I have been able to produce a MVIxxxx.DAT file by changing the values of a register C0F1xxxx something I can't remember the exact address. I'm  not sure if it's the same .DAT file as the compress .DAT. It was one of the Initialize H264 encode registers.

deleted.account.0

My logic is, as we can now do "low frame rate" h.264 movies, (like 1 FPS), then we don't need to work in Real Time.
So yes, we have say 25-30 YUV images on the SDCARD, then have a script to load them into VRAM, one by one.

I would imagine writing this 1 sec test .MOV may take a number of minutes to complete.

The test YUV files needn't be actual real life footage, it could be 1 sec of rendered 3D animation, with lots of detail to test the encoder performance.

Food for thought...

Chucho

I don't think you can feed YUV footage to the Canon encoder, as I understand it it goes like this,
JPEG path -> H264 encoder (NAL units, ect) MVIxxxx.DAT -> MOV wrapper (headers, tags, atoms) MVIxxxx.MOV.
You have to rewrite a lot of tasks just for a simple test.

1%

I dunno... looking at all this, do you think the bottleneck is at the encoder or the jpeg data being fed to it? We can record ridiculously high BR and yet visible quality is only a little different.

deleted.account.0

Perhaps the JPEG compressor needs to be adjusted before we'll see improved quality further down the chain...?

How about bypassing the middle man altogether & writing MJPEG .MOV files direct to SD Card? (like the older Canon Powershots used to do).
At low compression ratios, 3:1, the JPEG encoder still gives very good results, supports 4:2:2 colour space and is easier to edit - not to mention bypassing the double compression.

Uncompressed 8-bit YUV 1920x1080@25 FPS is around 103 MB/sec, MJPEG at 7:1 would give about 15MB/sec or 120 mbit/sec.

Leon

4:2:2 video would certainly be nice!

What about getting silent picture video to work properly?  Those .422 files would presumably make a good video?  The main problem when I tried it months ago was that the .422 files often are a mixture of frames (eg top third is one frame, bottom two thirds the next), and there isn't audio.  Perhaps they could somehow be dumped into a .MOV (or any other file), along with audio, even if you had to use a special program on the PC afterwards to convert it into something useable...

I'd also be interested in a 550D-compatible build.  Perhaps with sharpness -1 added in too?

1%

Better still... dump buffer that is fed to the JPeg encoder and bypass all of this. Its major work though, more than I know how to do. Although since we can hijack functions now its technically possible.

QuoteUncompressed 8-bit YUV 1920x1080@25 FPS is around 103 MB/sec, MJPEG at 7:1 would give about 15MB/sec or 120 mbit/s

2nd one my card could definitely do... but there is no MJPEG codec, it would have to be made from scratch.

Quote'd also be interested in a 550D-compatible build.

Before that happens need the stubs used for some of the functions in bitrate.c... I only have 600D firmware. I'd also need addresses for where to jump the invalid gop error. 550D also a bit weaker on processing power and no 64bit file size so no files over 4gb. 600D seems like a transition camera to t4i/5dIII.


QuoteJPEG path

Nanomad tried using different paths on T3, can the path be switched so compressor is getting larger files than 1920x1080? I know it can resize because of zoom mode, etc. With less frames in the buffer I think it can handle bigger ones. Canon was really stuck on that long gop encoding.

ass5001

Sandisk Extreme Pro 95MB/s
yes it's the best choice for 2x.

deleted.account.0

Quote from: 1% on August 31, 2012, 02:14:17 AM
Better still... dump buffer that is fed to the JPeg encoder and bypass all of this. Its major work though, more than I know how to do. Although since we can hijack functions now its technically possible.

2nd one my card could definitely do... but there is no MJPEG codec, it would have to be made from scratch.

How about just a series of Jpeg images written to SDCard? (avoiding the need to create an MJPEG codec from scratch)
Perhaps a new Folder is created for each "Record", it's a simple matter to convert image sequences to .MOV files - plus would also get around the 4GB file size limit of FAT on older camera's.

1%

Or raw stream of what comes out before its converted into H.264. The dat file is just the uncontainerized H264 stream.

Audionut

Bypassing the jpeg engine and all it's processing would be the way to go.

I don't see how it would be possible to capture the raw data.  You would never be able to record the data fast enough.

Chucho

In a earlier post I wrote about a register that dumped a MVIxxxx.DAT file. I found the register again it's C0F113C4 it's a Boolean register. Start recording after a couple of seconds, 10 or 20 change the the 1 value and it dumps a MVIxxxx.DAT to the memory card. I opened the .DAT file in a hex editor and searched for SPS 0x0000000167, PPS 0x0000000168, I-frames 0x0000000165 and P-frames 0x0000000161, I didn't find any.

Chucho

Or maybe it just stop recording before it deletes the DAT file from the card

g3gg0

hmm 1%, you uploaded a MVI_2369.MOV, remember?
it has one I every 4 frames, QP is about 10
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

deleted.account

I'm not a dev but interested in the flow path and state of the data at entry into the h264 encoder.

Is the .422 data (silent pics) considered the state of the feed for the h264 encoder? I've never bothered with them are they really compressed or just subsampled to 4:2:2?

1%

Does QP ever go above ~10? I've been looking and it seems to go lower but not higher.

QuoteI opened the .DAT file in a hex editor and searched for SPS 0x0000000167, PPS 0x0000000168, I-frames 0x0000000165 and P-frames 0x0000000161, I didn't find any.

The one time I got a dat file was when camera crashed while recording and it didn't get deleted. I could still play it in VLC it was just a raw TS file. I think it happened when we first went over the 4GB.

ilguercio

Let me get this straight, none of the things tried so far delivered a better image quality?
Canon EOS 6D, 60D, 50D.
Sigma 70-200 EX OS HSM, Sigma 70-200 Apo EX HSM, Samyang 14 2.8, Samyang 35 1.4, Samyang 85 1.4.
Proud supporter of Magic Lantern.

1%

Better than what you'd get without it. But its not enough. You can compress the same input as nicely as possible but you still have the same input.

I cap out at ~250-260Mbps with the static... qp slice is still -10. I'll try to up it, I think its at 0x6ce0 right by deblocking filter. It goes like 0 to 1xx (at -16 qscale). We'll see what happens.

Chucho

Quote from: 1% on August 31, 2012, 05:21:07 PM
Does QP ever go above ~10? I've been looking and it seems to go lower but not higher.

The one time I got a dat file was when camera crashed while recording and it didn't get deleted. I could still play it in VLC it was just a raw TS file. I think it happened when we first went over the 4GB.

TS like in MPEG2 file? I'm going to try to run a DAT file in a MPEG-2 analyser to see if I can get any information.

ilguercio

I'm sticking with CBR 1.0x as mov files are already huge and i don't want to burden my old laptop with excess weight of my files.
It looks like the solution isn't so easy and it's a shame given the fact that we could have so much better footage from our cameras.
Thanks for the effort, by the way :)
Canon EOS 6D, 60D, 50D.
Sigma 70-200 EX OS HSM, Sigma 70-200 Apo EX HSM, Samyang 14 2.8, Samyang 35 1.4, Samyang 85 1.4.
Proud supporter of Magic Lantern.

1%

QuoteTS like in MPEG2 file? I'm going to try to run a DAT file in a MPEG-2 analyser to see if I can get any information.

No like transport stream... mpeg2 ts is different, h.264 ts (or is it es?) is different. It is raw h.264 without the . mov container.

QuoteI'm sticking with CBR 1.0x

CBR 1.0x is actually compressing your footage. There is a difference between 40 and ~90 MBps. You give up too soon, as we're starting to figure out the encoder. That CBR just modifies the data rate parameters, you're actually getting Q+ (which i seen as high as Q+24) values to maintain. Watch what it does.

I recorded static @ 5000 iso and it fails right away at q-16... requests BR over 250. Need to find a way to keep quantizer but hard cap bit rate so it doesn't overrun hw buffer in encoder. We also haven't even started to try to increase frame size.

I recorded a few videos with QP parameter modified... there is crashing and all that but I got a few that overran the buffer right away and hopefully have increased qp slice values.

*Update...

I was having trouble so I set qscale to -17 and slice QP goes down to expected values and MVR records. I had to disable all assertions but I'm sure I can find the place where its checked and just NOP it.

ilguercio

So what should i do then, use 2.7x (it's my maximum setting with my 50D) for some reason?
Canon EOS 6D, 60D, 50D.
Sigma 70-200 EX OS HSM, Sigma 70-200 Apo EX HSM, Samyang 14 2.8, Samyang 35 1.4, Samyang 85 1.4.
Proud supporter of Magic Lantern.

1%

2x or setting qscale to something - is probably good.

Set slice to fixed value. CBR function can change qscale but it no longer alters the slice (0x6ce0) while recording. Not sure if its showing up in the files yet.

Leon

Are the .422 files uncompressed 4:2:2 YUV (which is 16 bits per pixel, I think)?  It's just that they should be 4.15MB each if that's the case...

Quote from: simonrfenton on August 31, 2012, 01:43:57 AM
Uncompressed 8-bit YUV 1920x1080@25 FPS is around 103 MB/sec, MJPEG at 7:1 would give about 15MB/sec or 120 mbit/sec.

For 4:2:0 chroma subsampling, there are 12 bits per pixel.  That would give a bitrate of 1920*1080*25*12 = 622 Mbps, or 78 MB/s.

JPEG compression ratios are based on size before chroma subsampling, so for 15MB/s you'd need a compression ratio of 10:1, which would be quite feasible, and of course much less compression could be used.

1%

Need to take a silent pic and check.

Here are today's results:

600D Slice locked to max(qp=10)/min(qp=2)? for CBR

https://bitbucket.org/OtherOnePercent/tragic-lantern/downloads/AE_SliceMin.bin

https://bitbucket.org/OtherOnePercent/tragic-lantern/downloads/AE_SliceMax.bin

*Set slice from menu, VBR fixed, sound with audio off and high bitrate. Deblocking filter works for ALL frames:

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