Please, I need your help.
I'm dealing with a background video for our homepage. This section has 100vh and is full-width. I'm using DIVI as a builder.
We hired a professional videographer to record a video for us. Now he asks me what should be the ideal:
frame size
frame rate
codec
file size
I've done some research and it seems like that the ideals are:
frame size: 1280 x 720
frame rate: 30FPS
codec: I don't know
file size: the less the better
Please, does anyone have any experience with background video? I'm pretty lost.
Also, would you upload it in the WordPress media library or would you use Vimeo/YouTube? I think you can't use YouTube as a background video, correct?
Thanks a lot!
Frame size:
1280 x 720 (=720p) means HD quality, which is quite good, but it is rather up to you, what quality do you find acceptable. Often 1920 x 1080 pixel (=1080p, fullHD) is used for background videos, like my main background video source is https://coverr.co/ where you can download free videos, specifically made for the purpose of being background videos. Those are 1920 x 1080 big. I would say, if you can ask for multiple files, ask for both, 720p and 1080p quality to be able to make a good decision.
The file size is connected to this, so the smaller frame sized video you will use, the smaller file size you will get.
Frame rate:
You could take a look at this image:
https://miro.medium.com/max/1300/1*uMlkXIMNF4VIZoi85NZ3aQ.png
to see what it means.
Movies on blu ray, dvd and cinema use 24 FPS, so that should be enough for you too. Here as well, the lower FPS means less filesize.
Codec:
h264
I'm a WordPress plugin developer and we always suggest this, when our users cannot figure out how to create a video, that plays on all browsers. So far it worked out well for everyone.
YouTube vs Vimeo vs MP4:
By default you cannot make Youtube videos to be backgrounds. There are some coding tricks, which might works, but I wouldn't suggest it.
Vimeo only allows background videos for Pro Vimeo users.
Using mp4 is simple, and also it works better in mobile and tablet devices. Some devices are opening up their Vimeo/Youtube applications automatically, when a Vimeo or Youtube video is started on a website. This is quite bad and your page will end up without background.
You should also note, that most browsers (even on desktop) only allow you to play videos automatically, if you will mute the video in the html code:
https://www.w3schools.com/tags/att_video_muted.asp
What #Gabor said.
1080p (1920 x 1080) is a good resolution for desktop.
If your user is on a mobile or other small-form-factor device it would be good if you could have the choice of 720p (1280x720) or even 360p (360x640). Those will save data downloads and fit the smaller devices. Look for a plugin that delivers the appropriate size video. You'll need a video file for each resolution.
Or don't show background video on users' mobile devices.
In your design think through what will happen in portrait mode. You probably want to clip off the right and left sides of the video material, so the center part fills the screen. So, the action should be in the center.
Is this video huge? Does it play for many minutes? If not, you absolutely should host it on your own site. Why get involved with, and pay for, some third-party media service if you don't have to? If it's really large (> 10MiB or so) you probably should ask another question and give more details.
Put no audio tracks in your background video files. Browsers restrict the playing of audio in background video, so there's no need to make your files fatter with audio tracks that won't play. (If you have audio, consider hosting a separate file to send users who click on the video to view it; most users won't.)
Use .mp4 files with H.264 video in them (one file per resolution). Other stuff, like webm with vp8 video, might generate smaller file sizes. But they don't play in as many makes and models of browser (I'm looking at you, Apple Safari.)
The video, in H.264 parlance, should be coded in the so-called Constrained Baseline Profile. It saves power when played on mobile devices and works better on slower devices.
Ask your videographer to give you streaming mp4 files (also known as fragmented mp4): they can start playing as soon as the first frame is downloaded.
Ask your videographer for advice about file bitrate. Your 1080p files should look decent coded with variable bit rate with a target of one megabit / second (8 seconds per megabyte). Your lower-resolution files will need a smaller bitrate: that's the point of them after all. But, your bitrate may vary. Action/adventure movies need a higher bitrate to look good than do talking heads.
As #Gabor mentioned, 24 frames/sec should be fine. 15 frames/sec is marginal. Ask your videographer what looks best for the material they created for you. Sometimes material shot at 30 frames/sec looks choppy at 24. (The way H.264 video works, once you get below 24 frames/sec the savings in file size aren't as dramatic as you might guess. 15 frames/sec takes more than half the file size of 30 frames/sec.)
Related
I first apologize if this question is in the wrong place or is formatted wrong. I am young and this is my first post ever here. I was planning on creating a camera app when I get my macbook but before that I was looking at other cameras and noticed that there is an app that shoots 4000x3000 24fps H.265 video on my iPhone 7 plus. How is this possible? Does the API easily let you choose resolutions above 4K or do you have to use a trick?
No, it's not really possible. An app that's allegedly doing it is interpolating pixels between the actual pixels that the camera is delivering. That means it's basically making up extra pixels, typically by averaging the colors of nearby pixels.
I'm really confused with this one as it seems impossible to do.
When running my site through GTMetrix I pass great but with Google page speed insights it's insisting my images can be optimized more for instance:
Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction).
The image in question is 65KiB so how Google thinks I can shave another 78.5 off it I don't know.
I'm using jquery unveil and using the retina function on it too could that be the problem?
Also I've tried downloading the images Google provides as their compressed version but these images have had their dimensions changed so would look terrible if I put them at their intended size.
Really confused, any help would be appreciated.
Thanks
There are few things you need to distinguish before proceeding with optimizing images for Google Page Speed.
Images are optimized for different platforms (Desktop and Mobile)
Images are optimized for physical size.
Reports for images can be "Compressing and resizing" and "Compressing" only. Compressing means u need to do a compression part, on other hand compressing and resizing means you need to use appropriately sized image for appropriate platform.
Depending on the report you are looking at (desktop or mobile), your item "Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction)." needs to be less in dimensions and compressed or just less in dimensions. Margin for resizing an image with CSS is around 20% so if you got 100x100px image you can resize it to around 120x120px with CSS without getting report on that item (that is if you also optimized it physically also). To check this in Chrome, inspect image and check "Natural" size in element selector.
You can deal with this on few ways:
Media Query (note that you have to use background image in this case)
Srssets
JS
Depending on the image compression package that you use, you might get different compression results. I've noticed that sometimes Google's Page Speed is able to optimise an image further than I have been able to (and other times not!)
Do you have a live URL for your web page? Or even the image? It helps to be able to see it live and compare!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have made some websites in Photoshop CS5, but I usually tend to just make them raw in notepad++. I normally make them live on the site, and edit the code and refresh the page to see the changes. I am wanting to move to the more professional method and making the entire template/design in photoshop. The thing holding me back from diving right in, is the very very start lol..
What is a good resolution to use for the template? I have came across different tutorials and they have say different sizes. For instance, my laptop resolution is 1366x768. I have a 22in LCD at my office, and I know it is a really large resolution as well. I would assume the min resolution of most monitors is 1024x768...
When creating a new template in Photoshop to create website templates, what size should I make the image and why?
Also, since we are on the topic, do you guys have any links to good resources of image collections and such that you find helps you the most in creating your templates? I am a programmer, and as we all know, most coders suck at images.. I am just trying to strengthen the other half of my brain :)
Thanks in advance!
I would suggest the following course of action:
Take a look at current statistics for the most widely used screen resolutions. As you'll see, 1366x768 is the most popular resolution right now, followed by good old 1024x768 which still has a huge user base. And keep and eye out for mobile resolutions as well.
Factor in the necessary screen real estate taken by browser chrome and other OS fluff.
Since designing for multiple screen sizes is becoming more important every day, I would strongly encourage you to pick a few target resolutions rather than only one. This can all be nicely handled by CSS. Even if you're targeting only desktops, it still makes sense to consider different screen sizes.
Since you're still getting your feet wet with Photoshop, you could start from one of the many grid-based PSD templates available. I know a 960px one and a 1140px one, but you can find many more. You'll probably have to use multiple grids anyway if you decide to support more than one screen size.
And then when you feel like thinking about all this a bit harder, go straight for this article: A tale of two viewports by Peter-Paul Koch.
Look at smashing magazine and sign up for their newsletter as well as webdesignerdepot and check out Codrops.net. They have great freebies, tutorials, and standards updates. I LOVE checking my mail to see them.
As for the PSD - their's no set size. I've seen professional wordpress developers mockup at 1100px wide (height is SO variant based on your layout). I wouldn't recommend much more than 1366px wide.
I might do 1366 or 1440 because that is the resolution most people will see. When you send a mockup at 1920 wide people think the website is too small, when the content is still the 940-980 that they all
Edit:
I myself do PSD's at either at 1100px or 1440px wide and the main content is is always 940-980px wide.
I use 1100 when there isn't much to look at graphically in the body background, and 1440 when the background is more crucial to the "feel" of the website.
You want to design your website for the most used screen resolution which seems to be 1280px by 720px. Therefore that is what you want your width to be, you can create any type of background and just make sure you fade it to one color or transparently and use CSS to change the background color.
Make sure you have guides that help you keep the content inline, best way, create a new document with the width 960-100px and the height 720px, then drag guides to all four sides.
Then you can change document size to 1280px by 800-960px.
The reason why you have a guide at 720px is because everything above that line is guaranteed to be seen on all resolutions, it's called "above the fold". Good designers take this in account for to ensure the audience will be drawn into exploring the site, a featured content slider is an easy way out.
incomepitbull, I understand where you are coming from...
I am also a back end developer who is trying to learn Photoshop..
Many front end designers are ignorant of what goes on on development stage...
Mostly the Photoshop moke up depends on the customer specification...
The height doesn't matter; use 960 px (12col,16col,24col), 980 px (12col,24,col), 1000 px (100 % responsive friendly for those not using grid systems) or 1140 (for webs targeting bigger monitors ie not mobile first px...)
After all, as developers, we fix all this problems; but good mockups are important...
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
I want to know like converting an image (gif or jpeg) to png8 using yslow smushit will increase the speed of the site performance? Will that work in ie6?
It depends on the image. PNG is suited to images with blocks of color, whereas jpeg is good for photo type images. Smushit will shave off any extraneous bytes, reducing the filesize, but if you have many small images in separate files, then you should consider spriting them in order to reduce the number of connections required to load your page.
Reducing the filesize will help, but reducing the number of files helps the most (typically).
It will make it quicker to download. PNG (AFAIK) will always be a smaller file size than GIF because it uses a better compression algorithm. Although some programs like Photoshop add a little overhead with meta data. It's also lossless, meaning you won't lose any of the image's quality.
It will work in IE6 because it supports PNG8. PNGs with 24 bit alpha transparency are not supported in IE6. There is a hack, but it's not optimal, though it is better than nothing.
There are a lot of factors involved here:
the size in pixels of the image
the size in (mega)bytes of the image
the speed at which the image can be sent to the user. This is a combination of the speed of your server and the speed of the user's connection.
the time it takes the browser to read the image and convert it to a bitmap for display
the speed of the user's computer/graphics card combination.
I'm not sure that converting images to png is going to make that big a difference to your site's performance unless you know that the bottleneck is due to the size (in bytes) of your images. If the users have a slow connection then this isn't really going to help.
Your question is very vague. I'll try answering anyway.
First of all, performance has two ends: The viewer of your site and the machine(s) where it runs on. The viewer will definitely benefit from smaller (in regard to filesize) images since it allows the page to load faster. For the server, the difference is usually not important, unless you are close to peak bandwidth of the connection.
For (non-animated) GIF images a conversion to PNG8 should be painless and beneficial, as PNG compresses much better. Also Internet Explorer 6 doesn't exhibit problems displaying PNG images with a 1 bit alpha channel (which is essentially what GIF has, too). When using an 8 bit alpha channel IE6 will have display artifacts.
Converting JPEG images to PNG will almost certainly increase the file size and won't improve image quality, so I'd advise against it.