Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
1st December 2018, 19:10 | #6561 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Quote:
Quote:
As best as I can tell, MeGUI is obtaining the source Input DAR from MediaInfo (at least for MKVs). It's oblivious to any DGIndexNV cropping (that's obvious as if you change the cropping in the index file as it has no effect on the Input DAR in the script creator). MeGUI is also oblivious to encoder padding, so if you don't let DGIndexNV crop it I think a 1080p source will open as 1920x1088, but to MeGUI the Input DAR would still be exactly 16:9. I assume DGIndexNV crops the padding by default (CLIP 0 0 0 8) so the script output and source resolution will match, although to me it seems odd the padding cropping is optional or exposed to the user. I'm not sure I can think of a good reason not to crop it. If DGIndexNV crops only the padding, there's no reason why you can't apply Avisynth's cropping and resizing as you normally would, but unfortunately the DGIndexNV cropping is over-ridden by any DGSource cropping. Why the DGSource cropping isn't "in addition to" the DGIndexNV cropping I don't know, but that's the way it works. So if you use DGSource to crop 4 pixels from the bottom, you're effectively undoing some of the DGIndexNV cropping instead, the output will be 1920x1084, and MeGUI will still see the Input DAR as 16:9. I'm pretty sure much the same thing will happen for any source where the width or height isn't mod16. I don't know if there's an easy way around it, but to me it means using DGSource to crop isn't a good thing, and therefore MeGUI shouldn't be using DGSource for resizing either. And.... based on the example in my previous post, I'd avoid using DGIndexNV entirely for mod2 sources. What's with mod4 being compulsory anyway if the encoder always pads to mod16? PS. I wonder what the logic was behind DGIndexNV specifying it's cropping in a different order to DGSource. For DGIndexNV it's Left, Right, Top, Bottom. For DGSource it's Top, Bottom, Left, Right For anyone who's used Avisynth for any length of time, DGIndexNV's "CLIP 8 8 4 4" probably requires a mental translation to the Avisynth order of Left, Top, Right, Bottom, which I seem to be quite prone to forget to do, and I'm easily confused. And it would be nice to shuffle the DGSource arguments around so you could specify cropping and resizing in a familiar fashion.... ie the Avisynth resizer way... and if it was up to me, using negative values for Right and Bottom to add a special touch of consistency. DGSource("D:\video.dgi", 1280,720, 8,2,-8,-4) Oh well..... Last edited by hello_hello; 3rd December 2018 at 07:04. |
||
2nd December 2018, 21:01 | #6562 | Link | |||
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Quote:
Quote:
Btw. I hope to be able to continue with the ChapterCreator soon (= this year), however I am a bit lost what was missing there based on the latest changes in the test branch. |
|||
2nd December 2018, 22:56 | #6563 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Quote:
I wouldn't expect MeGUI to know about any user modifications to the cropping in the index file. There's still the mod2 issue I mentioned in an earlier post. If you make yourself a small mod2 sample you'll see what I mean, but what seems to happen is when the padding to be cropped is mod2.... 718x480 with 2 pixels of padding as an example.... DGIndexNV adds "CLIP 0 2 0 0" to the index file but doesn't apply it, as far as I can tell. Instead the video is resized to 718x480, including the padding. When the index file is opened in the script creator, MeGUI enforces mod4 for the DGSource cropping, but it's actually mod2 cropping in mod4 increments because the source wasn't mod4. I guess in the end it's a DGIndexNV/DGSource mod4 obsession, and MeGUI just has to work with it. The world appears as though it'll continue to turn when the width is mod2 though, so why is there a need to enforce mod4? Quote:
I've backpeddled on the idea of locking the input or output fps. They should always be considered to be a numerator and denominator. The input fps can default to the source fps if it's known, and the output fps can default to the preview fps is it's being used, but you should be free to change both. And the chapter timings in the GUI should always reflect what's being saved. Regardless of the input type, I think it comes down to the two simple rules I mentioned a while back. 1: If the input/output fps are the same, the chapter timings don't change, even if they don't match the source frame rate. The keyframe numbers are calculated based on the input fps and chapter timings. 2: If the input/output fps are different, they become the numerator and denominator for chapter timings and stretch them accordingly, but they don't "stretch" the keyframe numbers. They're still calculated based on the input fps and the chapter timings. Oh, and I'm sure you were going to add a third column. One to display the input chapter timings, one to display the adjusted chapter timings, and a third to display the keyframe numbers. Thanks for all the hard work! I'll save another rant about switching from the old and not quite right ITU aspect ratios to the modern mpeg4 aspect ratios for some other time. Last edited by hello_hello; 2nd December 2018 at 23:04. |
||
3rd December 2018, 05:53 | #6565 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,821
|
There's nothing special about the source I'm using, whichever one you're referring to.
For the mod2 test I indexed a vob file with DGIndex, cropped it to 718x480, then encoded 500 frames. I used the output AVC/MKV as my source. There's DGSource vs LWLibavVideoSource screenshots here (no additional cropping applied to the encoded version), although I cropped the original video to 638x398 before using the encoded version as the source that time. The DGSource output appears to be resized to 638x398 rather than the padding being cropped. I'm sure the 1080p/non mod16 problem would be typical, given it's expected behaviour according to the help files. For the AVC/MKV I just opened, which I encoded myself, the top section of the dgi file after MeGUI ran the indexing looks like this: DEVICE 0 DECODE_MODES 0,0,0 STREAM 2 CLIP 0 0 0 8 RANGE 0 0 18446744073709551615 0 AUDIO At the end: SIZ 1920 x 1088 FPS 239760 / 10000 A screenshot of the Avisynth output with only the following in the script (aside from the LoadPlugin line). You might have to use the download link on the postimg site for the full size version. It won't display any larger than 720p in my browser. DGSource("D:\test.dgi") Info() With the script changed to the following by applying four pixels of bottom cropping with MeGUI's script creator. DGSource("D:\test.dgi", crop_t=0, crop_b=4, crop_l=0, crop_r=0) Info() Last edited by hello_hello; 3rd December 2018 at 07:59. |
3rd December 2018, 08:24 | #6566 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Zathor,
Here's my "artist impression" of what the next version of the AVS Cutter might look like. There'd probably be a need for an extra button on the preview to switch between the original script and the version with the trims applied, or something along those lines, but that's the idea. No pressure, of course. Whenever you have a few minutes to spare. PS. Is it a necessary limitation for the AVS Cutter to not allow overlapping frame numbers for Trim()? Last edited by hello_hello; 3rd December 2018 at 13:42. |
3rd December 2018, 12:46 | #6567 | Link |
Registered User
Join Date: Aug 2012
Posts: 43
|
2895
Bugs with DGIndex Cropping is still/again there. 1: When using Avisynth Cropping, crops additionally are applied in DGSource Filter 2: When using DGSource Cropping, wrong crops are applied, when the setting 1088->1080 in DGIndex is used. |
3rd December 2018, 14:20 | #6568 | Link | |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
Quote:
"I made a clip with a resolution of 638x398 (AVC/MKV) and indexed it with DGIndexNV and LSmash. The DGIndexNV dgi file includes CLIP 0 2 0 2" I do not have a file that when indexed shows CLIP 0 2 0 2. Please provide a link to this file if you want my help. If you don't want my help that's OK too. |
|
3rd December 2018, 14:52 | #6569 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Another cropping thing I'm not sure I understand. MeGUI has always allowed cropping of any mod. The mod setting only applies to resizing. Is there a reason related to decoding that forces DGSource to crop in increments of 4? For example, it's not possible to crop a mod4 source this way with DGDecode for a mod4 output width.
DGSource("D:\video.dgi", crop_t=0, crop_b=0, crop_l=2, crop_r=2) I assume that's a necessary limitation? DGSource isn't making it easy for you... When cropping with DGSource, MeGUI enforces mod4 cropping "increments" in the GUI when using the arrows to crop, but it still permits non-mod4 increments when you type in a cropping value. The end result is what you see in the GUI and what's added to the script aren't the same thing, and the resizing dimensions and aspect error calculations are likely to be wrong. If you do type a mod2 cropping value, MeGUI still enforces increments of 4 when using the arrows to adjust the cropping, but they're not mod4. Normal Avisynth cropping and resizing (4:3 720x480 source), after typing mod2 cropping values into the GUI. After doing the same with DGSource cropping enabled, an extra 4 pixels of cropping are added to the script, but it's not reflected in the aspect error calculation. Last edited by hello_hello; 3rd December 2018 at 15:23. |
3rd December 2018, 15:19 | #6570 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Quote:
Crop(2,0,0,-2) Trim(0,499) Here's me taking the time to write essays and post screenshots to describe problems, but silly me for thinking I was the one being helpful. Last edited by hello_hello; 3rd December 2018 at 15:37. |
|
3rd December 2018, 15:21 | #6571 | Link | |||
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Quote:
Quote:
__________________
Groucho's Avisynth Stuff |
|||
3rd December 2018, 18:02 | #6574 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,821
|
Quote:
Anyway, it's your program. I don't have the mod2 encodes I created for testing any more. If you'd rather be childish than spend the 30 seconds it'd take to create one yourself so you can check a reported problem, that's up to you. Last edited by hello_hello; 3rd December 2018 at 18:05. |
|
3rd December 2018, 18:15 | #6575 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
I'm not asking you to fix it. The help I could give you is to provide a fixed program. The help you can give me is to provide a stream.
If you can make the stream in 30 seconds, why don't you do that? Last edited by videoh; 3rd December 2018 at 18:24. |
3rd December 2018, 18:43 | #6577 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
It's not actually a problem and there is nothing to fix. But I'll be happy to oblige you by letting it go.
CLARIFICATION: Not shown to be a problem in DGDecNV. There are known issues in NVDec, but it's not established yet whether they account for the reported issue. Last edited by videoh; 6th December 2018 at 21:38. |
3rd December 2018, 19:06 | #6578 | Link | ||
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Quote:
|
||
3rd December 2018, 19:16 | #6579 | Link |
Registered User
Join Date: Aug 2012
Posts: 43
|
And am I missing some option?
I always get an error message when trying to open the *.dgi file in AVS Script creator. Seems to be related with the usage of relative paths in the dgi file. Setting in DGIndexNV.ini is always reset to not use Full Paths. Strange thing is: This error message names "DirectShowSource" as source. Last edited by pommesmatte; 3rd December 2018 at 19:18. |
3rd December 2018, 19:27 | #6580 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Are you sure about that? I force "Full_Path_In_Files=1" during every run of the dgindexnv step. How do you reproduce it? Do you open the DGIndexNV application manually inbetween? Could you please upload a log of the step?
|
Thread Tools | Search this Thread |
Display Modes | |
|
|