Feature Requests

Support forum for DGDecNV
Post Reply
DAE avatar
krosswindz
Posts: 4
Joined: Tue Sep 28, 2010 11:13 pm

Re: Feature Requests

Post by krosswindz »

The PIDs are the same, any tool to just cut the last 100MB of the m2ts file. If I use tsmuxer to actually do the cut I dont get the same error. Using DGSplit to split a 20 GB stream is something I am trying to avoid.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

You can use segment mode of DGSplit. You'll only have to write the sizes of the segments you select. Anyway, this is not a feature request. Make a separate thread if you want to continue it.
DAE avatar
HeadlessCow
Posts: 3
Joined: Mon Sep 20, 2010 12:32 pm

Re: Feature Requests

Post by HeadlessCow »

lev wrote:I'm still interested in the ability to specify a video card (especially as a RDP workaround). :D

I see you've added this in one of the recent builds, but just in case you didn't realize (or couldn't test), it still doesn't work via RDP. Functionality via RDP is pretty much the only feature I care about right now so I didn't want it to drop off your list if you thought it was resolved now :)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

I don't even know what RDP is, so if you want this you'll have to tell me:

a) what is RDP?
b) what is the proposed workaround for it?
c) how would I implement and test that?

If it's remote desktop you are talking about, I remind you that running remote desktop deinstantiates the video driver and that the video driver is required to use CUVID. You should use the known functioning alternatives to remote desktop.
DAE avatar
mastrboy
Posts: 36
Joined: Wed Oct 27, 2010 10:28 am

Re: Feature Requests

Post by mastrboy »

Feature requests:
- Crop in increments of 2x pixels instead of the current limit at 4x (I have a DVD series with a ugly 2pixel top bar)
- Bring back a hotkey for "Close" as in DGIndex (F3 in DGIndex was hotkeyed to close, but now that is Step)
DAE avatar
HeadlessCow
Posts: 3
Joined: Mon Sep 20, 2010 12:32 pm

Re: Feature Requests

Post by HeadlessCow »

neuron2 wrote:I don't even know what RDP is, so if you want this you'll have to tell me:

a) what is RDP?
b) what is the proposed workaround for it?
c) how would I implement and test that?

If it's remote desktop you are talking about, I remind you that running remote desktop deinstantiates the video driver and that the video driver is required to use CUVID. You should use the known functioning alternatives to remote desktop.
RDP = Remote Desktop Protocol. So I guess that answers my question :) I had hoped there was some way to still access the hardware even though the graphics drivers was unloaded in that session, but if it's not then I'll have to live without it.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

As I said there are other remote access methods that do not disable the video driver. I forget which one people were recommending.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

mastrboy wrote:Feature requests:
- Crop in increments of 2x pixels instead of the current limit at 4x (I have a DVD series with a ugly 2pixel top bar)
- Bring back a hotkey for "Close" as in DGIndex (F3 in DGIndex was hotkeyed to close, but now that is Step)
I've implemented both of these. They will be in the next release. Thank you for the suggestions.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Re: Feature Requests

Post by Guest 2 »

neuron2 wrote:As I said there are other remote access methods that do not disable the video driver. I forget which one people were recommending.
Logmein (free), Remotely Anywhere (paid), ThinVNC (free, very interesting product, HTML5 based).

Uh, I almost forgot: up RDP (as feature suggestion)
DAE avatar
RedDwarf
Posts: 14
Joined: Fri Oct 29, 2010 3:11 pm

Re: Feature Requests

Post by RedDwarf »

I think this might of been requested before but I cannot find any mention of it.

Can a De Blocking function be added? Preferably GPU assisted. Without the normal in look deblocking being done, much of the low bitrate HDTV broadcasts look quite poor. Currently it means using separate filters.

DGDecode has deblocking so can a de-blocking function/feature be added to DGDecNV?

I don't understand why this isn't already done because it would seem a necessary feature with AVC usually using it.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

It's certainly possible but what do you mean by this:

"Without the normal in loop deblocking being done..."
DAE avatar
RedDwarf
Posts: 14
Joined: Fri Oct 29, 2010 3:11 pm

Re: Feature Requests

Post by RedDwarf »

neuron2 wrote:It's certainly possible but what do you mean by this:

"Without the normal in loop deblocking being done..."
It was what I remember H264 calling the de-blocking, but I might of got it wrong.

Basically when a video is played in a Media Player, de-blocking gets done according to the amount the AVC video says should be done. As far as I am aware DGDecNV doesn't do any, or at least from what I have seen it doesn't appear to do any. If the AVC video expects de-blocking to be done when the video is displayed, to me it doesn't seem right to not do it. In effect, the returned video isn't as it was meant to be.

For some video that might not be a problem. But for others such as the fairly low bitrate video used for HDTV in the UK, which is typically a 10 Mbit transport stream with 1440x1088 resolution giving just over 9Mbit for video. It means quite noticeable blocks where any movement occurs when de-blocking isn't done. The blocks aren't practically unnoticeable when normally de-blocked during playback in a media player.

It would be nice to have the video which is returned to be as it was meant to be displayed, rather than having to use separate de-blocking filters in addition.
DAE avatar
Didée
Posts: 22
Joined: Wed Oct 27, 2010 2:19 pm

Re: Feature Requests

Post by Didée »

The deblocking is performed. As you noted (with slight misspelling), H.264 is doing "in-loop deblocking". That means that deblocking is not done "after the fact" like you do when e.g. playing back Xvid videos. In H.264, the deblocking is an essential "inner" process of both encoding and decoding. If deblocking would not be done (it is possible to switch off), then you'd get an all-corrupted output.

So you don't need an option to switch it on. Be assured, it already IS on.;) - (Perhaps you could have an option to switch it *off*, but you don't really want that, anyway.)

However, with TV transmissions it is quite possible that they used too weak inloop deblocking from the start, or even had it switched off from the start. (In case of doubt, you can expect all kind of silly-ness from TV stations.) In such a case, the video stream can exhibit blocking problems indeed, and further postprocessing might be necessary. (For such sources, the Deblock() filter as found e.g. in dgdecode.dll, is appropriate. It uses the basic deblocking mechanisms of H.264 deblocking.)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

I concur with everything Didée said regarding DGDecNV deblocking. (I'd use the built-in deblocking (cpu option) of DGDecode in preference to Deblock(), but if that is not strong enough a dose of Deblock() can be added. That's neither here nor there for the subject of this thread, however.)

RedDwarf, if you have any evidence that DGDecNV is not performing deblocking correctly, please present it.
DAE avatar
Didée
Posts: 22
Joined: Wed Oct 27, 2010 2:19 pm

Re: Feature Requests

Post by Didée »

Still, shouldn't it be considered to add some sort of deblocking to DGDecodeNV ? In particular for Mpeg-2 sources. Fact is, the white bearded man DGDecode can do quantiser-adaptive deblocking on mpeg-1/2, but the young guy DGDecodeNV can do not. One could argue this is a regression. :)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

Sure, what you say is correct. The problem is that CUVID does not give me any access to the quants. But I'm not so sure the quants bring that much to the table anyway. I've not seen any evidence for it. It would be nice to have a GPU deblocker and that's what I will probably tackle first.
DAE avatar
RedDwarf
Posts: 14
Joined: Fri Oct 29, 2010 3:11 pm

Re: Feature Requests

Post by RedDwarf »

Didée wrote:The deblocking is performed. As you noted (with slight misspelling), H.264 is doing "in-loop deblocking". That means that deblocking is not done "after the fact" like you do when e.g. playing back Xvid videos. In H.264, the deblocking is an essential "inner" process of both encoding and decoding. If deblocking would not be done (it is possible to switch off), then you'd get an all-corrupted output.
It can be turned off in ffdshow Directshow decoder without any corruption, the picture looks sharper but slightly blockier. De-blocking can be de-activated in x264 encoding settings as well. So I don't see what you mean about your reference to deblocking being essential to avoid corruption.
So you don't need an option to switch it on. Be assured, it already IS on.;) - (Perhaps you could have an option to switch it *off*, but you don't really want that, anyway.)

However, with TV transmissions it is quite possible that they used too weak inloop deblocking from the start, or even had it switched off from the start. (In case of doubt, you can expect all kind of silly-ness from TV stations.) In such a case, the video stream can exhibit blocking problems indeed, and further postprocessing might be necessary. (For such sources, the Deblock() filter as found e.g. in dgdecode.dll, is appropriate. It uses the basic deblocking mechanisms of H.264 deblocking.)
That surprises me because the video from DGDecodeNV is considerably more blocky than I see when opening the video via DSS in AvsPMod. That is why I doubted that it was performing any de-blocking.
It's very noticeable where there is fast motion but not so noticeable when decoded via Directshow.
If I open a DGDecodeNV video in AvsPMod and the same video with Directshowsource, the DGDecodeNV video will look very blocky in places whereas the same frame does not have very noticeable blocks in the DS decoded video. That's using ffdshow AVC DS decoder.
neuron2 wrote:........RedDwarf, if you have any evidence that DGDecNV is not performing deblocking correctly, please present it.
I will have to check through some videos when I have more time, stepping through frames to find something because it mainly appears where there is fast movement which can be missed when playing back at full speed. It was very noticeable in some places but not in others and it's finding it again. It's like some de-interlace line artefacts that appeared with the nVidia de-interlacing. They were noticeable in a few places in a video I looked at but I couldn't find any in others. :?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

RedDwarf wrote:That surprises me because the video from DGDecodeNV is considerably more blocky than I see when opening the video via DSS in AvsPMod.
That is ridiculous. DGDecNV is a bit perfect decoder just as all AVC decoders are that adhere to specifications. Again, please show your evidence and stop creating silly FUD.
I will have to check through some videos when I have more time
But you have enough time to spread FUD!
It's like some de-interlace line artefacts that appeared with the nVidia de-interlacing. They were noticeable in a few places in a video I looked at but I couldn't find any in others.
Which of course has nothing at all to do with deblocking.

If you're saying that one can get artifacts sometimes with a deinterlacer, well thank you, Captain Obvious. :roll:
DAE avatar
Didée
Posts: 22
Joined: Wed Oct 27, 2010 2:19 pm

Re: Feature Requests

Post by Didée »

I started writing a somewhat longish explanation about the what's and how's and why's of how AVC and deblocking is working ... but I lost mood. (But saved it ... if you insist by all means, I can show it)

Short report from the practical side: I can't reproduce.

Please show a source segment where DGDecodeNV gives blocky picture where other decoders don't.
User avatar
laserfan
Posts: 108
Joined: Thu Sep 09, 2010 5:16 pm

Re: Feature Requests

Post by laserfan »

I'm one of those anal-retentive guys that keeps all of my logs from my encodings. I have noticed that the log created by DGDecNV does not include a version number, nor does the .dgi file i.e. I don't THINK that the NV file number is exclusive to a release e.g. 2036=12.

Is there a way to automatically note the version? Or could it be saved with either the .dgi file or the .log file?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

laserfan wrote:Is there a way to automatically note the version? Or could it be saved with either the .dgi file or the .log file?
I'll add it to the DGI file for the next release. Thanks for the suggestion.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Re: Feature Requests

Post by Guest 2 »

More than a program feature request, this is a changelog feature request.

Please, please, please tell us when DGI version changes. Sometimes I upgrade versions and have to recreate DGI.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Feature Requests

Post by admin »

I missed the notification of DGI file version NV12 for build 2034. I have added it to the change log in build 2036.
User avatar
laserfan
Posts: 108
Joined: Thu Sep 09, 2010 5:16 pm

Re: Feature Requests

Post by laserfan »

neuron2 wrote:
laserfan wrote:Is there a way to automatically note the version? Or could it be saved with either the .dgi file or the .log file?
I'll add it to the DGI file for the next release. Thanks for the suggestion.
Thanks for indulging me--I oughta point-out that I haven't had any problems with "beta" versions of DGDecNV (requiring fallback to an earlier rev) since way before the tools' consolidation to DGDecNV! Seems like a very long time ago. But like I said, I'm anal (and a natural worrier) and if I do find any problems with encodings I make I like to keep all the records of what I'd done; "lessee my encoding was made July 10 so I musta used dgdecnv2019 which I'd downloaded on the 6th". Thanks again.
User avatar
Karyudo
Posts: 24
Joined: Tue Sep 21, 2010 11:47 am

Re: Feature Requests

Post by Karyudo »

Guest 2 wrote:Sometimes I upgrade versions and have to recreate DGI.
Maybe it's not quite kosher, but instead of re-indexing, I often (OK, always) [REDACTED].

Seems to work fine...
Post Reply