Cinesend

[Leo Enticknap]

A day or two to receive a feature is not a problem if you only play 2-3 features a week.

[Carsten Kurz]

Okay, as a single screen, 25MBit/s may actually be a starting point. Depends a bit on how long you book in advance. I know some cinemas using these services with a 16MBit/s connection. It can take one or two days to receive a feature that way. We use a 200MBIt/s cable connection, as we use three different services, and they may transmit overlapping. In general, most companies consider 50MBIt/s good enough. Occasionally, this services saved our ass a few times, when we received a bad hard disc, or a disc didn't arrive as scheduled. Sometimes, we received an emergency transmission within two hours after we reported a problem. Sometimes, when we book a new title, we see the transmission starting a few seconds after we hang up the phone with the booker.

[Harold Hallikainen]

DSL has gotten a lot better over the years. When I first got it, 6 Mbps down was high speed. Now at home I have 120 Mbps down, 20 Mbps up using two pairs.

[Frank Cox]

Right at this moment I have a 25mbps DSL connection and a 10mbps cable connection. I can get much faster service when I need it. I told the Cinesend guy that I'll get the faster service when there's something to download; no need to pay for a higher speed service that I have no current use for.

Their minimum required speed is 50mbps according to the email that I got from them.

[Carsten Kurz]

What type of internet connection do you have?

[Frank Cox]

I've installed the Cinesend gadget into my projector pedestal, got it wired, and turned it on to see the pretty lights flash.

They're supposed to get back to me with what the next steps are after this.

There are at least five fans in that thing, so it runs fairly loud. My UPS tells me that it draws 40 watts doing nothing in particular.

They told me that I can shut it off if I'm not expecting to receive any content, but there's no obvious way to do that short of pulling the plug or removing the face plate to access a power switch. And a lot of equipment doesn't like to be crash stopped that way, so I've sent them a question about that as well.

[Scott Jentsch]

Using the BitTorrent or similar protocol among trusted devices would be an incredible way to provide distribution, in my opinion. However, with the close association of BitTorrent and piracy, I can't imagine anyone in a board room approving such a thing. A clever engineer would have to call it a "secure distributed mesh network protocol" or something equally buzzword-worthy to prevent the aneurysms that would happen with the mention of BitTorrent.

If the system can limit the bandwidth consumption so that it doesn't overwhelm the connection, that would also be ideal. An intelligent system would see when a file was needed and give it priority over other files to be transferred and how much bandwidth it could consume in order to meet its target. I wonder if this box does that?

[Marcel Birgelen]

UDP and TCP are both layers on top of IP. TCP is a bi-directional transmission protocol that includes error-checking, balancing/throttling mechanisms, etc. UDP is just a datagram protocol. HTTP works on top of TCP and wget primarily uses HTTP(s), but can also use FTP (a troublesome protocol using multiple TCP ports, one for signalling and a separate port per transfer, especially active FTP (the classic version) often wreaks havoc on modern firewalls).

Yes, you can resume downloads if the server on the other side supports it. What's more problematic though, is error checking. You can create a separate hash of a file, e.g. a "zipped" DCP, but if you conclude at the end of the transfer it doesn't match, you don't know where it went wrong. So, you need to transfer the whole file again.

More modern data-transfer protocols divide files into chunks and use more elaborate hashing (lile Merkle trees), they can detect where the transfer went bad and you only need to re-send the affected chunk or chunks instead of the entire file.

Also, a modern download protocol can use multiple TCP sessions or implement their own "balancing" using e.g. UDP. The problem of a single TCP stream is that it often performs bad over links with high latency due to the TCP window size. That's the size of the buffer that the other side keeps on sending, until it receives an ACK from the other side. While there are possibilities to increase the TCP window size, today's internet is a difficult stack of all kinds of devices like firewalls that might interfere with that. So, opening multiple TCP streams can often increase transfer speeds.

Personally, I have my doubts with some implementations using UDP. There are lots of people out there that don't understand the fabric of the Internet and the way TCP works and how it more or less keeps the Internet together. As long as we keep building on top of TCP, the internet is "safe" so to say, from most stupid mistakes developers tend to make. UDP can be a dangerous tool in the wrong hands. It doesn't "self balance", if used incorrectly, it will fill all bandwidth it can get, even if it's supposed to share it with other users...

But you don't need to invest all the work into developing the most ideal transfer protocol. The bit-torrent protocol, even if employed as a point-to-point transfer protocol, for example, is as efficient and fast as it can get, checks all the checkboxes mentioned above and the protocol is open-source and implementations exist for all kinds of platforms. Maybe, marketing-wise, you may call it differently, because the movie industry might be afraid of the name...

[Harold Hallikainen]

Thanks! Looking at the wget manual at https://www.gnu.org/software/wget/manual/wget.html , I see "Wget has been designed for robustness over slow or unstable network connections; if a download fails due to a network problem, it will keep retrying until the whole file has been retrieved. If the server supports regetting, it will instruct the server to continue the download from where it left off."

Aspera claims to be faster than HTTP or FTP and appears to be based on UDP. I think of HTTP as a layer on top of TCP which is a layer on top of UDP.

Bit Torrent is also interesting since it spreads the "server side" around.

Harold

[Marcel Birgelen]

Thanks Steve! But could they be standardized hardware and OS that runs wget or similar to just get stuff from a specified URL? Cinemas could buy whatever system hardware they wanted (or the software could be integrated into a TMS, LMS, or the playback server). File transfers are not magic. Why special hardware?

I like the idea of the integration into the TMS. It should be a bit more sophisticated than a "wget" though, you want block-based downloads and checksums, so if the transfer cuts out in the middle, you don't have to redo the entire thing. If they're smart, they'd employ something like the bit-torrent protocol (yeah, it's known from the piracy stuff, but like many things, it's just a tool that lends itself for a specific purpose), where every client also is a server. This could save those distributors a ton of bandwidth. Also, bit-torrent could even be an interesting protocol to distribute content between servers on your local network.

[Frank Cox]

The box showed up today.

I'll drag it up into the projection room and see how far I can get with setting it up within the next couple of days....

[Scott Jentsch]

One reminder is to check the terms of service with your internet provider for any download/bandwidth quotas that might be on your account.

Do the math on the average download size and the number of downloads per month and make sure you don't end up with a big bill for overages, being throttled for taking too much bandwidth, and angering anyone else that is on your same network connection (e.g. cable internet) if your downloads cause their service to go downhill.

[Elia Orselli]

In Italy we have two main services for DCP digital delivery: one via satellite internet connection which services most of the distributors and one (now Eclair) that can be via satellite or via fiber connection.
The satellite-only system is totally free of charge for the venue. Instead the Eclair box and a dedicated fiber connection are free, but you have to pay a fee for each DCP download.
Two other providers tried to start with their own services (one giving a refurbished PC as client, the other with a software that was linked to an AWS account), but they never sent a single DCP...

[Harold Hallikainen]

Thanks! I've used Aspera a few times to get test DCPs. I also used FTP to get a several hundred GB feature a couple months ago. I like the simplicity of transferring a single file (tar, zip, etc.). The file package should, in my opinion, be taken apart as late as possible, possibly at ingest by the playback server. From what I'm reading, FASP uses UDP for the transfer with minimal reverse channel information as compared to TCP. It appears it was optimized for high latency networks. It appears to be a proprietary protocol developed by Aspera/IBM. There is a pretty dramatic comparison between FASP and FTP at https://downloads.asperasoft.com/en/...p_versus_FTP_4 . There's a calculator at https://www.ibm.com/aspera/file-transfer-calculator/ . There's a large discussion of FASP at https://www.reddit.com/r/rust/commen...e_alternative/ .

It seems to me that you should be able to fetch a feature with a URL. It would show up as a single file that is extracted during ingest. I think the transfer should use standardized open protocols.

So, interesting stuff, but definitely outside my area of expertise!

[Carsten Kurz]

Over here, we do not pay for any transfer towards the cinema (only for sending back hard discs). Of course, the costs for getting the content to us is still buried in the minimum guarantee we pay to the distributors.

Harold - these services do not use standard file transfer protocols. They seem to be ineffective and may require too many retransmits - minimum transfer entity for DCPs would be a reel, which is ineffective. With proprietary protocols, they can break it down into smaller blocks and perform integrity checking on that block level. Some of these protocols have been developed also with wonky satellite transfers in mind where you simply can not request a full reel again.
One favourite protocol is FASP/ASPERA. Usually, the cinema does not have to bother about details. You setup a client, they recognize you, and you are done. One of the software transfer services actually pay us some money for every transfer (basically, what they save against shipping a hard disc otherwise). One would think it is only a symbolic incentive. As it is up to the cinema to decide which of these services to book, getting around 5US$ per feature transfer is SOME incentive to use THAT service. Over the year, it pays our internet connection.

These software clients also support trailer downloads (all german - and I think all european cinemas now) download their trailers through the internet. Some of these services allow to shift their trailer downloads to this service, so, features and trailers come through the same client running in the background on one of our office PCs. We then ingest content through SMB or FTP. One small advantage of using the download service for trailers is that they come as one trailer DCP per folder unzipped - so you do not need to unzip them before ingest. These clients also perform a full verification/hash check on content once the transfer is complete.
These transfer protocols offer some handling benefits like e.g. Dropbox or GDrive - they keep fetching the content until it is complete and hash checked, even over multiple days and possible reboots. Once the transfer is complete, you get a confirmation email.