Archive for September, 2013

NLE Adulteration of Source Media: Potential Workflow-Issues

Friday, September 13th, 2013

I highlighted in (10 months ago) that Adobe Premiere etc. can adulterate media files, in terms of metadata and/or sidecar-files (depending on user-configurations of these applications.  I indicated that, regardless of the reasonableness of at least some of these actions, this could potentially cause problems to other applications.

Validating that concern, I note a post (2012-06-12) by Matt Davis on Philip Bloom’s website, stating (my italics):

  • …if sharing assets with FCPX and Adobe Premiere, Adobe ‘touches’ (resets the modification date) of each file without doing anything else to it, but also sprinkles sidecar files into directories of transcodable files for metadata, thus sending any returning FCPX activity into a tailspin, requiring a re-linking session. It’s oddities like these which haunt the implementation of FCPX in a wider system and make system managers wonder if FCPX is actually worth implementing in its current state.

That was over a year ago, and so the issue may or may not exist for the current version of FCPX.

As users, whether or not the actions of one application adhere to standards and another don’t, what we as users ultimately care about is workflow, which in this case translates to “does it connect up with my other tools/processes?”.  So we have to maintain a “situational awareness” of potential interoperability pitfalls.

Incidentally, I recall that FCPX’s predecessor (in history at least, if not development-line) FCP7 could adulterate source directories with its own sidecar files, produced by its SmoothCam effect.  Not knowing anything further for sure, I nevertheless wondered (at that time) what it might be doing “under the hood” of the QuickTime [.mov] wrapper.

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.