Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - rudi

Pages: [1]
Other experimental builds / Re: 12-bit (and 10-bit) RAW video
« on: June 14, 2013, 12:48:24 PM »
well, i implemented an memcpy using LDMIA/STMIA for LV buffer copying and this was a dead end.
so i tried to get EDMAC working.

I don´t want to keep the idea of a 12 bit shifter alive, but i´m just interested in how much MB/s you recieved with LDMIA/STMIA.
the mysterious "d" seemed to reach about 30-40MB/s on an smaller modell.
and as far as i can see from the debug scrennshots a memcopy can reach over 70 MB/s. Ist that correct. Was that LDMIA/STMIA?
Some years ago a made heavy X86/MMX/SSE2 optimisations and looked some days ago at ARM optimizing.
As far as i can see (and what "d" did) you can sqeeze out a lot of bubbles and stalls out of hand optimizing.
Shifts are also free in ARM. Nearly every instruction can be combined with the barrel shifter at no cost. (I´m sure you are ware of this).
And you have a lot of Cache/Flush/Prefill Options in ARM.
But again, i don´t want to reanimate the idea, i´m just curious how fast optimized LDMIA/STMIA / memcpy on a 5DMK3 can be.

just to think of:
CF-Standard below 5.0 can only adress max 256GB, and and there are no bigger CF-cards on the market than 128GB, so make shure your attached drive is not bigger than that and does not use  48-bit addressing...

but probably you all are aware of this.

just 2 cents


General Development / Re: 5D3/2 HDMI transfer speed?
« on: June 06, 2013, 11:44:37 AM »
Hey chmee and others (nice CineDNG-Converter work by the way, i was also totally braindead after trying to sort these little/big endian shifts out -for some personal tests, tell you later).

Here are some personal findings to the theme:

As far as the community knows this HDMI Chip (or a very similar) seems to be build in:

As far as we can see that means, that the  canons seem to be  limited to HDMI-1080i-Output, and the Chip can manage to process the Data with 80MHz. So we could assume, that the max possible data-throughput via HDMI is about 80 Mhz x 16 Bit data, which could mean max 80 Mio 16 Bit values. As the Raw Data from the sensor is 14 Bit/BayerPixel we could assume, that we could transfer about 80 Mio RAW Pixels per HDMI after hiding them in normal HDMI-data some way. 1920x1080@24fps with 16 Bit/RAW-pixel would mean about 50 Mio RAW-pixels. So there seems no hope for much higher resolutions.

The Magic Lantern Team can write the RAW-pixels to the HDMI-Chip, but the output will be modified to and HDMI-compliant output in hardware, like 16.235 conversion, sharpening color space conversion etc. But it could be possible to switch off some of these features in the HDMI-Chip. But still there will be probably coming modified data out the HDMI port.


Rudi (from slashCAM)

General Development / Re: uncompressed 14-bit RAW video recording
« on: May 18, 2013, 10:17:17 PM »
i was off some time, but have another, hopefully not too dumb question:
Would it be possible to use the edmac copy routine, to copy only every second line?
So sacrifying vertical resolution for more horizontal Pixels?
It doesn´t not necessary look too bad to interpolate every second line in post, and the possibilites would be enormous, if we could use e.g. 3840 x 820 @24fps, which would result in 125 MB/s, for a Super35mm equivalent Crop Factor of 1.5. In a cinemascope aspect ratio. If  you could it interpolate it to 3840 x 1640 in the post. see what i mean?



BIG BIG Kudos for you all!!
Just two cents from me for alle developers of ML:

My C-coding  times are about 6 years outdated, but when the sensor only has 12 Stops and and the Raw Data Rate is 14 Bit, maybe you could introduce something like a minimal Quick Compression by shifting away the 2 least significant bits. Maybe the processing power is enough for this litte bit shifting trick during copying the data from buffer to CF. This would lower the datarate with minimal loss.
On the PC/Mac/Linux side you just shift the lost bits back (with random bits) when converting to CinemaDNG or whatever.

Maybe my idea is completely off, then forget it.
Otherwise this could help to bring the datarates down a little without great visual loss...


Rudi from slashCAM

Pages: [1]