(M)JPEG encoder

[Chucho]

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.

[ilguercio]

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.

[1%]

Here is hoping... 2k at 4:2:2 with no line skip. I doubt data rate can support much more.

[ilguercio]

Here is hoping... 2k at 4:2:2 with no line skip. I doubt data rate can support much more.

All of this at once? Wow.

[1%]

4:2:2 already being thrown away. 2k is just next size up. If the frames can compress < card rate should be possible. Will probably need to be zoomed to not have line skip. It was probably the only way to fit 20MP sensor in <3MP video.

[Chucho]

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.

[1%]

Aren't the other cameras a little bit bigger, I saw sizes like 1600 something from logs of 5d2. Either way, it is what it is. 928x616 can become 1920x1080 easier on a PC than in camera.

Can you already dump stream from 500D? Would like to try...

[deleted.account]

T2i / 550d is 1056x704 when not recording, when recording movie silent pic is 1700xwhatever but quality is not as sharp, looks uprezzed, comparing 4:2:2 1056x704 to MOV shows MOV is soft too but that's no secret I guess, silent pic is not exactly new.

Agree would be interesting to get stream unuprezzed and do it on the PC after.

[3pointedit]

Will a bicubic upscale in PC improve upon Camera aliasing? Or just soften the aliasing?

[1%]

In photo LV, my silent pics are 2k. In Movie mode they are only 1056x704.. while recording 1680x945. Should find a way to see if they are all the same pic uprezzed. Otherwise movie mode needs to not be in movie mode. Also just saw a 1728x972, not sure where that one came from... maybe dzoom/crop?

[deleted.account]

ha ha that's what my thinking was looking at the uprezz in video mode, if silent pics are bigger in photo mode, then phot mode could be the new video mode. :-)

Wonder what fps can be sustained with .422's even at Simple in movie mode and why so many variations in rez?

[a1ex]

Please find here the silent pic sizes: http://bitbucket.org/hudson/magic-lantern/src/tip/src/vram.c#cl-261

[nanomad]

This reminds me that I actually have to fix the silent pic sizes....

[ilguercio]

Why silent pics have these stupid sizes? I don't understand what could be the motivation behind this.

[1%]

Crop mode in video is almost HD.

Funny thing is, I got several 2k pic in photo mode somehow today and now I can't reproduce... wtf happened. It was simple silent pics. I thought it was normal and I deleted them but from that file its not.

I am trying to run recovery on the card to get them back and upload here.

Success! It was converted with 422 to png but recovery pegs them as jpeg for some reason.
http://www.qfpost.com/file/d?g=oaiFA61Xu

Don't laugh at my messy studio

*still can't reproduce... but saw the possibilities of whats working and it looks better than video we get now by far.

[Chucho]

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

[3pointedit]

A good test would be with noisy high ISO footage. Be interesting to see what effect grading such poor pictures would be.

[1%]

I think 600D crop size is the biggest and closest to HD out of all of them. Next to 5DIII of course which is completely different.

So there is an MJPEG decoder in camera already? For the image player?

FF2F10D8:   'PlayBack\\MjpegDecRotatePath.c'

[Chucho]

FA_GetJpegBuffForLV seems to be null in the 600d, going to start dumping VRAM and look for the magic jpeg numbers FF D8 FF. 5d3 has the same problem but with the 5d3 you still can make a movie with uncompress YUV 422 files with the right CF card, SD cards are not fast enough:(

[1%]

Hopefully its somewhere.

FF0A1F80    FA_LvJpegCheck

These were null?:

2       ; *'FA_GetJpegSizeForLV'   
FF56DB6C:   ff1115e8       ; 0xff1115e8: pointer to 0xe51f01f4   
FF56DB70:   ff72d496       ; *'FA_GetJpegBufForLV'   
FF56DB74:   ff1115dc       ; 0xff1115dc: pointer to 0xe51f01e8

I read from those registers and get "deadbeaf" .... assholes!

I dumped ram (~268mb) and found FF D8 FF in serveral spots. How do you dump vram?


From looking at 40D thread... maybe LV jpeg as to be started? Esp on newer cameras.

NSTUB(0xFF0A161C, str:lv_save_raw_lv_af_raw_lv_start)

has lv_save_raw + lv_start

FA_StartLvTestImage

Has:
FA_StartLvTestImage+20:   'lv_save_raw'
FA_StartLvTestImage+32:   'lv_af_raw'
FA_StartLvTestImage+40:   'lv_old_start'

from log in the other thread are these stream addresses?

574C 40908294
5750 4A000090

Also:

FA_LvJpegCheck+36:   call('lv_no_flicker', *(arg0), 'FA_LvJpegCheck %d')


Another thought..... Maybe the unknown path/mode from http://magiclantern.wikia.com/wiki/Register_Map is the unused LV jpeg?

[a1ex]

The 600D looks similar to 5D3 and 60D... where MJPEG doesn't work at all

If it's somewhere, it has to be in EDMAC registers.

[1%]

Has anyone tried setting the registers to the unused path(s) and then reading that jpeg register?

The flicker was mentioned in the check jpeg function.

0x10 - Flicker

Also this:

0xC0F0501C [32] WREDMAC16 (would be WREDMAC7, but that seems unused)

  0xC0F05020 [32] RDEDMAC0 (would be WREDMAC7, but that seems unused)

How do these regs look on other cameras? I don't have nstub addresses for lv old or lv no flicker so I can't try to call them. I can try calling the jpeg check while outputing that reg to screen.

[nanomad]

Are you sure? 0xFF111928 seems like an interesting function to analyze on the 600D
as it uses B:/DCIM/LV%06d.jpg

[a1ex]

EDMACs are camera-specific, but usually they are just reordered.

5D2:

Code Select Expand


c0f04000:        1
c0f04004: 20000000
c0f04008:  4000080 <-- HD buffer
c0f04010:  2a70800
c0f04100:        4
c0f04108: 1c414000 <-- ?! 720x680 image
c0f04110:  27f05a0
c0f04200:        1
c0f04204: 20000000
c0f04208: 1fab73e0 <--
c0f04210:   e00020
c0f04400:        4
c0f04408:  2004070 <-- jpeg
c0f04410:  fff0200
c0f04500:        4
c0f04504: 20000000
c0f04508: 10000080 <-- ?
c0f04510:    104dc
c0f04600:        4
c0f04604:      300
c0f04608: 1faa8040 <-- luma, reverse endian, 320x200?
c0f0460c:        d
c0f04610:      2f0
c0f04614:     1000
c0f04800:        1
c0f04804: 40010000
c0f04808:   4346f8 <--
c0f04810:  7520020
c0f04900:        1
c0f04904: 40010000
c0f04908:   4a4778 <--
c0f04910:  13c0020
c0f04b00:        4
c0f04b08: 1c414000 <-- 720x680
c0f04b10:  27f05a0
c0f04c00:        4
c0f04c08: 1faa8040 <--
c0f04c0c:     1000
c0f04c14:     1000
c0f04d00:        4
c0f04d08: 10000080 <--
c0f04d0c:   540003
c0f04d10:    70200
c0f04d14:    70200
c0f04d18:      600
c0f04d1c:  fffc800
c0f04d20:      600
c0f04d24:  fffc800
c0f04e00:      104
c0f04e04: 80010000
c0f04e08:   700000 <--
c0f04e10:   700000
c0f04e20:   100000
c0f04e28:   100000
c0f04e30:   100000
c0f04e34:        7
c0f04f10:        1

c0f26100:        4
c0f26104: 20000080
c0f26108: 1c4f5000 <--
c0f26110:  27f0276
c0f26200:        1
c0f26204: 20000080
c0f26208:  1b07800 <-- LV buf
c0f26210:  1a805a0


60D:

Code Select Expand


c0f04000:        1
c0f04004: 20000000
c0f04008: 1c717c00 <- WriteEDmacWbInteg
c0f04010:   ef0020
c0f04200:        1
c0f04204: 20000000
c0f04208:  6000080 <- HD buffer, WriteEDmacYuv
c0f04210:  2bf0840
c0f04300:        1
c0f04304: 20000000
c0f04308: 1c307800 <- LV buffer, WriteEDmacVram
c0f04310:  1df05a0
c0f04400:        4
c0f04408:  2000070 <- WriteEDmacPackMem
c0f04410:  fff0224
c0f04500:        4
c0f04508: 1c73fc00 <- WriteEDmacFenYuv
c0f04510:  27f05a0
c0f04600:        4
c0f04604:      300
c0f04608: 1c83b8e0 <- WriteEDmacFen_B
c0f0460c:        d
c0f04610:      2f0
c0f04614:     1000
c0f04800:        1
c0f04804: 40010000
c0f04808: 1f788780 <- ReadEDmacDefCorre
c0f04810:   df07d0
c0f04900:        1
c0f04904: 40010000
c0f04908:   5e68fc <- ReadEDmacHivshd_V_
c0f04910:  49d0008
c0f04a00:        4
c0f04a08:  6000080 <- ReadEDmacYuv maybe (affects recording)
c0f04a0c:   570001
c0f04a10:    70420
c0f04a14:    70420
c0f04a18:      420
c0f04a1c:  fffc640
c0f04a20:      420
c0f04a24:  fffc640
c0f04b00:        4
c0f04b08:   56c410 <- ?
c0f04b10:  3e707d0
c0f04c00:        4
c0f04c08: 1c83b8e0 <- ?
c0f04c0c:     1000
c0f04c10:       80
c0f04c14:     1000
c0f04d00:        4
c0f04d08: 1c307800 <- ReadEDmacVram maybe (?! no visible effect)
c0f04d10:  4360f00
c0f04d18:    1f100
c0f04e00:      104
c0f04e04: 80010000
c0f04e08:   700000 <- ?
c0f04e10:   700000
c0f04e20:   100000
c0f04e28:   100000
c0f04e30:   100000
c0f04e34:        7
c0f04f10:        1


lvcdevResourceGet is the key to MJPEG. The problem is that it's not called on new cameras, but only on old ones and only in low-res liveview modes. On 5D3, attempt to call it via TryPostEvent results in ERR70.

Also: some strings in 5D2 might suggest that LVCDEV is used for H.264 recording:

Code Select Expand


ff966aa4: 'mvrRecForceStop : LVCDEV_H264EncodeResume'
ff966780: 'mvrTerminateEncoder : LVCDEV_H264EncodeStart'
ff9667b8: 'mvrTerminateEncoder : LVCDEV_H264EncodeStart timeout'
ff967870: 'mvrEncode : LVCDEV_H264EncodeStart'
ff9682a0: 'mvrEncodeDone : LVCDEV_H264EncodeStart'
ff9682f4: 'mvrEncodeDone : LVCDEV_H264EncodeSuspend'
ff9689a0: 'mvrRecSuspend : LVCDEV_H264EncodeSuspend'
ff968e00: 'mvrRecResume : LVCDEV_H264EncodeResume'
ff969384: 'mvrSMEncodeDone : LVCDEV_H264EncodeSuspend'


but it's not true, LVCDEV is idle during record.

[1%]

 FA_LvJpegCheck 429392408 << returns this.

called like:

int *foof;
*foof = 24;
FA_LvJpegCheck(&foof);


Also found virtual keyboard but can't get it to come up.
319: 22447.067 [GUI] ERROR ***** GetMenuTypeFromVKType illegal type(0)
    320: 22447.176 [GUI] ERROR ***** INPUT_BUF_SIZE = 0

But this OT