Port Cube
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Port Cube
DGSplit.
Or open in DGIndexNV, set project range, enable video in Demux menu, and Save project. Upload the resulting hevc file.
Or open in DGIndexNV, set project range, enable video in Demux menu, and Save project. Upload the resulting hevc file.
Port Cube
You should be kinder to your new members.
Port Cube
I was looking for this solution! I will upload the original in a few hours. Sorry for the inconveniences caused.
Port Cube
That's great. Can you do FTP? I ask because that download site is dreadfully slow. BTW, 50 MB should be fine.
And they also make you wait some ridiculous amount of time between downloads.
mwittmann, if you want to work on the bleeding edge with us, you have to get away from these download sites. I have a perfectly good fast FTP server. Can you use it?
And they also make you wait some ridiculous amount of time between downloads.
mwittmann, if you want to work on the bleeding edge with us, you have to get away from these download sites. I have a perfectly good fast FTP server. Can you use it?
Port Cube
That's a little better. Keep at it. Kisses, Brit.
Port Cube
If it took more than 10 minutes to download 112MB, I'd have already lost interest and moved on to something else. Kids have really short attention spans these days. Balti was telling me you shouldn't expect more than 6 seconds focused attention with modern youth. That has an upside and a downside, but mostly down.
Philco 38-12 arrives tomorrow! An early superhet.
https://www.radiomuseum.org/r/philco_38_12.html
She's a beaut!
Philco 38-12 arrives tomorrow! An early superhet.
https://www.radiomuseum.org/r/philco_38_12.html
She's a beaut!
- Wonder Woman
- Posts: 58
- Joined: Sun Feb 07, 2021 10:46 am
Port Cube
Only 7 minutes to go. I'm on it guys. Dudley, are you ready?
Port Cube
This time I sent the original. It was really easy to demux the selected frames with DGIndexNV.
Port Cube
Thank you. I will be sure to take into account your scenario as we develop a solution to the problem of processing YUV source. Your report and materials are greatly appreciated.
Is that good, Brit?
Is that good, Brit?
Port Cube
My current plan is now this. We will have 3 parameters (2 is not enough):
source is full or limited
cube lut is full or limited
desired output is full or limited
They will be required parameters, i.e., no defaults. When users go wrong I wanna be able to blame it on them.
So that is 8 possibilities. We also have either YUV or RGB input/output, so we're up to 16 possibilities. Please don't ask for the input and output to be different YUV and RGB. That would be 64 possibilities and I don't wanna do that.
I have already worked out the equations needed for each of the 16 cases. Note that I could collapse it to 2 parameters and 8 cases if we assume the input and output have the same range. But it's easy to keep it at 16 and give that flexibility. Not so easy to change YUV<->RGB due to Avisynth pixel-type considerations. I could do it, just don't wanna.
If y'all agree that this will cover your desired uses, I'll start coding and testing.
BTW, AFAICT, AVSCube() = timecube assumes the LUT is full range and has 1 parameter called fullrange to say if the input/output is full or limited. That does not allow for a limited range LUT.
EDIT: Sherman told me the 38-12 radio just arrived so I'll be on my own for this.
source is full or limited
cube lut is full or limited
desired output is full or limited
They will be required parameters, i.e., no defaults. When users go wrong I wanna be able to blame it on them.
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
So that is 8 possibilities. We also have either YUV or RGB input/output, so we're up to 16 possibilities. Please don't ask for the input and output to be different YUV and RGB. That would be 64 possibilities and I don't wanna do that.
![Wink ;)](./images/smilies/icon_e_wink.gif)
I have already worked out the equations needed for each of the 16 cases. Note that I could collapse it to 2 parameters and 8 cases if we assume the input and output have the same range. But it's easy to keep it at 16 and give that flexibility. Not so easy to change YUV<->RGB due to Avisynth pixel-type considerations. I could do it, just don't wanna.
If y'all agree that this will cover your desired uses, I'll start coding and testing.
BTW, AFAICT, AVSCube() = timecube assumes the LUT is full range and has 1 parameter called fullrange to say if the input/output is full or limited. That does not allow for a limited range LUT.
EDIT: Sherman told me the 38-12 radio just arrived so I'll be on my own for this.
Port Cube
Seems fine to my innocent eyes.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
I don't know if DGCube is internally "multithreaded" (I don't know how it's called for CUDA).
In that case, would be possible to have a threads parameter to adapt to slower, with less memory, and faster cards?
Port Cube
There's no multithreading. The time is so overwhelmingly dominated by the PCIe transfers that it's pointless to even think about trying to do anything in that regard. E.g., we decide to do 2 frames at a time. Theoretically the kernel processing of the first frame could be overlapped with the upload of the second frame. But the gain would be very small and it would require twice the GPU memory.
One thing we could do is integrate it into DGSource(). That would eliminate two full frame transfers with no increase in memory on the GPU:
not integrated:
compressed data -> GPU -> decode -> CPU -> Avisynth -> GPU -> cube -> CPU -> Avisynth
integrated:
compressed data -> GPU -> decode -> cube -> CPU -> Avisynth
So, yeah, it would be way faster. Let's get it working first as a standalone filter and then think about that. Thanks for provoking thought about it.![grateful :salute:](./images/smilies/icon_salute.gif)
One thing we could do is integrate it into DGSource(). That would eliminate two full frame transfers with no increase in memory on the GPU:
not integrated:
compressed data -> GPU -> decode -> CPU -> Avisynth -> GPU -> cube -> CPU -> Avisynth
integrated:
compressed data -> GPU -> decode -> cube -> CPU -> Avisynth
So, yeah, it would be way faster. Let's get it working first as a standalone filter and then think about that. Thanks for provoking thought about it.
![grateful :salute:](./images/smilies/icon_salute.gif)
Port Cube
Believe it or not, I was having dinner and thinking about that. I sat to my PC and I was replying with that idea in mind. Then I read your post and I smiled. Great minds think alike.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Another idea, in future and with proper OS integration, is to use DirectStorage, if possible.
https://docs.nvidia.com/gpudirect-storage/index.html
Port Cube
Remains to be seen if there is any there there. We'll see.DirectStorage
Port Cube
Curly, please approve me too.
No matter what, data must traverse PCIe, so I'm not clear on how "DirectStorage" is going to help. DMA requires access to the CPU bus. Could be I'm confused, keeping an open mind.
No matter what, data must traverse PCIe, so I'm not clear on how "DirectStorage" is going to help. DMA requires access to the CPU bus. Could be I'm confused, keeping an open mind.
Port Cube
Ya gotta earn it. Like big t. What's left, Boris Approved?
Port Cube
38-12: Gonna pull the chassis right now, guys. Standby...
Port Cube
Can't wait. Be careful, electricity can kill.
Port Cube
Like, if I got Curly Approved, and I didn't want that, what is my recourse?
Port Cube
You know, I am not a programmer, just a computer enthusiast.
AFAIK (https://developer.nvidia.com/blog/gpudirect-storage), CPU can be freed from having to manage data transfer to GPU. Perhaps it's won't increase GPU processing speed but, for sure, anything that is CPU related.
Or not?
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)