DGDecNV (linux)

frankaboy · Post by **frankaboy** » Mon Sep 04, 2023 8:34 am

Hi Sherman,

It would be great, if you could implement following features:

a) progress of the indexing operation, like dgdemux
b) eliminate report in display area
c) writing a log file

Post by **Sherman** » Mon Sep 04, 2023 9:01 am

Ha, I thought you'd ask for much more. Well, I do plan to add much more than you asked for.

What do you mean by "eliminate report in display area"?

Thank you.

frankaboy · Post by **frankaboy** » Mon Sep 04, 2023 12:11 pm

Hi Sherman my friend,
I mean that current limitation for Linux DGDecNV:

Currently, the display area is reported as the same as the coded frame
size in the DGI file. Crop as needed in your script.

Hope it is clear with the attachment

Post by **Sherman** » Mon Sep 04, 2023 1:03 pm

Gotcha! Not sure why it was done like that in the initial port. Should be easy to fix...for me.

I already have the CLI parsing fixed. In that regard, now instead of a comma-separated list for -i, we will have a simple list of arguments:

dgindexnv -i file1.m2ts file2.m2ts -o out.dgi

That is easier to implement and, in my not-so-humble opinion, is more linux-like.

Britney · Post by **Britney** » Mon Sep 04, 2023 1:10 pm

Way to go, Sherm! Humbleness is for simps.

Hey Frankaboy, you're not humble, right? How old are you and what do you do for a living? You seem like high IQ. That could be a plus or minus depending.

Post by **Curly** » Mon Sep 04, 2023 1:43 pm

simp = squirrel in my pants

knerk

Post by **Sherman** » Tue Sep 05, 2023 7:36 am

Folks, here are the current linux limitations:

------------
1. Only Vapoursynth is supported.

2. Only 64-bit operation is supported.

3. For HEVC and VC1 some fields of the DGI file are not yet implemented:
ASPECT, COLORIMETRY, and ORDER. These are not used by DGDecodeNV so
this is inconsequential for serving of the video.

4. CLI error handling may not be thorough at this time. Please report
any failures in that regard.

5. Progress of the indexing operation is not reported. This
will be implemented in a future version.

6. The display area is reported as the same as the coded frame
size in the DGI file. Crop as needed in your script.

7. Full paths are always used in the DGI file and generated script files,
and full paths are required in scripts that you generate manually.

8. A log file is not created.

9. Spaces in file names is broken. Use underscores instead of spaces for now.

10. The INI file is not supported for options.
------------

My plan is to correct 3-10. 1-2 will not be done. I will make two releases:

1. Slipstream for build 231 correcting spaces in file names and fixing doc errors.

2. New release for the limitation fixes. This will be called build 500, because we do not want to
imply any direct comparison with the Windows version. This version will cover Frankaboy's requests.

After releasing build 500, I will start to port the other features from the Windows version that
are applicable.

Post by **Sherman** » Tue Sep 05, 2023 9:46 am

Here is a slipstream for DGDecNV linux build 231:

* Fixed spaces in filenames.
* For multiple input files use a list of arguments instead of a
comma-delimited list. Refer to the manual for details.
* Updated and corrected the text documents.

https://rationalqm.us/dgdecnv/binaries

Please test this, guys. If no problems are found, Rocky will make a release announcement. Thank you.

frankaboy · Post by **frankaboy** » Wed Sep 06, 2023 1:38 am

Hi Sherman,
I have checked DGDecNV linux build 231 with spaces in filename.
It works without findings, many thanks.

Post by **Sherman** » Wed Sep 06, 2023 9:34 am

Thank you for your testing, Frankaboy!

Wonder Woman · Post by **Wonder Woman** » Thu Sep 07, 2023 10:03 am

Post by **Sherman** » Thu Sep 07, 2023 2:06 pm

@Frankaboy

Just curious. You asked for the coded/display size distinction to be restored. May I ask what the use case is that motivates you for this? Is it just the case of 1080-height streams coded as 1088? Or are there other cases? Please tell me all the cases that you have run into and that are relevant for you.

I could just slavishly copy the Windows version, but I have noted some strangenesses in how things are done. So I am thinking of doing things differently, but I want to be sure that what I do meets your needs.

Post by **Baltasar** » Thu Sep 07, 2023 10:47 pm

A noble goal, to be sure.

DJATOM · Post by **DJATOM** » Fri Sep 08, 2023 3:43 am

Sherman wrote: ↑
Thu Sep 07, 2023 2:06 pm
May I ask what the use case is that motivates you for this?

Usually there are 8 pixels at bottom for 1080p blu-rays that must be cropped. At least I'm using DGDecNV for blurays and have to crop that manually when encoding videos on Linux. But it would be nice to let plugin crop that for me

frankaboy · Post by **frankaboy** » Fri Sep 08, 2023 5:41 am

Hi Sherman,
I am back on Saturday evening. I will answer you in detail on next Monday.

Post by **Sherman** » Sat Sep 09, 2023 1:51 pm

Mr DJATOM. Correct!

My research shows there are ways for display != coded:

1. Anamorphic video. The aspect ratio information is applied. This is currently
done only for MPG2, e.g., DVD 4:3 -> 16:9 'widescreen'. Who cares?

2. The video ES specifies a cropping rectangle. This is applied but only for
right and bottom. So it's good enough to fix 1088->1080. Just have to
get the cropping rectangle under linux without nvdec. No big deal,
I already have it solved in my head.

I'll update this post as my research continues. A new standard for program
development.

frankaboy · Post by **frankaboy** » Mon Sep 11, 2023 8:44 am

Hi Sherman,

seems I wasn't able to explain understandably my request, sorry

.

Hopefully the pictures make it clear.
I have used for that example 4k video with resolution 3840x2160, format 16:9 (no black borders)!

In the vapoursynth preview (upper left corner) you see the current frame information.
That is fully okay in the preview mode.

But during encoding process, the frame information will be hard coded in the video.

My request ask for "elimination of frame information in the encoded video", preferably without cropping.
Maybe frame serving via dgdecodenv is possible, without the frame information.

Post by **Rocky** » Mon Sep 11, 2023 11:28 am

Do you have show=True in your script?

frankaboy · Post by **frankaboy** » Mon Sep 11, 2023 11:35 am

Hi Rocky,
yes I have show=True in the vpy script.

Post by **Rocky** » Mon Sep 11, 2023 11:45 am

So that is asking for the overlay. If you don't want it, omit that option or set it to False.

frankaboy · Post by **frankaboy** » Mon Sep 11, 2023 12:09 pm

Many Thanks,
show = False works fine.

I have used your recommendation for a typical script.
The behavior of show option is now clear.

Post by **Rocky** » Mon Sep 11, 2023 12:12 pm

You're right. I should remove that from the script sample. You have opened up an interesting line of analysis about coded size != displayed size.

frankaboy · Post by **frankaboy** » Mon Sep 18, 2023 10:09 am

Heyo Rocky,
hope you are fine?

I was busy during the last days, so no time to respond to your last post, sorry.

It is funny to read, that I had opened a interesting line, caused due to the fact,
that I didn't understand the current Linux Limitations for dgdecodenv.
Noobs error, laughing about myself.

To be honest, I don't know which impact "analysis about coded size != displayed size" has for dgdecodenv.

May you can explain it for non native English people.

Post by **Sherman** » Mon Sep 18, 2023 7:37 pm

Hello Frankaboy, always great to hear from you. And happy to explain things for you.

Pictures are encoded using "macroblocks". These typically are units of 16 pixels square. So imagine we have a video with size 1920x1080. Well, 1920 is divisible by 16 so it would be an integral number of macroblocks. However, 1080 is not divisible by 16. For the height then we have to encode the frame as 1088 because that is an integral number of macroblocks. Now we have the problem that our coded size is bigger than what we want to display, i.e., our display size. In short, coded != displayed.

Given this fact, that the two can differ, the video format syntax must contain some way to signal this, so the display process (or in our case, the source filter) can deliver the correct dimensions. Each of the four video formats that DGDecNV supports signals it in a different way. For example, VC1 allows for specifying a display width and height that differs from the coded size. AVC goes further and allows a display rectangle to be defined. It can be a little window anywhere in the frame. 1088 -> 1080 just requires to specify the rectangle for that.

Now here's the kicker. NVDec returns a four-tuple that specifies the desired window in the coded video frame. OK, great. But wait, in linux we do not have any decoding inside DGIndexNV. So to properly implement things, we have to parse the video syntax rather than getting the answer from NVDec.

In the wild, what we see is that this facility is rarely used except for this bastard case of 1088->1080. Consider UHD: it is 3840x2160. Both dimensions are divisible by 16.

There are a lot more nuances, such as that HEVC can specify 8-pixel macroblocks.

Anamorphic video also can cause coded != displayed. Anamorphic video was used for DVDs to make a kind of pseudo widescreen. That is obsolete nowadays.

Bottom line: we want to honor the specified rectangle, and hence the display width and height, if nothing else to cover the 1088->1080 case, which is still seen in the wild. We don't care about anamorphicity and expect you to handle that in your script with an appropriate resize operation.

OMG, I'm starting to sound like Rocky.

Post by **Curly** » Mon Sep 18, 2023 8:01 pm

too complicated ya noid

forgit video format this and that
are you kidding

one little code thing

if vi.height == 1088 vi.height = 1080

listen up kid
just do that and use coded width and height
forgit displayed

bow now to your cosmic guru