PDA

View Full Version : 4 Gig limit?


tenbar
05-15-2003, 01:20 PM
When using the render panel to convert my rtv to some other format (like DV), I noticed that the process would stop at some point. I'd have to close the app, reopen it and restart the render, which stopped at the same point as before. I finally figured out that the render process stopped when the output file reached 4Gb in size.

I don't have quotas for the disk turned on, there is plenty of room (i.e. the output disk is a 123GB striped volume), etc.

I've since found a way to avoid having to convert an rtv to a dv, but I'd still like to know how to correct this problem (if I can). I didn't have this problem when doing the original capture (which resulted in a 68GB RTV). Is this a limit related to the output format (i.e. can DV files only be 4Gb max), or something like that?

Thanks in advance for any hints....

JReble
05-15-2003, 02:04 PM
Are you trying to render the dv file to a hard drive that is not NTFS formatted or are you rendering it to your video drives? It sounds like your video drives are setup properly to handle large files but your others may not be.


Certain drive formatting limits your maximum file size to 4Gb. I know this is a problem in Win98 because it didn't really support NTFS formatting. I've never had the problem with any drive in Win2000, but that's probably because I have them all formatted NTFS. I believe it is possible to have a drive running in Win2000 or above with an older formatting on it that could cause this problem though.

Jim Capillo
05-15-2003, 02:29 PM
Are you sure that the render is really stopping? The reason I ask is because everytime I render out, the render panel disappears a few seconds after starting and it appears the render stops. I found that you just need to click on the render box on the menu bar at the top of the page and the render progress panel reappears, actually never having stopped. I haven't figured out whether this is a bug or feature........ :rolleyes:

JReble
05-15-2003, 03:14 PM
Jim I noticed that too. It took me a while to notice that for whatever reason, the render window was simply being obscured by the TED window. It seems that after a render begins the TED interface is often brought to the front automatically. If you just drag the TED window(or File Bin in some cases) out of the way, you'll see the render window still clicking away underneath. :)

tenbar
05-15-2003, 03:22 PM
Thanks for all the replies.

My answers to your questions:
The drive being rendered to is formatted with NTFS, is a video drive, the rendering really has stopped (i.e. it runs for about 17 minutes before stopping - the full RTV file is 56 minutes) - and as I'm watching the preview window on the render panel, the progress bar stops moving and the action in the video window freezes. This machine has never had anything but win2k on it and all the drives (system and video) have always been formatted with NTFS.

JReble
05-15-2003, 03:29 PM
Hmmmm.....then I would have to suspect whatever codec(s) you're rendering to. But you did say that you have the problem with rendering to several formats. That seems strange. Some particular codecs may be limited to or have their options set to only allow up to 4Gb files, but if you get that problem with every reder to anything but RTV I'd be perplexed as well. Anybody else have a thought?

Jim Capillo
05-15-2003, 03:39 PM
Hmmmm....... what does the CPU usage show when the system locks up ??????

(Crtl-Alt-Del then look under processes)

tenbar
05-15-2003, 03:49 PM
The system doesn't lock up. The render panel becomes unresposive (i.e. I hit cancel, but nothing happens), but the rest of the toaster interface is. I can minimize the toaster and use the explorer and Task manager to poke around. CPUs (I have a dual Xeon system) are both still active (but not pegged at 100% or anything like that).

I had this occur on both the DV codec (not the interleaved audio one, but the other one) and the MJPEG codec (i.e. both stopped after hitting 4Gb). I didn't let any of the other codecs run long enough to reach this limit (they were *way* too slow), so I can only say for certain it is a problem with the two codecs I mentioned.