New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support h264 for older IOS devices and OSX safari via config avconv params #16
Comments
Looking at the code more closely it does the following
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. |
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 |
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. |
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. A related issue is that if you want to save space, I'm not sure you need ogg encoding anymore. Firefox now supports webm. |
@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. |
Ideally what you'd want is something similar to image scales so you publish
|
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? |
I think I'll just put in a site setting of avconv params per output type. |
@seanupton I think your approach looks interesting but perhaps over complex? |
@djay no problem about not doing a release, just let me know when. |
This answer shows how to convert a video to be the most compatible.
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.
The text was updated successfully, but these errors were encountered: