I uploaded a test video on YouTube with a 2.39:1 aspect ratio and YouTube converted it into the following qualities: 240p, 360p 480p, 720p, 1080p.
I downloaded the 1080p video to check its dimensions and they were 1920 x 664, or an aspect ratio of 2.89:1.
Does that mean that "1080p videos" don't need to have a 16:9 aspect ratio?
Let's say I have two videos, both 1920x1080.
Does that mean that both videos have same aspect ratio of 16:9 ?
Does that mean videos qualified as 1080p need to have:
dimensions 1920x1080
aspect ratio 16:9
Wikipedia says "1080p is a set of HDTV high-definition video modes that are characterized by 1080 horizontal lines of vertical resolution and progressive scan. The term assumes a widescreen aspect ratio of 16:9, thus implying a resolution of 1920 × 1080 (2.1 megapixels)," although no credible source is cited.
YouTube/Google define their interpretation of 1080p in YouTube Player API Reference for Embeds: Playback quality:
Quality level hd1080: Player height is 1080px, and player dimensions
are 1920px by 1080px (for 16:9 aspect ratio) or 1440px by 1080px (for
4:3 aspect ratio).
I've never heard of a 2.89 aspect ratio. 16/9 = 1.7̅ 1920 x 664 is really strange. Maybe it's a bug in YouTube's converter. But I guess you could gain more control by uploading video which you've already converted to a standard aspect ratio yourself.
Related
I'm working on a react native application in a company and my manager asked me what is the best image size in pexels to upload from API (dashboard) to fit the View in the application ?
And I'm using percentage units not numbers: (width: '80%', height: '50%') I don't know what is the best sized of images to fit or the aspect ratio of the image and react native is unitless!
What should we add 'Hint' for the client in the dashboard when he upload any image ?
Or how could I know the best image dimensions to fit all screens ?
In our organisation, we usually follow the following convensions to make an image fully responsive.
Get the dimentions of the image using: const {width, height} = Image.resolveAssetSource('path-to-your-image');
Get the ratio factor of width and height by using: const ratioFactor = height/width;
Whenever you set the width of your screen by 'n' digit, set the height to 'n*ratioFactor'
In this ways the image can never be stretched or compressed. It will be fully responsive according to it's dimensions.
Preferably use image with standard dimentions as 1024 x 768 pixels.
In case the app target both iOS and Android, there is a multitude of devices with various resolutions and pixel densities from high-end iPads to low-end androids devices with smaller resolutions.
The General rule of thumb is to find the average image size which will not pixelated (look blurry) on the high-end devices but does not have a large download size in case some users will have slow internet.
You should start with 1024 x 768 pixels which is a standard dimension for iPad
Consider using resizeMode prop of react native image. With resizeMode you can manage to render image based on available space in screen.
Check it here : https://reactnative.dev/docs/image#resizemode
Cocoa drawing sizes (widths & heights) are specified in points which are defined as follows in the OS X Cocoa Drawing Guide documentation:
"A single point is equivalent to 1/72 of an inch"
I understand from this that a point is a physical distance. So if my screen is 20 inches wide (for example) I would have 20 x 72 = 1440 points of horizontal width in points to work with. In other words, a point is independent of the resolution of the device.
This does not seem to be so...
A simple cocoa application using window width as a test shows that:
1) when my resolution is set to 1680x1050 it will take a width of 1680 points to span the width of the screen
2) similarly, if I change my resolution to 2560x1440 it will take a window width of 2560 points to span the width of the screen
Also confusing (in a contradictory way) is the statement made in the High Resolution Guidelines Apple Document that:
Each point in user space is backed by four pixels
The above tests seem to indicate that I have a user space of 1680x1050 when my display resolution is set to 1680x1050. If there are 4 pixels per user point then this would point to an effective "real" resolution of 2 times (1680x1050) = 3360x2100 which is more than the native resolution my 13 inch retina macbook pro of 2560x1600.
Points are an abstract, virtual coordinate system. The intent is that you usually design and write drawing code to work in points and that will be roughly consistent to human vision, compensating for different physical display pixel densities and the usual distance between the display and the user's eyes.
Points do not have a reliable relationship to either physical distance units (inches, centimeters, etc.) or physical display pixels.
For screen displays, there are at least three different measurements. For example, the screen of a Retina MacBook Pro has 2880x1800 physical pixels. In the default mode, that's mapped to 1440x900 points, so each point is a 2x2-pixel square. That's why a window on such a system has the same visual size as the same window on a non-Retina MacBook Pro with a screen with 1440x900 physical pixels mapped to 1440x900 points. The window is measured in points and so takes up the same portion of the screen real estate. However, on the Retina display, there are more pixels allowing for finer detail.
However, there is another layer of complexity possible. You can configure that Retina system to display more content on the screen at the cost of some of the detail. You can select a display mode of 1920x1200 points. In that mode, the rendering is done to a backbuffer of 3840x2400 pixels. That allows for rendering at a higher level of detail but keeps the math simple; points are still mapped to 2x2-pixel squares. (This simple math also avoids problems with seams when drawing abutting bitmap images.) But 3840x2400 is greater than the number of physical pixels in the display hardware. So, that backbuffer is scaled down when actually drawn on the screen to the physical 2880x1800 pixels. This loses some of the higher detail from the backbuffer, but the results are still finer-detailed than either a physical 1920x1200 screen or scaling up a 1920x1200 rendering to the physical 2880x1800 screen.
So, for this configuration:
Screen size in points: 1920x1200
Backbuffer in in-memory pixels: 3840x2400
Physical pixels in display hardware: 2880x1800
Other configurations are, of course, possible:
Screen size in points: 2880x1800
Backbuffer in pixels: 2880x1800
Physical pixels: 2880x1800
Everything will be teeny-tiny but you'll be able to fit a lot of stuff (e.g. many lines of text) on the screen.
Screen size in points: 1280x800
Backbuffer in pixels: 2560x1600
Physical pixels: 2880x1800
This will actually make everything (text, buttons, etc.) appear larger since there are fewer points mapped to the same physical pixels. Each point will be physically larger. Note, though, that each point still maps to a 2x2-pixel square in the backbuffer. As before, the backbuffer is scaled by the hardware to the physical display. This time it's scaled up slightly rather than down. (This scaling is the same thing as happens on a non-Retina LCD display when you select a mode with fewer pixels than the physical display. Obviously, an LCD can't change the number of physical pixels it has, so the different resolution is accomplished by scaling a backbuffer.)
Etc.
Is there any way to fill video without stretching and cutting the video ?
1- MPMovieScalingModeFill - its stretching video.
2- MPMovieScalingModeAspectFill - its cutting video.
3- MPMovieScalingModeAspectFit - its shooing video in centre and showing black area.
No. Think about it! The MPMoviePlayerController's view is not the same aspect (ratio height to width) as the movie. So to make it fit, either you must cut some off (of either height or width), or you must letterbox it (black area) with one dimension being too small, or you must distort.
You should do the opposite: size the MPMoviePlayerController's view to fit the aspect of the movie!
I've created a simple WebRTC chat app using tokbox / opentok 2.0.
However, I am having trouble figuring out how to make sure that the video appears in a 16.9 aspect ratio. The default on most systems is 4.3, and on my MacBook Pro, I am getting 16.9 squished into a 4.3 box.
Is there an api call I am missing to force a widescreen aspect ratio?
There is no way to change the aspect ratio on TokBox's API, although you can set the width and height properties when you call initPublisher or session.subscribe(). It says in the documentation:
If the width and height of the display do not match the 4:3 aspect ratio of the video signal, the video stream is cropped to fit the display.
When one looks at the Guidelines for fonts, we see that fonts are specified in points. A point is 1/72 of an inch so it is an absolute measure: a 10 points character should show at the exact same absolute size on any monitor at any resolution. That would make sense to me as I want to be able to read text -at the same size- whether on a 10 in tablet or a 23 in monitor. In other words, I want my text to be readable on a tablet, but I do not want it to be too big on a monitor.
On the other hand, I can understand that some UI elements could be specified in pixels, as in the Page layout guidelines.
However, in XAML font size is specified in pixels which is device dependent (to my understanding). Hence the fonts size will look tiny on a monitor with a higher resolution! See this post for more details. The answer in that post says "this way, you are getting a consistent font size". I can't see how I am getting a consistent size when it changes when the resolution changes?!?
Should I load different font size programmatically depending on the resolution of the device?
I see here that Windows does some scaling adjustment depending on the DPI. Will this adjustment be enough for my users to have a great experience on a tablet and on, say, a 20 inch monitor (or should I programmatically change the font size depending on the device resolution)?
Bonus question: WHY are the Font Guidelines written using points when the software tools do not use points (like, what were they thinking)?
"What were they thinking" is extensively covered in this blog post.
You'll also see described how scaling for pixel density is automatic:
For those who buy these higher pixel-density screens, we want to ensure that their apps, text, and images will look both beautiful and usable on these devices. Early on, we explored continuous scaling to the pixel density, which would maintain the size of an object in inches, but we found that most apps use bitmap images, which could look blurry when scaled up or down to an unpredictable size. Instead, Windows 8 uses predictable scale percentages to ensure that Windows will look great on these devices. There are three scale percentages in Windows 8:
100% when no scaling is applied
140% for HD tablets
180% for quad-XGA tablets
The percentages are optimized for real devices in the ecosystem. 140% and 180% may seem like odd scale percentage choices, but they make sense when you think about how this will work on real hardware.
For example, the 140% scale is optimized for 1920x1080 HD tablets, which has 140% of the baseline tablet resolution of 1366x768. These optimized scale factors maintain consistent layouts between the baseline tablet and the HD tablet, because the effective resolution is the same on the two devices. Each scale percentage was chosen to ensure that a layout that was designed for 100% 1366x768 tablets has content that is the same physical size and the same layout on 140% HD tablets or 180% quad-XGA tablets.