Any space on the roadmap left for 2-pass encoding via ffmpeg?
Instead of calling ffmpeg once, you'd call it twice, with slightly different parameters (for each pass, of course). The result would be enhanced quality output at a smaller filesize for flv and when using h264, it starts to shine even more. :)
Comments
Comment #1
iLLin commentedYea its been in my thought process. I have been thinking on making "actions" and then defining an action to a video field. So you can add unlimited passes if you wanted to... I just haven't quite got the UXP figured out yet. Needs to have an "easy" work flow that isn't confusing. And then we need a formatter that's going to be able to handle this output.
Maybe instead of giving too much rope in this, we create a framework that extends/creates pre defined actions for us. So we could have HTML5 action (this action creates an ogg,mp4 with a fall back of flv)... etc. High Res / Low Res action. 2/3 different sizes? HD Quality Action? Then each of those will have their own formatter to accommodate the specific action? Inside each action displays the passes and the command that's to be ran, here you can customize it for each...
Thoughts and ideas?
Comment #2
Anonymous (not verified) commentedYes I think you are right on this. Prefilled presets which are editable and offer 2 lines of encoder parameters are sufficient for the most usage cases (probably 99%). 2-pass encoding is probably the most advanced thing you'd want your webserver to do, for a "normal" website anyways. Usage cases which require more than 2 CLI commands are for example muxing/demuxing/watermarking, but I suspect that heavily explodes the scope of this module. The only thing I could think of right now is watermarking. That would be very sweet. But it would be certainly required to create an UI simply for the process of adding watermarks: uploading, sizing, positioning, ... so, uhm, let's add that to the wishlist but way down there. :-)
I'd suggest 3 editable presets:
- 720p (just to be future proof :-P )
- HQ (VGA, H264, medium encoding quality)
- LQ (QVGA/VGA, H264, low encoding quality for small bandwith users)
If a user needs something more advanced than this, he's likely going to need to go for RMTP, dedicated streaming/CDN serving anyways. Most users probably won't even need 720p, tho it's getting popular for screencasts.
As HTML5 is becoming the de-facto solution for video embedding (slowly but .. it *will*), you might actually cut a curve and make it a default already. FlowPlayer is able to play H264 perfectly - so there wouldn't even be the need for a special FLV conversion/fallback solution. The fallback would consist only of choosing the player (built-in or Flash-Player) which will stream the same media file.
The logic would be limited to
- serve 720p, HQ or LQ content, based upon user's choice (overlay, play button)
- to either a HTML5 player or SWF Tools/FlowPlayer, based on user's brower-version (automagically)
This would require a different approach on including the players tho. Something like a thumbnail (the generated thumb) which has an overlay attached to it, offering the enabled encoding options with a simple "Play" button. On hitting the play button, the Thumbnail container will be replaced with the actual video player. That would require a bit of jQuery magic I believe. Similar to the formatters which "Embedded Mediafield - Videofield" offers. Tho they seem to create problems, as far as my testing goes for another website project.
An additional option which could be interesting is to allow people to download the HQ media by adding a link underneath the video player. That could be configured on per-preset level to keep the formatters-dropdown from showing a hundred combinations.
In the end, the user should be able to "tick" profiles on and off: Either per content-type or sitewide. I'm not sure wether it is really necessary to have presets on a per content-type basis. The thing I definately wouldn't offer is choosing presets on a per-node level. First, because the UI on node/edit/add pages is already cluttered with all sorts of stuff. Second, every option you add has a chance of creating confusion: The user should just be able to upload a file, select a thumbnail from the generated ones and hit save. Aspect-ratio checking, probably letterboxing to compensate for preset-sizes/differences et al should be configured on a higher level and should be handled without the user needing to think about resolutions. Well, I have to add that I'm quite the UI purist tho .. :-P
I am actually already a bit confused with the current form on the node-edit/add page: The checkboxes for "override automatic conversion" and "convert on node save" are only useful for the first time you save an item and the first thing I did was to prohibit those options from being displayed, using the module "Formfilter". :-)
What do you think?
Comment #3
iLLin commentedI don't think you gave this much thought :p.
Let me sleep on this and think about this some more.
Comment #4
Anonymous (not verified) commentedWell, it's your call ..
Comment #5
iLLin commentedI was being sarcastic when I said you haven't given this much thought lol. You have thought about it way more than I have.
I'm thinking why can't we have a default, that plays on page load, or loads (instead of a thumbnail) and then just have options to change to a higher resolution? Maybe spit out each resolution as links in the them and let the themer do what they want with them?
So new tab in admin, why not call it "2 Pass Encoding" or "2 Pass" or something, that has predefined actions. Create a class file "action" that will extend for each action we do. Put in some hooks for the current system to integrate/extend the current functionality (need to do this anyway).
When setting up the field in the content type, I guess add a new area to either use default encoding, or use a 2 pass action? If using a 2 pass action, we need to make sure the right cck formatter is selected as it will have different options than the regular video formatter.
What else we got to think of?
Comment #6
Anonymous (not verified) commentedHehe that sarcasm didn't got thru very well. ;-)
A default with links which can be styled underneath the player is simple, yet effective, that's correct.
I'm not sure about the architecture of the plugin. I'd leave that up to you to choose the best solution since I'm really not that good at the whole coding aspect.. :P
However, I'd suggest showing less options to the enduser than what's currently available. For example, codec and format lists are sources for misconfiguration. I'd specialise the options to allow for a slim choice of actual web-ready formats. As I already stated: MPEG4, H264 and - as a fallback - FLV. By selecting a container format, you basically already choose your codecs: FLV is not hard to figure, mp4 too and for h264 i'd choose *.mov as it's kind of originating in that corner.
Futhermore I'd completely remove audio codec selection and just provide a bitrate selection for audio. AFAIK ffmpeg selects the best possible codec for audio depending on the videocodec and container on it's own. So all you'd need to select is: a) container b) video bitrate c) audio bitrate d) maybe fps. This makes the configuration a lot easier for the unadvanced user while leaving the pros all the options by using the "advanced textfield".
Coming to think of it .. 2 Pass encoding is a rather intensive procedure and requires quite some power on the webserver side. Encoding takes significantly longer depending on the settings so i'm not sure wether it is really "safe" to offer that as a "clickable" setting. Maybe it would be good for a start to just add the option to add a second encoder line under the "advanced" section of the current profiles. Those who know what they're doing will know what to put in there and use the advanced options anyways. Those who don't know how the whole thing works are probably better off by just using single pass with limited options. IMHO. :-)
Comment #7
alexfisher commentedSubscribing.
Comment #8
Milan0 commentedI agree with having some kind of framework for preset encoding types, even multiple video types per video, for different platforms.
We could also integrate this with Rules.
Comment #9
hypertext200We will have separate section to create video profiles, it can be a another tab in video settings. There you can create custom video profiles, underneath transcoder tab you can see presets you already have for the selected transcoder, it can be Zencoder, FFMPEG or whatever.
Initially we will have profiles
Users can create custom profiles and those also will be showing there, create custom profiles interface same like current transcoder settings interface which is to add video bitrate bla bla.
I thought of implementing this one soon, but issues is how can I handle n-pass encoding, is it better to integrate with rules? but I don't like end-users to mess up with loads of modules.
Comment #10
ppcc commentedsubscribing
Comment #11
hypertext200Mobile profile which I'm going to add in to profiles
Comment #12
martin_s commentedsubscribing
Comment #13
damiandab commentedsubscribing
Comment #14
3dloco commented+1 :)
Comment #15
hypertext200Few days back I committed a FFMPEG profiles code, which is working as below.
The video module do have presets (by default HTML5 mp4, HTML5 ogv, HTML5 webm), all those presets are .inc files you can find them in presets folder, but if you want to add another preset then you can create a folder called presets and add your .inc file according to same standers in default presets.
HTML5 webm preset as below.
You can see there
commandarray which is actually to run commands, now video module is designed to run with any type of installed Transcoders. Eg, in this case its using ffmpeg but you can see we are using ffmpeg2theora, mcoder and HandBrekeCLI too.So to enable 2 pass encoding what you want to do is set the
commandparameters as appropriate.Welcome your comments!!
Comment #16
hypertext200