Re-encoding Existing Videos

Video Cloud enables you to take an existing video in your Media Library and easily update the video renditions associated with it. Using the re-encoding feature, you can maintain all of the metadata associated with the existing video, while updating only the actual video files delivered to viewers. This feature is available only to Video Cloud  Pro and Enterprise publishers.

You can update a video either by re-transcoding from the video's existing source already in our system, or by providing a new source file to be transcoded.

• Why re-encode your videos?
• How to re-encode your videos

Why re-encode your videos?

Whether you are starting with a newly-uploaded video or one that's already in your Video Cloud Media Library, there are many reasons to re-encode your videos.

Before we introduced multi-bitrate streaming, videos uploaded to Video Cloud were as a rule transcoded as VP6 (FLV) video files with a total bitrate of 512 kbps. That remained the default rendition for a large number of uploads. Now, with Video Cloud's Adaptive Encoding Engine and multi-bitrate streaming, we have the ability to deliver both very high quality, high definition H.264 video as well as lower bitrate H.264 video that's suitable for mobile devices. Re-encoding your videos enables you to take advantage of these features for the videos that you already have in your Video Cloud Media Library, not just newly-created videos.

Re-encoding from existing source

If you are satisfied with the quality of the original source for a particular video, you may want to re-encode from it in order to take advantage of Video Cloud features that have been added since the source was originally transcoded.

• Take advantage of Video Cloud's improved transcode quality. Video Cloud's Adaptive Encoding Engine, deployed with the v4.0.5 release on March 25, 2010, creates H.264 videos with higher-quality video than our previous H.264 or VP6 transcodings. If you created a video before the Adaptive Encoding Engine was available, you may want to re-encode the video into H.264 using this engine, regardless of whether the video was originally encoded into H.264 or VP6.
• Take advantage of Video Cloud's Adaptive Encoding features. The Adaptive Encoding Engine offers other benefits in addition to higher-quality. For example, if you created a video from a non-square pixel (anamorphic) source before this engine were available, the video most likely has a slightly "squished" output. Re-encoding this same video from its existing source using the new encoding engine will correct this distortion, in addition to producing a higher quality output.
• Target a different output codec. If you originally created your videos with VP6 (FLV), we recommend that you re-encode the video from the original source but using H.264. The H.264 codec offers higher video quality and broader support on mobile devices.
• Update a video's rendition set to reflect your latest settings. The set of rendition options for multi-bitrate rendition videos may have evolved significantly since you uploaded a particular video. For example, to support video delivery on mobile devices, you probably want one or more renditions that use H.264 at a comparatively low bitrate. Re-encoding your video from its original source will cause its rendition set to match your current preference.
• Upgrade a single rendition video to multi-bitrate renditions. You may have uploaded a video before Video Cloud's multi-bitrate renditions (MBR) feature was introduced. Re-encoding such video will result in it being upgraded from having a single rendition to as many renditions as the publisher has configured for MBR.
• Note: the originally uploaded source for single rendition videos is not stored in the Video Cloud system. Therefore, when a single rendition video is re-encoded from its original source, the output of that single rendition is used as the source for re-encoding. This is likely to result in output of lower quality compared to the output that would have been produced had the original source been used. For this reason, we recommend that if you want to re-encode a single rendition video into multiple renditions, you should re-encode from the original source file, using the reencode-from-new-source tag, rather than using the single rendition that's already in your Video Cloud Media Library.

Re-encoding from a new source file

Previously, if you wanted to start using a higher quality source for one of the videos already in your Video Cloud Media Library, you would have had to delete the existing video and create a new one in order to use the better source, or else re-encode the video yourself and substitute new renditions in the video using the Media module or FTP batch provisioning. This feature enables you to upgrade the video's output quality without losing any of the metadata for that video, while letting Video Cloud's Adaptive Encoding Engine handle the transcoding.

In addition to this, all of the re-encoding benefits listed for Re-encoding from existing source apply here as well.

• Provide a better quality source for an existing video. This is the most common use case for re-encoding from a new source.
• Upgrade a single rendition video to multi-bitrate renditions. Using multi-bitrate renditions, instead of a single rendition, lets you take advantage of Video Cloud's dynamic bandwidth detection features, so that the Video Cloud player can deliver a rendition of the video that best matches the viewer's window size and available bandwidth. You can also deliver lower-bitrate renditions suitable for mobile devices. When upgrading a single rendition video to a multi-bitrate rendition one, we recommend that you upload the original source video for re-encoding. Video Cloud does not maintain original sources for single rendition videos and re-encoding a single rendition video from the existing file would result in the original output being used as the re-encoding source. This is not ideal for output quality.

How to re-encode your videos

In this release, you can re-encode your videos using Video Cloud's FTP batch provisioning feature, which is available only to Video Cloud Pro and Enterprise publishers. In a subsequent release, we plan to make re-encoding available using the Media API. For introductory information, read Using FTP Batch Provisioning.

Main steps for re-encoding videos with FTP batch provisioning

1. If you are uploading new source video files, prepare your assets for uploading.
2. Create an XML manifest file that describes the videos you are re-encoding.
3. If you are providing new source video files, upload your files to the Video Cloud FTP server. If you are re-encoding from existing files, skip to the next step. (If you are a Video Cloud Enterprise publisher, you can optionally upload your files to the Video Cloud Aspera server.)
4. Upload your XML manifest file to the Video Cloud FTP server.
5. Check your email for notification that your manifest has been processed.

Creating an XML manifest for re-encoding

When you use FTP batch provisioning, you create an XML file, called a manifest, that describes in detail the videos you are creating or modifying. Read Using FTP Batch Provisioning and FTP Batch Provisioning: Reference for the XML manifest for detailed information about creating the FTP batch provisioning manifest.

For re-encoding, there are two key XML elements you need to use. If you are re-encoding using an existing source file in your Video Cloud Media Library, use the reencode-from-existing-source element as a child of the top level publisher-upload-manifest element; use the reencode-from-new-source element if you are supplying a new (possibly higher quality) source file with the XML manifest.

Re-encoding videos with the "reencode-from-existing-source" element

If you are re-encoding from an existing source file that's already in your Video Cloud Media Library, you need to provide the reference ID (refid) of the video, as well as some encoding instructions. Read detailed information about the attributes you can use in the reencode-from-existing-source element.

Here is an example:

<?xml version="1.0" encoding="UTF-8"?>
<publisher-upload-manifest publisher-id="Your-ID" preparer="Ed" report-success="TRUE">
  <notify email="myemail@myemail"/>
  <reencode-from-existing-source
     title-refid="video1"
     encode-to="MP4"
     encode-multiple="TRUE"
     overwrite-images="TRUE"
  />
</publisher-upload-manifest>

The above manifest would trigger a re-encoding of video with reference ID video1. The targeted codec would be H.264 and multiple renditions would be created. The images, thumbnail and video still, would be captured during the re-encoding and would replace any existing images for the video. 

Re-encoding videos with the "reencode-from-new-source" element

If you are providing a new source video for re-encoding, you need to provide not just the reference ID (refid) of the video, but also an asset element that identifies the new source file that you are uploading along with the manifest. If you are using another video asset that's already in your Video Cloud Media Library, you can provide the reference ID of that video asset along with the reference ID of the video you are modifying.

Read detailed information about the attributes you can use in the reencode-from-new-source element, as well as how to create an asset element. Note that you'll need the exact size in bytes of the new source file and, optionally, an MD5 checksum for the file. Read more about this in Preparing your assets.

Example manifest: uploading a new source video

<?xml version="1.0" encoding="UTF-8"?>
<publisher-upload-manifest publisher-id="Your-ID" preparer="Ed"
                           report-success="TRUE">
  <notify email="myemail@myemail"/>
  <asset
     refid="new-source-asset"
     type="VIDEO_FULL"
     encode-to="MP4"
     encode-multiple="true"
     size="1689428"
     hash-code="87197cf99b194a97c79b8810e58df1e8"
     filename='newSource.mov'/>
  <reencode-from-new-source
     title-refid="video1"
     new-source-refid = "new-source-asset"
     overwrite-images="FALSE"
/>

</publisher-upload-manifest>

The above manifest would trigger a re-encoding of video with reference ID video1. The new source for video1 is provided in the same manifest: the asset with reference ID new-source-asset. The targeted codec, H.264, is determined by the encode-to attribute of the referenced asset element. Whether multiple renditions or a single rendition are created is determined by the encode-to attribute of the referenced asset element. The existing thumbnail and still images for the video would not be replaced.

Example manifest: using source video already in Video Cloud

<?xml version="1.0" encoding="UTF-8"?>
<publisher-upload-manifest publisher-id="Your-ID"
      preparer="Ed" report-success="TRUE">
  <notify email="myemail@myemail"/>
  <reencode-from-new-source
      title-refid="video1"
      new-source-refid = "source-asset-1"
  />

</publisher-upload-manifest>

The above manifest would trigger a re-encoding of video with reference ID video1. The new source for video1 would be the video asset with reference ID source-asset-1 that had been uploaded to Video Cloud previously.

If you are re-encoding from a new source file that is already in our system and not provided in the manifest, the video will be re-encoded to have multiple renditions and your default target codec will be used for each rendition.

When rendition swapping occurs

When a multi-bitrate video is re-encoded, rendition swapping does not occur until all of the re-encoded renditions are ready for delivery. That is, new renditions are not added as soon as they complete. When all renditions have completed, as long as there were no failures, all of the existing renditions are removed and all of the new renditions are added to the video. This is an all or nothing operation: the video to be re-encoded will either end up with all old renditions, if any of the new renditions were failed to be created, or all new renditions, if there were no failures.

Success notification

If you use a notify element in your XML manifest, Video Cloud sends email notifications of success or failure for the re-encoding process. When a video is successfully re-encoded, you will receive an email of the following form:

The re-transcoding of publisher's, ### (Pub-name), video, ####, 
  with reference-id, "ref-id", has been successfully completed.
  All of its previous renditions have been replaced with newly created ones.

When the renditions of a video targeted for re-encoding are not updated due to a failure to create one of the new renditions, you will receive an email of the following form:

The re-transcoding of publisher's, ### (Pub-name), video, ####,
 with reference-id, "ref-id", has failed due to problems during creation
 of at least one of the new assets.  The video will remain unchanged. 

You will get a separate email for each video that you submit for re-encoding.

Current Limitations

You can't add renditions to a video one rendition at a time. Re-encoding is a wholesale operation where all of the renditions specified in a publisher's transcoding options set are created and all of the existing ones are eliminated. In the future, we are planning to allow publishers to a specify a single rendition to be added to an existing video.

Note that you cannot re-encode videos that use remote assets. When you use remote assets, the video files are never uploaded to the Video Cloud servers, and therefore are not available to be re-encoded. However, you can replace a remote asset with new renditions on Video Cloud using reencode-from-new-source:  

<?xml version="1.0" encoding="UTF-8" ?>
<publisher-upload-manifest report-success="TRUE" preparer="Anna" publisher-id="68221946001">
  <notify email="agene@brightcove.com" /> 
  <asset
     refid="mynewsource"
     type="VIDEO_FULL"
     encode-to="MP4"
     encode-multiple="true"
     filename='mynewvideofile.mov'/>
  <reencode-from-new-source
     title-refid="myremotevideo"
     new-source-refid = "mynewsource"
     overwrite-images="True"/>
</publisher-upload-manifest>

Read more about remote assets.