I'm using DirectShow with a simple approach (IGraphBuilder RenderFile) and try to control everything else with querying supplemental interfaces.
The option in question is aspect ratio. I thought that it is maintained by default, but actually the same program behaves differently on different machines (maybe versions of DirectX). This is not a huge problem for a video in a window, because I can maintain the aspect ratio of my window by myself (based on the video size), but for full-screen mode I can not understand how can I control.
I found that there are at least two complex options: for VMR video and with adding overlay mixer, but is there a known way for doing this for IGraphBuilder' RenderFile video?
When you do IGraphBuilder::RenderFile, it internally adds a video renderer filter to the graph. It is typically a VMR-7 Video Renderer Filter:
In Windows XP and later, the Video Mixing Renderer 7 (VMR-7) is the
default video renderer. It is called the VMR-7 because internally it
uses DirectDraw 7.
At this point you can enumerate graph's filters, locate VMR-7 and use its interfaces such as IVMRAspectRatioControl to specify mode of interest.
Related
For saving memory and improving performance，I want to use a special format texture to deal with jpeg picture. The format handles by GL_TEXTURE_EXTERNAL_OES but process is same to GL_TEXTURE_2D (only different from glBindTexture and shader program texture declaration)
I have done it in egl hardware mode('rasterizer_type': 'direct-gles'). But have problems when I use skia hardware mode ('rasterizer_type': 'hardware'), I found skia hardware mode don`t support it directly and will call render_image_fallback_function_ (HardwareRasterizer::Impl::RenderTextureEGL) to deal with it likes 360 video. I found the result for display is very different from it show in egl hardware mode, It seems that the way only use to deal with 360 video. Is there a way to possible I let skia hardware mode support the special format directly or I only add a new way in TexturedMeshRenderer to deal with picture to distinguish 360 video.
Cobalt/Starboard supports letting the platform define custom (possibly accelerated) image decode functionality in starboard/image.h, are you using this to set GL_TEXTURE_EXTERNAL_OES, or are you modifying common Cobalt code?
If you are modifying Cobalt code, you may want to search through https://cobalt.googlesource.com/cobalt/+/master/src/cobalt/renderer/rasterizer/skia/hardware_image.cc for references to "GL_TEXTURE_2D" and make sure that they still make sense after your changes. In particular, you may need to adjust HardwareFrontendImage::CanRenderInSkia().
Dose cobalt support youtube 360 video(Spherical Video)? If yes, how it's been implemented, is there any document for it? Does it need the platform to do extra things to support it?
Almost. There is still some small remaining work that prevents this from being a simple yes, but the vast bulk of the work is done and has been shown to function.
A document will soon be appearing in the source tree explaining all this, but here is a preview...
In order to support spherical video, a platform will have to support decode-to-texture, introduced in Starboard API version 4. Cobalt will choose between punch-out and decode-to-texture when creating an SbPlayer, based on whether a mesh transform has been applied to the video tag. In decode-to-texture mode, every frame, the video texture will then be queried from the player, and rendered into the UI graphics plane with the current transform applied.
I have a fairly simple question. Or at least I thought I would be simple to solve but couldn't find any answers online.
Anyway
I used this example form MSDN to play a file using DirectShow:
How To Play a File.
It's really simple with only a few lines of code and it works.
Then after some research I managed to create a VMR9 filter and add it to the graph. This also worked.
There's just one thing
When I play a video file using the VMR9 filter the quality looks worse in VMR9.
I tried changing it with IVMRMixerControl9::SetMixingPrefs but nothings seems to change. IVMRMixerControl9::SetMixingPrefs does actually return S_OK.
dwPrefs &= ~MixerPref9_FilteringMask;
dwPrefs |= MixerPref9_BiLinearFiltering;
Or am I using the wrong filter?
edit: problem solved
I just did a comparison with Media Player Classic by putting it on VMR9 (windowed) mode. It gave me the same quality. So if I want better quality am gonna have to use EVR (enhanced video rendering) instead of VMR9 (Video Mixing Renderer 9).
VMR-7/VMR-9 quality issues are a long standing problem:
Poor Picture Quality with VMR9 as renderer
VMR9 scaling issues on Vista
EVR is suggested to be used instead, to get proper/nicer scaling and visual picture quality.
In Windows Vista and later, applications should use the EVR if the hardware supports it. Otherwise, fall back to the VMR-9 or VMR-7. The EVR offers better performance and better video quality than previous renderers. Also, it is designed to work with the Desktop Window Manager (DWM).
Better performance is questionable, and EVR is sadly having its own issues though, but when output quality is in question EVR is the answer.
I am using OGRE to make a re-rendering of the film, which has a wide aspect ratio (around 1.85). The OGRE dialog seems to be showing the standard full screen resolution by default (800/600, 1024/768, etc.), but those obviously have aspect ratios of 1.333 or around that. But as long as I am not running full screen mode, why should I be restricted to these screen sizes only?
I can definitely change the viewport size, but that would make it difficult for me to generate the video later.
Any idea?
There are no any restrictions for using non standard (4:3) aspect ratio screen resolution in Ogre. Default OGRE configuration window just show list of defaults resolution.
But if you need other screen side you should create it from the code directly depending on the dimensions of your input video.
I'm currently writing an OpenGL renderer and am part-way through writing some classes for enumerating display adaptors, devices and modes for use in drop-down lists.
I'm using EnumDisplayDevices to get the adaptors and then EnumDisplaySettings for each device, giving me bpp, width, height and refresh rate. However I'm not sure how to find out which modes are available full-screen (there doesn't appear to be a flag for it in the DEVMODE structure). Can I assume all modes listed can in-principle be instantiated full-screen?
As a follow up question, is this approach to device enumeration generally the best way of getting the required information on Windows?
OpenGL has not this distinction between windowed and fullscreen mode. If you want an OpenGL program to be fullscreen you just set the window to be toplevel, borderless, without decoration, stay on top and maximum size.
The above is actually a dumb question. By definition windowed mode must be the current display settings. All other modes must be available full-screen (provided the OS supports them, i.e. 640x480 not advisable in Vista/7).
Hmmph, not correct at all, and with an attitude too. You have variety of functions that can be used.
SetPixelFormat, ChoosePixelFormat, ChangeDisplaySettings.
The PixelFormat functions will let you enumerator available modes. ChangeDisplaySettings with allow you to set whatever screen mode (including bit depth) your app wants. Look them up in MSDN.