Author Topic: uncompressed 14-bit RAW video recording (Read 762788 times)

arrinkiiii · « **Reply #175 on:** May 08, 2013, 01:21:47 PM »

YES!!! YOU GO g3gg0 !!!

1% · « **Reply #176 on:** May 08, 2013, 04:46:19 PM »

600D: http://imgur.com/a/KE9RY#0

With global draw off... memcpy64 starts winning. So as long as you don't use it for anything else... I guess memcpy is faster. Even with zebras/overlay peaking, dma_memcpy still has speed to spare while memcpy bogs down to single digits... so I guess dma scales better...

Greg · « **Reply #177 on:** May 08, 2013, 08:53:45 PM »

500D :

1% · « **Reply #178 on:** May 08, 2013, 09:18:31 PM »

How are these so fast with GD on? Not a lot of indicators?

Greg · « **Reply #179 on:** May 08, 2013, 09:25:56 PM »

Maybe it's a bug they were setting the default ML.

1% · « **Reply #180 on:** May 08, 2013, 09:34:05 PM »

Default ML doesn't have a lot of indicators enabled. I guess I'll try turning things on/off and find whats slowing it down.

Found a big hit to everything is the new peaking/display filter.. without dma_memcpy the hit is even bigger... but still not trivial.. hit to EDMAC is fairly huge too. I guess this is all the side effect of really high CPU usage. Sucks.. the blinking dots peaking is a bunch less useful for me. Anamorphic probably does it too... I guess defish doesn't anymore since I saw it was sped up in some commits.

squig · « **Reply #181 on:** May 09, 2013, 01:29:01 AM »

Do you think a bare bones "Magic Blondie" build with nothing but LV_rec would get us closer to 24p?

1% · « **Reply #182 on:** May 09, 2013, 02:00:32 AM »

Won't make that much of a difference. Still limited by card write speed and shoot_malloc total size. Only possibility is to shrink reserved memory for other canon things.

minimimi · « **Reply #183 on:** May 09, 2013, 04:34:53 AM »

Solved compilation error. Because ,CreateMemorySuite is imported to exmem.h

Code: [Select]

diff -r 22fd8107540b modules/lv_rec/lv_rec.c
--- a/modules/lv_rec/lv_rec.c   Thu May 09 00:10:56 2013 +0200
+++ b/modules/lv_rec/lv_rec.c   Thu May 09 11:32:32 2013 +0900
@@ -9,7 +9,6 @@

 unsigned int exmem_clear(struct memSuite * hSuite, char fill);
 unsigned int exmem_save_buffer(struct memSuite * hSuite, char *file);
-struct memSuite *CreateMemorySuite(unsigned int address, unsigned int size, unsigned int flags);

 /* file footer data */
 typedef struct
@@ -593,7 +592,7 @@
         data.dmaFlags = 0;

         /* create a memory suite that consists of lv_save_raw raw buffer */
-        data.memCopySuite = CreateMemorySuite(shamem_read(RAW_LV_EDMAC), save_data.frameSize, 0);
+        data.memCopySuite = CreateMemorySuite((void *)shamem_read(RAW_LV_EDMAC), save_data.frameSize, 0);
         PackMem_RegisterEDmacCompleteCBRForMemorySuite(data.dmaCopyChannel, &complete_cbr, 0);
         PackMem_RegisterEDmacPopCBRForMemorySuite(data.dmaCopyChannel, &pop_cbr, 0);
     }

a1ex · « **Reply #184 on:** May 09, 2013, 02:18:13 PM »

Are these numbers real or there's a bug in my benchmark code?!

139MB/s for a 2GB file CF+SD or 118 CF only?!

(source: https://bitbucket.org/hudson/magic-lantern/commits/7e2bd05de88e752eca98b3e8e36a46f23db02968 )

1% · « **Reply #185 on:** May 09, 2013, 04:59:25 PM »

Leaps and bounds ahead of SD.

N.Mendes · « **Reply #186 on:** May 09, 2013, 11:20:30 PM »

Quote from: a1ex on May 09, 2013, 02:18:13 PM

Are these numbers real or there's a bug in my benchmark code?!
139MB/s for a 2GB file CF+SD or 118 CF only?!

Wow... F***ck**ing Impressive! So, if my english doesn't suck too much, the 1% last comment says that "Yes, it's real and not a bug"
Really crazy...

Also, someone already asked before but i'v seen no clear answer:

In term of quality, is there a difference between "Yuv422" and the 14bit raw from burst mode?

And why "Yuv422", is it prores 422 10bits? (so not as good as the 14 bit raw from the burst mode right?)

Thanks for what you do fellas, you're really crazy..

1% · « **Reply #187 on:** May 09, 2013, 11:43:07 PM »

6D with new timing:

Buffer size is fairly important. 4MB drop for ~2M

hirethestache · « **Reply #188 on:** May 10, 2013, 01:46:42 AM »

Quote from: 1% on May 09, 2013, 11:43:07 PM

6D with new timing:

Buffer size is fairly important. 4MB drop for ~2M

So what does this mean for us non coders(other than more of a reason to eagerly wait a release!)

g3gg0 · « **Reply #189 on:** May 10, 2013, 02:00:13 AM »

this means we are working and testing

arrinkiiii · « **Reply #190 on:** May 10, 2013, 02:02:59 AM »

...dont stop !!! ...testing for having a good release !!!

mindogas · « **Reply #191 on:** May 10, 2013, 06:22:42 AM »

Everyone who is using 422ToImage please update to 1.9.1 version. There was made some corrections regarding .YUV files ordering, decoding then in threads simultaneously, fixed HDR processing for single shoots and some other little fixes.

lourenco · « **Reply #192 on:** May 10, 2013, 06:53:37 PM »

CF LEXAR 1000X in my 5D3. I am able to record continues 1904x 960 at 24 fps or 1904x1080 x 20 fps for single file 422 YUV with lv_rec.

I am thinking if we were able to record to SD and CF, I would be able to obtain 1904x1080 x 24 fps. I noticed the CF card benchmark is slower in liveview vs in playback mode. If it is possible to speed up the CF card in liveview mode, it might be possible to do 24fps with just the CF card.

1% · « **Reply #193 on:** May 10, 2013, 10:02:56 PM »

Live view is using other edmac channels + more memory and CPU. Only way to speed things up is to turn off some canon stuff or shrink its memory. You'd get more frames too with bigger shoot malloc.

What is shoot malloc on 5d3 anyways?

a1ex · « **Reply #194 on:** May 10, 2013, 10:19:11 PM »

244MB in photo mode (RAW quality), 168 in LV. Changing pic quality results in even less free RAM (e.g. only 88 with SRAW, 168 with jpeg).

The total RAM seems to be 512MB. Where did it go?!

1% · « **Reply #195 on:** May 10, 2013, 10:25:00 PM »

Heh... so you just have ~10 more MB than I do... same story... raw is the best (thankfully) on memory. The other cameras are stuck with sraw and L.

So we have disableaewb.. I also found DisableWBdetection and DisableFaceCatch... maybe there are more like the AEWB.. would maybe free up some CPU and hopefully memory.

a1ex · « **Reply #196 on:** May 10, 2013, 10:39:09 PM »

I would try to stop somehow the edmacs that bring LiveView data (or alter their configuration to output one line only). Not sure how... should work by writing to edmac registers from some vsync spot (similar to redirecting the lv_save_raw buffer in the burst dng code).

What about running the benchmarks with most overlays active? (focus peaking and such). If the numbers are similar, CPU usage doesn't matter; it's just the data bus being overloaded by all those image buffers.

1% · « **Reply #197 on:** May 10, 2013, 11:00:21 PM »

I can't say CPU doesn't matter... running those benchmarks with new peaking enabled absolutely kills memcpy. Unless its all from creating another image buffer to actually apply the peaking. Also GD on slows everything down.

seems I gained 1MB after I ran that aewb disable, hasn't gone away yet, have 31 and 104MB now on 600D

600D Edmacs:

6D Edmacs - Both of these are 720P60

N.Mendes · « **Reply #198 on:** May 10, 2013, 11:32:06 PM »

Quote from: lourenco on May 10, 2013, 06:53:37 PM

CF LEXAR 1000X in my 5D3. I am able to record continues 1904x 960 at 24 fps or 1904x1080 x 20 fps for single file 422 YUV with lv_rec.

In raw mode?

lourenco · « **Reply #199 on:** May 10, 2013, 11:36:15 PM »

Quote from: N.Mendes on May 10, 2013, 11:32:06 PM

In raw mode?

It was in 422 YUV. Not in Raw mode.

News:

Author Topic: uncompressed 14-bit RAW video recording (Read 762788 times)