With the advent of digital projection comes the age of explicit distrust.
In the olden days, when 35mm projection was the norm and 70mm what you hoped for, the film distributors would usually send the prints to the cinemas well in advance, mostly because the boxes were heavy and the distributors had little control over the actual physical distribution, but also because they imagined it would take the projectionist some time to assemble a 35mm print for a show.
Balancing the tip in the opposite direction was the fact that they also feared that a new film might be illegally scanned at a cinema. Never mind the fact that it wasn't easy to set up a reasonable scanning facility at a cinema without the managers noticing, nor do the actual deed, as it would invariably involve actually projecting images for however long the film was.
It was not common; most new feature films that ended up on Pirate Bay, or whatever the VHS precursor was called, were, in fact, pirated by employees of the production company or by a very early link in the distribution chain, long before the films reached the cinemas.
Today, when films are digital and delivered to cinemas in hot-swappable hard disk drives, the industry uses every means at their disposal to stop the illegal copying.
Unfortunately, as evidenced by the many bittorrent sites on the internet, they mostly focus on the wrong targets.
Modern digital films are frequently encrypted, meaning that they require a digital key to unlock them for a show. This key is matched to not only a specific theatre but also a specific digital projector and server at that theatre. The key is dated, with a start date and time, and an end date and time, so that it will only be valid for the screenings and, usually, for a limited time before and after them.
Now, many producers and distributors will send unencrypted films to film festivals such as the Göteborg Film Festival, their reasoning being that digital keys are not always reliable and can cause problems, but also because sometimes the venue needs to be changed at a short notice. Others send their films encrypted but with liberally timed keys, lasting for days, weeks or even months, to help minimise problems.
Which we appreciate. None of us is against the companies protecting their property; while digital keys are a hassle, the actual license files are small and can easily be distributed through email, FTP, etc.
But not every film distributor or production company will understand or even care about what we think or what problems they help create.
Last night, I screened the Spanish film Living Is Easy with Eyes Closed, a charming story about what happened when John Lennon came to Almeria, Spain, to act in a film. About halfway through, I noticed that the server's screen warned that the film's license key had expired. It stated that the show contains "one or more unlicensed clips".
Someone, somewhere, had decided that since it was the only screening at my cinema, the Draken, there was no need to wait until the show was over, which was around 1 AM. As if, after a 17-hour workday, I would stick around to scan the film, never mind the fact that the server manufacturer, Dolby, has other arrangements in place to prevent me from doing so.
Yet, the film is already available on the internet (I checked).
Now, if someone had fainted in the auditorium during the film (which happened two nights ago, by the way) and I had been forced to pause the film, I would not have been able to continue the show. The key will allow us to finish an ongoing show but not to interrupt it and finish it later.
I'm sure the director, who was present at the screening for a midnight Q&A, would have been thrilled to explain why the audience didn't get to see the conclusion of his film.
Last year, we screened Spring Breakers, one of Hollywood's many attempts at making money from showing bikini-clad teens, in this case Selena Gomez (in spite of the fact that I hear it's easier to watch moving images of scantily clad females on the internet). The license key was timed between fifteen minutes before the screening started and one hour forty-five minutes after, making any kind of check by me to check the image format and noting a curtain call cue an impossibility, not to mention the fact that had something happened during the screening and we had been forced to stop it, we again had risked not being able to finish the show.
The production company didn't stop there, however. They also distributed night vision binoculars to the ushers, with strict orders to monitor the audience during the show. They also wanted to place a guard in the projection booth for the duration of the screening, but I refused, informing the festival that said guard would also have to run the show since I wouldn't be there.
We do our utmost to run beautiful shows. We take pains to ensure that the screening is as good as we can possibly make it, running a few minutes of every film to see that it's OK, that the key works, that the image aspect ratio is the correct one, that the audience gets value for their money - tickets are quite expensive these days and most of us regard the audience as our true employers - but the production companies and film distributors aren't helping.
I think I speak for most of us when saying that we don't do what we do for them. Had it only been them I doubt I would have bothered at all, to be honest.
Trust is earned; it's not given freely and they haven't done anything to earn mine.
Thursday 30 January 2014
Sunday 26 January 2014
Finally, A Book About eXist
O'Reilly just released an early draft of Erik Siegel and Adam Retter's eXist book, aptly named "eXist". The timing is perfect, as I have not yet finished my XML Prague demo that, as you might know if you've read my earlier blog posts, features eXist.
Guess what I'll be reading the next few days?
Guess what I'll be reading the next few days?
This Year's Göteborg Film Festival Logo...
...is pretentious and boring.
I mean, really? What were you thinking? That, after a dozen shows, anyone would still even pretend to like it?
Please, filmmakers: Don't quit your day jobs. If you have them, that is.
I mean, really? What were you thinking? That, after a dozen shows, anyone would still even pretend to like it?
Please, filmmakers: Don't quit your day jobs. If you have them, that is.
Wednesday 22 January 2014
T-2 Days and Counting
The annual Göteborg Film Festival is almost upon us, with only two days left when I write this. 11 days of film and, for me, 11 days of clicking Play because it's all digital now, with the exception of one (1) film.
I've written about the advent of digital film before, but also about the death of a profession, and while I briefly considered another stab at these two subjects, I quickly came to my senses; I feel that I've said pretty much everything I have to say on the subject. This year's festival is merely a confirmation of those two blog posts, and there is little reason to reiterate any of it.
So I'll write about the death of a cinema instead. More specifically, my cinema, the Draken, until recently the last surviving Cinerama theatre with its original appearance intact, until last summer mostly unchanged by both the ravages of time and pitiful small-screen multiplexes. It survived them both, although Svensk Filmindustri, Sweden's only cinema owner of note, did have plans to convert the theatre into a double-screen abomination in the early seventies.
What it didn't survive, in the end, was the long-planned "renovation" by its owner, Folkets hus, a k a Sweden's working class movement. The original 1950s chandeliers were thrown away and holes cut into the marble walls to lead the way to toilets forced into the space under the auditorium. Light riggings were carelessly hung up in the auditorium itself and computer-controlled fluorescent lights with only nominal dimming capabilities were allowed to replace the old auditorium lighting.
And in the large upper foyer, the maritime-themed painting that used to be the pride of the cinema has now been replaced by a motorised conference screen. My cinema has now been reduced into a pathetic two-screen cinema. Or, rather, conference hall. Well done, Folkets hus.
Those closest to you are the ones that can hurt you the most.
I've written about the advent of digital film before, but also about the death of a profession, and while I briefly considered another stab at these two subjects, I quickly came to my senses; I feel that I've said pretty much everything I have to say on the subject. This year's festival is merely a confirmation of those two blog posts, and there is little reason to reiterate any of it.
So I'll write about the death of a cinema instead. More specifically, my cinema, the Draken, until recently the last surviving Cinerama theatre with its original appearance intact, until last summer mostly unchanged by both the ravages of time and pitiful small-screen multiplexes. It survived them both, although Svensk Filmindustri, Sweden's only cinema owner of note, did have plans to convert the theatre into a double-screen abomination in the early seventies.
What it didn't survive, in the end, was the long-planned "renovation" by its owner, Folkets hus, a k a Sweden's working class movement. The original 1950s chandeliers were thrown away and holes cut into the marble walls to lead the way to toilets forced into the space under the auditorium. Light riggings were carelessly hung up in the auditorium itself and computer-controlled fluorescent lights with only nominal dimming capabilities were allowed to replace the old auditorium lighting.
And in the large upper foyer, the maritime-themed painting that used to be the pride of the cinema has now been replaced by a motorised conference screen. My cinema has now been reduced into a pathetic two-screen cinema. Or, rather, conference hall. Well done, Folkets hus.
Those closest to you are the ones that can hurt you the most.
Oh, and...
...most of the ProX stuff is available at Github. Not the eXist web pages, yet, but that's because I'm still experimenting with them and there's some work left. There's the Balisage demo, and there's the basic ProXist stuff, with pipelines and XQueries and such, and there's the authoring environment (with Relax NG schema, FO, etc), but no instructions on how to get any of it to run, yet.
I have a test app running locally, a little something that is about as simple as I can make it, but since I am not a web developer (I'm a markup geek), the HTML is awkward, the CSS nonexistent apart from the default eXist stuff, and the XQueries somewhat painful. I do think it's going to be pretty cool, though, and look forward to presenting it at XML Prague.
I have a test app running locally, a little something that is about as simple as I can make it, but since I am not a web developer (I'm a markup geek), the HTML is awkward, the CSS nonexistent apart from the default eXist stuff, and the XQueries somewhat painful. I do think it's going to be pretty cool, though, and look forward to presenting it at XML Prague.
ProXist and My XML Prague Paper
I recently submitted the final version of my XML Prague whitepaper about my eXist implementation of ProX, called ProXist (with apologies for the tacky name). While I'm generally pleased with the paper, the actual demo implementation I am going to present at the conference is not quite finished yet and I wish I had another week to fill in the missing parts.
Most of the ProXist stuff works but there are still some dots to connect. For example, something that currently occupies the philosophical part of my brain has to do with how to run the ProX wrapper process, the one that configures the child process that actually does stuff to the input. ProX, so far, has been very much about automation and about things happening behind the scenes, and so I have aimed for as few end user steps as possible.
My Balisage ProX demo was a simple wrapper pipeline that did what it did in one go. Everything was fitted inside that pipeline: selecting the input, configuring the process that is to be applied to the input in an XForm, postprocessing the configured process and converting it to a script that will run the child process, running the child process, saving the results. Everything.
But the other day, while working on the eXist version and toying with its web application development IDE, it dawned on me that there doesn't have to be a single unified wrapper process. If its components are presented on a web page and every one of them includes logic to check if the information from a required step is available or not (for example, a simple check to confirm that an input has been chosen before the process can be configured), they don't have to be explicitly connected.
The web page that presents the components (mainly, selecting input and configuring the process to be applied on the input) then becomes an implicit wrapper. The user reads the page and the presentation order and the input checks are enough. There is no longer a need a unified wrapper process.
Now, you may think this is obvious, and I have to admit that it now seems obvious to me, too. But I sometimes find it to move from one mindset (for example, that automation bit I mentioned, above) to another (such as the situation at hand, the actual environment I implement things in) as easily as I would like. If this is because I'm getting older or if it's who I am, I don't know. In this particular case, I was so convinced that the unified wrapper was the way to go that it got in the way of a better solution.
At least I think it's a better solution. If it isn't, hopefully I can change my mind again and in time.
See you at XML Prague.
Most of the ProXist stuff works but there are still some dots to connect. For example, something that currently occupies the philosophical part of my brain has to do with how to run the ProX wrapper process, the one that configures the child process that actually does stuff to the input. ProX, so far, has been very much about automation and about things happening behind the scenes, and so I have aimed for as few end user steps as possible.
My Balisage ProX demo was a simple wrapper pipeline that did what it did in one go. Everything was fitted inside that pipeline: selecting the input, configuring the process that is to be applied to the input in an XForm, postprocessing the configured process and converting it to a script that will run the child process, running the child process, saving the results. Everything.
But the other day, while working on the eXist version and toying with its web application development IDE, it dawned on me that there doesn't have to be a single unified wrapper process. If its components are presented on a web page and every one of them includes logic to check if the information from a required step is available or not (for example, a simple check to confirm that an input has been chosen before the process can be configured), they don't have to be explicitly connected.
The web page that presents the components (mainly, selecting input and configuring the process to be applied on the input) then becomes an implicit wrapper. The user reads the page and the presentation order and the input checks are enough. There is no longer a need a unified wrapper process.
Now, you may think this is obvious, and I have to admit that it now seems obvious to me, too. But I sometimes find it to move from one mindset (for example, that automation bit I mentioned, above) to another (such as the situation at hand, the actual environment I implement things in) as easily as I would like. If this is because I'm getting older or if it's who I am, I don't know. In this particular case, I was so convinced that the unified wrapper was the way to go that it got in the way of a better solution.
At least I think it's a better solution. If it isn't, hopefully I can change my mind again and in time.
See you at XML Prague.
Monday 6 January 2014
ProXist
I've been working on an eXist-based implementation of my XProc abstraction layer, ProX, hoping to have something that runs before XML Prague, next month. It turns out that the paper I submitted on the subject has been accepted, so now I guess I just have to.
The ProX implementation should not be terribly complicated to finish, but until recently it risked to be rather hackish (is that a word?) because the XMLCalabash eXist module written by Jim Fuller was rather primitive: it would only support pointing out the pipeline to run and one, hard-coded output port. I foresaw a more or less complete rewrite of the ProX wrapper in XQuery.
Luckily, Jim very graciously agreed to rewrite his module into something more immediately usable. I received the first updated module to test in December and the most recent update just a few days ago. He also found a bug in Calabash's URI handling and sent a first fix to me along with the updated module. There are still things to do but for me, Christmas came really early this year.
Oh, and I'm calling the implementation, and the paper, ProXist. Sorry about that.
The ProX implementation should not be terribly complicated to finish, but until recently it risked to be rather hackish (is that a word?) because the XMLCalabash eXist module written by Jim Fuller was rather primitive: it would only support pointing out the pipeline to run and one, hard-coded output port. I foresaw a more or less complete rewrite of the ProX wrapper in XQuery.
Luckily, Jim very graciously agreed to rewrite his module into something more immediately usable. I received the first updated module to test in December and the most recent update just a few days ago. He also found a bug in Calabash's URI handling and sent a first fix to me along with the updated module. There are still things to do but for me, Christmas came really early this year.
Oh, and I'm calling the implementation, and the paper, ProXist. Sorry about that.
Subscribe to:
Posts (Atom)