Looking for a video-converting/transcoding genius...

[Entity]

Heh. For the past 48 hours I've been drooling over this demo and trying to see how close I can get to replicating it with some materials that aren't nearly as intensive as the ones he posted. I have a site that converts WMVs to H264-encoded MP4s to stream in flash (also to let Mac/other users download the MP4 files and play them back in VLC more easily) and we do about 15 vids worth of batch conversion right now using MediaCoder. I'm pretty sure I have some ugly settings in there -- it works, but the filesizes are usually like 1.5-2x the size of comparable WMVs.

I'd be willing to pay for someone to help come up with a Mediacoder profile that will encode with more efficient settings. We use a Windows XP x64 box for doing all of our encoding and I'd just like to get the process streamlined so we can batch a bunch of WMVs and spit out some properly-encoded MP4s. I've seen a lot of ffmpeg commandlines posted but haven't had a lot of luck implementing them (I know I'm going about this in a kind of backwards way) to get everything to work properly.

Rob

 

[QuixoticOne]

Well it depends somewhat on your source material's characteristics as well as the encoding time you want to spend on encoding the materials.

You can tell the encoders to be more thorough at looking for compression opportunities at the cost of slower encoding times.

You can of course encode at more high compression rates but lose some original quality in the process via lossy compression.

There are also compatibility issues in that not all client software will be able to play back all options of encoded formats that may exist within H.264 or MP4 or whatever, so you may not want to use certain encodings even if they're desirable from an coding efficiency and quality standpoint depending on your decoder clients.

Getting a good optimized compile for X64 or SSE3 or whatver you have to work with will of course help the codec do the best job possible in the shortest encoding time possible.

Do you find that you're getting both substandard encoded video quality AND substandard compression rates?

 

[Entity]

No, the quality where we are right now is fine. The main problem is that for a recent transcode I did, a 126MB WMV came out to be a 230MB MP4. The resolution on this is pretty large (1600x578) but even with that said, 230mb for about an hour of footage is more than a lot of people's connections can handle easily, and we're trying to make it as small as possible while retaining as much of the quality. Unfortunately I a) don't have a ton of experience in this stuff and b) don't have enough time to

We're ok with slowing down the encoding times...basically the areas of importance, in order, are:

1) Compatability. If it can't stream in the newest version of flash, we definitely can't use it. It would be nice to have it playable in Quicktime but that's not a necessity.
2) Quality. The video is "animated" (it's a mix of screencasts and some animations that have been done -- mostly screencasting).
3) Filesize.
4) Encoding times.

Based on what I've seen other people do using ffmpeg, I feel like I'm way behind the times in terms of optimization but I don't really know where to start. I know a lot of people spend time doing some pretty intense encodes and really all I care about is having it batchable on the platform (XP64) we're using, and using as much of the processing power that we have (2x quad-core 2.33ghz) as possible. A tall order, I know, which is why I'm hoping to find someone who would take this on as a quick contract/consulting job since it's probably a minimal amount of hours for someone who has experience in this but has already taken me days and I'm nowhere near where I need to be.

thanks a ton for the response-
Rob

 

[QuixoticOne]

Hmm. I'd consider trying to help you solve this perhaps as a fixed bid type of short contract or something like that.

I really don't have enough experience with specifically screencasts / animated types of input sources to know off the top of my head what encoding options are best for that, though the generalities as to what compromises / encoding constraints would likely encode with good quality and lower bitrates seem pretty obvious.

It depends on what you've already tried and what qualitative result it's going to take to satisfy your needs as to how straightforward it might be to improve on what you've already done.

I also don't know what you've tried already and in what other ways they've failed for you (besides the H.264 = 2x the WMV size example).

Clearly I understand that you don't want the H.264 output to be greatly larger than the well encoded WMV9 input. But if you've found that you've generated a lot of trial encodes where the H.264 is reasonably small in size but the quality doesn't meet your perceptual needs then that's perhaps getting into a fine area as to what's the right trade-off between quality and size which is a pretty subjective thing that a third party isn't totally going to be able to estimate in your stead.

Also it'd be interesting to see what particular software builds and conversion options you've tried. It could be that you're missing some newer / better codec options or configurations depending on what you're running.

Why hasn't running ffmpeg via command lines worked well for you? Is that purely a procedural issue with generating a batch control system for it, or have you had some system incompatibilities with the build you're using and your OS or something?

Anyway I'd suggest that it'd take some experiementation and reviews of your precise source materials characteristics to possibly come up with a more reasonable configuration for you. It may be there's some "canned" coding configuration that works great for screencasts 95% of the time but if that's the case, I don't know what it would be offhand, maybe someone else will.

Ideally it seems like you wouldn't have to use a video codec at all for screencasting and animations anyway since the most efficient protocols for screencasting would be things like RDP or WPF/E or whatever that understood and encoded the nature of the source material most efficiently from the start. And of course vector / sprite based animations could in theory get done in a more high level flash-coded design process to begin with. But of course I realize that the transcoding to flash video is sort of the broadest common denominator in terms of multi-platform accessability, and that you may not have the ability to change the way you're aquiring / generating the source content at this time.

 

[Entity]

Originally posted by: QuixoticOne
Hmm. I'd consider trying to help you solve this perhaps as a fixed bid type of short contract or something like that.

I really don't have enough experience with specifically screencasts / animated types of input sources to know off the top of my head what encoding options are best for that, though the generalities as to what compromises / encoding constraints would likely encode with good quality and lower bitrates seem pretty obvious.

It depends on what you've already tried and what qualitative result it's going to take to satisfy your needs as to how straightforward it might be to improve on what you've already done.

I also don't know what you've tried already and in what other ways they've failed for you (besides the H.264 = 2x the WMV size example).

Clearly I understand that you don't want the H.264 output to be greatly larger than the well encoded WMV9 input. But if you've found that you've generated a lot of trial encodes where the H.264 is reasonably small in size but the quality doesn't meet your perceptual needs then that's perhaps getting into a fine area as to what's the right trade-off between quality and size which is a pretty subjective thing that a third party isn't totally going to be able to estimate in your stead.

Also it'd be interesting to see what particular software builds and conversion options you've tried. It could be that you're missing some newer / better codec options or configurations depending on what you're running.

Why hasn't running ffmpeg via command lines worked well for you? Is that purely a procedural issue with generating a batch control system for it, or have you had some system incompatibilities with the build you're using and your OS or something?

Anyway I'd suggest that it'd take some experiementation and reviews of your precise source materials characteristics to possibly come up with a more reasonable configuration for you. It may be there's some "canned" coding configuration that works great for screencasts 95% of the time but if that's the case, I don't know what it would be offhand, maybe someone else will.

Ideally it seems like you wouldn't have to use a video codec at all for screencasting and animations anyway since the most efficient protocols for screencasting would be things like RDP or WPF/E or whatever that understood and encoded the nature of the source material most efficiently from the start. And of course vector / sprite based animations could in theory get done in a more high level flash-coded design process to begin with. But of course I realize that the transcoding to flash video is sort of the broadest common denominator in terms of multi-platform accessability, and that you may not have the ability to change the way you're aquiring / generating the source content at this time.

YGPM.

 

[Barfo]

wow, that demo looks good.