SDXC & Movie Recording Time Limit

[Vincent Olivier]

Hi Guys,

After reading, talking to Canon and testing myself firsthand, the 4GB is not just a filesystem issue, but firmware hardcoded limitation as well. That is the firmware will stop movie recording whichever limit is reached first (overheating, 4GB file size or 30 minutes). Even on SDXC cards which do not have the inherent 4GB file size limit.

I was wondering if ML can bypass all of those limits. Specifically, with ML installed, would I be able to record at least 192 minutes of full 1080p/24fps movies on a 128GB SDXC card on my T3i (I know ML is not out yet for the T3i/600D)?

Thanks!

Vincent

[Jordy]

I think the only format that the camera can work with is FAT32
(correct me if I'm wrong).
The property of this format is that it cannot hold files larger then
4GB. And for 1080p footage this is about 12 minutes (on my 5D).

So maybe a solution could be that the camera starts recording again
right after it stops because of the file limitation. Or if possible,
just keeps recording with writing multiple files on your card.

But I'm not sure in how far this is possible, because people have been
complaining about this a lot. And ML tries to cover the most things
that people need in the DSLR FW.

Jordy Vandeput

[Vincent Olivier]

Well I tested a Lexar 64GB SDXC class 10 card on my T3i and it works fine with an exFAT file system (confirmed on my iMac SD card reader).

And the card can take one 64GB file no problem (also tested on the computer card reader).

I confirmed with Canon that the 4GB file size limit is hardcoded in the firmware regardless of the file system of the card.

I'm a programmer. I can help with the dev if I can get the firmware running on my T3i (which is not the case at the moment).

Vincent

[Vincent Olivier]

Well anyways, here are the possible solutions, only the first one
being operational right now :

1) Use DSLR.BOT's auto-restart function to have the movie recording
stopped and restarted through the infrared protocol of the camera. I
get a ~2s gap between movies with that solution.

2) Write an EOS API widget that listens for movie recording halts and
auto-restarts. This is currently not possible as the "movie start"
command has not been published by Canon yet (even if it is available
in the "EOS Utility").

3) Look at ML's "movie_restart" option (found in "movtweaks.c") to
have the movie recording automatically restarted as per advertised
menu help string (line 313). Is this implemented for my camera (t3i,
seems to be missing from the t3i branch)? Is that implemented at all?
Will it do what I think it does? Does it eliminate the gaps between
the movie files?

4) Have the ML software bypass completely the 4GB and the 29m59s
limits completely for SDXC cards (with an exFAT file system supporting
files larger than 4GB).

Anyways, these are my options right now. Would really like to have
this fixed before a documentary shooting I will start in August…

Any help, any pointer is appreciated. Regards,

Vincent

[erik venhues]

all this ideas are nice, but the last one i think isnt possible.
cause the canon camera just reads fat16 or fat32 sdcards to load
autoexec or a firmware file (which is nessecary to implent exfat.
So if we can go into the "real" firmware it should be possible to add
exfat filesystem, but without that, no way.
i am not a well programmer, but this is just a logical thing what i
think.
best erik

[Vincent Olivier]

Hi Erik,

That is not what I read in "Step 2. Making the SD card bootable" of the install procedure here : http://magiclantern.wikia.com/wiki/550d_install

SDXC seems to be an option to load a firmware. Besides, the camera supports SDXC for sure (I tested it), so even if the firmware cannot be loaded from a SDXC card why would it mean that SDXC can fully be supported by ML?

Regards,

Vincent

--
http://magiclantern.wikia.com/

To post to this group, send email to ml-d...@googlegroups.com
To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en

[Alex]

From what I understand, you can't do the initial install step from a
SDXC card, but you can use it just fine after this.

["Sztupák Sz. Zsolt"]

Handling files larger than 4GB means special functions on a 32-bit
device (as you cannot address more than 4GB of space with a 32-bit
unsigned integer). So even if the FW supports SDXC cards and the exFat
filesystem it also needs to support file functions that can address
files larger than 4GB. I don't think Canon cared much about this in
DryOS, as omitting this makes a lot of things harder (or on the other
side: including this makes a lot of things much more complex).

SztupY

[Vincent Olivier]

Ok, so abandoning the SDXC implementation even if, in reality, support for large block storage file systems in the desktop world arrived long before 64-bit OSes. But I agree that rewriting DryOS's basic file handling might not be worth the effort (as I'm certain, since they actually support SDXC, Canon will be looking into it in the near-enough future).

Anyways, I'm compiling the ARM toolchain (on Mac OS X) now. I'm left with automatically restarting movie recording (and creating movie file sequences) and trying to reduce the gap below the 2s I get from the DSLR.BOT solution already (provided that a firmware solution might be a teeny bit stabler than the ugly hardware infrared hack I'm relying on now).

Will be moving this conversation to the T3i dev thread until I get ML running on it with a reasonable functionality.ù

Godspeed to us, then! ;-)

Vincent

[SztupY]

On máj. 29, 19:41, Vincent Olivier <vinc...@nbourbaki.com> wrote:
> Ok, so abandoning the SDXC implementation even if, in reality, support for large block storage file systems in the desktop world arrived long before 64-bit OSes.

Yes, Operating Systems did support large block file systems, AND >4GB
files for a long time, but this only means they provide the programmer
with two sets of APIs. One for easy file access, but only for files
<4GB, and one with a bit more complex file access scheme, but allowing
>4GB access (for 32 bit applications of course, for 64 bit programs
this is not an issue).

This only means that there are still a lot of 32-bit programs that are
incapable of handling files larger than 4GB. It's usually not a
problem, because for a lot of cases it is unneded (there arent't too
much file formats where the 4GB limit is a practical problem, eg. you
don't usually send people 6GB large doc/xml/pdf/jpg/etc files), but
because of this assumption there are a lot of programs that break
today.

I don't actually think that it's a priority for Canon to include large
file support in DryOS, as the EOS series are primary DSLR cameras,
which you use to take photos, and those photos even in RAW format are
well under the 4GB treshold. On the other side movies can be simply
split into smaller chunks (which can be joined without gaps of
course), and avoid the large file problem entirely (DVDs for example
also solved this problem this way back then). It's true that the
gapless splitting is yet not possible with the original firmware, and
is probably not possible with ML either (you have to paralellize the
point where the old recording stops and the new recording starts to
avoid creating gaps).

SztupY

[Vincent Olivier]

And since the MovieStart function call seems to be handled as a black box within ML, there would be a lot of work to do, even for the gapless optimization.

V

[Vincent Olivier]

Another solution has sprung up.

Instead of using movie record, one could use the HDMI liveview with an external recorder such as this one : http://www.blackmagic-design.com/products/hyperdeckshuttle/

Let's now see how far the HDMI liveview can go with ML in terms of both audio and video.

Vincent

[Alex]

call("MuteOn") ;)

[jraiber]

oh crazy. this peace is a real game changer and so cheap for (or
better because of) uncompressed material. everybody could decide at
home, which codec to use...
but i think, it's to hard to figure out in which part of the digic the
quantization and subsampling to 8bit takes place...and to change it.
if you can't get such a clean fullscale image out of the hdmi, it's
not worth to think about it, the improvements wouldn't be soooo
incredible much besides our good old recording on sd or cf with an
extended bitrate.

but as i think about it a little longer... hmmm... it must be the need
for less processing power to put the full sampling out, and you do not
need to compress anything cause, you wouldn't press
record.....interesting....

jan

[jraiber]

i mean quantization to 8bit an subsampling to 420

[Vincent Olivier]

Yes! Exactly (processing power, uncompressed sampling, etc.).

But there is also the question of how much uncompressed you can fit in the biggest SSD available now (512GB). And, like you said, if it is configurable to not oversample compared to what the camera sends.

There are other issues, like it would be nice to continue to use the viewfinder (stream a magnified portion of the image for autofocus, for instance) and not have it disabled because we send full HD to HDMI.

Anyways this sure is exciting!

Vincent

[Andrew Coutts]

There is one reference to this in the 500d dump, try searching for
strings like 420 with the console. ex:

In [7]: D = load_dumps("500|5d2|550")
..
..
In [8]: t1i, mk2, t2i = D
In [9]: t1i.load_names("stubs-500d.110.S")
In [10]: sel t1i
In [11]: s 420
ff192c70: '[JPCORE] SetEncodeYuv420LosslessParam %d,%d'

[Antony Newman]

Andrew,

FYI: Some of the '_A' and '_B' variables in the [JPCORE] code are also refered to as ALPHA and BETA respectively.

* CALL "mvrSetQscaleYC"

* CALL "mvrSetDeblockingFilter"

* CALL "mvrSetDefDBFilter"

 

For some reason, I made notes on two following routines when I was tracing JPCORE / QSCALE.

I never got a chance to play with them though....

 

/******** 5D2 2.0.4

0xFF88FE90 AJ_STR_0x37BC_HDMI_struct__0xC4__HDMIOutputSizeToFULLHD_related()

0xFF88FE9C AJ_LDR_0x37BC_HDMI_struct__0xC4__HDMIOutputSizeToFULLHD_related()

0x00008588 aAJ_0x8588_H264Rapper_related_0x00_to_0x28_sub_address

*********/

 

AJ

[jraiber]

looks very interesting, but I'm not able to figure out, how to use
it...


On 13 Jun., 14:25, Antony Newman <antony.new...@gmail.com> wrote:
> *Andrew,*
>
> *FYI: Some of the '_A' and '_B' variables in the [JPCORE] code are also
> refered to as ALPHA and BETA respectively.**
> *
>
> ** CALL "mvrSetQscaleYC"*
>
> ** CALL "mvrSetDeblockingFilter"*
>
> ** CALL "mvrSetDefDBFilter"*