Real Video Sizes

[1%]

Since 4:2:2 is still off and could be shaky. A feature request gave me an idea.

Can we set 1080P (or others) mode to encode at actual LV buffer size and save all of the bits being wasted from resizing? I know JPcore is configured for specific modes but I think this is just for sensor area/line skip and quality. RequestH264 encode is called with a fixed size but has other parameters.

How do I hijack this function and replace 1920x1080 with real LV size while still passing the other parameters? Wouldn't crop 1700x1000 or whathaveyou be better at 100mbps than 1080P at the same?

[nanomad]

If i remember right the "encoder" tables for X/Y res are stored in rom. You can probably use the cache hacks to store that address into the data cache and then edit it with the real resolution.
I'm also quite sure it would cause an err70 but we may be able to bypass it using the usual tricks

[1%]

I just see it doing requestH264encode(1920,ar1,1080, arg2) or something like that. There is another table?

I found: 0xFF2F3F44 (aAJ_ptr_to_0x150E8_ResizeYuv_struct_0x00_to_0x88)

That may be for playback?

761F0:   aAJ_0x3174C_SetParameterResizeYuvForMovie


I like this but I have no access to it. I only have rom from x10000 and up. Gonna have to dump the rest.

[deleted.account]

I kind of thought that would be the intention with 4:2:2 anyway as mentioned on the silent pic thread, maybe better to resize in post, I've been looking at resizing methods with the 4:2:2 silent pic 1056x704 from T2i and Avisynth with ResampleHQ filter provides a heap of different algos, does it a 32bit precision and in linear light, also the Dither tools plugin has uses too.

Admittedly this was done on uncompressed 4:2:2 rather than h264 but maybe theres some milage in the resize after anyway apart from upping bitrate, perhaps decent 720P (after resize) at 60fps or higher frame rates at 1056x704 for T2i maybe?

[nanomad]

requestH264encode is weird, even on the 1100D it uses 1920x1080 

[nanomad]

I think I have good news, sort of.
On the 600D the X res of the image video file is configured at *(0x5724+0x30). I bet that 0x34 is actually the other resolution

[deleted.account]

And on a T2i the stream is actually 1088 in the MOV, not 1080. The decompressing codec or media player crops 8 rows off the bottom. VLC screenshot will give 1088 and show the bottom 8 is actual usable not so called black padding for mod16.

[1%]

I'll try changing them I guess and see what happens. Should see whats there in 720p/dzoom/"1080("

The 1088 is on my camera too but its all resized anyway.

Ok, from looking... the first size is indeed the horizontal rez. 0x5758  is unfortunately 0.  Now I'll try changing it.

Something sets it at recording start and changing it afterwards seems to be having no effect. At least trying it in crop mode with real values like 640/1280/etc. Where about was it set? I can try to nop it.

Tried invalid values.. no error 70. I think its only set at movie start. After that its ignored.


I found: Function str:MovieRecorder\MovRecState.c_dwWriteStart_dwStr at FF18F6F0
This the right place?

0x5724 is referenced as: aAJ_0x46C4_LVCDEV_0x00_to_0x44

[nanomad]

Alright, sorry for the delay but i wasn't at home
How-to:
Set video mode to HD or VGA
Place 0xFF1112A0  into instruction cache at boot
Replace it with a  MOV     R11, #whatever
Switch video mode to fullHD

In order to generate MOV R11,#whatever use ARMada http://www.g3gg0.de/wordpress/projects/armada

[1%]

I did this:

Code: [Select]

.code 32
.org 0xFF1112A0
.ens LITTLE_ENDIAN
.hex
MOV     R11, #500

Got this:

Code: [Select]


10

Endianess: LE - Little Endian

7DBFA0E3

Bytes: 0x04
BL's: 0

Ran this:

Code: [Select]

cache_fetch_line(0xFF1112A0, TYPE_ICACHE);
cache_fake(0xFF1112A0 , 0x7DBFA0E3, TYPE_ICACHE);

Got freeze in 1080P when recording starts. Is that address right?

[nanomad]

Yes the address is correct

One thing you can try is dumping the memory from 0x5724 to 0x5724+0xFF in two different video modes. At least we can try deciphering what's there

It could also be that the encoder has a fixed algorithm for the 3 video sizes (the canon code suggests that)

[1%]

I tried

MOV     R11, #6c0

06B0A0E3


Got 0 for 0x5754 while recording. However I don't know if the size is changed, the movie still comes out at 1080P.

Becomes 2 in crop mode.

tried on:

Code: [Select]

cache_fetch_line(0xFF1117D0, TYPE_ICACHE);
cache_fake(0xFF1112A0 , 0x691EA0E3, TYPE_ICACHE);

cache_fetch_line(0xFF1113C4, TYPE_ICACHE);
cache_fake(0xFF1112A0 , 0x691EA0E3, TYPE_ICACHE);

No dice.

[nanomad]

As i said, try dumping to file whatever is inside the memory region between 0x5724 and 0x5724+0xFF
At least we can figure out if that data is actually used by the encoder or not

[1%]

I need to dump to a real file: Working on that.

http://imgur.com/a/rCJbq

Here is 720P Mode - Not Recording

Code: [Select]

5724 0
5728 39A030C
572C 0
5730 0
5734 0
5738 F
573C 0
5740 0
5744 0
5748 0
574C 40908274
5750 0
5754 0
5758 0
575C 0
5760 0
5764 90903C
5768 9081A8
576C 0
5770 1
5774 0
5778 FF11162C
577C FF10DBE4
5780 0
5784 0
5788 0
578C 0
5790 0
5794 0
5798 73750
579C 0
57A0 0
57A4 1
57A8 91867C
57AC 3D0
57B0 91A490
57B4 80050008
57B8 80050010
57BC 80050005
57C0 8005000B
57C4 80030011
57C8 80050000
57CC 8005001C
57D0 8005000C
57D4 80050014
57D8 B000000
57DC 8005001B
57E0 80050029
57E4 3002E
57E8 80050027
57EC 80050033
57F0 80050013
57F4 80050002
57F8 80030042
57FC 80010004
5800 80040013
5804 30039
5808 0
580C 0
5810 0
5814 0
5818 0
581C 0
5820 0

While Recording:

Code: [Select]

5724 0
5728 39A030C
572C 9071E0
5730 1
5734 0
5738 3
573C 13E
5740 254E4
5744 0
5748 0
574C 40908274
5750 4A000090
5754 500
5758 0
575C 0
5760 0
5764 90903C
5768 9081A8
576C 0
5770 1
5774 FF18FB60
5778 FF11162C
577C FF10DBE4
5780 0
5784 0
5788 0
578C 0
5790 0
5794 0
5798 73750
579C 0
57A0 0
57A4 1
57A8 91867C
57AC 3D0
57B0 91A490
57B4 80050008
57B8 80050010
57BC 80050005
57C0 8005000B
57C4 80030011
57C8 80050000
57CC 8005001C
57D0 8005000C
57D4 80050014
57D8 B000000
57DC 8005001B
57E0 80050029
57E4 3002E
57E8 80050027
57EC 80050033
57F0 80050013
57F4 80050002
57F8 80030042
57FC 80010004
5800 80040013
5804 30039
5808 0
580C 0
5810 0
5814 0
5818 0
581C 0
5820 0

Is something getting cut off?

1080P I increased time to 100ms but I still get nothing from 5730 in the file

Code: [Select]

5724 0
5728 39A030C
572C 907200
5730 0
5734 0
5738 3
573C 7D
5740 411E8
5744 0
5748 0
574C 40908294
5750 4A000090
5754 780
5758 0
575C 0
5760 0
5764 90905C
5768 9081C8
576C 0
5770 1
5774 FF18FB60
5778 FF11162C
577C FF10DBE4
5780 0
5784 0
5788 0
578C 0
5790 0
5794 0
5798 73760
579C 0
57A0 0
57A4 1
57A8 91869C
57AC 3D0
57B0 91A4B0
57B4 80050008
57B8 80050010
57BC 80050005
57C0 8005000B
57C4 80030011
57C8 80050000
57CC 8005001C
57D0 8005000C
57D4 80050014
57D8 B000000
57DC 8005001B
57E0 80050029
57E4 3002E
57E8 80050027
57EC 80050033
57F0 80050013
57F4 80050002
57F8 80030042
57FC 80010004
5800 80040013
5804 30039
5808 0
580C 0
5810 0
5814 0
5818 0
581C 0
5820 0


Code: [Select]

Something wrong here?

char log_filename[100];
   
    int log_number = 0;
    for (log_number = 0; log_number < 100; log_number++)
    {
        snprintf(log_filename, sizeof(log_filename), CARD_DRIVE "ML/rr%02d.LOG", log_number);
        unsigned size;
        if( FIO_GetFileSize( log_filename, &size ) != 0 ) break;
        if (size == 0) break;
    }
   
    FILE* f = FIO_CreateFileEx(log_filename);

unsigned i;
for( i=0x0 ; i<0xff ; i+=0x4 )
{
const uint32_t *reg = (uint32_t*) (0x5724+i);
        my_fprintf(f, "%X %X\n", reg, *reg);
        msleep(100);
}
   
    FIO_CloseFile(f);


[Roman]

This would be freaken awesome.

When I learned that it goes from an 18mp sensor, scales it down to lower than 1080p then upscales it back again...
My mind = blown at how retarded that seems.

[Kenjee]

Well, upscale is the Canon`s easy way to reduce line-skipping aliasing. Some dev got tap on the back for that.

[1%]

It seems lazy but actually makes sense. Skip some lines out to get the 20mp sensor down to a manageable frame size. The upscale it to consumer friendly 1080P. They'll never know the difference.