- Welcome to Magic Lantern Forum.
News:
Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
Recent posts
#1
Camera-specific Development / Re: 200D shoots raw video
Last post by Walter Schulz - Today at 05:30:09 PM #2
Camera-specific Development / Re: 200D shoots raw video
Last post by kitor - Today at 05:25:25 PMWon't happen. M100 runs PowerShot firmware flavour - thus it is CHDK target.
#3
Camera-specific Development / Re: 200D shoots raw video
Last post by falcon - Today at 05:21:21 PMHow close a relative is M100? If something happens, will it be an easy port?
#4
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by names_are_hard - Today at 12:42:35 AMQuicker: taking less than 8 years 
Having never looked at the MLVFS code, and never worked with FUSE either, I can only wildly speculate. I assume MLVFS translates accesses to the MLV file, by indexing within the file to know where each frame is, checking what's being accessed, and turning that frame into DNG (or whatever, I've never used it).
So, assuming I'm guessing right, somewhere in there it maps access location to frame. You'd want to change that mapping so accesses to frames 1 or 2 returned the data of the dng generated for 1, and you'd want to ensure there's caching. I'd guess the FUSE layer does caching for you.
For example, if we pretend frames are at even 1000 byte offsets, and that 1000 bytes of MLV frame turns into 1000 bytes of DNG, reads from offset 10 and offset 1010 into the MLV should both return the data offset by 10 in the DNG generated for the first frame.
Having never looked at the MLVFS code, and never worked with FUSE either, I can only wildly speculate. I assume MLVFS translates accesses to the MLV file, by indexing within the file to know where each frame is, checking what's being accessed, and turning that frame into DNG (or whatever, I've never used it).
So, assuming I'm guessing right, somewhere in there it maps access location to frame. You'd want to change that mapping so accesses to frames 1 or 2 returned the data of the dng generated for 1, and you'd want to ensure there's caching. I'd guess the FUSE layer does caching for you.
For example, if we pretend frames are at even 1000 byte offsets, and that 1000 bytes of MLV frame turns into 1000 bytes of DNG, reads from offset 10 and offset 1010 into the MLV should both return the data offset by 10 in the DNG generated for the first frame.
#5
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by vastunghia - Yesterday at 10:27:55 PMDefine 'quicker'
Anyway I might have some spare time when my sons are grown up, that will happen in a few years, will look into that then and let you know how it goes
Apart from jokes, I took some C/C++ courses back at uni some 20 years ago and have been using Python for scientific programming for work since then. If somebody could at least give me a hint at where to start looking, and for what to look, I would even give it a shot.
Anyway I might have some spare time when my sons are grown up, that will happen in a few years, will look into that then and let you know how it goes
Apart from jokes, I took some C/C++ courses back at uni some 20 years ago and have been using Python for scientific programming for work since then. If somebody could at least give me a hint at where to start looking, and for what to look, I would even give it a shot.
#6
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by names_are_hard - Yesterday at 09:47:03 PMNobody wanted to do it in the last 8 years. I think it will be quicker if you learn how yourself. No harm asking, of course.
#7
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by vastunghia - Yesterday at 09:22:43 PMI was expecting this objection 
My only hope is that 1. this new feature is not so difficult to implement (and it does not sound so), 2. some guy smarter than me at reading code is experiencing my same issue, and 3. he/she will read this post and think "Dang! Good idea! Let me implement this!"
My only hope is that 1. this new feature is not so difficult to implement (and it does not sound so), 2. some guy smarter than me at reading code is experiencing my same issue, and 3. he/she will read this post and think "Dang! Good idea! Let me implement this!"
#8
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by names_are_hard - Yesterday at 09:01:59 PMSounds plausible to me. I think the bigger problem is, who's going to do the work? Last time MLVFS was updated looks to be 8 years ago?
#9
Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on ...
Last post by vastunghia - Yesterday at 08:30:21 PMSo, I was thinking about the issue I have with MLVFS -- namely, that even with a super-fast NVMe drive, my CPU power (i5-8500) is not enough to guarantee real-time (24 / 25 fps) playback in DaVinci Resolve, when using MLVFS with 3.5K (3.7K in UHD terms), 14-bit lossless compressed raw footage. It seems close to. But not enough.
So I realized that, at least for the purpose of selecting shots / editing / color grading, half fps would probably be at my CPU's reach and would not cause so much bad experience for me. And when I say 'half fps' I mean skipping one frame every two.
I tried to understand if there is such an option in DVR, but apparently there is not. So I was wondering if this could be possible on MLVFS side: maybe some sort of option that would expose to the file system (and to DVR in the end) 1. an fps metadata keyword which is half the actual one and 2. one frame every two (say, only odd ones, but enumerated consequently -- 001, 002, 003 etc).
Do you think this would work?
(And: is there anybody out there being able to playback 3.5K 14-bit footage in real-time using MLVFS?)
So I realized that, at least for the purpose of selecting shots / editing / color grading, half fps would probably be at my CPU's reach and would not cause so much bad experience for me. And when I say 'half fps' I mean skipping one frame every two.
I tried to understand if there is such an option in DVR, but apparently there is not. So I was wondering if this could be possible on MLVFS side: maybe some sort of option that would expose to the file system (and to DVR in the end) 1. an fps metadata keyword which is half the actual one and 2. one frame every two (say, only odd ones, but enumerated consequently -- 001, 002, 003 etc).
Do you think this would work?
(And: is there anybody out there being able to playback 3.5K 14-bit footage in real-time using MLVFS?)
#10
Post-processing Workflow / Re: fastcinemadng
Last post by vastunghia - May 13, 2024, 12:14:24 PMQuote from: megapolis on May 13, 2024, 10:44:04 AMCan't you do that with the current software? If it's not, please send me your MLV for evaluation.
"current software", in the context of the task MLV -> cDNG, for me means MLVFS or MLVapp. Just for clarity.
And no, no way to get real-time playback / conversion with 3.5K (which is 3.7K actually) 14-bit lossless compressed MLV raw footage. At least with my specs (super-fast NVMe drive + i5-8500).
Still interested into checking one of my MLV files?
Btw, thanks for your feedback on FastCinemaDNG vs ZLUDA! I had some hope since apparently it works out of the box even for high-level and (apparently) heavily Nvidia-optimized software such as Blender. But I guess it would take plenty of time anyway.