Messages

1% no I haven't been able to produce a "stream" yet. And yes other camera buffer size are bigger like the 5d2 1120x752. All I can say is grading a 24 bit depth video is way cleaner than a 8 bit
Edit; I get it now jpeg are RGB 8-bit+8-bit+8-bit = 24-bit
Edit 2; jpeg are Y (Subsamp 1x1), Cb (Subsamp 2x1), Cr (Subsamp 2x1) 4:2:2 not RGB

The h.264 are not even true Full HD there upsize. The live jpeg stream from the 500d is 928x616 looks as sharp as the h.264.

HA!!! I guess Alex is already working on this. From 500d stub FA_GetJpegBuffForLV jpeg stream address 0x42004070, FA_GetJpegSizeForLV size of buffer 0x41349. I guess will we be getting mpeg 422 pretty soon.

Hi, I'm trying to pin point exactly were the h264 encoder gets initialize but I can't seem to figure it out. There's initializeH264encoder @ 0xffc8288 in the 600d but that not what I'm looking for. I'm looking for something in the MovieRecoder task or in the MovWriter task. Anybody have any hints?
I've found some of the mjpeg decoding tables that can also be used as encoding tables bit_dc_luminance @ 0xff65c2a0, val_dc_chrominance @ 0xff65c2b0, bit_dc_chrominance @ 0xff65c2d0, bit_ac_luminance @ 0xff65c300, val_ac_luminance at 0xff65c310, bit_ac_chrominance @ 0xff65c3b2, val_ac_chrominance @ 0xff65c3c4, Huffman_something_fixed_table1 @ 0xff65c468, Huffman_something_fixed_table2 @ 0xff65c4c8, Huffman_something_fixed_table3 @ 0xff65c528, Qtable_something_ table1 @ 0xff65c588, Qtable_something_ table2 @ 0xff65c608, Qtable_something_ table3 @ 0xff65c688 and Qtable_something_ table4 @ 0xff3db970.

One more thing about the 1Dc, the heat issue. The 1Dc is the first true video based dslr. All dslr have heating issues but there main use are for still pictures. The 1Dc is marketed as a video camera and there doing there best to eliminate this issue. The 1Dx should be able to do anything the 1Dc can do, the only thing would be it would have the same heating issues as all the others dslr.
Now back to the topic. 1%, I notice the different encoder I also notice there is no mjpeg decoder.

Alex, your truly a mad doctor. Dr. Frankenstein would be proud. Your creating a true beast.

the 1DX and the 1Dc run on twin Digic 5+ and only the 1Dc can do 4K MJPEG or 1080P60, I guess the real challenge is to get the firmware of the 1Dc and to see what is the difference ... they have reworked the 1Dc for massive heat dissipation, witch lead me to think that maybe they also run the processor at a higher clock speed.

I honesty think that the 1Dx and 1Dc are more alike then anybody thinks. I don't think the 1Dc processor is any more faster then the 1Dx. If you look at the spec of both cameras there exactly the same the only difference is the clean HDMI and the 4k mode. I think the main difference is the firmware. That why the 1Dx is out and has a firmware update and the 1Dc is not out yet. My guess is there still tweaking the firmware. You may be able to dump the 1Dc firmware with a modded 1Dx updater. You may also want to decrypt the 1Dx updater and see if you can find any trace of a mjpeg encoder. I've seen some raw 4k mjpeg .mov samples files and I can say its not true 4k is more like 2k footage. But again this was a pre-production 1Dc. Maybe if you can get a picture taking with a 1Dc a model id number can be parse from it.

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.

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

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.

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.

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.

http://www.jongbel.com/?page_id=19 is trail software that give detail information about the NAL units includes slices I,P,B and there offsets and all the seq_parameter that are set including profile_idc and level_idc.
Correct me if I'm wrong but how I understand it is that the SPS "sequence parameter set" sets the Profile_idc and the Level_idc in the NAL units. Is this only use for decoding and not encoding? [JPCORE] H264_SPS_PPS may lead to some good hints. Also NSTUB(0xFF1C90B0, H264E_OperateNalUnit_fGetSpsPps) may also be a good place to look for some hints.

http://chdk.setepontos.com/index.php?topic=8550.msg89435;topicseen#new
Does anybody else have firmware 4.1.0?

My really wild guess
mvrSetGopOptSizeFULLHD (3833856, 3309568, 2785280, 2260992, 1736704)

In the 600d dump in function 0xFF42B29C just before it branches to SetEncodeH264Parameter there is a table for all the available resolution for the h264 encoder. 160, 120, 160, 120, 320, 240, 320, 240, 640, 480, 640, 480, 1024, 768, 1280, 720, 640, 480, 1024, 768, 1920, 1088. This table is the same for 50d, 5d2, 500d, 7d, 60d, 600d and 5d3.

Maybe you can find some usefull information by debuging. By calling NSTUB(0xFF28357C, lvdbg_enablelog) you get a .GRO file along with your movie file. I still don't know how to dissembler the .GRO file any ideas would help. I still haven't try lvdbg_printmember. I'm working with a 600d.

I don't think 422 is possible in baseline coding. If you trace back SetEncodeYuv422LosslessParam it goes back to TTJ RAW and TTJ MRAW, SetEncodeYuv420Losslessparam traces back to TTJ SRAW

GH2 encoder is software based Canon's is hardware based

Does any body know how [JPCORE] works? It has a lot of H.264 libary functions like JporecoreSliceqpd which is the Slice QP delta Quantization scale it range is -26 to 25. Also JpcorePicpyPicpcD which are the picture py an pc chroma QP offset for the loop-filter it range is -12 to 12. And then you have JpcoreDbfalphaDDbbetaD which is connected to Mvrsetdeblockingfilter the loop-filter alpha/beta table offset are -6 to 6. Making the deblocking filter stronger should improve the muddy shadows. Also MrvSetGopOptSizeFULLHD is set to 12 setting it to 1 should give you all I-frames no?

Can you get the shutter count by printing out ioGlobalStdset?

void MyGlobalStdSet ()
{ int f1 = -1;
   while (f1==-1) { f1=FIO_CreateFile("A:/STDOUT.TXT"); if
(f1==-1) SleepTask(100); } ioGlobalStdSet(1,f1);}

NSTUB (0xFFB4A358, ioGlobalStdSet);

I couldn't find firmware for HV20 or HV40. If there are firmwares the chdk digicdv2 decryptor should work on them. I'm still trying to figure out the structure of the firmwares.
Here's a link for the instruction reference for the m32r
 http://documentation.renesas.com/doc/products/mpumcu/e32rsm.pdf
And a m32r compiler
http://www.linux-m32r.org/eng/download.html

Digic DVII HV30 and HF100
Digic DVIII HFS21, XF305, XF105 and C300

All 6 camcorder firmwares are XOR encoded with a 0x1040 bytes block key.
All 6 camcorders use some sort of DRYOSV2 shell.
Camcorders XF305, XF105 and C300 use DRYOS version 2.3, release #0012.
Digic Dv processor are not arm architecture.
Good info can be found here
http://chdk.wikia.com/wiki/HF10/100_Firmware_Analysis
http://chdk.setepontos.com/index.php?topic=1641.0
http://www.hv20.com/showthread.php?20098-Official-Firmware-Hacking-Thread-(new)

A nice read, link posted at canon rumors
http://www.chipworks.com/en/technical-competitive-analysis/resources/recent-teardowns/2012/07/inside-the-canon-rebel-t4i-dslr/