200 MB Limit/Large Downloads

[Eric Meeson]

Is there a particular reason for the 200 MB download limit the Camect imposes? I'm pulling down a few hours of footage right now for a police investigation, and as this is a 4 MP camera, that means it is breaking the footage into 3 minute chunks.

Is there any better option for pulling large amounts of data down off the system?

[CamectChao]

The 200MB limit is set because it has to download the file to the memory of the browser. It cannot be too big, otherwise it'll crash the browser.

[Will Stillwell]

Uh, how is it we can download bigger files in our browsers?  

Just curious the difference here.  Couldn't it save a file chunk to disk of a bigger size , then present a download link to the user?  

~Will

--
You received this message because you are subscribed to the Google Groups "Camect User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@camect.com.
To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/d9079a06-5a32-4766-b269-5679614a2d1fn%40camect.com.

[Arup Mukherjee]

When you ask a browser to download a link via http from the public internet, it can just fetch the data and write it straight to the disk as it goes without having to hold the whole thing in memory first. That's how normal large downloads work. 

When you're downloading from the hub in the Camect UI, there's no publicly-accessible url that the browser can be instructed to fetch from, and an app running in your browser is not allowed to write directly to your disk. The data has to be downloaded from your hub over WebRTC, held in memory (i.e. not disk) by the app, and then more or less presented to your browser as a complete file that the browser downloads to your disk. Using a lot of memory can cause the browser to crash on lesser devices, hence the limit on size. 

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/CANM50hkkcVf9km%3D1uDeE_8MaKUv1XSNcx9073NKE5CDPo77jXA%40mail.gmail.com.

[Eric Meeson]

Interesting limit, but it makes sense as described.

I'm assuming that has something to do with the way Chrome sandboxes browser apps so it isn't something that can be readily worked around?

[Will Stillwell]

I agree thank you Arup for explaining that.  Makes perfect sense.  Is there a way to make it work like a normal download if accessing from the local login via IP?  I know that is having to handle downloads different for remote vs local login.    Just my brain thinking on it.  

~Will

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/bd547354-a327-4921-a1cf-23e491adcb15n%40camect.com.

[Dolf Starreveld]

It seems to me that things could be changed. The stated problem is the lack of an identifiable URL to download a longer video. So what if, upon creation of the download scenario a random UUID would be created, stored in a DB along with details of start and end time and video source. The same machinery that today stitches together the video stream could still be used. When a URIL including that UUID is requested as a normal http download the server would use the UUID to lookup details, send out an appropriate header segment, followed by the bytes of the same stream that would otherwise be constructed. Except now it can be much larger and does not require memory to hold the whole video segment.

What am I missing here, other than prioritization of engineering resources?

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/CANM50h%3DmD-V1FZAbq5XPQeBxcDwbtXiZZET4H1TC1QcmHiRuRw%40mail.gmail.com.

[Arup Mukherjee]

As Will observed, any solution based on a temporary url will only work if the browser can connect directly to your hub via http -- i.e. it would only work when you're on the same network as the hub, as there's no non-WebRTC means to connect directly to your hub when you're outside your firewall. (And we don't want to send your video to our cloud and back to work around this.) 

For now, we'll provide a way to allow people to request a bigger chunk size when using a browser on beefy hardware. Eventually, if we were to do something that required local access to the hub, I think we would be more likely to allow you to write the video directly to a USB drive as that would probably be better for large video exports than having to get everything through the browser. 

[Will Stillwell]

Oh, save to usb would be an awesome feature.    Vs just saving all video to the usb drive.   But another option would be to mount the drive.  But not save all video to it.  But rather flag save video to file share on the USB drive.  Access said file share via FTP.   or some other protocol on the local network. 

~Will

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/CAKtfXE3zcC8g1U-euSKJZbSzYAfGpyDvq%3DPuB%2BoagVsr%3D7QZcA%40mail.gmail.com.

[Jack]

Another option may to use a file joiner(merge) program that can take many files and create one big one.  To do it quickly, use a file joiner that has a "No re-encoding" mode.  In the example in the post below, a two hour video would be 8GB, which I suppose would require at least 8GB of free computer memory. 
I have used a program in the past  that I really like called VideoProc (7 days free), but not for Camect files like the example.  There are other free file joiner programs available including VLC.