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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 1st December 2018, 19:10   #6561  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by Zathor View Post
Thanks, let me check that, how do you reproduce it? It should never show both cropping options in the script code obviously.
Without the "use Nvidia cropping" option checked, I seemed to be able to reproduce what you see in the screenshots below by first enabling and applying some cropping (which only adds Avisynth cropping to the script), but after enabling resizing, the cropping appears in both places. I even reset the Avisynth template first to see if that'd make a difference.



Quote:
Originally Posted by Zathor View Post
If resize is done by DGSource also cropping should be done that way otherwise you get unexpected results.
Which means DGSource probably shouldn't be used for resizing either.

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.
hello_hello is offline   Reply With Quote
Old 2nd December 2018, 21:01   #6562  |  Link
Zathor
Registered User
 
Join Date: Nov 2009
Posts: 2,405
Quote:
Originally Posted by hello_hello View Post
Without the "use Nvidia cropping" option checked, I seemed to be able to reproduce what you see in the screenshots below by first enabling and applying some cropping (which only adds Avisynth cropping to the script), but after enabling resizing, the cropping appears in both places. I even reset the Avisynth template first to see if that'd make a difference.
Correct, there was a bug so that when the first dgi file was opened in AVS Script Creator the option to resize with DGSource() was disabled independent of the settings in the AVS preset (fixed, but not uploaded yet). Thanks for pointing that out.

Quote:
Originally Posted by hello_hello View Post
Which means DGSource probably shouldn't be used for resizing either.
My only statement was that it must be used together. If it should be used at all is up to the user. By default the option to crop/resize with DGSource() is disabled, so the user has to enable it.

Quote:
Originally Posted by hello_hello View Post
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).
[...]
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.
I change it in the way that the DGI file will be read (CLIP) and that values will be added on top of the selected values in MeGUI in the DGSource() call. However if a user modifies the CLIP values directly, there is no chance that MeGUI can adjust the input (D)AR.

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.
Zathor is offline   Reply With Quote
Old 2nd December 2018, 22:56   #6563  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by Zathor View Post
I change it in the way that the DGI file will be read (CLIP) and that values will be added on top of the selected values in MeGUI in the DGSource() call. However if a user modifies the CLIP values directly, there is no chance that MeGUI can adjust the input (D)AR.
That'd probably do the trick, although it's not exactly intuitive from a user perspective unless you know why it's happening. I imagine lots of people will ask why their specified 4 pixel cropping has become 12 pixels in the script etc, but I can't think of a better alternative.

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:
Originally Posted by Zathor View Post
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.
The short answer is.... just make it work like chaptergen.

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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 01:25   #6564  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by hello_hello View Post
That'd probably do the trick, although ...
Can you post a link to your source file please?
videoh is offline   Reply With Quote
Old 3rd December 2018, 05:53   #6565  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by videoh View Post
Can you post a link to your source file please?
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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 08:24   #6566  |  Link
hello_hello
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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 12:46   #6567  |  Link
pommesmatte
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.
pommesmatte is offline   Reply With Quote
Old 3rd December 2018, 14:20   #6568  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by hello_hello View Post
There's nothing special about the source I'm using, whichever one you're referring to.
Sure there is. You said previously:

"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.
videoh is offline   Reply With Quote
Old 3rd December 2018, 14:52   #6569  |  Link
hello_hello
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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 15:19   #6570  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by videoh View Post
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.
In the time you spent typing your post you could've made one as I described. Just encode a mod16 video with the following in the script and use it as the source. Or crop it to 638x398 as I did. It'd take about 30 seconds. I've already deleted the encodes I made for mod2 testing, and I was reporting a problem, not asking for help.

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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 15:21   #6571  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by hello_hello View Post
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?
Sometimes it helps to read the manual:
Quote:
Cropping Filter


Use this option to crop your video.

Use the checkbox in the upper left corner to Enable or Disable this filter. Position the Left, Right, Top, and Bottom controls until desired results are achieved.

The Auto Crop buttons can be used to automatically crop away black bars (letterboxing and pillarboxing). Auto Crop mod 4/8/16 will enforce at least mod 4/8/16, respectively, for the resulting width and heigth. For best results, navigate to a frame with high contrast between the video and the black bars before entering the cropping dialog.

DGIndexNV stores the cropping settings in the DGI file and DGDecodeNV reads them and applies the same cropping to the served video, so that what you see in the DGIndexNV window is what you get in the served video.
Also, further down in DGIndexNVManual.html:
Quote:
APPENDIX F: Auxiliary INI File Options

Fine_Cropping=0/1: When set to 0, the cropping granularity is 4 pixels. When set to 1, the cropping granularity is 2 pixels, subject to the constraint that the cropped width must be mod 4. E.g., you can crop 2 pixels from each side.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Old 3rd December 2018, 16:49   #6572  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by hello_hello View Post
I was reporting a problem, not asking for help.
Why would you report a problem if you do not want it fixed? If you do not have the source code, then you need my help to get it fixed.

Last edited by videoh; 6th December 2018 at 21:36.
videoh is offline   Reply With Quote
Old 3rd December 2018, 17:09   #6573  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by Groucho2004 View Post
Sometimes it helps to read the manual
I read them, but I wasn't sure if it was a necessary limitation due to the way the video is decoding, or if it's a design decision in case there's instances where mod2 cropping causes problems.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 18:02   #6574  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by videoh View Post
Why would you report a problem if you do not want it fixed? If you do not have the source code, then you need my help to get it fixed. I understand your DG derangement is affecting your thinking, but get a grip.
There's a distinction between reporting a problem and asking for help. If I don't have the source code, then it doesn't matter how much help I get, I can't fix the problem. See the difference yet?

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.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 18:15   #6575  |  Link
videoh
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.
videoh is offline   Reply With Quote
Old 3rd December 2018, 18:30   #6576  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Just leave the problem unfixed. I've lost interest and moved on.
hello_hello is offline   Reply With Quote
Old 3rd December 2018, 18:43   #6577  |  Link
videoh
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.
videoh is offline   Reply With Quote
Old 3rd December 2018, 19:06   #6578  |  Link
Zathor
Registered User
 
Join Date: Nov 2009
Posts: 2,405
Quote:
Originally Posted by pommesmatte View Post
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.
Thanks, this will be fixed (hopefully) in 2896. Excpect a release in the next hours.

Quote:
Originally Posted by hello_hello View Post
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.
Based on the current issues (see above) I cannot fully change it as I would like it as I do not have the time for it. So in 2896 this will be partially changed/adjusted based on your feedback.
Zathor is offline   Reply With Quote
Old 3rd December 2018, 19:16   #6579  |  Link
pommesmatte
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.
pommesmatte is offline   Reply With Quote
Old 3rd December 2018, 19:27   #6580  |  Link
Zathor
Registered User
 
Join Date: Nov 2009
Posts: 2,405
Quote:
Originally Posted by pommesmatte View Post
Setting in DGIndexNV.ini is always reset to not use Full Paths.
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?
Zathor is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:00.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.