Archive for the ‘H264’ Category

Adobe Premiere: H264 Markers: Work in Quicktime but not MP4

Tuesday, February 25th, 2014

(Updated as of 2014-03-20)

  • H264 supports chapter markers (in some form) in principle, but Adobe Premiere is unable to utilise this (at least as of 2012, and I can’t see a way of doing it in February 2014).
    • If the H264 is encoded into a QuickTime [.mov] wrapper/file (as opposed to a [.mp4] one), and that [.mov] file is played in a QuickTime player, then those chapter markers will appear in (the bottom-right corner) of that player.
  • Apparently FCP (both 7 and X ) can also do this.
    • Presumably


YouTube Upload Formats: “That Old Chestnut”

Friday, September 6th, 2013


When uploading to  YouTube (or Vimeo or indeed most online video services), the uploaded video need not be in the format that will ultimately be served to the audience. Instead, it is essentially in an an archive role, and based on this archive, the services will (now and/or in the future) encode their own copies at various resolutions.   The uploaded “archive” should therefore be of the best quality, and is not constrained to be in a format that plays well on most target devices.

YouTube defines two upload-formats: Standard (for typical enthusiast videos) and Enterprise (for serious matter such as movies or corporate productions).  A 5-minute video in Standard format may be about 350 MB while in Enterprise format it may be around 2GB.  So for practical purposes, Enterprise format requires an Enterprise internet-connection.

  • Standard-Level Encoding:
    • YouTube gave good results when the video was uploaded in H264 at 8 mean 16 max Mbps.
      • I (currently) believe this is a good practical upload-format to use in most cases.
        • It has given good results for general scenes (in the experience of others as well as myself).
      • My maximum bitrate (16Mbps) exceeds Adobe’s YouTube 1080 preset, which defines 8Mbps mean=max.
      • However it is way below YouTube’s official (and YouTube-expert-confirmed) advice of 50Mbps (mean=max) for Enterprise-class (productions and internet connections).
        • I wonder whether such high bandwidth is only really of advantage to fast-changing scenes e.g. foamy sea-spray or to future derivation of 4K from it etc.
        • It could presumably be regarded as a useful format for archiving in general, at least where no subsequent significant levels/color manipulation was intended.
    • Poor results were obtained when uploaded (mistakenly) at 720p25 at 5 Mbps (mean=max), especially when played (from YouTube) at lower resolutions, when blocking was apparent.
    • I am not too sure about Adobe Media Encoder’s YouTube 1080 preset, maybe it is slightly under-specified, the audio bitrate as well as the video bitrate.
  • Enterprise-Level Encoding via custom settings in Adobe Media Encoder (version CC of August 2013)
    • These are essentially “BluRay-like” / “Gold Standard” formats, from which YouTube’s servers can derive multiple present-day play-formats.  Their use should also result in good-quality archive material from which, in future, to derive further (as yet uninvented or not-yet-popular) formats.  To “stand the test of time”…
    • Audio 320Kbps
    • Video:
      • Bitrate:
        • 50 Mbps for 1080p (25 fps)
        • 30 Mbps for 720p (25 and 50 fps?)
      • Level:
        • 4.2
          • General H264 advice is use lowest Level that permits (includes as an option) your required bitrate.
          • Level 4.2 additionally has a reasonable number (hence density) of macro-blocks.
      • Mode
        • Mode should be [High] (as opposed to [Baseline] or [Main] ).
          • [High] implies CABAC encoding (which is computationally-intensive but gives superior-quality results) and two B-frames.
            • These are both requirements for Enterprise-class YouTube uploads.
        • We are essentially uploading an archive format as opposed to playable, so we don’t care how computationally intensive it is.
  • Key Frames Distance
    • Same thing as GOP size or length (I assume).
    • YouTube’s official spec says it should be half the frame-rate…
      • e.g. 12 in the case of 25 fps ?
      • As opposed to a general rule of thumb (elsewhere) of three times the fps.
        • e.g. 75 frames in the case of 25 fps or 150 frames for 50 fps.
          • Scary numbers…
          • Various people report less smooth motion when shorter keyframe distances are used.  But maybe that only applies to lower bitrates?
  • B-Frames:
    • This is the number of bi-directional (B) frames between I and P frames, e.g. a value of 3 would give: [IBBBPBBBPBBBPBBBP]
    • The recommended number is 2 for YouTube-Enterprise context (as opposed to 3 in some other contexts).


I had shot two videos on my trusty Sony EX3 camera, one at 1080p25 the other at 720p50.

Reason?  The first one was a standard live entertainment event, demanding some run&gun, hence I shot it at highest definition.  However the other event was a sporting one, and 50 fps provides more potential for handling fast action in various ways (smoother action or slow motion).  On this camera, 50fps was only possible in 720p, not 1080p (the camera can also record 1080i50 (fields/second), from which one can generate motion-estimated full-frame 1080p50, but that is extra work, not conducive to productivity, hence best avoided).

On my Adobe CC editing system, I completed the 720p50 video first, then encoded that to 720p25 (Adobe Premiere CC’s YouTube preset, of 5Mbps, mean=max) for checking and eventual upload to YouTube.  A day or two later I completed the (longer) 1080p50 video, then similarly encoded that to 720p25 for smaller file and faster upload for the draft/check process.

Then came time to upload the 1080p25 video to YouTube, initially with distribution set to Private.  It was late and I forgot to change the encoder setting to 1080.   Mistakes can happen, that’s why it was initially made Private and why a test-play or two at various resolutions was in order.   When played (from YouTube), not only did this reveal the reduced resolution, unexpectedly there was also some very obvious blocking on fast action, especially when the YouTube video was played at lower resolutions.

…Which of course illustrates the exact purpose of Quality-Checking is for, in the workflow…

Naturally the first thing to so was re-encode at 1080 (duh!).  Adobe’s YouTube-preset for this used a VBR bitrate 8 Mbps (mean=max).    Then also I also increased the maximum bitrate to 16.  I hadn’t time for experimenting, so I just made a best-guess.  Result: Success!  Following upload of the result to YouTube, test-plays of this looked far better in all respects at the various play-resolutions.

So I did some further web-research … which led me down a (finite) “rabbit-hole” wherein I discovered the existence of two kinds of upload-format standards: Standard (a few Mbps) and Enterprise (BluRay-ish, tens of Mbps).  Aghast at the latter, I did further web-searching, which confirmed it.


Convert FLV Video Files

Monday, July 22nd, 2013

To convert from [.flv] to another format, use VLC Media Player’s [Media > Convert/Save] option.  Be sure to set the destination as well as the source.  VLC can only convert to formats in its own internal container and codec sets, but e.g. can convert to [.mp4] containing H264.

Thereafter can use e.g. Sony Vegas to generate e.g. [.avi] containing CFHD, e.g. for onward use in applications that don’t recognize mp4-h264.  Vegas is more accommodating and flexible than (straight use of) Adobe Media Encoder, as regards non (broadcast) standard frame sizes and proportions.  Conveniently, Vegas automatically matches the Project to the footage on footage-import.

Prior to that, I tried installing and using Riga, the two-way FLV convertor, but it didn’t work on  my Window 7 (64-bit) machine,  opening only a blank window where a GUI was expected, and both the downloader and installer were both full of bloatware (NB needed to install in Advanced mode in order to avoid some of that).  Pointless…

H264 Profiles: Baseline, Main, High : In Sony Vegas and Sorenson Squeeze

Thursday, June 21st, 2012


  • For H264-based encoders, their configuration dialog typically offers a choice of Profiles, being Baseline, Main or High.  The default varies over varieties of encoder.  What do these mean exactly, and what guidance is there for choosing between them?
  • How do they influence things (encoding speed, quality, file-size) in practice?
  • What are their specific effects in Sony Vegas (my traditional workhorse) and Sorenson Squeeze (that I am currently experimenting with)?
    • Both of these applications offer (among their choices) CUDA-acceleration for H264 encoding.

The answer(s):

  • Profile controls the degree of sophistication in encoding and decoding.
  • It’s best to choose “High”
    • Baseline is the “cheap & nasty” variety, e.g. making no use of B-Frames.
    • Main is intermediate between Baseline and High.
    • High offers best compression, and is the typical profile for broadcast (BluRay and TV).

Experimentally, I found:

  • Within each encoding tool, viewed on its own:
    • Insignificant differences in encoding time and (perhaps to be expected) only marginal differences in file size.
      • Note: In my experiment I used MainConcept to compress HD 1920×1080 25p footage of a mid-shot of a lecturer in a static scene (himself moving undramatically in the context of static lighting and seen against a static and fairly neutral background).  Settings were for bitrates of 12Mbps average, 24Mbps maximum
  • Comparing the different tools:
    • Squeeze 8.5 took about twice as long as Sony Vegas 11 to encode to the same-specified (as far as I can deterimine) target.
  • I was unable to discern any difference in quality.  A quality measuring method would be useful here!

I have remaining uncertainties about specifying the number of reference-frames, both in general and in terms of how to do this in the various encoding applications.