Transcode video/audio for full platform coverage

[noahadler]

Use hive:job-queue to interface with ffmpeg, and generate derivatives of video and audio uploads which can be served to guarantee playback on all web and mobile targets.

[mpaddock]

Video transcoding working with ffmpeg through differential:workers. Still some kinks to be worked out with when the transcoding is getting done after upload.

[noahadler]

Current implementation of VideoTranscodeJob replaces the original file with the converted file in the FileRegistry. I'm not sure that's appropriate... e.g., the md5 will be wrong, and we may need multiple derivatives available to target different platforms, without losing track of the provenance. May need something in settings.json to define what derivatives/ffmpeg options we want?

[mpaddock]

Should those just be added into the @params for the job instead of Meteor.settings? Agreed on the replacement of file in FR, I'll change that to an insert.

[noahadler]

They could. However, in that case I'm not sure what we'd gain from having
a separate VideoProcessorJob instead of just using the ExecJob, since it's
essentially all in the form of esoteric ffmpeg options. Since we have a
VideoProcessorJob, I thought it might be nice to abstract that to a level
that would be easier to change without rebuilding/changing code. Otoh,
since we mostly need to transcode derivatives to serve to different
platform clients, we'll have to keep track of that internally anyway. I
guess it's 6 of one...

On Wed, Jan 7, 2015 at 11:13 AM, Michael Paddock [email protected]
wrote:

Should those just be added into the @params https://github.com/params
for the job instead of Meteor.settings? Agreed on the replacement of file
in FR, I'll change that to an insert.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[mpaddock]

Video transcoding can take a custom target type from settings.json now, but defaults to mp4. It'll also check to make sure we don't convert things to the same type.

In addition, video transcoding now creates a new entry in FileRegistry and generates the Md5 and Thumbnail for the transcoded video.

I didn't think about this in advance, but still to do is letting targetType be an array to do multiple transcodings at once?

[noahadler]

Great! Yep, definitely an array would be good. We also want some way to
specify more complex options than just the target type. For instance, we
may want to use different codecs with the same container, or different
resolutions for different streaming bandwidths.

On Wed, Jan 21, 2015 at 4:28 PM, Michael Paddock [email protected]
wrote:

Video transcoding can take a custom target type from settings.json now,
but defaults to mp4. It'll also check to make sure we don't convert things
to the same type.

In addition, video transcoding now creates a new entry in FileRegistry and
generates the Md5 and Thumbnail for the transcoded video.

I didn't think about this in advance, but still to do is letting
targetType be an array to do multiple transcodings at once?

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[noahadler]

So this is cool, but now we end up with two copies of the video (if the original upload isn't an mp4) in the file registry. Not sure how we want to handle this, but I sort of thought the derivative video should be like a thumbnail, which is to say useful for specific performance or functional reasons, but doesn't need belong in the same place as a file specifically uploaded by a person.

I'm not sure the best way to handle this. We could 1) only store the derivative files on disk, 2) mark files with an attribute in the file registry (e.g., 'original', 'derivative', 'thumbnail', etc.), 3) add an optional 'parent' attribute in file registry to keep a provenance tree.

[mpaddock]

I see what you're saying. I definitely don't think videos should be automatically transcoded upon upload unless the app itself wants that.

Marking files as derivative and then giving a FNOD would probably be the way to go. I don't think I understood your goal of the file registry. To that end, should there be an option pass-in to replace when uploading? If all we're interested is playback in apps, it doesn't seem like storing the original file indefinitely would be necessary.