support h264 for older IOS devices and OSX safari via config avconv params

[djay]

This answer shows how to convert a video to be the most compatible.

• Only use the H.264 Baseline Profile Level 3.0
• Resolution below 640 x 480 and framerate up to 30 fps
• B frames are not supported in the Baseline profile.
• bitrate limit of 900kb.

http://stackoverflow.com/questions/4240915/h-264-encoded-mp4-presented-in-html5-plays-on-safari-but-not-ios-devices

The current code assumes an uploaded mp4 is already compatible so doesn't convert it.

[djay]

Looking at the code more closely it does the following

• converts it to mp4 if the original is not mp4 and then throws away the original. Any subsequent conversions would be converting from the mp4 version
• if the original is mp4, leaves it untouched, even if the encoding is such that it doesn't work on all h264 devices.

Seems more sensible to me to always retain the original and always make a mp4 copy regardless. Or at least make it a setting to keep the original or not.'But I think this needs advice from someone who knows a lot about cross compatible videos.

[djay]

Updated the title to reflect that this problem also affects OSX safari as it only supports quicktime and the mp4 simple profile. see http://www.animemusicvideos.org/guides/playback/playosx.html#MP4_Issues

[vangheem]

I just didn't want to leave the original around since we're already wasting a lot of space replicating the formats already.

I particularly like adding a feature as it just adds complexity with little benefit. Let's just decide on the best way and do it.

[djay]

ok if you don't want to keep the original but a) it should be made clear b) if you choose the manual reencoding then it should be made clear that it will be reencoding from a transcoded copy. The bigger problem is that it doesn't transcode a mp4 file which means you don't get the guarentee of compatibility that this product is aiming for. So I suggest we at least change the code to always throw away the original and generate a new mp4.

A related issue is that if you want to save space, I'm not sure you need ogg encoding anymore. Firefox now supports webm.

[seanupton]

@djay @vangheem I am now working on something indirectly related (need ability to plug policy, site-specific avconv options into conversion process); what I am thinking might look like the converter checking policy after avprobe, but before avconv -- something like this utility interface:

https://gist.github.com/seanupton/f1e0e72efed014d400b4

This might allow for determining when to replace the original based on the metadata extracted from the source material (which I would switch to using JSON output from avprobe/libav >= 9.0).

For simplified example, a default policy could state that if the profile is already "Baseline" in an h.264 stream, keep the original, otherwise replace/re-encode.

[djay]

Ideally what you'd want is something similar to image scales so you publish a HD and SD version of the video and let the user switch. Like YouTube or plumi. It might be time to switch to more flexible data structure that stores codec sets at user defined sizes using rules similar to what you suggest? On 3 Oct 2014 06:23, "Sean Upton" notifications@github.com wrote:

@djay https://github.com/djay @vangheem https://github.com/vangheem I am now working on something indirectly related (need ability to plug policy, site-specific avconv options into conversion process); what I am thinking might look like the converter checking policy after avprobe, but before avconv -- something like this utility interface:

https://gist.github.com/seanupton/f1e0e72efed014d400b4

This might allow for determining when to replace the original based on the metadata extracted from the source material (which I would switch to using JSON output from avprobe/libav >= 9.0).

For simplified example, a default policy could state that if the profile is already "Baseline" in an h.264 stream, keep the original, otherwise replace/re-encode.

— Reply to this email directly or view it on GitHub https://github.com/collective/wildcard.media/issues/16#issuecomment-57726020 .

[seanupton]

Though exact infrastructure for transcoding horsepower is going to vary from site to site, the lower-res encoding runs tend to be much cheaper (so one could say as a reasonable default, 'we don't care about getting the HD stuff to use h264 "Baseline" profile, they can stay as "Main" or "High", but we'll always encode the SD output to Baseline profile, regardless of source resolution or aspect ratio'). And we would never have cause for upconverting anything, so when we talk of adding additional "scales" (or whatever we want to call this kind of thing), we are adding things that are only marginally more expensive to make and store?

The question is how to specify keys or attribute names these things, format-plus-profile-alias? And possibly deciding which to default to for playing in mediaelement?

[djay]

I think I'll just put in a site setting of avconv params per output type.

[djay]

@seanupton I think your approach looks interesting but perhaps over complex? What I will do is build on top of https://github.com/collective/wildcard.media/commit/5c4a665e78b71acc52694dc8ee2a7c2763643b7f to have avconv params per output format. (but not based on size or input format) as this is simpler. @vangheem can you not make a release until this is done so that we don't have to worry about upgrades to the registry? I think being able to set this globally for all sites on an instance would be useful but I would tend to use either environment vars or zope.conf for this. That means no additional python packages need to be deployed. Maybe if there are no registry entries, then it would look for the environment var PLONE_AVCONVPARAMS_MP4 etc?

[vangheem]

@djay no problem about not doing a release, just let me know when.