Nanoflash advice for AF101

[blackcat]

I'm planning to do grading in Color. I'm shooting for at the very least some art house theatrical release, and I know you say it doesn't matter what I shoot on, (Blair Witch Project anecdote yaddi yadda) but the content of the story. Still, this Wilt stuff makes me wonder, if it's not good enough for BBC is it good enough for theatrical release?

Good enough is relative.

Indy film is my reason for doing digital video. I just do freelance work to pay the bills between projects. I know other folks in the indy film world who are shooting on the AF100. If you are looking for a sub-10k camera with a true video camera form factor, large sensor, xlr inputs, and interchangeable lenses, the AF100 is your only choice at the moment. As far as we know, by this summer there will only be two choices. If you want to consider a DSLR, that is an option, but I don't see how that is going to give you any better shot at a theatrical release. The Sony F3 with an external recorder is a good option, and it is a much more expensive one. I expect to see some F3 productions coming out over the next 1-3 years.

Plenty of people get into major festivals with 4:2:0. At least the last time I talked to anyone, they weren't demanding 4:2:2. Now, getting a theatrical release is extremely difficult no matter what you shot it on.

The BBC has its own specifications, and they were set high enough to cut out all of the indy level HD cameras at first. All of the people I know who have finished successful independent film projects worked on cameras that did not have BBC approval for their highest end HD. All of the cameras are changing very quickly though. By the time an independent feature gets finished and goes to distribution, the camera that it was shot on is more or less outdated.

If you are shooting a feature, the camera is not going to be your largest expense. Even if you cut and grade everything yourself, you will be out of the job market while you do it.

As far as the AF100 goes, I am grading in color with the native codec without a problem. Being fairly experienced in color, it meets my expectations for this type of camera. I am also watching the Ninja, but I am going to wait to see what others say about it.

 

[jdesignhi]

The Nano also enables the ability to shoot true 1080/60p with audio. The AF100 disables audio recording during overcranking, but still outputs the audio over its SDI and HDMI output, and the Nano can record that. You could then "conform" the resulting 1080/60p files from AVCCAM to 60fps, plug in the audio from the Nano, and have true "live" 1080/60p footage.

Hi Barry,

When shooting 1080/60p on the AF, doesn't it output a 1080/30p signal (audio and video) out the HD-SDI and HDMI ports at the same time that it records the 1080/60p signal to the internal SD cards? And, if so, Dan, what would the appropriate settings be on the Nano?

Many thanks, friends—

Jeff

 

[dcloud]

I'm enlightened. Thank you, but you should also note that "not true HD" and "600 lines" were issues raised and used in the Alan Roberts report and I was simply making a reference to that report and the whole thread it spawned. Maybe you should read it? I wish the knowledgeable on this site wouldn't be so caustic and pompous when educating fledgling filmmakers like myself.

in my experience, a shot where a dslr shows more than 600 lines it moires/alias and made the footage unusable.
but for some reason the af100 does it fine without problem. and it doesnt blur it, it resolves data in it. more than a dslr.

ive shot side by side with dslrs and dslrs are a bit softer. the af100 resolves a bit more detail (albeit very unnoticeable to normal viewers.) this does prove that its not as sharp as an xdcam but it does outresolve and outperform a dslr.

 

[Barry_Green]

When shooting 1080/60p on the AF, doesn't it output a 1080/30p signal (audio and video) out the HD-SDI and HDMI ports at the same time that it records the 1080/60p signal to the internal SD cards?

It outputs 1080/60i. And on the Nano it will automatically adjust to recognize the incoming 1080/60i signal.

 

[Dan Keaton]

In some Panasonic Camera manuals, they describe the output of their cameras as 1080i59.94 or 1080i60 or use similar terms (such as 1080/60i) when actually they are, in some cases 1080psf29.97 or 1080psf30.

Background:

The "psf" means "Progressive Segmented Frames". This is a nice way to allow older monitors, ones that can not handle true progresive images to accept a progressive image, since PSF makes it appear to be interlaced.

In our experience, I cannot remember finding a camera, that in progressive mode, puts out anything other than Progressive Segmented Frames. So PSF is very common.

In PSF, the odd lines are put into one field, and the even in the other field, with two fields making up a frame.

This is very similar to interlaced, but it starts out with a progressive sensor.

The nanoFlash has an option to take the two fields and recreate the original true progressive frame and record it.

Thus, when enabled (in our Video|Record PSF>Prog(ressive) menu item), then we will convert what looks like 1080i59.94 or 1080i60 to 1080p29.97 or 1080p30.

This, of course is what one would want us to do. The camera has a true progressive sensor, and we record a true progressive frame.

I was stumped for a while with the Panasonic HDX900. It's 1080 mode was only outputing (according to Panasonics's specs as 1080-59.94i).

I did a lot of research and determined that it was actually 1080psf29.97.

With this knowledge, we did a lot of testing and determined we could get many extra flavors of 1080 out of the HDX900.


Now, with the AF100, I am certain that the 1080/60i is truely a PSF signal.

Thus, if you are shooting in the AF100 with a frame rate of 30, you should enable our Video|Record PSF>Prog(ressive) option.

Note: the nanoFlash automatically sets this option for 1080psf23.976, 1080psf23.98 and 1080psf24.

I hope this helps.

 

[Barry_Green]

The AF100 outputs 24PsF if you are shooting in 24p and have the 24PsF option turned on. It is a true, properly-flagged PsF, and monitors that understand an incoming PsF signal will auto-adjust to scan at 24fps, which is very nice. And it works perfectly with the Nano.

In other modes, it is outputting either a progressive signal embedded in 59.94i, or it is outputting a true 59.94i (because, lest we forget, the AF100 does have the ability to scan and record actual interlaced footage too).

The Nano automatically recognizes and properly records 1080/30p as PsF from the AF100.

What I haven't tried, is whether it would understand variable frame rates as true progressive, from lower-than-30p frame rates. Example -- would it know how to record a true 12p or 18p? I doubt it, but maybe it would. If Convergent updates the system so that it reads the "valid field" and "duplicate field" flags from the timecode stream, it may indeed become possible to record and store a true variable-frame-rate signal from the AF100 in both 720p and 1080p modes (but only up to 30p in 1080, because faster-than-30p can't be done on HD-SDI and the AF100 starts outputting fields instead of frames at that point; it records true progressive frames to its internal codec, but the output over HD-SDI can't be true progressive frames faster than 30p because HD-SDI is incapable of transmitting that much data.)

 

[Dan Keaton]

Dear Barry,

Most cameras, as far as I know, when they are set for variable frame rates (such as Sony's Slow and Quick modes), typically output the full number of frames over the HD-SDI interface.

This works very nice for external recorders, like the nanoFlash.

You can record at one variable frame rate in the camera, and choose another via the nanoFlash's Crank Function.

Thus, the AF100 will output 720p59.94 (frequently called 720p60) and we can record, in Crank Mode from 1 to 60 frames per second.

In 1080p29.97 (fequently called 1080p30), we can record in Crank Mode from 1 to 30 frames per second.

I our Crank Mode, one first sets the timeline base frames per second, typically 24 frames per second, then sets the Crank value to the number of frames per second to be recorded.

Except in special cases, the nanoFlash does not record audio while in Crank Mode. This, of course, is typical of variable frame rate applications.

One special case is timeline base of 24, with a crank of 24.

There is also a way to ramp the crank rate while recording. This requires a trip to our manual for the proper keystrokes.

 

[Barry_Green]

Most cameras, as far as I know, when they are set for variable frame rates (such as Sony's Slow and Quick modes), typically output the full number of frames over the HD-SDI interface.

I don't think that's true... HD-SDI doesn't support variable frame rates as a protocol. The cameras have to embed their variable frame rates within a standard transport signal, which would be 24PsF or 59.94i.

Unless we're saying the same thing but coming at it from different angles.

Here's what the AF100 does -- its SDI is always outputting 720/60p (we'll use 60p to avoid interlacing issues). No matter what frame rate you set the camera at, it will always output sixty frames on the SDI output. If you set the camera at 30p, it will still output sixty, but those sixty will not all be unique. It will output duplicate frames. If you set it to 12fps, each frame will be output on the SDI five times. If you set it to 30p, each frame will be output twice. If you set it to 20p, each frame will be output three times.

Now, when it is output, the camera flags which frames are "originals" and which are "duplicates". If the Nano would read those flags out of the timecode stream, it could discard all the duplicates and only store the originals. That's how "pN" mode works on the P2 cameras, and that way it would make an easy, one-stop, always-guaranteed-to-work system with the Nano. By using your "crank" feature, you may or may not be getting the right cadence. Here's an extreme example -- 54 frames. When you tell the AF100 to record 54 frames, it will generate and output 54 unique frames and six duplicates on the SDI. If you told the Nano to record only 54 frames, how would it know which were the genuine originals and which were the duplicates? I doubt it would work. I would strongly suspect that if it isn't reading the timecode stream to differentiate real from duplicate frames, it's not going to have the proper cadence.

Now, when you go to 60i it becomes more complex, because the camera has to split frames into fields. Again, the camera will output flags to identify the right fields for proper reassembly into progressive footage, but you'd need to be reading those fields in order to assure getting the footage accurately.

I believe that the Nano's crank feature would be useful for a camera that doesn't have its own variable-frame-rate capability, but it is not the right way to store footage from a camera that is designed to do variable frame rates inherently. I do encourage you to inspire your engineers to research this and hopefully implement a firmware update that recognizes the frame flags and stores the valid frames, it would be a very welcome addition to your already-excellent product. Reading the frame flags out of the timecode stream is really the right way to do it and would ensure 100% success in all scenarios.

 

[bgundu]

This must be so tough for 3rd party manufacturers to create products to be used on various cameras as they have they're own protocols

I don't think that's true... HD-SDI doesn't support variable frame rates as a protocol. The cameras have to embed their variable frame rates within a standard transport signal, which would be 24PsF or 59.94i.

Unless we're saying the same thing but coming at it from different angles.

Here's what the AF100 does -- its SDI is always outputting 720/60p (we'll use 60p to avoid interlacing issues). No matter what frame rate you set the camera at, it will always output sixty frames on the SDI output. If you set the camera at 30p, it will still output sixty, but those sixty will not all be unique. It will output duplicate frames. If you set it to 12fps, each frame will be output on the SDI five times. If you set it to 30p, each frame will be output twice. If you set it to 20p, each frame will be output three times.

Now, when it is output, the camera flags which frames are "originals" and which are "duplicates". If the Nano would read those flags out of the timecode stream, it could discard all the duplicates and only store the originals. That's how "pN" mode works on the P2 cameras, and that way it would make an easy, one-stop, always-guaranteed-to-work system with the Nano. By using your "crank" feature, you may or may not be getting the right cadence. Here's an extreme example -- 54 frames. When you tell the AF100 to record 54 frames, it will generate and output 54 unique frames and six duplicates on the SDI. If you told the Nano to record only 54 frames, how would it know which were the genuine originals and which were the duplicates? I doubt it would work. I would strongly suspect that if it isn't reading the timecode stream to differentiate real from duplicate frames, it's not going to have the proper cadence.

Now, when you go to 60i it becomes more complex, because the camera has to split frames into fields. Again, the camera will output flags to identify the right fields for proper reassembly into progressive footage, but you'd need to be reading those fields in order to assure getting the footage accurately.

I believe that the Nano's crank feature would be useful for a camera that doesn't have its own variable-frame-rate capability, but it is not the right way to store footage from a camera that is designed to do variable frame rates inherently. I do encourage you to inspire your engineers to research this and hopefully implement a firmware update that recognizes the frame flags and stores the valid frames, it would be a very welcome addition to your already-excellent product. Reading the frame flags out of the timecode stream is really the right way to do it and would ensure 100% success in all scenarios.

 

[Barry_Green]

I've talked with Dan before about how they implemented it and I think they have a pretty clever idea that means it can work on other types of cameras too. Unfortunately it's not working perfectly with the AF100, it doesn't properly strip out pulldown out of 720p mode etc. But if they can implement the flagged frames feature, it will work the right way all the time...

 

[Dan Keaton]

Dear Barry,

I agree with all of your points. And yes, basically, I was trying to say what you said at the start of your post.

We have many other features besides Cranking.

In one, we convert 720p60 to 720p30 (provided that the camera is set for 720p30 and outputting duplicate frames over 720p60.

In another, we convert 720p60 to 720p24, and 1080i60 (actually PSF) to 1080p24 if the camera is adding pulldown frames.

Bgundu, very astutely pointed out that it must be tough, as each camera or camera manufacturer may have it's own protocol to flag duplicate frames.

We detect duplicate frames by checking each and every frame to see if it is the same from the previous one. Technically, I believe we do this at the start, to determine a pattern, then we follow the pattern. Our Chief Engineer is away at this moment, so I cannot confirm this.

But, I do know that we examine the frames (very carefully) to determine if we have duplicate frames (to avoid having to implement the various flagging protocols).

Our scheme has worked very well, up to the AF100.

While we have purchased an AF100 in our lab, our engineers have been swamped and thus I do not have an answer, or a fix for the issue you mentioned.

Just to be clear, one should not use, to the best of my knowledge, our Cranking feature in an attempt to remove "pulldown frames" (which are duplicate frames). We have other tools to do so (all of which may not be currently working with this one camera, the AF100, at this time).

As soon as possible, we will find and fix this issue.


We will get to this as soon as possible.

Thus, we have (for most cameras), pulldown removal (almost any pattern) for 720p and 1080, and this includes 2:2 pulldown.

But, we have more work to do to determine what is preventing our code from working, in certain cases, with the AF100.

 

[Torontonian]

Hi Dan,

Thanks for all of this info! And thanks to Barry as well!

I wanted to follow up and ask about recording 720/24p using the Nanoflash on the AF100. Is this possible? I'll be shooting at a tight turnaround event and will need to hand off MXF files to an Avid editor. I've read conflicting info as to whether this is possible. If not, are there other solutions I'm not considering?

Thanks for any insight you can give!

 

[Katty Galloo]

What about 'Nano flash' versus 'Ninja' or 'Samurai' ?

 

[Katty Galloo]

And, the Nano is portable to other cameras too. You can use it on an F3, you can use it on an HV40, you can use it on an AF100, etc. Only drawback towards true futureproof-ness is that the Nano uses 8-bit recording, which is fine for today but some cameras (like the F3) put out 10 bits, so to take full advantage of what those camera heads can do you'd want 10-bit recording. For an AF100 that's a non-issue because the AF100 outputs 10 bits.
.

Hey Barry, I hear all over the net, the AF100 outputs 8bits, so am getting a litle confused here is it 10 bits or 8 bits ?

 

[mkfotos.com]

Hey Barry, I hear all over the net, the AF100 outputs 8bits, so am getting a litle confused here is it 10 bits or 8 bits ?

8 bits (apparently in a 10 bit wrapper, but you're only getting 8 usable bits in those 10 bit words).

 

[Katty Galloo]

So the 10 bit wrapper is a commercial trick?

 

[Katty Galloo]

Just to let you know that we've briefly tried the Ninja with the AF101, and it seemed to work fine. So you'll be able to go up to 220Mbit/s on very inexpensive storage media. The SDI version is called the Samurai and has some additional features that we haven't announced yet. All will be revealed at or before NAB.

Dave Shapton
President
Atomos EMEA

Waaw am realy looking forward to that course this is the one I set my goal at , hit me

 

[Barry_Green]

So the 10 bit wrapper is a commercial trick?

All HD-SDI data MUST be in a 10-bit wrapper. That's how HD-SDI works, it always transmits 10 bits.

But many cameras have 8-bit outputs. Most cameras have 8-bit outputs. All the Canon HD-SDI cameras output only 8 bits, all the JVC cameras output only 8 bits, and almost all the low-cost Sony and Panasonic models output only 8 bits. So in order to make 8 bits compatible with SDI, they have to add two zero bits to the signal, creating "8 bits in a 10-bit wrapper". That's not a "commercial trick", that's just how it's done. If you need true 10 bits, you have to pay the money for a true 10-bit camcorder, such as an HPX370.

 

[Katty Galloo]

All HD-SDI data MUST be in a 10-bit wrapper. That's how HD-SDI works, it always transmits 10 bits.

But many cameras have 8-bit outputs. Most cameras have 8-bit outputs. All the Canon HD-SDI cameras output only 8 bits, all the JVC cameras output only 8 bits, and almost all the low-cost Sony and Panasonic models output only 8 bits. So in order to make 8 bits compatible with SDI, they have to add two zero bits to the signal, creating "8 bits in a 10-bit wrapper". That's not a "commercial trick", that's just how it's done. If you need true 10 bits, you have to pay the money for a true 10-bit camcorder, such as an HPX370.

Ok Barry, thanks for the expenation, now I see clear