2017-09-18

Disques, partitions et "filesystems" ...

Un résumé (en anglais) des différents types de formatage de disques pour pouvoir échanger des disques durs ou clés USB entre Mac, Windows et Linux: Hard drive partitions and file system essentials.

2016-09-15

Un délicieux petit manuel de cinéma documentaire d'auteur

Ca a plus de vingt ans, mais je crois que ça reste d'actualité:




(il y a des sous-titres français et allemands en cliquant sur les bons boutons sous la vidéo)

Labels: ,

2015-11-16

Notes on workflow with Avid

After writing recommendations about workflows several times for different projects, I tried to summarize things on a more generic page.

Since it is a bit too long for a blog post, it is on a separate page:
Avid workflow summary.

It is mainly about syncing, timecode, export to sound design, and some specific details, because these are the things I have often seen done wrong, or get asked about. I guess I will update it occasionally, so you can suggest corrections or additions in the comments of this post.

Labels: , , , , , ,

2013-11-04

Which size for DCP subtitles?

A question about the "best" size of DCP subtitles piqued my curiosity. Since I have access to a sample of DCP folders from a distributor, it was easy to do some statistics and find out what others felt was the right size for subtitles.

Executive summary: the answer is 42, which seems perfectly appropriate since it also happens to be "the answer to life, the universe and everything". (If you didn't know, you may be interested to see that Google's calculator does, and gives you the correct answer when asked this essential question).

 

All the DCP's I had access to used the CineCanvas (or Interop) standard for subtitles, which is described in the "Subtitle Specification for DLP Cinema" published by Texas Instruments. The document doesn't give an "official" size recommendation for subtitles, but it does provide a default size if the file doesn't specify it. The default is 42.

It also explains what the number 42 is supposed to mean (in the context of subtitles, not in that other more profound meaning):

"Size is given in points. Fonts are rendered as if the screen height is 11 inches, so a 72pt font would be 1/11 screen height.
Default Size = 42"

And that also seems to be the preferred size for the 124 feature length movies in my sample:


Font Size Number of DCPs
36 1
37 2
38 7
39 21
40 10
41 3
42 68
44 6
45 3
46 1
47 1
48 1
Total 124

 

That disk also had 40 trailers with subtitles. For these, the preferred font size seems to be smaller at 39:

Font Size Number of DCPs
39 31
40 1
41 1
42 6
44 1
Total 40
 

Points and pixels

There are 72 points per inch, so the screen height is 11 * 72 = 792 points.
In 2K, the DCP sizes are:
  • 2048 x 1080 pixels for full frame
  • 1998 x 1080 pixels for 1.85
  • 2048 x  858 pixels for Cinemascope (2.39)
(In 4K, the sizes would be 4096x2160, 3996x2160 and 4096x1716 pixels)
So in full or 1.85:
  • 792 points = 1080 pixels
  • 1 point = 1.3636... pixels
  • 1 pixel = 0.7333... points
  • 42 points = 57.3 pixels
In Belle-Nuit Subtitler, the subtitle size appears to be set in pixels, which it then converts to points when exporting to "DLP Cinema".
I'm not sure about Cinemascope. Would 42 points be rendered as 45.5 pixels (42x858/792) ? Or still as 57 pixels ? Or would it depend on the projector ?
 

Labels: , , ,

2013-10-15

Sony F55 quirks

After working 6 weeks with a Sony F55 on a feature shoot, here are a few notes focusing on some idiosyncrasies of this quite nice camera.

Basically, the camera feels like a mini-version of the Alexa. I don't know how much cheaper it is, but it is definitely a lot lighter. With a Fujinon 19-90 zoom, this is a very nice solution for shoots where an Alexa with an Allura zoom would be much too cumbersome (or too expensive?).

We used it to shoot XAVC S-Log with normal gamut, and were very satisfied with the grading tests we did during preparation.

However, the camera has many little quirks which may be worth knowing about. It does excellent pictures, but don't expect the reliability and solidity of an Alexa. The firmware we used is version 1.21 from August 2013.

Hole in camera body

The biggest problem was a hole in the camera body, which produces flares on the sensor when the sun hits the hole under the right angle. Not all models seem to have this hole. Most cameras turned up by this Google image search don't have it. But this video does show the same hole that we found on our camera body, between the viewfinder connector and the focal plane mark.

 

I suppose that is where a viewfinder connector cap would be attached. If the cap is removed, it opens a path for light to the sensor. Our camera had an Arri "VFA-1 Viewfinder Adapter". I guess that cover was removed when the Arri adapter was installed.

The problem was easy to fix with some black tape, but it had already ruined 1 shot when we found out.


Genlock

The camera's manual says it accepts many different signals on it's Genlock input. We used an Ambient timecode generator, and set it to send a 1080p25 signal. The camera didn't accept that, nor did it accept a 1080p50 signal. However, 1080i50 seemed to be accepted, even though we were really shooting 25p.

Timecode

We made the effort to find the correct Genlock which the camera would take, in the hope to have reliable frame-accurate timecode sync with the external audio recorder. But even with a Genlock feed from the Ambient to the camera, the external audio is still often 1 frame in advance of the picture (and the camera's audio), sometimes even close to 2 frames. Apparently, timecode-synced external audio is never late in relation to the camera audio and picture. It is either correct, or 1 or 2 frames early. (On a 7 week shoot with the Alexa last year, timecode sync was frame accurate on every shot).

Another problem related to TC is the "EXT-LK" indicator on the display. It is supposed to show when the camera receives external timecode. The problem is that if you remove the external timecode, and even reboot the camera, the display continues to show "EXT-LK", even though it is obviously wrong. So don't rely on it.

And of course, you do need a permanent external generator. The internal one will drift much too quickly, like with (almost) any other camera.

Camera randomly stops after starting

A few times per week, the camera would appear to start, and then stop after about 2 seconds. When it happened, it tended to happen a few times in a row, and then not at all for several days. We were always starting the camera with the "Assign 4" button which was mapped to "Rec". I don't believe it had anything to do with the way the button is pressed. Weird.

Spurious "backup battery" error

Twice during the 6-week shoot, the camera said the backup battery was bad and needed to be replaced. Rebooting the camera seemed to clear this "error", which looks more like a sensor or software error, than a real problem with the backup battery. After the reboot, the date and time were still correct, but the timecode had reverted back to "rec run" instead of our "free run" setting. The other settings had been preserved.

WiFi remote: fun but unusable

We wanted a remote switch, and the only option we had available was the WiFi dongle. It was fun to try it out, but after playing with it for a while, I wanted to actually use it three times, and these were exactly the times when it failed. It is much too unreliable to be of any real use.

The problem seems to be that the wireless connection gets lost very easily, even when the smartphone I used was less than 1m. away from the camera. This was a Samsung/Android phone, with which I otherwise never have wireless problems.

The worst case was when we started the camera from the phone, and then couldn't stop it. Neither with the phone, nor with the switches on the camera. Nor could we shutdown the camera with the power switch. The only solution was to remove the battery. Of course, if you want to use a remote switch, it's usually because there are some difficulties with the shot, so it's definitely the time when you don't want to have weird bugs show up. That is when we stopped trying to use the wifi.

Can't we just have a 2-wire cable with a mechanical switch for starting and stopping the camera remotely? It may not be trendy and fun, but definitely tends to "just work".

Timezone

The camera has no notion of daylight savings time. So when shooting during the summer, you have to set it to your neighbor timezone to get correct times in the metadata and (some of) the file timestamps (some time stamps will still be completely off for some other reason).

File times

While the "CreationDate" recorded in the XML matches the camera's time, some (not all) of the .MXF files on the card have weird modification times. That means you cannot rely on the times displayed by your file manager. I still don't know what triggers this weird behavior. Battery change? Viewing clips? Something else?

Aspect marker

We were shooting scope, and used the apsect marker mask. It would be nice if the aspect mask could remain even when using the "display" button to turn off all other information in the display. And it would be nice if the mask could also be sent out on the second SDI output, to avoid the need to mask the monitors with tape or whatever.


Labels: , , ,

2013-08-12

burnt-in timecode with ffmpeg

Burning-in timecode is easy in Avid or Final Cut, but if for any reason you need to do it the hard way with command-line ffmpeg, here is how.

To not make it harder than necessary, there are links to pre-compiled versions of ffmpeg on their download page. For Mac OS X, as of August 2013, there were these 2 versions:

  •  http://ffmpegmac.net, which unfortunately didn't have the needed filter. It would give the error
    "AVFilterGraph ...] No such filter: 'drawtext'".
  • the version 2.0.1 built by Helmut Tessarek worked fine. Unfortunately, it is compressed with 7-zip, so you may need to get a decompressor first. I used Keka (not open source, but free).

Below is the command I used to quickly encode Sony mpeg2 MXF files into H264 Quicktimes, preserving the original timecode in the QT TC track (ffmpeg does this automatically), and also burning it into the picture.

Since the command itself is quite awful, it is best to predefine variables, so that the long command itself can be copy/pasted directly, without further editing, or at least not too much...

# set variables for the input and output files:

in=/path/to/input_file
out=/path/to/ouput_file.mov

# the timecode rate must be set. Should be identical to the FPS.

tc_rate=25

# select a monospaced font file on your machine. On Linux, try:

font="/usr/share/fonts/truetype/droid/DroidSansMono.ttf"

# or on Mac:

font="/Library/Fonts/Andale Mono.ttf"

# size and position:

fontsize=46
position="x=w-text_w-(text_w/6):y=text_h" # top right

# For bottom right, try this instead: position="x=(w-tw)/2: y=h-(2*lh)"

# get the timecode, and escape the ":" to be able to use it in the burn-in filter

timecode=$( ffmpeg -i "$in" 2>&1 | awk '$1 ~ /^timecode/ {print $NF}' )
tc_escaped=${timecode//:/\\:}

# To test encoding only the first x seconds, use:

test_secs="-t 20"

# or for the whole video, leave this empty:

test_secs=

# quality/size/speed : (try crf between 18 and 25? lower is better quality and bigger file.)

crf=23
preset=ultrafast # (superfast, fast, slow, ...)

# And finally (with de-interlacing and without scaling):

ffmpeg -threads 0 -i "$in" $test_secs -acodec copy -vcodec libx264 -preset $preset -crf $crf -deinterlace -vf "drawtext=fontfile=$font: timecode='$tc_escaped': r=$tc_rate: $position: fontcolor=white: fontsize=$fontsize: box=1: boxcolor=black@0.2" "$out"

or to keep only video with audio channel 1 (throwing away audio channels 2, etc. ):

ffmpeg -threads 0 -i "$in" $test_secs -map 0:0 -map 0:1 -acodec copy -vcodec libx264 -preset $preset -crf $crf -deinterlace -vf "drawtext=fontfile=$font: timecode='$tc_escaped': r=$tc_rate: $position: fontcolor=white: fontsize=$fontsize: box=1: boxcolor=black@0.2" "$out"

 

Labels: , , ,

2012-02-01

SxS cards crash OS X 10.6.8

The SxS card driver from Sony is not compatible with the latest (and last?) Snow Leopard update 10.6.8, at least on some Mac Book Pro models. When inserting an SxS card into the Express card slot, the system crashes with a "kernel panic".

Apparently, Sony has no intention to fix the problem. This is what they say on their download page:

Attention (July 2011): Users of MacBook PRO* with Intel CoreDuo Processor (*Early 2006 Model: MA464/MA092)
Sony has found that a message will appear to say you need to restart your CoreDuo-based MacBook PRO when you update the OS to Mac OS X 10.6.8 (released on June 23, 2011) and insert an SxS Memory Card into its ExpressCard slot. We do not recommend that you update your OS to 10.6.8. If you have already updated your OS and could not switch back to the previous version (such as 10.6.7), please use your SxS card in an XDCAM or XDCAM EX video recording product, connecting it to your Mac via the USB cable. You may also be able to use your card with an 'SxS Memory Card Reader/Writer SBAC-US10,' which is sold separately.

If you have this problem, the only solution seems to be a re-install of the OS. Then, a system update to 10.6.7, and finally disabling all further automatic updates.

If you are thinking of avoiding a re-install and doing a downgrade from 10.6.8 to 10.6.7 instead, forget it. I tried, and failed miserably, ending up with an unbootable machine (kernel panic straight away at startup). But if you do know of another solution than a re-install, please leave a comment.

Labels: , ,