F35: Tutorial - How to Record & Extract VFR and Ramp Footage from F23/F35 with Odyssey 7Q

V

Viddovation

Veteran
Tutorial - How to Record & Extract VFR and Ramp Footage from F23/F35 with Odyssey 7Q

Hey guys! As far as I know what I'm sharing is new knowledge that either no one had thought of before, or if they had, was something private and not shared for public use across the group. Apologies if that isn't the case.


Of all the features the F23/F35 originally offered with the SRW1 and Codex recorders, perhaps the most elusive feature set to utilize with the modern SSD recorders is the ramping and VFR (Variable Frame Rate Options). The SRW1 and Codex accomplished this feat because they could read special DDID packets in the ancillary part of SDI feed. While modern recorders could likely be programmed to do this as well, the market segment simply isn't big enough for them to bother spending the time. Luckily, I've determined a work around that while not hassle free, is reliable and poses a limited amount of additional workflow hassle.


Lets first discuss how the VFR/ramping works in the F23 and F35. When you choose a variable frame rate, the IF box continues to pump out frames at the frame rate of the mode you're currently in. However, since less real frames are being generated, some of these are going to be duplicates. The ratio of duplicates to real frames will vary based on the number of frames you've chosen, or where you are in a ramp. These are pixel perfect duplicates. They do not even have different noise distribution, because they are simply a buffered copy of a single sensor image, repeated until the next real sensor image is collected.

While the Odyssey won't automatically remove these duplicates for us, we can have the Odyssey record the entire stream for us, and then use tools on our computer to get an image sequence with no duplicates in two easy steps.

Okay so here are your steps:

1. Get free software called DupeGuru, or an alternate duplicate file remover: https://www.hardcoded.net/dupeguru/
1. Record your VFR/ramping clip on the Odyssey, using the DPX mode.
2. Transfer your DPX image sequence to your work drive - for safety, don't delete or overwite the original folder until you're satisfied with the result!
3. Use Dupe Guru. You have to select your DPX image sequence folder to be scanned. Make sure it is the only folder currently being scanned.
4. Dupe Guru will generate a list of files with duplicates. Make sure to select to view only duplicates - this makes sure one of each file is left unmolested. Then use Command-A to select all, putting checkboxes on all the duplicates. Delete all the duplicates.
5. At this point our image sequence has gaps in numbers. We need to remove the gaps so our video editing software doesn't think we're missing frames. If you have a recent version of OSX, just select all the remaining dpx images, and ctrl click, then use the "Rename Items" option, and use "Format" so that you can set them for sequential numbering.

This should do it. Because dpx files have no compression, the files should be perfect binary matches, making this process super easy and reliable. It is worth noting that the dpx files do contain metadata including the voltage level of the Odyssey. I'm not sure how CD coded this, but it may be possible for this to fluctuate during a recording, resulting in a less than 100% binary match between files. However, Dupe Guru does have the capability to note a close but not perfect match, so this shouldn't cause any real problems.

At this point you can open the dpx sequence and either edit it or re-encode to whatever codec you like. The dpx file is 444, but if you used a 422 mode on the F23/F35 then the data inside is still only from a 422 source. Also, by default the DPX sequence will try to play in the frame rate that had been selected on the camera, so make sure to interpret the footage to whatever frame rate you want if your project rate is not the same frame rate you were using on the camera for your VFR or ramp shot.

This method is going to use your SSD media quickly, because DPX files are big, but on the backend you can save space by removing the duplicate frames, and even by re-encoding to prores once ingested and processed.

Final note: Keep in mind that your audio file will not match up once you do this!!! If you use a constant VFR rate, then adjusting and matching the audio ought to be possible, particularly if you slated, but if you use the ramping feature, you will likely need to go to special effort to put audio to your ramped footage.


Let me know if you have further questions, I'll try to answer.
 
Last edited:
I suspect there are ways of making this work even on compressed frames, using something like ffmpeg with the "mpdecimate" filter. The threshold for considering frames identical is user-definable, which should make for reasonable results.

I haven't tried it.

P
 
Phil Rhodes said:
I suspect there are ways of making this work even on compressed frames, using something like ffmpeg with the "mpdecimate" filter. The threshold for considering frames identical is user-definable, which should make for reasonable results.

I haven't tried it.

P
Click to expand...

Completely agree with you on the theory. Were the DPX method not both reliable and practical given the tools available to me, I would have explored that avenue further.


EDIT:
Of course, with the uncompressed .dpx file we're doing a pure binary match (or very near match), which takes very little computing power. With a compressed image sequence, we're not processing discrete image files, but a decoded stream of images. Our comparisons then would be against each decoded frame. Depending on the compression scheme used, two frames that were identical uncompressed might have some variation by the time they're decoded from the compressed file. So a more computationally intensive alogorithm would be needed to determine the dupe frames. Also, keep in mind the risk of multiple unique frames with little or no action being mistaken for duplicates and being discarded erroneously. This risk would actually diminsh as gain increased!
 
Last edited:
James, is there a particular reason you prefer using in-camera ramping, to recording 50p and doing the ramp in post (where you don't have issues of exposure changes from the ramping)?
 
Grug said:
James, is there a particular reason you prefer using in-camera ramping, to recording 50p and doing the ramp in post (where you don't have issues of exposure changes from the ramping)?
Click to expand...

Well, as this also applies to the F23, 59.94p/60p is also in play.

As to the question. To me, its about options. There are situations where doing ramping in post is going to be easier or even preferable. However, the behavior isn't actually the same, and depending on what you want to achieve you may find the in camera results superior. Having this technique available lets me choose based on the situation.

Let's talk about exposure during ramping. The F23 and F35 permit you to compensate for the exposure change with either a modification in shutter angle or gain. Or you can leave the compensation off, and then yes, you will see a light shift. With the shutter angle compensation the camera will maintain a constant shutter speed (but not shutter angle!), and with gain compensation the camera will maintain constant shutter angle (but not shutter speed!) and keep the exposure constant with gain adjustments. If you don't require a constant shutter angle, that compensation looks good.


So lets address the real differences in end product. If you ramp in post, then you presumably used a constant frame rate, constant shutter speed, and constant gain setting during recording. For argument, we shall assume so. These frames were recorded at equal intervals. In creating a post ramp, you end up needing frames at time intervals that were not recorded. The computer can either choose the nearest frame and use it as is, or it can use image blending techniques to try to approximate what that frame would have been. And, if you want your final product to feel as though it had a constant shutter angle (meaning a varying shutter speed), then it will have to combine multiple frames and blur them together to approximate what the longer shutter would have captured. The quality of the result may depend on what type of motion is being captured.

By contrast, the in camera ramp/vfr will actually space its image sensor frame captures apart at the desired amount of time. It will capture the correct moment in time, with the correct global shutter result. It won't be a guess - it will be accurate. So, if you have the capability of executing the in camera ramp at the correct time, and want to avoid messy computations, then using the in-camera ramp lets you get pixel perfect results.


One more consideration. You asked about ramping, but there is also a very real application for constant rate VFR. With the F35 you can do 8fps to 50fps constant VFR recording. With the F23 that becomes 8fps to 60fps. Some constant VFR rates can be extracted from a base rate by a simple removal of every X frame. From 50p you can extract 2,5,10, and 25 frames per second. With 24p you can extract 2,4,8, and 12. With 30p 2,3,5,6,10, and 15. Just drop every X frame, and its reliable.

But, if you do that you can't get a shutter speed any greater than what would have been 360 degrees for the base recording rate. Mind you, you could carefully average and blur together the sets of frames, but this could only reliably give you an approximation of a 360 degree shutter, and only if you had a 360 degree shutter capture at the base rate.


And of course, if you wanted, for whatever reason, a wonky frame rate, and an accurate shutter angle for it, you couldn't get that. Not really. Any computation in post would be wonky math, and you'd get less than pristine images to work with after blending and such was done.


So situationally, there are reasons to consider using in camera ramping and VFR.
 
Update:

I've realized a limitation. DupeGuru and many other duplicate file finders are not sequence oriented. This means they have to check every file against every other file that hasn't already been determined to be a duplicate. The longer your sequence, the more extended the period of time to run the duplicate file check.

What would be preferable is a duplication check that ran in numerical sequence, only checking each file against the immediate predecessor. I may be able to code something to that end, but I've got other things on my plate right now.
 
Does this mean we can record off speed frame rates like 32, 36, 40 etc? If we could this would be awesome!!!
 
samphibbs said:
Does this mean we can record off speed frame rates like 32, 36, 40 etc? If we could this would be awesome!!!
Click to expand...

Yes. Record at 50p (or for F23 59.94p and 60p also work), and set the VFR where you want it. Process for duplicates after, and renumber files so NLE doesn't see gaps in the image sequence.
 
If someone wants to supply a short sequence of dpx files from a ramping shot I can try writing something in python to do this. There might be a chance that the dpx files metadata will identical metadata for duplicate frames but not for changing ones. If so it would be very quick to find duplicates using the meta data instead.
 
Last edited:
dhessel said:
If someone wants to supply a short sequence of dpx files from a ramping shot I can try writing something in python to do this. There might be a chance that the dpx files metadata will identical metadata for duplicate frames but not for changing ones. If so it would be very quick to find duplicates using the meta data instead.
Click to expand...

Unfortunately, no. I've been through the headers with a hex editor and I've referred extensively to the specification for DPX V2.0 to understand them. Here's the spec: http://www.simplesystems.org/users/bfriesen/dpx/S268M_Revised.pdf

The headers specify a number of things, but they don't have a flag for duplicate frames. There are some "user" spaces in the header where Convergent Designs has custom data, and in theory they could put such a flag in (assuming the hardware was up to the feat), but they certainly don't do so currently. Nor does the file retain the ancillary part of the SDI signal where the original Sony DDID packet flag resides.

The only thing that changes frame to frame in the header is a Convergent Designs custom header space that reads out the current unit voltage in ASCII. Everything else is constant.

However, if your python script can test binary blocks, the spec gives you the details to find the image data offset (appears to always be 4096) and as the image data runs to the end of file, you could compare binary image data. A well implemented compare routine would never test the whole binary on a mis-match, but would return false as soon as a single variation was found (which would almost always happen in the first few bytes).

I'm looking into developing this with Objective C.
 
That is too bad, in that case c++ would be good to for the speed increase but python would be easier to make it cross platform. If you get a working solution and don't mind sharing it please do, I will do the same.
 
Viddo you never cease to amaze with f35.

Phil Rhodes said:
I suspect there are ways of making this work even on compressed frames, using something like ffmpeg with the "mpdecimate" filter. The threshold for considering frames identical is user-definable, which should make for reasonable results.

I haven't tried it.

P
Click to expand...

This would be great for us using hyperdeck with prores. Any chance viddo? Also I thought you made this work already when you had srr1? Maybe with the almost uncompressed 880 setting?
 
SJX said:
Viddo you never cease to amaze with f35.

This would be great for us using hyperdeck with prores. Any chance viddo? Also I thought you made this work already when you had srr1? Maybe with the almost uncompressed 880 setting?
Click to expand...

The SRR1 used very light compression. I never looked at the byte/bit stream for that compression, so I can't comment on it beyond the overall statement that compression likely forces you to compare frames with more complicated logic than being able to simply do a pure binary level comparison. I no longer own an SRR1. The SRR1 had support for the VFR from the Sony PMW-F3, but not the F35. Sony at one time planned to release an SR-R3 that would have docked to the F35, and presumably would have supported VFR. Sony never released that product.

This work is new for me.


Regarding the Hyperdeck Shuttle. I don't have one, and have little experience with them. Googling tells me it records uncompressed Quicktime files, but apparently not DPX. In theory this ought to contain perfect binary matched frames, but because they're all in one .mov container file your workflow is going to be different. Either you need some sort of filter or plugin that will do your duplicate testing and elimination on the mov file directly, or to use my discrete file image sequence based method you'll need to export to an uncompressed image sequence such as dpx, then process. All around, more of a pain in the butt than starting with dpx, but certainly plausible.

The BMD Hypderdeck Shuttle also only goes up to 30p, so you won't get as many VFR options as a recorder than supports 60p will give you.
 
dhessel said:
That is too bad, in that case c++ would be good to for the speed increase but python would be easier to make it cross platform. If you get a working solution and don't mind sharing it please do, I will do the same.
Click to expand...

I'm not worried about micro efficiencies, but limiting the comparison to a purely sequential one makes a huge difference.

As of now I have something very rudimentary coded in Objective C that conducts the sequential duplicate check on a folder of dpx images, ignoring differences in the header, reviewing only the binary image data. It then sends the duplicates to the trash, and renames the remaining files as an incremental set starting at 0. Finally it modifies the xml file to reflect the new image count. After Effects happily accepts the resulting sequence, free of duplicates.

I need to make improvements in error correction and in threading, as well as progress bar implementation. I also need to create a larger data set to stress test it.

I will probably need to charge something if I make this tool available to others. For the moment though I'm focused on making it reliable and efficient.
 
Alright. Last night I recorded a 32 minute VFR/Ramping clip on the F23. The Odyssey was set for 59.94p RGB 444 dpx (10bit), and it was coming from the F23 59.94p YUV 4:2:2 dual link SDI output. For most of the duration the VFR was set to 1fps, with ramps to 60p over 30 seconds being done several times, and then finally a ramp to 24p at the very end. The resulting file was close to 1TB, filling my drive nearly completely.

I used the Gain compensation feature, and kept a constant 180 degree shutter angle. This limited dynamic range, but kept meant motion blur was half a second long for the 1fps portions.

This proved a challenging stress test on the post side. Over 113,000 separate image files were in a single folder. OSX Finder wasn't happy about this, and was an initial hurdle. Code wise, I wrote in Objective C, and had used a class called NSFileManager to address the files, and NSURL to reference them. With the 1TB dataset, NSFileManager essentially crashed when I asked it to enumerate the directory. I had to rewrite to use POSIX C calls instead. NSURL was functional, but exceptionally slow, and likewise I exchanged it for string based paths that resolved much faster. Finally, doing nearly 1TB of data reading and comparison will only go so quickly. Realizing that the noise in each frame would be unique, I dropped my comparison to the first 64 bytes of image data, and it was still accurate in determining which were duplicates and which were unique.

The result is faster than real time (31 minutes), but I need more tests to get you a more specific benchmark. Too many elements were still be modified on the fly here.

Here's the resulting clip. I've color adjusted, but this is the clip entire, duplicates removed, but no other editing applied. It's boring, but will let you review the motion flow. While the recording was done at 59.94p, I edited it as 23.98p, so as to have periods of slow motion.
 
Where is the clip?

Why would arri spend all the time and money making film cameras that ramp if over cranking and removing frames is the same effect. Check out ramps in 300, they were done in camera.
 
Well thanks for all this research- that was an excellent motivation to try ramps in camera. I've always found excessive timewarps with constant framerate kind of hacky, at least how its used a lot in sports/action at the peak moment of action. As a camera operator I was thinking ehh this is another thing for me to worry about why not lock it down but shutter compensation alone I think is something you could exploit narratively. Really becomes an editors tool later on. (EDIT: I think I meant to say editors have enough decisions to make. Sometimes less freedom to ramp willy nilly is a good thing- make it part of the scene)
 
You must log in or register to reply here.
Back
Top