H265 again... since flame do not handle h265 mov footage

It works also with 8k, 12bit source files as H.265(HEVC) out of the box. Color space is always FullRange. If you shot in Flog, Clog, or whatever log… your Imported clip does NOT degrade.

can you give me an screenshot of the logfile? just enter in terminal:

tail -f /var/tmp/flame_h265_import.log

log output will look like this

Ok, thanks to @johnag for the session today. Now I think about to create a high quality export module for h265, 10bit or 12bit 4:2:2 (client friendly mp4) to export directly from the timeline or media hub. Yes we all use Handbrake and ffmpeg. But a quick 'n easy client delivery on demand … (yes h265 hevc play on their mobile phones) and also as backup… wouldn’t it be nice?
For me, using the Apple Silicon Video Toolbox Framework anyways… would be possible in short time

Should be another topic, but what if you can use ComfyUI (for example inspyrenet matte /depht and normal extraction / creation)? on the same machine or same lan?

I mean controlled from flames side?

That’s what we’re all looking for. You have it running?

I can report that this plugin works very well and simple to use.

I havent however worked out how to get a log image into flame from my iphone recordings. It always has some sort of LUT applied. It’s probably a setting at the recording stage.

Hi,

I hope you don’t mind if I can offer some feedback on the plugin?

  1. I noticed that you need a reel in your groups called Reel 1. If you don’t then nothing will be imported. I usually name my reels like rushes, gfx, imports etc. So I guess is there a way for the plugin to test for reel 1 being there. Maybe a dialogue box pops up and asks us to create a reel before it imports. Or if theres no reel then make a reel 1. I’d prefer to be prompted to create a reelname for the import if that’s possible.

  2. If you highlight lots of files for import there is no feedback on whats happening other than the spinning wheel. Is there a way getting some feedback on what its doing so to estimate how long the import will take?

  3. Is there a way of allowing us to cancel a long import. At the moment it appears I will have to force quit flame.

  4. I notice that the files in tmp are Prores422 not HQ. Is there a reason for that?

  5. Are the files in tmp the ones that will be used in flame? What happens in a soft import or a soft archive situation. Will I lose the media? If so maybe the converted files should live next to where they were imported from.

  6. After import the file appears in the reel as an open sequence. That means lots of open record tabs. Would it be better that the clips were flagged as source sequences instead?

As I said, I hope you don’t mind my feedback. I know there are limited options and time you can invest in all of this so don’t feel that you need to address any of these things.

2 Likes

Hi John: I just did send you the actual version with fixes.

Here the Change log:

  1. now user definable reels. you can rename the reels to your preferences

  2. and an import status feedback of what file is processing at the bottom right in the flame window.

  3. flame calls the decoder … if you select a bunch of big files, this h265_decoder works trough the selected files and gives the ok back to python hook in flame.
    you can monitor the progress in the flame window and/or at any detail with a terminal window enter :

tail -f /var/tmp/flame_h265_import.log

  1. I can implement
  • Apple ProRes 422 HQ : ‘apch’ (‘hcpa’ in little-endian)
  • Apple ProRes 422 : ‘apcn’ (‘ncpa’ in little-endian)
  • Apple ProRes 4444: ‘ap4h’ (‘h4pa’ in little-endian)

…for now I used Prores422 because HQ brings no picture improvement but much bigger filesize. For footage coming from drones, iphones and consumer cam’s I think that’s reasonable for now.

  1. In a normal shooting situation, the files ends on a card or portable ssd with limited space. If you want, that the transcoded files ends up in a folder beside the source…
    I can implement this too (will take a day or so)

  2. now as source sequences…

Let me know how this works for you. Cheers, Xteve

1 Like

OMG that’s fantastic! Thank you.

Re point 5, I’m concerned that the transcoded files are sitting in a temp folder and when the job is over they will get deleted.
I understand that putting them next to the source wouldn’t work either for those situations where the footage comes in on a usb.
Can we be asked where to store the transcodes before hand? That way we can define our main project media drive.

1 Like

the folder where the converted files are stored in
/var/tmp/flame_h265_convert

I attach a simple shell script that will create an alias (symbolic link - folder) on the Desktop.

the shellscripts content is:

#/bin/sh
cd ~/Desktop
ln -s /var/tmp/flame_h265_convert ./h265Imports

please unzip it, doubleclick… creates the link to the folder on your desktop.

where_is_my_footage.sh.zip (841 Bytes)

1 Like

personally, I use the mac terminal a lot. But for much smoother user experience I just could rebuild the pkg installer… so this will be automatically happen when you install the plugin.

If you like, I could design a Folder Icon up to your preference.
I am not allowed to use any Autodesk graphical elements in the plugin.
But anything else… no problem.

…not yet, but I am working on it. I guess next week I could present a first integration.
code wise… it looks not too complicated.
And next week I will take some effort into it.

1 Like

@johnag

I am working on:
**Understanding the “User’s” Intentions

  1. User Workflow: User select H.265 files in Flame’s MediaHub to import them into a reel.

  2. Transcoding: The selected H.265 files … to be transcoded to ProRes 422 or HQ or 4444 with audio tracks equivalent to the source files.

  3. Output Management: The transcoded files should be stored in a way that is accessible and does not depend on the user selecting a directory or managing symbolic links!!!

  4. Avoiding Data Loss: The transcoded files should be stored in a reliable location that remains accessible even if external drives are disconnected!!!

My Proposed Approach:

Given these points, the approach should be:

  • Use a Fixed Temporary Directory: Store the transcoded files in a predefined directory (e.g., /var/tmp/flame_h265_convert) that is always available when Flame is running.

… I have tested different approaches, but this feels like my workflow to go for.

Please let me know what you think. My point here is: I don’t want to mess with any wiretap network access (speed issues). If you have any preferred Harddrive or SSD to store the encoded files before they get imported, I can of course make this work for your specific requirements.

Now as dmg with Installer (pkg), and documentation

Hi Guys, I hope I can post the final result here:

Today a new Version became alive. Now you can choose the path to the conversion folder with an easy text-edit of :
/Users/YourName/.flame_h265_config/output_dir.txt

~/.flame_h265_config/output_dir.txt will be created by installation

Only make sure, the folder path exist!

Ok here we go:

I did build a plugin for Autodesk Flame to import H.265 HEVC footage, no matter what!
I did implement 2 different software components:

  1. the h265_decoder cli commandline tool written in Objective-C++.
    • using just and only the ultra optimized function calling to the hardware - VideoToolBox (Apples Hardware encoder/decoder system)
    • gives ultimative speed in reading h265 HEVC 4k,6k,8k, Xk in 8,10,12 bit 4:2:0, 4:2:2 footage precise frame accurate
    • cpu is only used for the drive readout supply and does not interfere with the 2x EncDec hardware engines on my Apple Silicon Mac
  2. The easy lightweight Flame Hook (python3.11x):
    • in the Mediahub select your footage, single or multiple… Import! You see the Import Status per file in Flames down right corner
    • after extensive testing sessions with many different hevc sources, I would say it’s a new benchmark. The ONLY bottleneck is the speed of the footage drive
    • you will feel no difference from importing h.265 hevc footage anymore; EXCEPT there is NO PREVIEW (yet)
    • optimized for Flame 2025.2.x
    • its blazing fast, BUT YOUR CPU and GPU utilisation Monitor does not show it. The Apple Video Hardware Engine does it (google for M1Mon) to monitor ALL of your hardware on Apple Silicon. gives an better insight.
  3. The result footage ending up in your reels is absolutely equal to the input footage. If your camera overcrank to say 50.9 fps… the result will just mirror it.
    • if you drop a rec709 file in… same rec709 comes out! 10bit422with 24bit PCM audio… yeah… same. Fooage will never be degraded. On pixel!
    • Today, on march 2, Sunday… there is no other H.265 HEVC Import on Flame in sight.
  4. Downside: While importing… I see a spinning ball and the progress footage by footage down right in flame. While the Import happen, I can’t do other tasks in flame for now.

I am just a guy who need an H.265 HEVC importer in a studio when the friendly Agency lady pulls her phone or usbc-sd and ask:
Can you ?

Ok: Update from Today… You can define the fastest and biggest temporarily folder for the transcoding now as you like!
Thank’s goes to John

1 Like

I did look into it. Well, it’s not as easy. getting frames out of flame works well. Let accept Comfyui these as input via websocket… tricky! I am on it. Yes, Flame can send via python hook, and I got at some point comfyui inspyrenet rembg processed files back imported. but I am far from impressed. I will work on it next week again.