DG NV tools

[Guest]

1. Oversight on my part. Just forgot to update the string.

2. Pilot error, no fix for that. You can always edit the DGA file.

3. Please note the error next time. Also, tell me what app you used for the first encoding.

[laserfan]

Regarding my CUVIDServer note:
Please note the error next time. Also, tell me what app you used for the first encoding.Here is my exact sequence:

1. Use a DGTool to index a video, launch CUVIDServer, look at video with avs/Vdub 1.9.0, then run 2-pass x264 encoding using same simple avs e.g.

#For h264
DGSource("video.dga")

#For MPEG2
#DGSource("video.dgm")

#For VC-1
#DGSource("video.dgv")

2. Hours later, after x264 completed, launch DGAVCIndexNV and make a test.dga from x264 output. Note CUVIDServer is still active/in system tray.

3. Using test.avs (just DGSource("test.dga")) Open With...Vdub, get this pop-up dialog:

Server
cuvidMapVideoFrame() error.
[OK]

I can click OK on this dialog, but Vdub is "Not responding" and must be closed by End Process, and CUVIDServer is still running but can't be exited by normal means, must also End Process and re-launch it to get it to work.

Note that I did try this same sequence on a short test clip, and it worked fine--it did NOT throw the error. Then I tried another full-length video (six hours or so to complete x264) and got the error again. Further, between 1. and 2. above, the PC has automatically gone into "Standby" mode; maybe that is the issue i.e. for my next encoding I will disable this "auto Standby" behavior and see if I get the same CUVIDServer hangup again (maybe it does not wake-up from Standby properly?).

EDIT: Well, duh, only after writing-down the sequence above had the "Standby" thing occurred to me. And now that my morning coffee's starting to affect me did I think to simply go to Standby and out again. Sure enough: launch CUVIDServer and open a vid with avs/dgx/vdub. Fine. Go to Standby, come out of Standby (CUVIDServer still running). Try again--Error. This time:

Server
Failed to create video decoder (100)
[OK]

Frozen as before i.e. must End Process and re-launch to recover.

So the problem is Standby related I believe and maybe (another) Windows XP Pro x64 anomaly, assuming you or others can't dupe this problem.

[Guest]

It's a known issue that you can't have a screensaver kick in or go to standby with the server running in the D3D versions. As I said, the server is not yet D3D-less.

[laserfan]

It's a known issue...OK. If this is in the Readme.txt or any other docs I can't find it--you may want to add same somewhere...

[Revgen]

OK. If this is in the Readme.txt or any other docs I can't find it--you may want to add same somewhere...

It'll be gone once Nvidia comes out with the new driver. Neuron2 will update the server to work with the new driver once it's released.

[Varies]

neuron2
My last error with D3D was fixed by driver update ^^ but i had new bug.
DGIndexNV
http://i054.radikal.ru/0908/14/e8fddcda203et.jpg (http://radikal.ru/F/i054.radikal.ru/0908/14/e8fddcda203e.png.html)
DGIndex
http://s60.radikal.ru/i170/0908/f4/8b1d63b7cabft.jpg (http://radikal.ru/F/s60.radikal.ru/i170/0908/f4/8b1d63b7cabf.png.html)

[Guest]

Use Video/Cropping Filter.

It's not a bug and has been discussed.

Looks like I'll have to do something different with this as it is causing confusion.

Can I please have a stream sample so I can see your frame sizes, etc.? If you don't give a stream, there's a good chance that your issue may not get fixed.

[laserfan]

It'll be gone once Nvidia comes out with the new driver. Neuron2 will update the server to work with the new driver once it's released.I got it, thanks. Yeah if I'm going to use the beta versions I need to follow these threads more closely...

[Varies]

It's not a bug and has been discussed.
why not? if i used same scripts and had differing screenshots...
stream and scripts in PM.

[Guest]

If you read the discussion you would understand.

http://forum.doom9.org/showthread.php?p=1315069#post1315069

[Varies]

thanks ^ ^ i just skip two pages before :)
You may do this as option?

[Guest]

I will pop up a choice message box if I see the stream cropping. If invoked by the CLI the box will not be popped up and it will always honor the stream's specified cropping. I will also add an auxiliary INI file option to allow you to suppress the message box entirely and always honor the cropping.

[laserfan]

since the new betas came out, i see you are leaving the source as is. 1920x1088

Yes, you can just use "Video/Cropping Filter" to crop it.

I have seen some streams that have good content in that last 8 pixels and thought it would be useful to have the option to retain it when resizing. I'm open to reconsidering that decision if it bothers people too much.This has confused me (easy to do, I know). Upon processing a 1920x1088 blu-ray (re-encoding using DGTools and x264), and not doing any cropping, I see that the result, after re-muxing and playback on PC with Cyberlink PDVD, shows the bottom of the screen "stretched" i.e. 8 pixels of blurriness. But neither the original .h264 nor the re-encoded .264 when played using avs/Vdub showed any such anomaly on-screen (and neither does the original using PDVD). Even the re-muxed .m2ts when played-back with MPC looks fine.

I don't know if this is a tsMuxeR question (which sees the re-encoding as 1920x1088) or purely a PDVD quirk, or if I simply need to crop the bottom 8 pixels every time with DGTools--and to that question I didn't see the original NEEDED any cropping. Can someone enlighten me. :o

[Guest]

Asking about PDVD here is OT. Do you have an issue for my NV tools?

[laserfan]

Asking about PDVD here is OT. Do you have an issue for my NV tools?I don't know WHERE the issue is, but the "now 1088 vs. before 1080" is the only thing that's changed, so I thought I'd ask here!

OK then, let me ask a different question: if I open a stream with DGAVCIndexNV that is shown to be 1920x1088, and if it shows video perfection all-around i.e. no black or distorted lines at the bottom, then it's OK not to crop?

Or another: If I really don't care about the bottom 8 pixels even if they DO contain "good content" then is there a way to assert the crop setting(s) so I don't have to remember to do them every time?

EDIT: I apologize--I see now that if I set DGAVCIndexNV to Display Full HD I can see that the bottom 8 pixels are distorted. I could not see this in the normal display as-opened.

OK now I know how to look and how to crop!

[Guest]

OK then, let me ask a different question: if I open a stream with DGAVCIndexNV that is shown to be 1920x1088, and if it shows video perfection all-around i.e. no black or distorted lines at the bottom, then it's OK not to crop? As I stated already the intent was to retain the information when resizing to a standard format, such as 1280x720.

http://forum.doom9.org/showthread.php?p=1315069#post1315069

Is it OK to make an output stream with a height of 1088? I'd have to check every application out there to answer that.

Or another: If I really don't care about the bottom 8 pixels even if they DO contain "good content" then is there a way to assert the crop setting(s) so I don't have to remember to do them every time? I have already told you I will address that and also how I will address that.

http://forum.doom9.org/showthread.php?p=1316896#post1316896

[laserfan]

See the edit I made to my post; I was not able to see the answer to the "good content" question until I switched to Full HD mode! I'm good, thanks! :)

[Guest]

It should have also been visible before but at half height. Maybe you just didn't notice it.

You'll be able to set an INI file option to always honor the cropping in the next beta.

[laserfan]

It should have also been visible before but at half height. Maybe you just didn't notice it.

You'll be able to set an INI file option to always honor the cropping in the next beta.My eyes aren't as good as they used to be, but the blurring is virtually impossible for me to see at half-height, and not easy even at Full, except now I know to look for it.

Looking forward to the next beta, thanks...

[ultratoto14]

After a bad manipulation, i resize to 1280*720 a SD DVD with your tool, only green frames as result. Just to inform you, i do not need to upscale DVD.

[SomeJoe]

@neuron2:

Just to clarify on the 1080/1088 issue: Under the former version of your NV tools when the stream encoding was 1088 but the display was 1080, did you always crop the bottom 8 pixels? Or is there additional information in the stream that told you which pixels to crop e.g. maybe the top 8, or top 4/bottom 4?

I'm asking because I'm trying to answer if I want to reencode to a 1920x1080 stream from a 1920x1088 source, can I safely always crop the bottom 8 (intending for this to be equivalent to the previous NV tools version behavior), or will I have to view the decoded source to determine where to crop?

[Guest]

The stream can specify cropping. Previously I always honored it. For 1088 it is always the bottom 8.

[SomeJoe]

The stream can specify cropping. Previously I always honored it. For 1088 it is always the bottom 8.

Very good, thanks. :thanks:

[GZZ]

also a new nvidia driver out, version 190.62

CUDA Updates
• Added support for 64‐bit video encoding.
• Added support to make all GPUs within an SLI group available for CUDA
applications to use.

Not sure if its what Neuron2 was waiting for to complete the next beta version ?

[Revgen]

I just downloaded the lossless "Island Trailer" uploaded by Ben Waggoner in the BD Replication thread. I made an x264 encode from it. The original avi is 2419 frames, but DGAVCIndexNV and the original DGAVCIndex files both incorrectly state the framecount as 2412 frames in Vdub. However, when I use FFMPEGSource it correctly states the framecount as 2419 frames.

My x264 settings.x264 --profile high --level 4 --ssim --pass 2 --bitrate 24000 --stats "E:\KingKong.stats" --thread-input --deblock -2:-2 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 4 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --me umh --subme 9 --psy-rd 1.0:0.15 --partitions all --trellis 2 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --fullrange on --colorprim bt709 --colormatrix bt709 --transfer bt709 -o "g:\island.264" "g:\island.avs"

I used Jeeb's 1222 32-bit build.with the x264_win_zone_parse_fix_06.diff and x264_hrd_pd_interlace.16.diff patches.

Here are the DGAVCIndexNV and DGAVCIndex files.

http://www.sendspace.com/file/aiijmw
http://www.sendspace.com/file/nmhrqj

[Guest]

Post a link to your x264 encode.

[Revgen]

Sure.

The entire encode is 270mb so it'll take awhile.

[Revgen]

PM Sent.

[Guest]

I have it fixed locally and it will be in the next beta. Thanks for pointing it out.

The new Nvidia driver includes the fix I needed so the CUVID server will go D3D-less.

Trying to get a beta out this weekend.

[Revgen]

Cool.

Looking forward to it.

[foxace]

hello neuron2 the beta7 don't work in megui why ? the autocrop don't work.

[Guest]

I don't know anything about MEGUI autocrop. Ask the MEGUI people about it.

[foxace]

ok thank. yet the beta6 work good in megui

sory my english is bad

[laserfan]

Dunno that this creates any problems, but I noticed that having used the crop function and re-encoded a 1920x1088 .h264 (i.e. the .dga contains CLIP 0 0 0 8) using .avs w/DGDecodeNV and x264, that the resulting clip when opened again with DGAVCIndexNV still shows as 1920x1088 in its Header, and when indexed again shows in the Information box Frame Size, and Display Size, and in the dga SIZ 1920x1088. Izzat right? Within the x264 log is shown the expected size i.e.

avis [info]: 1920x1080 @ 23.98 fps

:confused:

[Guest]

x264 must make a frame with a coded size of 1088 because it needs an integer number of macroblocks. It specifies a cropping rectangle to get a display of 1080. My indexers will report the coded size and the display size (yes I know it is not that way right now). Please wait for the next beta.

[laserfan]

Ah, thank you very much for the explanation--now I understand about "coded size" vs. "display size". At last.

:)
_____________________________________________________________________________
"The best way to learn anything is to solve a problem that is meaningful to you." --Laserfan

[Efenstor]

I'm having audio sync problems (accumulating offset) with Beta 7 when I load (i.e. index and DGSource) about 100 MTS'es of different length sequentially (from an AVCHD cam).
I tried different AC3 decoders and all give the same result.

[Guest]

Post a link to the first two files.

[Guest]

After a bad manipulation, i resize to 1280*720 a SD DVD with your tool, only green frames as result. Just to inform you, i do not need to upscale DVD. I don't know what you mean by "After a bad manipulation". Are you saying that upscaling is not working?

[7ekno]

I am also having issues with "AVCHDlite" streams from Panasonic ...

The only filter that gets close to importing them into Avisynth right is DSS2() ...

The DGTools is reporting 50fps correctly, but only producing every 2nd frame for display (it doesn't matter whether I select "Honor Pulldown" or not), so it effectively produces a "fast forward" result (25fps being displayed at 50fps) ...

The same thing also happens in DGAVCIndex and DGAVCIndexNV ...

Example clips (MTS with AVC video and AC3 audio, straight from a Panasonic AVCHDlite device):
00000.MTS (http://www.mediafire.com/file/vjzytkenzyi/00000.MTS.rar), 00001.MTS (http://www.mediafire.com/file/lmhn2zzigmg/00001.MTS.rar), 00002.MTS (http://www.mediafire.com/file/madjydtjjx0/00002.MTS.rar)

7ek

[Revgen]

The only filter that gets close to importing them into Avisynth right is DSS2() ...

EDIT

I'll check em out.

[7ekno]

So ffmpegsource doesn't work with them either?
FFMS (the original one does), but it produces blocking and aweful chroma artifacts when seeking ... FFMS2 reports 25fps and display 25fps, it just drops the duplicate fames ...

On top of that, can you actually play these videos with libavcodec based decoders?
Not sure, I use The KMPlayer (with Haali spliter/internal splitter) pointed at CoreAVC for the decoder, it reports 50fps with normal playback (and I can see the difference in The KMPlayer between a DSS2() encoded MKV at 50fps with duplicates and a FFMS2 encoded MKV at 25fps without duplicates .. the 50fps versions have the motion appear less jerky) ...

Can you play them with MPC-HD with dxva decoding?
Not sure, never tried it as I have never had a playback problem with the MTS files themselves ...

Files linked and posted if ya wanna experiment ;)

7ek

[Guest]

That's really weird. I'll investigate. I can't even imagine what might cause that. :confused:

[Revgen]

^Found a fix.

Load the file in gdsmux (comes with the Haali media splitter, look in c:\program files\haali). Convert to mkv. Load mkv in DGAVCIndexNV. Create an index file. Load in avisynth.

[Guest]

That's a workaround, not a fix. :)

This should be fixable if I can find out the syntax element used to signal the duplicates.

[Guest]

Here's another workaround until I find out the syntax trick.

# if you want the duplicates
vid=DGSource("E:\tmp\00000.dga")
interleave(vid,vid)
assumefps(50)

# or if you don't
DGSource("E:\tmp\00000.dga")
assumefps(25)

[ultratoto14]

Are you saying that upscaling is not working?

Exactly.

On Largo Winch DVD, index using mgppgindecnv,

DGSource("VTS_12_1.dgm",resize_w=1280,resize_h=720)

Only give me green frames. Removing resize attributes and it's ok.

[Guest]

Works fine for me in my local beta 8. Let's see what happens after I release that.

[7ekno]

Convert to mkv. Load mkv in DGAVCIndexNV. Create an index file. Load in avisynth.

Here's another workaround until I find out the syntax trick.

Thanks :)

I am actually using H264TSto to convert a whole directory of MTS's to MKV, then indexing and using that way from MKV ...

It would just be nice not to have to bother with the MKV step if there turns out to be a simple way to get around it in DGAVCIndex (any version!) ...

Tek

[Guest]

It would just be nice not to have to bother with the MKV step if there turns out to be a simple way to get around it in DGAVCIndex (any version!) Isn't my suggestion simple enough? It's a lot simpler than your approach.