DGDecNV (linux)

DG tools for linux

Moderator: Sherman

User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Hi Sherman, :salute:

It would be great, if you could implement following features: :D
a) progress of the indexing operation, like dgdemux
b) eliminate report in display area
c) writing a log file
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

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.
Sherman Peabody
Director of Linux Development
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

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 :scratch:
Attachments
report_in_display_area.png
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

Gotcha! Not sure why it was done like that in the initial port. Should be easy to fix...for me. :lol: 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.
Sherman Peabody
Director of Linux Development
User avatar
Britney
Posts: 150
Joined: Sun Aug 09, 2020 3:24 pm

DGDecNV (linux)

Post by Britney »

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.
User avatar
Curly
Posts: 741
Joined: Sun Mar 15, 2020 11:05 am

DGDecNV (linux)

Post by Curly »

simp = squirrel in my pants

knerk
Curly Howard
Director of EAC3TO Development
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

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.
Sherman Peabody
Director of Linux Development
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

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.
Sherman Peabody
Director of Linux Development
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Hi Sherman,
I have checked DGDecNV linux build 231 with spaces in filename.
It works without findings, many thanks. :salute:
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

Thank you for your testing, Frankaboy!
Sherman Peabody
Director of Linux Development
User avatar
Wonder Woman
Posts: 58
Joined: Sun Feb 07, 2021 10:46 am

DGDecNV (linux)

Post by Wonder Woman »

User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

@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.
Sherman Peabody
Director of Linux Development
User avatar
Baltasar
Posts: 61
Joined: Tue Nov 02, 2021 9:51 am

DGDecNV (linux)

Post by Baltasar »

A noble goal, to be sure.
User avatar
DJATOM
Posts: 176
Joined: Fri Oct 16, 2015 6:14 pm

DGDecNV (linux)

Post by DJATOM »

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 :)
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Hi Sherman,
I am back on Saturday evening. I will answer you in detail on next Monday.
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

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. :o
Sherman Peabody
Director of Linux Development
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Hi Sherman, :salute:
seems I wasn't able to explain understandably my request, sorry :facepalm: .

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.
Preview_vapoursynth_dgidecodenv.png
But during encoding process, the frame information will be hard coded in the video.
Encoded_vspipe_dgdecodenv.png
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. :scratch:
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Rocky
Posts: 3684
Joined: Fri Sep 06, 2019 12:57 pm

DGDecNV (linux)

Post by Rocky »

Do you have show=True in your script?
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Hi Rocky,
yes I have show=True in the vpy script.
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Rocky
Posts: 3684
Joined: Fri Sep 06, 2019 12:57 pm

DGDecNV (linux)

Post by Rocky »

So that is asking for the overlay. If you don't want it, omit that option or set it to False.
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Many Thanks,
show = False works fine. :hat:
I have used your recommendation for a typical script.
The behavior of show option is now clear. ;)
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Rocky
Posts: 3684
Joined: Fri Sep 06, 2019 12:57 pm

DGDecNV (linux)

Post by Rocky »

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.
User avatar
frankaboy
Posts: 69
Joined: Wed May 17, 2023 4:24 am

DGDecNV (linux)

Post by frankaboy »

Heyo Rocky,
hope you are fine? :salute:

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. :D :facepalm:

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.
Frankaboy
I enjoy 3D movies
:popcorn:
User avatar
Sherman
Posts: 596
Joined: Mon Jan 06, 2020 10:19 pm

DGDecNV (linux)

Post by Sherman »

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.
Sherman Peabody
Director of Linux Development
User avatar
Curly
Posts: 741
Joined: Sun Mar 15, 2020 11:05 am

DGDecNV (linux)

Post by Curly »

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
Curly Howard
Director of EAC3TO Development
Post Reply