StaxRip

[stax76]

@Anakunda

I wanted to test it but my license don't work, I reinstalled Windows often recently (migrated to Win10 and currently migrating to skylake hardware but having trouble with bad RAM), the problem is the URL for license key generation is dead (http://neuron2.net/licensing.html).

@amango

You mean file batch mode? In normal mode there is a new data view in the muxing dialog, this data view has columns to set default and forced flags.

@ShamisOMally

Jesus, last game I played and can remember by name was Half Live! Thanks for the offer. There are three games I want to try at some time: GTA V, Metal Gear Solid V and Mindcraft.

[sneaker_ger]

@Anakunda
the problem is the URL for license key generation is dead (http://neuron2.net/licensing.html).
He moved his site:
http://rationalqm.us/
http://rationalqm.us/licensing.html

[Anakunda]

@Anakunda

I wanted to test it but my license don't work, I reinstalled Windows often recently (migrated to Win10 and currently migrating to skylake hardware but having trouble with bad RAM), the problem is the URL for license key generation is dead (http://neuron2.net/licensing.html).


Okay I'll try to wait, If I recollect right previous issue was obolete DGsource version. Upgraded to suggested build and apparently new build doesn't solve anything.
From the temporary script I see StaxRip tries DGdecNV but fails. Playing .dgi files using 32bit DGDecodeNV works.

Edit: ffplay encode_Source.avs is playable! Problem must be on StaxRip side.
LoadPlugin("C:\Program Files (x86)\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("H:\video\(workset)\MadMaxFuryRoad\source.dgi")

[stax76]

@Anakunda

first please try if it also happens with a recent build, I tried it and it works here.

http://www.mediafire.com/download/kb4a641slubzmob/StaxRip_x64_2015.08.18.7z

https://onedrive.live.com/redir?resid=604D4754F64B0ABC!1606&authkey=!AF8gcK4OyAy5UTg&ithint=file%2c7z

[dejong12]

Stax, two questions:

1. Did you see my post two pages back about RGTools?
"RgTools.dll cannot be found, while RemoveGrain is selected, even though RgTools does exist in the Apps subfolder."
EDIT: This now works on the build you posted before me.

2. When using DGSource, after trying to load a video into StaxRip, it fails and gives me the following error:
System exception - Access Violation
(C:\PATH_TO_VIDEO\video.avs, line 2)

DGSource("C:\PATH_TO_VIDEO\video.dgi")
Any idea what's going on? It does this for every video I feed to StaxRip. I've got the latest DGDecNV 2049 set up correctly.
EDIT: This is still happening on the build you posted before me.

[stax76]

1. Did you see my post two pages back about RGTools?
"RgTools.dll cannot be found, while RemoveGrain is selected, even though RgTools does exist in the Apps subfolder."

I don't remember it, I tried RemoveGrain for both AviSynth and VapourSynth, it works and my plugin directories have only the default plugins included with AviSynth and VapourSynth.

When using DGSource, after trying to load a video into StaxRip, it fails and gives me the following error:

There was a updated 2049 build so re-downloading might help, when StaxRip ask for the location don't forget you need the x64 build.

[dejong12]

There was a updated 2049 build so re-downloading might help, when StaxRip ask for the location don't forget you need the x64 build.
I've downloaded the latest build just half an hour ago again to try and that build gives me the error. I've also used the x64 binaries.

[stax76]

Can MPC x64 open the avs file?

[videoh]

Just FYI...

AVG 2015 has started blocking DGIndexNV 64-bit. You may need to add an exception for it.

[dejong12]

Can MPC x64 open the avs file?
Nope, MPC-HC x64 can't render the file.

Just FYI...

AVG 2015 has started blocking DGIndexNV 64-bit. You may need to add an exception for it.
I don't use any antivirus except for Windows Defender.

[stax76]

Does MPC show the same error message and can VirtualDub x64 open it?

[Anakunda]

When using DGSource, after trying to load a video into StaxRip, it fails and gives me the following error:
System exception - Access Violation
(C:\PATH_TO_VIDEO\video.avs, line 2)

DGSource("C:\PATH_TO_VIDEO\video.dgi")
Any idea what's going on? It does this for every video I feed to StaxRip. I've got the latest DGDecNV 2049 set up correctly.
EDIT: This is still happening on the build you posted before me.

That's the same what's happening to me, having latest DgTools and paths set correctly also. I assume StaxRip rejects the output for some reason.

Just FYI...

AVG 2015 has started blocking DGIndexNV 64-bit. You may need to add an exception for it.
I confirm that's not A/V issue, using no A/V, beyond that as I wrote feeding the temporary script StaxRip creates into ffplay64, the source video can pass through to screen.

[stax76]

Are you sure you re-downloaded 2049 and set the path to the correct x64 DLL? There was a memory access violation raised by DGDecodeNV, this memory access violation was only happening under special circumstances like running Windows 8 or higher but not Windows 7, it was happening only in certain clients like .NET applications or MPC but not in all clients, VirtualDub x64 was not affected for instance. Donald has fixed it and re-uploaded 2049. If you absolutely cannot get it working then please send a log file.

[dejong12]

Does MPC show the same error message and can VirtualDub x64 open it?
MPC shows the same message. VirtualDub x64 opens the .avs fine.

Are you sure you re-downloaded 2049 and set the path to the correct x64 DLL? There was a memory access violation raised by DGDecodeNV, this memory access violation was only happening under special circumstances like running Windows 8 or higher but not Windows 7, it was happening only in certain clients like .NET applications or MPC but not in all clients, VirtualDub x64 was not affected for instance. Donald has fixed it and re-uploaded 2049. If you absolutely cannot get it working then please send a log file.
I'm 100% sure I've downloaden the latest 2049 and correctly set up the path to the x64 binaries.

I can't send you a log file because StaxRip does not create one. When it asks to try using another source, it fails by giving the same error. No video is then imported into StaxRip.

[Groucho2004]

MPC shows the same message. VirtualDub x64 opens the .avs fine.
What does AVSMeter (x64) have to say?

[dejong12]

What does AVSMeter (x64) have to say?
AVSMeter works just fine.
http://i.imgur.com/6sDba41.png

I'm using Windows 10 btw, I don't know if that matters?

[Anakunda]

Virtualdub64, AvsMeter64, ffmpeg64 work with DG NV source for me also and also no log is created on testing preferred filter

[Groucho2004]

I'm using Windows 10 btw, I don't know if that matters?No idea, wait for stax to figure it out. :)

[stax76]

the last changed date of the DLL must be exactly 2015.05.10

http://forum.doom9.org/showthread.php?p=1721117#post1721117

[dejong12]

the last changed date of the DLL must be exactly 2015.05.10

http://forum.doom9.org/showthread.php?p=1721117#post1721117
Mine is from 19-03-2015. I've downloaded it again to reconfirm and that one also shows 19-03-2015. The .exe has a later date: 27-05-2015.

[Groucho2004]

Mine is from 19-03-2015. I've downloaded it again to reconfirm and that one also shows 19-03-2015. The .exe has a later date: 27-05-2015.
Confirmed. Stax, you'll have to notify Don Graft on his forum. Maybe he mixed things up with the latest slipstream.

[amango]

@amango

You mean file batch mode? In normal mode there is a new data view in the muxing dialog, this data view has columns to set default and forced flags.


Yes I mean file batch mode. I made a profile that just should encode any file to H265.

I select many files to convert in file batch mode. All this files have one subtitle track (Anime).

The current version of StaxRip just remux the subs with this command in batch file mode.

-default-track 0:0

What I need is that all the converted files should be remuxed using this command

-default-track 0:1

And the older version of StaxRip I used never had that problem, it successfully took over the subtitles status from the old files.

EDIT: MKVMerge 8.3 does not seem to be compatible with StaxRip 1.3.1.5

[diloume]

Hello,

is the CBR mode working under nvidia h265 coding ? Since version 1.3 The software always impose a bitrate..

What can-i do ?

Thank for answer..

[diloume]

Sorry, I found the answer of my question..

[videoh]

Confirmed. Stax, you'll have to notify Don Graft on his forum. Maybe he mixed things up with the latest slipstream. That's right, it got messed up on a subsequent DGIndexNV slipstream.

The corrected package is now online.

[stax76]

Yes I mean file batch mode. I made a profile that just should encode any file to H265.

I select many files to convert in file batch mode. All this files have one subtitle track (Anime).

The current version of StaxRip just remux the subs with this command in batch file mode.

-default-track 0:0

What I need is that all the converted files should be remuxed using this command

-default-track 0:1

And the older version of StaxRip I used never had that problem, it successfully took over the subtitles status from the old files.

EDIT: MKVMerge 8.3 does not seem to be compatible with StaxRip 1.3.1.5

iirc mkvmerge enables default flags if nothing is specified, that's probably what you were getting before. If somebody can tell me the logic mkvmerge uses I consider to apply the same logic (or an alternative).

[dejong12]

That's right, it got messed up on a subsequent DGIndexNV slipstream.

The corrected package is now online.
Thank you, it works now!

EDIT:
Now that DGDecNV is working again with StaxRip, I face a problem with 1080p AVC videos.
The DG log file in the temp folder correctly shows 34492 total frames, but the imported file only shows 34478 frames when I preview the video and after the encoding,
effectively missing 14 frames in the beginning of the video.
All the other sources handle these kind of videos correctly. What's going on?

[videoh]

The DG log file in the temp folder correctly shows 34492 total frames, but the imported file only shows 34478 frames when I preview the video and after the encoding,
effectively missing 14 frames in the beginning of the video.
All the other sources handle these kind of videos correctly. What's going on? Try it manually without staxrip for debugging. Just make a basic script with DGSource() and then open the script in VirtualDub. How many frames do you see? If it is still off, then please post the DGI file.

Also, where are the missing frames, at the beginning or the end?

[dejong12]

Try it manually without staxrip for debugging. Just make a basic script with DGSource() and then open the script in VirtualDub. How many frames do you see? If it is still off, then please post the DGI file.

Also, where are the missing frames, at the beginning or the end?
The frames are missing at the beginning.
Opening the video in DGIndexNV.exe directly shows that frames are missing.
However, after demuxing it says 34492 total frames. And opening the file in StaxRip with other sources, the preview shows 34493 frames.
VirtualDub says 34478 frames.

[videoh]

Please post a link to the unprocessed source file. If it is too large then please cut the first 200MB using DGSplit. Also, I asked for the DGI file. Did you miss that?

There are several possibilities to explain what is happening but I cannot guess which applies. It's up to you to provide the requested materials if you want your issue to be analyzed/resolved. Thank you.

Also, if this occurs without staxrip then it would be better to open a thread in the DGIndex subforum so as not to clutter this thread.

[dejong12]

Please post a link to the unprocessed source file. If it is too large then please cut the first 200MB using DGSplit. Also, I asked for the DGI file. Did you miss that?

There are several possibilities to explain what is happening but I cannot guess which applies. It's up to you to provide the requested materials if you want your issue to be analyzed/resolved. Thank you.
Yep, I missed that, my apologies. Here (https://www.dropbox.com/s/iijwvvme52hn994/test.rar?dl=0) is the .rar file with the video (split to 200mb) and the .dgi from the original video.

[videoh]

Thanks, investigating...

[videoh]

Did you cut an MKV with DGSplit? Sorry, that is not a valid operation. I suppose I shouldn't assume people know this. You can validly do a binary split only on a stream file, not one with global headers.

In any case, there aren't frames missing at the start. It's just that the 3 leading B frames have been replaced with the first decodable frame. Given that, I'm going to need the whole file. Your DGI indicates something fishy at the end of the file, and so I will need the whole file.

Is your capture device giving you MKV, or did you get this somewhere else?

[dejong12]

Did you cut an MKV with DGSplit? Sorry, that is not a valid operation. I suppose I shouldn't assume people know this. You can validly do a binary split only on a stream file, not one with global headers.

In any case, there aren't frames missing at the start. It's just that the leading B frames have been replaced with the first decodable frame. Given that, I'm going to need the whole file. Your DGI indicates something fishy at the end of the file, and so I will need the whole file.

Is your capture device giving you MKV, or did you get this somewhere else?
Before doing anything wrong again, I should split the .264 file?

My capture device gave me a .ts file (or when using WMC .wtv). I cut the series with VideoRedo.

EDIT: When cutting the .ts file in VideoRedo and remuxing it back into .ts, DGIndexNV shows the first frame correctly. So it looks like something is going wrong when remuxing it into .mkv.

[videoh]

I need the TS file that came out of VideoRedo. The entire TS file please.

If VideoRedo makes an MKV then give me the entire MKV file. Thanks.

[dejong12]

I need the TS file that came out of VideoRedo. The entire TS file please.

If VideoRedo makes an MKV then give me the entire MKV file. Thanks.
Read my edit above your post. I can send both if you want.

[videoh]

I told you that the fishiness is at the end of the file but you keep going on about the start of the file.

If you want me to help you, please give me the TS file that comes out of VideoRedo. Then I can try remuxing to MKV etc. to try to see what is happening.

Usually, the frame count discrepancy comes because of a bad cut at the end, and the loss of a few frames at the end is inconsequential.

[dejong12]

I told you that the fishiness is at the end of the file but you keep going on about the start of the file.

If you want me to help you, please give me the TS file that comes out of VideoRedo. Then I can try remuxing to MKV etc. to try to see what is happening.

Usually, the frame count discrepancy comes because of a bad cut at the end, and the loss of a few frames at the end is inconsequential.
I've cut 2 minutes from the series and put both .ts and .mkv in the .rar for you to compare. Both are created with VideoRedo.

Link (https://mega.nz/#!9ERUFT5Y!T2q732KsgKIEcz3AvAcSseJwOm0o8SwiBlSgCv8UYTI)

[videoh]

I can't help if you don't give me what I ask for. I'll say it one more time. I need the entire TS file for the episode that comes out of VideoRedo. If you can't or won't provide it then you are on your own.

In any case, your link just gives me a blank page.

[dejong12]

I can't help if you don't give me what I ask for. I'll say it one more time. I need the entire TS file for the episode that comes out of VideoRedo. If you can't or won't provide it then you are on your own.

In any case, your link just gives me a blank page.
Link (https://www.dropbox.com/s/4b7ej6sbnviguts/episode.ts?dl=0)

[videoh]

Sweet, thank you! Downloading...

[videoh]

If you demux the AVC ES from the TS and then convert that to MKV with mmg.exe everything is fine and acts exactly the same as if you index the TS.

If you feed the TS directly into mmg.exe then everything gets hosed, and frames are lost at the start.

Conclusion: Your guess was correct. mmg.exe is not properly reading the TS. It is not unusual for applications to fail miserably at parsing interlaced transport streams. Apparently mmg.exe is yet another example. You should demux the audio and video, apply a delay correction to the audio as needed (or do it when muxing MKV), and then mux them into an MKV.

[dejong12]

If you demux the AVC ES from the TS and then convert that to MKV with mmg.exe everything is fine and acts exactly the same as if you index the TS.

If you feed the TS directly into mmg.exe then everything gets hosed, and frames are lost at the start.

Conclusion: Your guess was correct. mmg.exe is not properly reading the TS. It is not unusual for applications to fail miserably at parsing interlaced transport streams. Apparently mmg.exe is yet another example. You should demux the audio and video, apply a delay correction to the audio as needed (or do it when muxing MKV), and then mux them into an MKV.
Thank you for investigating the issue and providing a solution! I'll raise the issue at the creator of MKVToolnix.

[videoh]

My pleasure. Good luck with your projects and thank you for bringing to light the bad version I had online.

[stax76]

I think mkvmerge uses time codes so it works fine for playback but is unusable for encoding. dsmux muxes it better allowing for encoding afterwards, unfortunately it fails on certain sources and it's discontinued.

[dejong12]

I think mkvmerge uses time codes so it works fine for playback but is unusable for encoding. dsmux muxes it better allowing for encoding afterwards, unfortunately it fails on certain sources and it's discontinued.
I've just tried to remux the .ts into .mkv with dsmux and I can confirm that the resulting .mkv works correctly in DGDecNV, so there's a problem with mkvmerge. And my apologies for hijacking the thread.

[sneaker_ger]

I'm not seeing what you are seeing.
Downloaded episode.ts, used "mkvmerge -o episode.mkv episode.ts" (mkvmerge 8.3.0).
Opened using lwlibavvideosource(), both files show exactly 34500 frames. Mkv timecodes are 100% regular.

[dejong12]

I'm not seeing what you are seeing.
Downloaded episode.ts, used "mkvmerge -o episode.mkv episode.ts" (mkvmerge 8.3.0).
Opened using lwlibavvideosource(), both files show exactly 34500 frames. Mkv timecodes are 100% regular.
It only happens when using DGSource as a source filter.

[sneaker_ger]

Maybe videoh can add his knowledge about what exactly is wrong with the mkvmerge output to your bug report:
https://github.com/mbunkus/mkvtoolnix/issues/1409

What does DGSource do when a stream does not start on a recovery point?

[stax76]

I've just tried to remux the .ts into .mkv with dsmux and I can confirm that the resulting .mkv works correctly in DGDecNV, so there's a problem with mkvmerge. And my apologies for hijacking the thread.

It's not really a bug or something as far as I can see, it's more a limitation and a better implementation is rather unlikely because it should be very hard to do even for a master programmer like Mosu, you can create a ticket but don't expect much.