Don Moir
Typically VOB files (or any file) that has a special display aspect ratio.
For example: A VOB with actual resolution of 720x480 with a display aspect ratio of 16:9. The display aspect ratio is a modifier embedded in some videos that is the intended way to display the video... or a 720x480 with a display aspect ratio 4:3. Seems to be any video with a difference between the numeric and display aspect ratios.
VDJ displays the video as intended, but when a plugin calls DrawDeck and then returns S_OK, the video shrinks. This is an example of a 720x480 with a display aspect ratio of 16:9.
This is how it should look and the way it looks when no plugin is running that calls DrawDeck:
This is what happens when any video plugin calls DrawDeck and returns S_OK: (the video display has decreased in size)
This does not occur when the display aspect ratio is the same as the numeric ratio.
Also when OnDraw is called with a video like this, the width and height of the video is given as 720x480 and the plugin does not know that it has a different display aspect ratio if it wants to do something with the texture.
For example: A VOB with actual resolution of 720x480 with a display aspect ratio of 16:9. The display aspect ratio is a modifier embedded in some videos that is the intended way to display the video... or a 720x480 with a display aspect ratio 4:3. Seems to be any video with a difference between the numeric and display aspect ratios.
VDJ displays the video as intended, but when a plugin calls DrawDeck and then returns S_OK, the video shrinks. This is an example of a 720x480 with a display aspect ratio of 16:9.
This is how it should look and the way it looks when no plugin is running that calls DrawDeck:
This is what happens when any video plugin calls DrawDeck and returns S_OK: (the video display has decreased in size)
This does not occur when the display aspect ratio is the same as the numeric ratio.
Also when OnDraw is called with a video like this, the width and height of the video is given as 720x480 and the plugin does not know that it has a different display aspect ratio if it wants to do something with the texture.
geposted Fri 29 Mar 19 @ 10:35 pm
Adion
Thanks for reporting, will fix
geposted Sat 30 Mar 19 @ 8:03 am
Don Moir
Does not look like TVertex is used for GetTexture() for video plugin.
Maybe you could redefine it to deliver the display aspect ratio parameters.
Something like this to keep it compatible.
Maybe you could redefine it to deliver the display aspect ratio parameters.
Something like this to keep it compatible.
struct TVertex
{
........union
........{
...............struct {float x,y,z;} position;
...............struct {float displayWidth, displayHeight, ratio;} display;
........};
........DWORD color;
........FLOAT tu,tv;
};
geposted Sat 30 Mar 19 @ 1:45 pm
Don Moir
Are you going to provide a way so a plugin can determine the correct display ratio? Or are you just going to leave that broken?
geposted Mon 08 Apr 19 @ 5:33 am
Adion
Still have to update the sdk downloads, but there are 2 new flags that video plugins can use in the current early access release:
#define VDJFLAG_VIDEO_OUTPUTRESOLUTION 0x400000
#define VDJFLAG_VIDEO_OUTPUTASPECTRATIO 0x800000
VDJFLAG_VIDEO_OUTPUTASPECTRATIO will just keep the aspect ratio the same as the output, without increasing the resolution. (As currently used by the Blur Black Bars plugin)
VDJFLAG_VIDEO_OUTPUTRESOLUTION will render the deck plugins in the same resolution as the output (For text plugin and similar that require the full output resolution)
With either of these the render target is guaranteed to have square pixels, and you can use GetTexture to get the vertices to know more about the source.
Also note that you are allowed to keep a pointer to TVdjPluginInfo8 and update the flag based on the plugin needs between every OnDraw call
#define VDJFLAG_VIDEO_OUTPUTRESOLUTION 0x400000
#define VDJFLAG_VIDEO_OUTPUTASPECTRATIO 0x800000
VDJFLAG_VIDEO_OUTPUTASPECTRATIO will just keep the aspect ratio the same as the output, without increasing the resolution. (As currently used by the Blur Black Bars plugin)
VDJFLAG_VIDEO_OUTPUTRESOLUTION will render the deck plugins in the same resolution as the output (For text plugin and similar that require the full output resolution)
With either of these the render target is guaranteed to have square pixels, and you can use GetTexture to get the vertices to know more about the source.
Also note that you are allowed to keep a pointer to TVdjPluginInfo8 and update the flag based on the plugin needs between every OnDraw call
geposted Mon 08 Apr 19 @ 6:03 am
Don Moir
Ok will have a look. Thank you.
geposted Mon 08 Apr 19 @ 11:45 am
Don Moir
The thing is that decks have been worthless for something like TellyVisuals. That is for 2 reasons. First and without the new flags, the TellyVisuals image is only given the area of the video resolution to draw into. Then that image is scaled to actual display size. Of course everything is distorted and looks like crap. Not something any professional would want to see. Second, is the frame rate is dropping to frame rate of the video which can be all over the place. It could be 60 FPS for something like a CDG or 20 or 30 FPS or whatever. None of these is going to produce smooth results. Again not professional when you have things going from smooth to not smooth. Given these problems which are not explained anywhere, it is left up to me to try and explain this to end users who usually don't quite get it. Why do I have to try and explain it? Because no one else will.
My only recourse was to try and capture the video images from the decks and display them properly on the master. That almost works except in the case of videos with a special display aspect ratio. In that case, the information is not provided by VDJ. That is not something I want to do anyway. Another can of worms. Would be nice if the actual video textures were directly accessible from the master. I mean the actual video textures as well as the main drawing texture. Best I can do now is on the master, I am given the whole texture of what ever is in it which is likely not the same size of a video texture and is the size of the entire video window display. So manipulation of that texture is not ideal.
I am going to go thru this showing the problems with and without the new flags in separate posts.
My only recourse was to try and capture the video images from the decks and display them properly on the master. That almost works except in the case of videos with a special display aspect ratio. In that case, the information is not provided by VDJ. That is not something I want to do anyway. Another can of worms. Would be nice if the actual video textures were directly accessible from the master. I mean the actual video textures as well as the main drawing texture. Best I can do now is on the master, I am given the whole texture of what ever is in it which is likely not the same size of a video texture and is the size of the entire video window display. So manipulation of that texture is not ideal.
I am going to go thru this showing the problems with and without the new flags in separate posts.
geposted Tue 09 Apr 19 @ 3:50 am
Don Moir
First with none of the new flags. This is using a low resolution video (260x40) to exaggerate so the problem can be seen easier.
This is TellyVisuals displaying a blue border the size of the display area on deck 1. There is no video playing on the deck so there is no problem. The FPS is a constant 60.
This is what happens when I put the low res video on deck 1. TV has been given the 260x40 resolution of the video to display in. This effects all video plugins. Then that 260x40 area is scaled to fit the display. The new video flags change this behavior but I am showing how it is without the flags in this post. The blue border now only displays in the area given by the video. Not the actual display size. Imagine how distorted text and everything else is going to be. This size is also going to be changing for every video of different resolutions which just adds to the problem and would be make you look like a complete fool.
This is TellyVisuals displaying a blue border the size of the display area on deck 1. There is no video playing on the deck so there is no problem. The FPS is a constant 60.
This is what happens when I put the low res video on deck 1. TV has been given the 260x40 resolution of the video to display in. This effects all video plugins. Then that 260x40 area is scaled to fit the display. The new video flags change this behavior but I am showing how it is without the flags in this post. The blue border now only displays in the area given by the video. Not the actual display size. Imagine how distorted text and everything else is going to be. This size is also going to be changing for every video of different resolutions which just adds to the problem and would be make you look like a complete fool.
geposted Tue 09 Apr 19 @ 4:13 am
Don Moir
Now with the same scenario as above with the low res video on deck 1 and TV displaying it's border using the new flag VDJFLAG_VIDEO_OUTPUTRESOLUTION.
You can see that the TV display is no longer distorted to death. But you can see that FPS has dropped to 10 which is no good but the display is much better and how it should have always been. In this case I am letting TV display the video texture in the background so the panel border is covering over the video. The FPS will go back to 60 when the video is either paused or stopped. So this constantly changing FPS is bad and still makes decks bad for something like TV.
This image is same as above except now instead of the displaying the video image as part of TV's background, I am letting the panel display it so it fits within the bordered area and no longer covered up by it.
You can see that the TV display is no longer distorted to death. But you can see that FPS has dropped to 10 which is no good but the display is much better and how it should have always been. In this case I am letting TV display the video texture in the background so the panel border is covering over the video. The FPS will go back to 60 when the video is either paused or stopped. So this constantly changing FPS is bad and still makes decks bad for something like TV.
This image is same as above except now instead of the displaying the video image as part of TV's background, I am letting the panel display it so it fits within the bordered area and no longer covered up by it.
geposted Tue 09 Apr 19 @ 4:30 am
Don Moir
Now what about the special aspect ratio problem. Neither of the new flags give me anymore control of that. I don't want VDJ to display it. I want to be able to display it at the correct display aspect ratio size. If VDJ displays it then TV cannot do anything cool with it, like scale, rotate, flip, etc. TV4 is going to bring this to a whole new level where things can fly around, rotate, spin, scale, all at the same time. You will be able to automate this under special programmed control.
Here is a vob that has a special display aspect ratio. Just VDJ is displaying the video. TV is not running in this image and the video is displaying correctly.
Now with TV running and it wants to display the video image. It can't get the aspect right because that information is still not provided by VDJ. The actual resolution of the video is 720x576. That is all that is given to TV. This video has a modifier that says it is to be displayed at 16:9. That information is not given to a plugin so it has no idea how to display it correctly. The following image would be exactly the same as the above if the proper display information was given to a plugin by VDJ. The actual display size (ratio) should be 1024x576 but plugin has no way of knowing that currently.
Here is a vob that has a special display aspect ratio. Just VDJ is displaying the video. TV is not running in this image and the video is displaying correctly.
Now with TV running and it wants to display the video image. It can't get the aspect right because that information is still not provided by VDJ. The actual resolution of the video is 720x576. That is all that is given to TV. This video has a modifier that says it is to be displayed at 16:9. That information is not given to a plugin so it has no idea how to display it correctly. The following image would be exactly the same as the above if the proper display information was given to a plugin by VDJ. The actual display size (ratio) should be 1024x576 but plugin has no way of knowing that currently.
geposted Tue 09 Apr 19 @ 5:13 am
Don Moir
I think ideally, the actual video textures would be made directly available to a plugin on the master so it could do with them as it sees fit. Of course it should also be given the correct display aspect ratio of those textures. As it is now, a plugin on the master only has access to everything that has been drawn before it. This means a plugin cannot really manipulate the video textures directly. I could punt and steal the textures from the decks but that is not good. Make it more flexible.
PS: By the way, the varying FPS only occurs on decks and not on the master. The master FPS attempts to display at the frame rate you have given it. But only 60 FPS (typical monitor refresh rate) for both skin and video actually gives smooth results.
PS: By the way, the varying FPS only occurs on decks and not on the master. The master FPS attempts to display at the frame rate you have given it. But only 60 FPS (typical monitor refresh rate) for both skin and video actually gives smooth results.
geposted Tue 09 Apr 19 @ 5:26 am
Adion
With either of the new flags, you will have the output resolution, and the vertices will tell you how they should be drawn on that output without distortion. That should be enough information to do anything like rotation etc... correct as well.
If your plugin wants to do compositing of the various decks in its own way, it would make more sense to make it a video transition. A multi-deck video transition should have access to all decks and draw the result as it pleases.
If your plugin wants to do compositing of the various decks in its own way, it would make more sense to make it a video transition. A multi-deck video transition should have access to all decks and draw the result as it pleases.
geposted Tue 09 Apr 19 @ 6:52 am
Don Moir
If the vertices worked than that might be ok. This is what I get for vertices on Deck1 for DTS video: Appears just some garbage in position.x variable. Besides that, even if they did work, I would think they would be the vertices of how it was going to be displayed in VDJ, maybe bars, zoom, or crop which would be useless. I did mention above though that you could use the vertices to retrieve the display aspect info since they did not appear to be used at present.
I don't think changing from a video plugin to a transition helps anything at all. Completely different use case.
I don't think changing from a video plugin to a transition helps anything at all. Completely different use case.
geposted Tue 09 Apr 19 @ 7:59 am
Adion
Strange, we use vertices in many of the internal plugins.
This is how you retrieve them?
Also not sure why a video transition doesn't fit your use case.
If you want to organize different sources on the master output, then that is exactly the job of the transition.
This is how you retrieve them?
TVertex* vertices = nullptr;
void *texture = nullptr;
if (GetTexture(VdjVideoEngineAny, (void**)&texture, &vertices)!=S_OK)
return E_FAIL;
Also not sure why a video transition doesn't fit your use case.
If you want to organize different sources on the master output, then that is exactly the job of the transition.
geposted Tue 09 Apr 19 @ 8:05 am
Don Moir
Yep... Has been that way since 8 came out I think. Worked in 7 but never had much use for them since I handle the display particulars myself. Also in 7, if you used them, the z value would caused a blur any time you drew using the vertices... Ever wonder why a plugin could cause a slight blur in 7 ? That's why but no one knew and I did not bother to mention it.
In my case if it fails to get the texture, I draw everything else not the VDJ texture. So I don't just return from it on failure which should never happen anyway unless something has gone bad.
It appears to me that the transitions, are used for transitions :) and not for a steady display case. It also rules out audio only vis etc. I believe. I can hide something to get to the textures but that's not the thing to do.
In my case if it fails to get the texture, I draw everything else not the VDJ texture. So I don't just return from it on failure which should never happen anyway unless something has gone bad.
It appears to me that the transitions, are used for transitions :) and not for a steady display case. It also rules out audio only vis etc. I believe. I can hide something to get to the textures but that's not the thing to do.
geposted Tue 09 Apr 19 @ 8:08 am
Adion
In your QuickWatch screenshot, vertices seems to be of type TVertex[2] though, how did you declare it?
geposted Tue 09 Apr 19 @ 8:13 am
Don Moir
struct TVertex
{
struct {float x,y,z;} position;
DWORD color;
float tu,tv;
};
In OnDraw:
TVertex vertices [2];
{
struct {float x,y,z;} position;
DWORD color;
float tu,tv;
};
In OnDraw:
TVertex vertices [2];
geposted Tue 09 Apr 19 @ 8:21 am
Adion
Should be TVertex *vertices;
You get a pointer to the vertices (so you can change them and call DrawDeck() after if you don't need anything more advanced)
Also there are 4 vertices, one for each corner.
You get a pointer to the vertices (so you can change them and call DrawDeck() after if you don't need anything more advanced)
Also there are 4 vertices, one for each corner.
geposted Tue 09 Apr 19 @ 8:24 am
Don Moir
Ok duh... I guess that was changed from 7... Never paid much attention to it since I don't use it. But they will be set according to the bar crop or zoom... Is that correct?
geposted Tue 09 Apr 19 @ 8:28 am
Adion
Yes
In vdj7 the vertices were passed as argument to OnDraw() all the time I think.
In vdj7 the vertices were passed as argument to OnDraw() all the time I think.
geposted Tue 09 Apr 19 @ 8:31 am
