Feature Requests

[Karyudo]

One might argue, then, that making a quick fix to the DGI (soon to be thwarted by a CRC check...) should also not introduce errors in delivered frame locations, trims, etc., between versions, and thus should perhaps be unofficially allowed (but not "supported") for those who know what to tweak where??

I'm thinking in particular of my most recent project, where I came across the MKV with compressed headers, and you created a new version to parse such streams. In the interim, I'd remuxed with uncompressed headers and indexed the result, and was editing from that DGI. When the new version came out, I installed it to be current -- but I now had a perfectly-good DGI from the previous version (made just the day before!) that ostensibly I couldn't use. One tiny fix later, and I was fine without having to reindex. But a CRC check would have added some level of annoyance...

I don't suppose you could check the CRC, and pop up a warning along the lines of:

Code: Select all

CRC Check Fail: This DGI was made with a previous version of DGIndexNV, and may not work correctly with the current version. It is recommended that the project be re-indexed with the current version. Proceeding without reindexing is done at the user's risk, and problems arising from ignoring this CRC check will not be supported.

Ignore CRC Check | Cancel and Re-index

But if we have to re-index, we have to re-index. I'm not the one that has to support/fix problems that users may bring upon themselves by not using your product the way it was meant to be used. I really can't get too bent out of shape by a very slight annoyance in an otherwise brilliant and bulletproof piece of software, and you'll hear no further whining/suggesting from me on this topic!

[admin]

One might argue, then, that ...

No, you can't argue that. I told you already that a file format up rev is guaranteed to mean that something will be wrong if you do not re-index to make a properly formatted DGI file that is compatible with the new software.

I'm thinking in particular of my most recent project, where I came across the MKV with compressed headers, and you created a new version to parse such streams. In the interim, I'd remuxed with uncompressed headers and indexed the result, and was editing from that DGI. When the new version came out, I installed it to be current -- but I now had a perfectly-good DGI from the previous version (made just the day before!) that ostensibly I couldn't use.

Who says you couldn't use it? The DGI file version did not go up from 2035 to 2036, and 2036 would not reject it.

One tiny fix later, and I was fine without having to reindex.

There was nothing to fix. Please tell us what your "tiny fix" was. Ha ha, busted!

And BTW, the CRC thing was a joke. There are some valid reasons to edit a DGI file, such as overriding the frame rate (although that can be done in your script too).

Can you imagine how messed up things would be if we didn't have a file format version number, which was designed to save you grief?

Now if you proposed that I add functionality to automatically generate a corrected new format DGI from existing ones, which is something I have thought about, then you might have a case. But that would be pretty low on my priority list, given that only one person has ever found this to be an irritant. It also would not always be possible to create a correct new file without re-scanning the source file(s).

[laserfan]

I don't get why anyone would bother to mess with old dgi files given how wicked-fast the indexing process has become?

[Karyudo]

I've found that indexing some MPEG-2 files is pretty slow, but I'd agree that indexing h264 stuff is quick.

admin, now that I think about it, it's quite likely I started the day with a version older than 2035, indexed a couple of files, then found that it wouldn't index an MKV with compressed headers, upgraded to 2035, and found that 2035 also wouldn't index MKVs with compressed headers. Then when 2036 was introduced and I tried to use a DGI I'd indexed just a day or two earlier, it didn't work. But clearly I'm still in the wrong, because I should have stayed up to date and used 2035 in the first place!

My new rule (eerily similar to your long-standing rule): If old DGI does not work with current version, re-index. No ifs, ands, or buts!

[kypec]

I don't get why anyone would bother to mess with old dgi files given how wicked-fast the indexing process has become?

I've found that indexing some MPEG-2 files is pretty slow, but I'd agree that indexing h264 stuff is quick.

I'm not sure what am I doing wrong but indexing MKV files (untouched stream ripped directly off bluray disc with MakeMKV, VC-1 or H.264) using DGIndex revision 2035 takes more than 40 minutes
for standard 2-hour movie.
MKV is located on external HDD (connected over eSATA), .dgi index is being written on local HDD.
My system: i7-920, 6GB RAM, Windows 7 x64, GeForce 8400GS 512MB
Any ideas?

[admin]

When I did the performance changes I did not do it for the MKV parser code. That still needs to be done. I'll move it up on the priority list.

That code from the MKV guys needs quite a bit of work to run fast.

[kypec]

When I did the performance changes I did not do it for the MKV parser code. That still needs to be done. I'll move it up on the priority list.
That code from the MKV guys needs quite a bit of work to run fast.

Thanks for clarification and even more thanks for moving it higher on your priority list!
What speed improvement (very rough estimation) do you think we can expect of that redone MKV parser?

[admin]

It should become comparable to TS parsing.

[mastrboy]

Feature Request:
- Move crop out of .dgi file to avisynth function parameter
- A simple batch processor/gui-helper, those for loops in cmd is a pain..
I'll try to elaborate a little of what im thinking:
I usually encode anime tv-series which i rip with dvd-decryptor sorted into episode folders, each folder contains the vob file for the episode. Usually i write a cmd file that loops through the folders and use DGIndexNV command-line switches on each vob file to index them and save the .dgi in each directory, i would love to see a simple menu item than just loops through supported files and indexes them while saving the .dgi file with the same filename as source file in the same directory that vob (or other supported) file resides, while being recursive.

(Sorry that my last request caused problems, "cropping in increments of 2x" )

[yesgrey]

Any luck of a DGDecNV DirectShow filter ever come to life?

It would be really great to have AVC and VC-1, both progressive and interlaced, decoded by the GPU...
I know there are already free DXVA filters, but I think they don't work with interlaced sources, and can't be used with madVR...

[admin]

It's an interesting idea.

Regarding the existing filters you mentioned, why don't they work with MadVR?

[yesgrey]

Regarding the existing filters you mentioned, why don't they work with MadVR?

They use DXVA, and only VMR9 (XP) and EVR(Vista/7) support it. The only filter that works is CoreAVC with its CUDA support, but it only supports H.264 progressive, I think it doesn't support interlaced, and no VC-1 and MPEG2 neither.
Furthermore, I'm having some hiccups when using it with madVR. I don't know if it's any problem by having two applications using the GPU at the same time (madVR and COreAVC), or if it might be any problem with CoreAVC's implementation. I've thought that you might be able to make it work flawlessly...

[admin]

Some more questions...

Are you thinking of this primarily for playback purposes, rather than filtering, transcoding, etc? The answer determines how frame accurate it has to be.

Are you wanting an ES decoder with an input pin for compressed video and an output pin for decompressed video? I.e., a decoder filter you could use with existing splitters. Or are you thinking of a full source filter that includes a splitter.

Any further specifications you may be thinking of would also be useful to know. Thank you.

[ZooStation]

+1 for a directshow filter! Having the possibility to repatriate the decoded stream from the gpu to the cpu à la CoreAVC 'cuda' would allow the ffdshow raw filter to jump in. This is currently impossible for 1080p24 VC1 on my 5-year-old Athlon X2. The fastest software decoder is still too slow on this computer forcing me using DXVA for playback and thus, sadly staying away from madVR + postprocessing.
I certainly don't mean to stand in for yesgrey answering questions about madVR, but the thing is madshi's renderer only accepts YV12 for input as to version 0.34. When or even if there will be NV12 support isn't sure yet. I thought it would be worth reminding this detail, since I understand it might make things trickier for hardware deinterlacing. Please correct me if I'm wrong.
Personaly, I would use such a filter solely for playback purposes. Frame accuracy is not a concern as long as seeking in the video remains comfortable. And finally splitter-wise, I think those already available are fine enough.

[yesgrey]

Are you thinking of this primarily for playback purposes?

Yes. For all the other stuff we already have the current DGDecNV, so I think there is no need for accurate frame serving...

Are you wanting an ES decoder with an input pin for compressed video and an output pin for decompressed video? I.e., a decoder filter you could use with existing splitters. Or are you thinking of a full source filter that includes a splitter.

Yes, only a decoder filter to use with existing splitters, unless you feel it would be preferable and easier to create s full source filter, but in that case you would also need to handle other kind of streams, like FLAC and DTS-HD, ect and feed them to their decoders...

Any further specifications you may be thinking of would also be useful to know. Thank you.

Ok. I will think about it and let you know...

Thanks for considering this.

[madshi]

Hey admin,

yesgrey asked me to come here for further DirectShow DXVA <-> madVR questions.

The reason why madVR (currently) does not work with DXVA decoding is that in a DirectShow chain the renderer must provide/support the DXVA interfaces, and madVR currently does not support that. The main problem for me is that AFAIK DXVA decodes to GPU RAM NV12. Now NV12 is a valid D3D surface format, but not a valid D3D *texture* format. madVR is doing its work using pixel shaders and pixel shaders can only read textures, not surfaces. So this is all quite problematic for madVR to handle. I might find a workaround for that sooner or later. But for now DXVA <-> madVR is problematic.

So, if you can find a way to provide a filter which accepts h264, VC-1 and MPEG2 bitstream as input pin, and outputs raw NV12 or YV12 uncompressed video on the output pin, while using hardware accelerated decoding, that would be great! One problem with this design approach would be that to my best knowledge hardware decoding is usually done to GPU RAM, while a DirectShow output pin usually outputs to system RAM. Which means that your DirectShow filter would probably have to transfer the decoded data back from GPU to system RAM. Transfering lots of data back from GPU RAM to system RAM is not really a common thing to do, so GPU drivers might not be well optimized for that. Meaning, performance could suffer.

One thing to think about is who'd do the hardware deinterlacing. In a DirectShow filter chain, usually the renderer does that. On the other hand, if you write a DirectShow filter which uses hardware decoding and still outputs to system RAM, maybe it would make sense to make use of hardware deinterlacing, too. But I'm not really sure.

A fair warning: If you haven't done DirectShow programming before (I don't know if you have), be prepared for a painful experience...

If you need any more information, or if you need custom madVR interfaces for something, just let me know.

[yesgrey]

One problem with this design approach would be that to my best knowledge hardware decoding is usually done to GPU RAM, while a DirectShow output pin usually outputs to system RAM. Which means that your DirectShow filter would probably have to transfer the decoded data back from GPU to system RAM. Transfering lots of data back from GPU RAM to system RAM is not really a common thing to do, so GPU drivers might not be well optimized for that. Meaning, performance could suffer.

This raises a question... Would it be possible to find a way of sending the output for madVR directly via video mem? It seems a waste of resources the decoder copying the frames from video RAM to system RAM when we know that madVR first step is copying it from system RAM to video RAM... of course this should be optional, because some people might want to use other filters for processing the video frames, which work on system RAM.

madshi, one more thing. What do you think of admin's question about the frame accuracy? How accurate would you need it to be for madVR?

[madshi]

This raises a question... Would it be possible to find a way of sending the output for madVR directly via video mem? It seems a waste of resources the decoder copying the frames from video RAM to system RAM when we know that madVR first step is copying it from system RAM to video RAM...

The problem is that I can't use NV12 or YV12 GPU RAM surfaces. madVR splits YV12 data into luma and chroma channels and uploads them separately to the GPU. Only this way madVR can access the data via pixel shader without any manipulation by the GPU/driver. If admin's decoder could split the data into separate luma/chroma textures on the GPU, then that would be just fine, but I don't know if that's possible. I don't think it's possible with Direct3D APIs, at least.

What do you think of admin's question about the frame accuracy? How accurate would you need it to be for madVR?

I don't even know what "frame accuracy" means exactly.

[admin]

Hi madshi,

Thanks for dropping in. It's an honor to see you here. And thanks for the information on DirectShow and madVR. I'm just getting my feet wet now with DirectShow. I hope it is not as painful as you say!

I'll probably be in touch with you as I make progress and have questions. Ciao!

BTW, frame accurate means that if the application asks for frame X (or the equivalent time), then the next displayed frame will be exactly X, and not just some frame close to X. Close is considered good enough for a player. My first effort will just be an ES decoder, so the seeking will be controlled by the splitter. We'll have to see if the splitters are doing a good job in that regard.

[madshi]

Thanks for the nice welcome, admin!

I'm just getting my feet wet now with DirectShow. I hope it is not as painful as you say!

It probably depends a bit on what you do. Probably writing a decoder is less painful than writing a renderer, because writing decoders is what everbody does, while writing a renderer is not a very common thing to do.

Some things you may want to look out for:

(1) Different splitters may use different FOURCC values, e.g. for h264 IIRC I've seen 2 or 3 different ones...
(2) After a seek, the Haali splitter may silently drop some frames which are not needed for proper decoding of the target frame. Most other splitters feed all frames, beginning from the I frame, up to the target frame, I think.
(3) If there's a format change during playback, you have to handle that properly. This is between the splitter <-> decoder, but also between decoder <-> renderer. E.g. IIRC VRM9 always triggers a dynamic format change, after the media type has already been agreed upon. See more information here:

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

One other thing to think about is whether you want to implement chroma upsampling (YCbCr 4:2:0 -> 4:2:2 or 4:2:2) and colorspace conversions (YCbCr 4:4:4 -> RGB) or not. If it was me, I would simply always output native format (almost always YCbCr 4:2:0) and leave all conversions to the renderer. No need to reinvent the wheel inside of the decoder. Would save you some programming time, too.

You know, the h264 spec allows more than 8bit. Not sure if the GPU hardware supports that, though. If you plan to support > 8bit decoding with your decoder, I'd appreciate if you would try to output the video data in its native bitdepth instead of rounding it down to 8bit internally. Here are the FOURCC values defined by Microsoft for > 8bit YCbCr:

http://msdn.microsoft.com/en-us/library ... 420formats

The next question would be 3D support. I think the latest NVidia and ATI GPUs should support 3D decoding in hardware, too, but there's not even a splitter for that available yet. So maybe you should ignore that for now...

I'll probably be in touch with you as I make progress and have questions. Ciao!

You can also directly email me at madshi (at) gmail (dot) com.

BTW, frame accurate means that if the application asks for frame X (or the equivalent time), then the next displayed frame will be exactly X, and not just some frame close to X. Close is considered good enough for a player. My first effort will just be an ES decoder, so the seeking will be controlled by the splitter. We'll have to see if the splitters are doing a good job in that regard.

I see. I don't think DirectShow playback has to be frame accurate, as long as the splitter puts the correct presentation timestamp on each frame.

[admin]

Thanks for that information, madshi. It is very useful to a DirectShow noob like me.

[yesgrey]

Any further specifications you may be thinking of would also be useful to know.

I feel current DGDecNV already has all features I would need. I've read the manual and noticed that it already supports all formats that I use, namely DVD, Blu-ray, mkv, AC3 and FLAC, so, in case you decide it would be easier for you to go for the source filter approach, the current features set is already a very good one.

If you go for the source filter approach it would give you a better command on everything, which might end up as a more reliable and best performing solution. If you go for the decoder approach it would give you a wider range of users, and would also allow the support of other formats you still don't support, which will give the users greater flexibility. In the end, it would be your decision.

Now one question that might end up as a feature request: do you have access via CUVID to all deinterlacing modes offered by the GPU drivers, or only to BOB and WEAVE? I've read that now they have more advanced deinterlacing algorithms, and it would be a really nice feature to have the possibility of using them all...

[WILLIS]

chapter creation inside .ts file

[admin]

do you have access via CUVID to all deinterlacing modes offered by the GPU drivers

No. CUVID has limited support at this time.

[admin]

chapter creation inside .ts file

Without more detail this will go nowhere.