Michael, On Tue, 2009-06-23 at 15:30 -0700, Michael Smith wrote: > So to clarify: > - the profiles are ONLY to map some specific known profile names to a > set of property values for a particular element, so that if you have > two different encoder implementations (which both support the same > basic semantics, but have different property names, or different > units, etc.) you can set things up without knowing the specifics of > the encoder. Correct, though it is also useful in the following scenario: if several H.264 encoders exist in your GStreamer installation, then you can request something like "video/x-h264 Baseline Profile" and GStreamer would give you an H.264 encoder that supports that profile (it is possible that one would support Baseline and Main, another support all profiles, and yet another could be a highly optimized High Profile only encoder). The point is to basically add feature information in a standardized way to the various encoders that is easy to load as a preset. > They're NOT for providing a drop-down of different encoding settings > in your application, or anything like that. There are a number of > major problems with trying to use them for that purpose (which is what > I initially thought they were for). Your application still has to > provide that layer entirely. However, they CAN be used for this purpose. Choosing a profile is a useful action in many cases, especially when encoding for various devices. My ultimate goal is of course to hide all this behind the device profiles themselves as is currently done in Arista, but there's no reason that Transmageddon can't let a user select profiles and qualities based on these preset files. > In my opinion, this is not very helpful. In reality, if you have two > different encoders, either: > - they support the same semantics, so making them use the same > property names/values for that is simple. Generally true, though it's possible encoders support different types of profiles as in the example above, and forcing every application to save which settings are required for which published profiles for every encoder type is insane. > - they support different things, so just mapping names/values/etc > doesn't help you at all It will eventually let you query for a suitable encoder for a particular format and/or device. Those that do not support what you need are not in the query results. > On to some specifics about the presets you've proposed: > - Where you have things like "Quality High", you've just selected a > bitrate. But, that only makes sense at a particular size of input > (resolution/framerate/etc for video, number of channels, sample rate > etc for audio). Why not just a preset called "Bitrate 128kbps"? That > maps equally well to the underlying properties, but doesn't imply > anything about quality - which is good, since the preset is _only_ > setting the bitrate, and actually doesn't have anything to do with > quality. Agreed - I think all quality presets should set the quantizer and set pass=qual or pass=quant as in my other email. Bitrates should be the responsibility of the developer or the device profiles, being set to either satisfy some quality constraint via a formula that takes into account physical dimensions and framerate of the output or the physical limitations in bitrate and buffer size of the device you are encoding to. Again I talked a bit more about this in my other email. > - Some presets are designed to be applied along with others, some are > mutually exclusive (e.g. for AAC, the profiles are mutually exclusive, > but a profile and a bitrate can both be selected). But there's no > information provided about which is which. So, an application just has > to hardcode profile names, so this isn't in practice at all > extensible. I also agree with this. Along with some being mutually exclusive the order matters as values can be overwritten. Perhaps a type field could be added to group presets, then during loading warnings or exceptions can be raised if a "profile" type is loaded after a "pass" type and such? Not as extensible as we might like but I'm trying to think within the limits of the preset format. > I think in practice what people want is an "encoding profile" that > specifies things more completely - e.g. for audio, it might say > "stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and > have a name of "Medium quality Foo Audio" (this would need to be > translateable somehow, but that's a different issue). You could > provide a replacement profile with the same name using a different > encoder, of course. This is what the device profiles are for, which internally will use the encoder presets to select encoding profiles, qualities, etc. The preset files are a necessary change before we start locking down a device profile format which will result in giving you and others the profiles you want to see. > Summary: > - I don't think the aims are clear. > - I don't think the current proposal works very well for what its > aims are, OR for what people are likely to think its aims are. I hope some of this mail cleared that up; if not let me know. To know where I am coming from you can take a look at Arista ( http://programmer-art.org/projects/arista-transcoder ) - my goal is a generic system for such profiles in GStreamer, and Christian deserves most of the credit for really trying to get things going in a generic way and into GStreamer trunk. If you still think these presets/profiles won't do what you want - any ideas on how to go about getting the results you'd like to see other than saying that our approach won't work? Take care, -- Daniel G. Taylor http://programmer-art.org
Attachment:
signature.asc
Description: This is a digitally signed message part