Originally Posted by melgross
What, you don't think that's been thought of before?
It's no solution.
If you knew something about filming, you would know that you can't stop every time you reach the end of a file.
There's such a thing called "continuity".
Eto eto... Melgross-san, you sound to my reading here to be a little worked up over that, and your answer doesn't make much sense to me. I will try and elaborate, since you seem to have missed my point.
The other thing is you sound very accusing in your statement `If you knew something about filming...'
Tangentially; I will freely admit I don't know a very much about filming; I don't work in the movie industry after all, and the closest I get is recording stuff on my Powershot G9. Given it only shoots in low-def 4:3; I haven't had file-size issues.
But whilst I may not know too much about filming, I do
know a fair amount about some of the graphics codecs, the various ways of storing colour, and the compression methodologies that are used in these. What is more, I would love for you to educate me (and other readers) as to the potential pitfalls my solution would fall into. I like to read and write for educational purposes rather than just stating stuff and assuming the reader knows why it is factual...
The original problem as I currently understand it was not being able to shoot a movie over a certain length because you ran into the maximum file size that Fat32 can support. If that isn't the case, then our entire discussion on the subject (and the rest of this post) is meaningless since we have had our wires crossed from reply#1. If this is the case, I apologise for misreading/interpreting your post - and please disregard the rest of this one.
My suggestion was (direct quote)
`One workaround for large files on Fat32 is simply to save multiple smaller files.'
I was not advocating this is what should
be done nor that it was the only
thing that could be done. What I was indicating was merely one particular solution that could be employed to get over the limitations.
As an aside, it seems silly to me to have a camera that will shoot in HD 1020p (by your words) that doesn't do something about this - either writing to a different type of file-system, or by working around the limitations of Fat32.
So my envisaged solution was that as the camera is writing to disk, the part that actually does the writing could split the output into multiple files as it goes. With the caveat of looking backwards to indexes and your last point(s) of reference that the compression codec requires [a further aside, I wonder why such a professional camera would want to shoot HD straight to such a lossy and difficult to post-edit format, assuming the max file-size wasn't an issue] the actual data is essentially just written out and forgotten. Once you've got more than a certain way through writing (which one assumes one can accommodate in the available 4GB), you simply cut and write what is no longer required to file. If your lookup window is greater than 4GB, then you have a problem (and I suggest you want a different codec).
Admittedly you do not get a single nice file on disk at the end; hence me saying you would then need a re-stitch tool for the end user (and probably in the camera too) to stream back the information.
You say: ``There's such a thing called "continuity".'' and you are of course right, there is indeed such a thing as `continuity'. I'm presuming you mean by the statement though that this `continuity' is the reason why the above wouldn't work.
The question is actually: can you encapsulate the file-io to the point where people continue to see `continuity'. The answer to that question is definitely `yes' - given enough smarts (whether by the above method or another)
However as we have all already said, it is probably less effort simply to change the underlying file-system to something more appropriate for the size of the files now being generated.
``Fine, YOU tell the manufacturers to not use the only current file format that's standard there.''
Now I find that a bit of a weird non sequitur to make. It isn't my place to be saying that and didn't say that we should. I was suggesting a workaround for
the current limitations. As I've already said, I'm aware that it is a standard of sorts. However it is not the `only' format used on flash devices. Also, the layout of the data on top of the file system varies from camera to camera, so it is hardly like a given flash card will always work when taken straight out of one camera and put into another without re-formatting. There's no particular reason to stay with it other than it being easier (cheaper) to do so.
``It's not as though they aren't aware of the problem''
I'm sure they are; I wasn't implying that they weren't.
``We hope to see a solution around the end of the year''
Who are `we'? Everyone likes to see solutions though...
``But it will have to come in on a new generation of equipment''
Well, it would be weird in this day and age for manufacturers not to use it as a way to sell more product