Page 1 of 2
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 9:50 am
by Rocky
DGSource does not deliver any aspect ratio information at all (EDIT: yes it does but only for Vapoursynth). It delivers only the decoded video. So your question is incoherent. Nevertheless I try to clarify things for you.
The aspect ratio information is shown in the DGIndexNV Info dialog. There must have been a preview operation for that information to be included in the log file (there can't be a preview with CLI), but it is always available in the DGI file.
The source MPG file you provided specifies aspect_ratio_information as 3. That means DAR 16:9. The MPEG2 spec specifies a way to derive a SAR from the DAR and frame size. You can read the spec if you are interested. But be aware that DGDecNV does not calculate or report any SAR value, so all this is irrelevant to your question. DGIndexNV reports only the DAR, and DGSource() does not deliver anything regarding aspect ratio.
I cannot be held responsible for what other tools are /calculating/reporting/inferring for SAR. There is also a lot of confusion and ambiguity with the notation, so that may be underlying what you are seeing. E.g., SAR is sometimes used as "Storage Aspect Ratio" and as sometimes as "Sample Aspect Ratio".
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 10:04 am
by hydra3333
thank you for the clarification.
I guess lsmash must somehow deliver it, on the basis of the resulting output file characteristics when using lsmash as the source.
oh well.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 10:10 am
by Rocky
Ah, noticed you are using Vapoursynth. Perhaps the SAR gets set in the per-frame metadata by lsmash. I'll check that.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 10:16 am
by Rocky
Yes, Vapoursynth has this:
int _SARNum, int _SARDen
Pixel (sample) aspect ratio as a rational number.
I will add setting that to my to-do list, but it's not high priority. Is it some kind of showstopper for you?
BTW, my calculation yields 1.422 as the PAR (SAR).
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 10:21 am
by Rocky
Haha, I just looked and I am already setting it. I'll check to see what it is setting for your stream and correct it if needed.
EDIT: Yup, my bad. I wrote the DAR in there. Will fix it. Thank you for pointing this out.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 11:11 am
by Rocky
Let me know if this is working better:
http://rationalqm.us/misc/DGDecodeNV_hydra.dll
I tested it for MPG2 only but it should be OK for all the video types.
EDIT: Rename it to DGDecodeNV.dll of course.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Fri Jul 31, 2020 8:22 pm
by hydra3333
Thanks !
Close but no cigar I'm afraid.
Code: Select all
Width : 720
Width : 720 pixels
Height : 576
Height : 576 pixels
Sampled_Width : 720
Sampled_Height : 576
Pixel aspect ratio : 1.000
Display aspect ratio : 1.250
Display aspect ratio : 5:4
Looking for something more like:
Code: Select all
Width : 720
Width : 720 pixels
Height : 576
Height : 576 pixels
Sampled_Width : 720
Sampled_Height : 576
Pixel aspect ratio : 1.422
Display aspect ratio : 1.778
Display aspect ratio : 16:9
which is what one gets with lsmash or when adding '-vf "setdar=16/9"' on the ffmpeg commandline and then plays OK in media player classic home cinema.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sat Aug 01, 2020 9:08 am
by Rocky
Having trouble duplicating your result (not to mention the nightmare of vapoursynth error messages -- don't give a full path to the DLL and it tells you to update windows -- are you kidding me?). I have these scripts:
FILE2_dgdecodenv.vpy:
Code: Select all
import vapoursynth as vs
from vapoursynth import core
core.std.LoadPlugin(r'D:\Don\Programming\C++\DGDecNV\DGDecodeNV\x64\release\DGDecodeNV.dll')
video = core.dgdecodenv.DGSource(r'FILE2.dgi', deinterlace=0, use_pf=False)
video = vs.core.text.ClipInfo(video)
video.set_output()
FILE2_lsmash.vpy:
Code: Select all
import vapoursynth as vs
from vapoursynth import core
core.std.LoadPlugin(r'D:\tmp\hydra3333 SAR problem\LSMASHSource.dll')
video = core.lsmas.LWLibavSource(source=r'D:\tmp\hydra3333 SAR problem\FILE2.mpg', ff_loglevel=6)
video = vs.core.text.ClipInfo(video)
video.set_output()
When opened in VirtualDub2, they both show identical ClipInfo. There are no other properties that I am aware of, so it seems both scripts make available the same information.
Now, on to ffmpeg. I can't follow your command at all. It's complicated by NVENC and stuff. And my latest ffmpeg says that '-input vapoursynth' is an unknown input format. So I made simple ffmpeg lines using a pipe:
vspipe --y4m FILE2_lsmash.vpy - | ffmpeg -i pipe: encoded_lsmash.mp4
vspipe --y4m FILE2_dgdecodenv.vpy - | ffmpeg -i pipe: encoded_dgdecodenv.mp4
Then I run mediainfo on the MP4 files and I get the same thing for both (except for very small difference in bitrate):
Code: Select all
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29 s 640 ms
Bit rate : 369 kb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.036
Stream size : 1.31 MiB (99%)
Writing library : x264 core 161
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box : avcC
This does not show PAR like your post does. I do not understand why.
So I am simply unable to account for your result either theoretically or by trying to duplicate it. The ball is in your court if you want to go further. Do things with a simplified ffmpeg command as I am not going through the NVENC rigamarole. You have to somehow prove that the two source filters are delivering different information, whereas I claim to have shown that they deliver the same information.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 4:27 am
by hydra3333
Thank you for trying !
How interesting.
The ffmpeg.exe is a custom cross-compile (but no patching on my part) with vapoursynth enabled.
I'll do some further testing (using the updated dll you posted) with ffmpeg/vsedit/virtualdub2 and let you know what I find.
I cannot currently explain the difference ! I'm leaning toward my error but cannot as yet say why.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 5:56 am
by hydra3333
Just checking ... you and I are using the same DLL (the link you provided to DGDecodeNV_hydra.dll) ?
I still get the same results so far (re-doing my ffmpeg commands)
Edit: it looks like ffmpeg and/or vapoursynth may be playing up. Initial result:
1. consistently - using lsmash : with vapoursynth input directly it is successful, however with pipe is now fails with the same .vpy.
2. consistently - with dgsource: it fails with the same .vpy on both pipe and direct .vpy input.
I used a .bat to ensure the right .vpy etc were consistently used repeatably 
I'll try another video and the original dgsource .dll to see what happens.
So, I tend to concur it isn't dgsource since issues also arise with lsmash.
I cannot explain why my pipe result (a fail) differs from yours, although I had upgraded to vapoursynth R51 just prior to these tests.
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 7:00 am
by Rocky
Yes, I use that one. Of course, you have to rename it to DGDecodeNV.dll.
Can you post a link to the ffmpeg you use, please? And can you simplify the command line to the minimum that shows the error? Are you getting different ClipInfo for DG and LSMASH contrary to what I showed, i.e., that they are the same?
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 10:29 am
by hydra3333
initial log is attached if you were interested.
ffmpeg option "-v verbose" is set so one can see lines containing text string SAR for the input streams rather than on the outputs.
edit: ignore this post, the .dll wasn't in the right place with the right name
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 10:39 am
by hydra3333
Rocky wrote: ↑Sun Aug 02, 2020 7:00 am
Yes, I use that one. Of course, you have to rename it to DGDecodeNV.dll.
Oh. I should have warned of a dummy alert here.
I'd imported it like this and it didn't crash. I'll rename it and try again.
Code: Select all
core.std.LoadPlugin(r'G:\HDTV\000-TO-BE-PROCESSED-DVD-MOVIE-ONLY\TEST\DGDecodeNV_hydra.dll')
Rocky wrote: ↑Sun Aug 02, 2020 7:00 am
Can you post a link to the ffmpeg you use, please? And can you simplify the command line to the minimum that shows the error?
Sure. Give it a good scan (I would). I use vapoursynth portable, so I drop the .exe in the same folder as extracted vapoursynth and python 3.8.
https://drive.google.com/file/d/1MXcB9z ... sp=sharing
Cross-compiled via a hackup here:
https://github.com/hydra3333/h3333_pyth ... cript_v100
Re the other stuff, I'd like to run some more tests. (Initial minimum commandline and log shown in post above)
Re: DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 11:09 am
by hydra3333
Ah.
It does go a bit better when you drop the .dll into the right folder (I suppose with the license file) and give it the right name.
Apologies.
The attached log now shows DGSource works a treat with direct .vpy input, however files created via pipe (with lsmash too) have incorrect attributes according to mediainfo.
So, the new DLL works just fine !!
Thank you. And again for your perseverance & patience.
Re: [Solved] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 11:26 am
by Rocky
Super happy we got it sorted out for you. I'll include it in the next slipstream. Thank you for bringing the issue to light.
Importing it with the wrong name should have given a license violation error on green video.
Hmm, now SOLVED or RESOLVED?
https://englishlessonsbrighton.co.uk/wh ... d-resolve/
Re: [Solved] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 11:31 am
by hydra3333
I got a green video alright when I finally looked at it ... I was focused on the logs.
Re: [Solved] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 12:27 pm
by hydra3333
he he, I used to work for the gov't where the worth of a report was assessed by the "n grams" method ... don't get me started
edit: oh, in the US that'd be "n ounces" or something I guess
Re: [SOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 6:05 pm
by Rocky
Re: [SOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 6:58 pm
by hydra3333
Rocky wrote: ↑Sun Aug 02, 2020 6:05 pm
... although I'm lazier nowadays, playing with English was the name of the game back in the day, if one wanted to get on in gov't. The more verbose it was, the weightier the report was, and of course the more valuable it must have been !
Hence, "n grams" where the greater the n the greater the obvious value
Re: [SOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Sun Aug 02, 2020 8:40 pm
by Rocky
I see, yes. Thank you for the explanation. Writing is hard and exhausting for me; still I enjoy it in moderation. Sky writing!
Re: [RESOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Tue Sep 29, 2020 7:08 pm
by hydra3333
Hello.
I got some aspect ratio problems again "recently" after a NV download. Well, I'm lazy, I worked around it via ffmpeg commandline option and forgot about it for some time.
Just wondering, it really is a funny world, would it be possible for the aspect ratio fix to have become unfixed, or is it somehow me ?
Separately and while I'm here, asking your opinion if you're prepared to give it :-
Someone purporting to be "Sabine Hossenfelder" has a "for dummies" science/physics type youtube channel which has a lot of interesting videos for lay people (like me), however she is said to be German but has what appears to be a Russian accent.
Would you happen know offhand if she's real, or fake ?
Not that I expect fake things on the internet or anything
...
https://www.youtube.com/watch?v=nGVIJSW0Y3k (this example video is well off-topic for her and funny, if a tad pointed; she goes off at lefties and righties and "follow the science").
Thanks
Re: [RESOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Wed Sep 30, 2020 7:52 pm
by Rocky
Regarding aspect ratio stuff, please post a source sample and method to duplicate your issue. I am not aware of any regressions in this area.
Regarding Sabine Hossenfelder, she's a "science populizer" and a mainstream quantum mysterian (she believes in quantum nonlocality, which she tries to account for with "superdeterminism"). She doesn't appear to have any significant original research in QM, but correct me if I have missed anything.
Her blog is here:
http://backreaction.blogspot.com
She'll be happy to talk to you for $150 per hour.
http://backreaction.blogspot.com/p/talk ... st_27.html
Bargain basement. Any competent consultant makes 300-500/hour.
She uses sensationalism (a form of rhetoric) to draw attention to herself. For example, using profanity in her videos and blog, wearing a mask in her avatar, calling people stupid, etc. This is how people with no really significant ideas behave. It's all about Sabine!
Re: [RESOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Wed Sep 30, 2020 11:25 pm
by hydra3333
OK and Thanks.
I'll try to locate a recent source.
[RESOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Tue Feb 02, 2021 8:28 am
by JKyle
I'm afraid this AR issue is not resolved yet.
It seems that DGSource passes on a reversed DAR value as a SAR value for some videos in VapourSynth.
Here's the sample video:
here.
Its SAR is 1:1 and DAR is 16:9. You can see that in DGIndexNV too.
The vpy is very simple:
Code: Select all
import os, sys
import vapoursynth as vs
core = vs.get_core()
sys.path.append(r"D:\Utilities\StaxRip\Apps\Plugins\VS\Scripts")
core.std.LoadPlugin(r"D:\Utilities\StaxRip\Settings\Plugins\Dual\DGDecNV\DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r"D:\Downloads\test_1audio_temp\test_1audio.dgi", deinterlace=0, fieldop=0)
clip.set_output()
But when this script is passed to x265, a wrong SAR value (=reversed DAR) is passed on.
x265 3.4+65-aMod(GCC10.2.1) DJATOM
D:\Utilities\StaxRip\Apps\Encoders\x265\x265.exe --crf 27 --output-depth 10 --output D:\Downloads\test_1audio_temp\test_1audio_DGSource_x265-direct-input_out.hevc D:\Downloads\test_1audio_temp\test_1audio_DGSource_x265-direct-input.vpy
vpy [info]: 1920x1080 fps 24000/1001 i420p8 sar 9:16 frames 0 - 2478 of 2479
...
At first, I thought this was an issue with the x265 build, so I reported an issue on its repo.
Here.
The author agreed to add an option to
ignore the SAR value passed on by the script
just like vspipe does.
But, the issue still remains: it seems that DGSource passes on
a reversed DAR value as the SAR value in VapourSynth.
Can you please take a look into this? Thanks.
[RESOLVED] DGSource seems to be delivering incorrect aspect ratio ?
Posted: Tue Feb 02, 2021 9:21 am
by Curly
Thanks man. Two things seem to have gone wrong.
1. Confusion about meaning of SAR. Vapoursynth is apparently using "SAR" as "pixel (sample) aspect ratio", but that is strictly the PAR, while SAR is the "storage aspect ratio", and is inferred as DAR/PAR. So we tried to calculate and return SAR thus defined. But when that was coded, it was erroneously inverted.
2. Vapoursynth says it wants the SAR with _SARNum/_SARDen, but interpreting SAR as PAR would require returning the PAR in _SARNum/_SARDen.
So, bottom line, we will change it to return the PAR. That would always be 1:1 for HD and may be != 1:1 for SD (could be NTSC or PAL).
Please confirm this is what you want and we'll make a slipstream right away. We also have a Doom9 thread asking Myrsloik to confirm this interpretation.