15

I want to create a website with a HTML5 video background.

I have a short 1080p mp4 clip that I want to use (20s). I intend to run the video in a letterbox format (5:2 ish), full screen behind the page content (for an example see Paypal's website: https://www.paypal.com/uk/webapps/mpp/home)

What would the best export settings in Premiere CC for this purpose?

16

You should export multiple versions to accommodate for different browsers. With HTML5, you can offer different versions of the video and the browser will automatically pick the first one that's supported. For example, take a look at the source code of the paypal website you refered to:

<video autoplay="autoplay" muted="muted" poster="none">
    <source src="https://www.paypalobjects.com/webstatic/mktg/wright/videos/send-money.mp4" type="video/mp4">
    <source src="https://www.paypalobjects.com/webstatic/mktg/wright/videos/send-money.webm" type="video/webm">
</video>

As you can see, they offer both a mp4 (H264 codec) and a webm version of the video. Those would be good options for you as well.

Furthermore, you should try to keep the videos as small as possible, so that site visitors with slow internet will also be able to watch it. For that purpose, you should export the video with 720p instead of 1080p (nobody will see the difference, especially if the video is in the background) and aim for a bitrate below 1 Mbit/s. For example, the paypal video uses a bitrate of about 700 Kbit/s. If you don't need the audio, you could export without audio or with a low audio bitrate, i.e. 96 Kbit/s.

You can also save the video from the website to your computer and check the codec, bitrate and other parameters e.g. with MediaInfo or similar programs.

Update November 2018

Since this question is still getting a lot of views, I wanted to add some up-to-date information. By now, all modern browsers support MP4 (MPEG-4/H.264), and have been for a long enough time that you will be fine offering only MP4 for most projects. Check the link above for a browser compatibity table to make sure all browsers your project needs to support can play MP4. Keep in mind to use AAC for the audio track, not MP3, since it's supported by fewer browsers.

Still, you can and should offer a WebM video as the first <source>, since it features better compression, so users on a limited data plan will thank you. I just wanted to add that if you are limited in terms of disk space, render time or some other variable that makes it difficult to offer WebM, MP4 is all you need by now.

Also, since my original answer included something about audio, one additional takeaway that's not strictly related: Browser vendors are cracking down on autoplay videos (video that start playing automatically after loading the page, without a user interaction), especially if the video contains audio. For example, Safari will only allow autoplay videos if the video contains no audio track, or the video is muted (using the corresponding attribute on the <video> element). So if you don't need the audio track, export your video without one (autoplaying videos with audio are obnoxious UX anyway). And if you do need the audio, keep in mind that some browsers will block the autoplay, so make sure to include a placeholder image using the poster attribute.

7

As MoritzLost says, downscale. Maybe put a link somewhere to the full-quality version for people that are interested. Lower rez will also lower resource usage on the client side. Even downscaling to 640p, 576p, or even 480p might be good, depending on the content, and how visible it will still be behind the text of your page.

Also, since EVERYONE that visits your site will be loading this video, it's worth taking extra trouble to make sure you squeeze out as much quality per bitrate as you can. Esp. if you're not planning to change the video very often. For h.264, that means feeding a lossless source to x264 with preset = veryslow, crf = 26 (or 2-pass bitrate target). x264 is the best h.264 encoder. (independent testing of various h.264 encoders has confirmed this.) It has a lot of really clever algorithms for finding ways to make a really small file that looks good, given enough CPU time. (And can run fast if you need it to, but encode time isn't really relevant for this use-case: encode once, download and play MANY times.)

Do NOT play audio by default when your page loads. Hopefully sane people already know this, but MoritzLost was talking about audio. Pages that auto-play audio are widely loathed and regarded as evil.

If you have a link to a full-quality version of the video, you could include audio with that. 96kb/s is enough for AAC stereo to sound excellent. 64kb/s will still sound good. (as long as you don't use a bad encoder, e.g. anything in ffmpeg other than libfdk-aac.

edit:

I had a look at paypal's video. (view page info -> media -> find the video -> save as).

mediainfo output:

General
Complete name                            : /f/p/home-signup.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42
File size                                : 10.9 MiB
Duration                                 : 1mn 11s
Overall bit rate                         : 1 276 Kbps
Movie name                               : Homepage SignUp - Alan Version
Album/Performer                          : Sorgel, Chase(AWF)
Composer                                 : Sorgel, Chase(AWF)
Description                              : This video is about Homepage SignUp - Alan Version
Encoded date                             : UTC 2014-03-13 16:26:17
Tagged date                              : UTC 2014-03-13 16:26:29
Writing application                      : HandBrake 0.9.9 2013051800

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : Main@L4.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1mn 11s
Bit rate                                 : 1 273 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.046
Stream size                              : 10.9 MiB (100%)
Writing library                          : x264 core 130 r2273 b3065e6
Encoding settings                        : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date                             : UTC 2014-03-13 16:26:17
Tagged date                              : UTC 2014-03-13 16:26:29
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

So they used x264 via Handbrake, but they suck at choosing an appropriate CPU-time vs. rate-distortion tradeoff. ref=1,me=hex,subme=2 looks like the veryfast preset. (x264 --fullhelp to see how each preset differs from medium, which uses the default settings for everything.) Luckily for them, the default crf 23 quality setting is about right for their use case. They could have saved I'd guess another 20% bitrate from the 1273kb/s they got from crf23 by using better settings, like veryslow, or even just medium or slow.

They also decided to limit themselves to h.264 Main profile, for compat with some older Android / iOS devices, which is sadly still a good idea, I guess. (--profile Main). Video that uses more bitrate than needed for the quality is kind of a pet peeve, so it really annoys me that people still distribute Baseline profile encodes. Main profile can't use 8x8dct, which hurts quite a bit, too, but at least it can use CABAC to save about 15% bitrate vs. CAVLC, regardless of absolute rez / bitrate / any other settings.

IDK if it's possible with HTML5 video to have a Baseline, Main, and High profile stream available. I know you can have mp4 and webm alternatives, but those are just containers.

3

I pretty much agree with everything that MoritzLost is saying.

I just wanted to add screen shot of the export window settings to help with setting the values on premiere pro.

I usually press command-M (Mac) to bring up the export screen And I would set it like you see below.

The important setting to note is the Bitrate settings, I would set it to 1Mbps VBR, and allow to as high as 2.4 for scenes that get a lot of activity at a particular time.

Try to aim for a 1MB file size. (Paypal's sendmoney video was 1.2MB for 13 seconds, no audio)

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.