To origin for these higher level device profiles is the XML format defined in the Arista transcoder, they have been changed quite extensively though as the underlaying featureset in GStreamer has evolved. There are a few changes in the XML example below though from what Arista does today. First of all we replace all element names with GStreamer Caps and secondly we replace all element attribute settings with preset calls. Finally we expand the XML format to include all allowed choices for a given device, so that the application can offer the user other valid choices if they want to. Many GStreamer Caps are listed in the GstreamerCaps list.
To try to keep the discussion clear we always refer to these files as 'profiles' and the element specific GStreamer files as 'presets'. These files are meant to provide all information needed to create a usable caps profile for encodebin.
<?xml version="1.0"?> <device> <make>Apple</make> <model>iPod</model> <description>Profile for Apple iPod / iPhone</description> <author> <name>Joe Example</name> <email>firstname.lastname@example.org</email> </author> <version>1.0</version> <icon>file://ipod.svg</icon> <default>Normal</default> <profiles> <profile> <name>Normal</name> # You can have multiple profiles, Low, Normal and High, in this example we only include Normal <container>video/quicktime,variant=apple</container> <extension>m4v</extension> <audio> <caps>audio/mpeg,mpegversion=4, channels=2, rate=44100, base-profile=lc </caps> </audio> <video> <caps>video/x-h264, profile=main</caps> <border>N</border> <passes>2</passes> # Number of passes in multipass encoding <width>320, 640</width> # range supported by device, as we want to avoid upscaling when possible <height>240, 480</height> # range supported by device, as we want to avoid upscaling when possible <framerate>1, 30</framerate> # range supported by device, as we want to avoid increasing rate when possible </video> </profile> </profiles> </device>
The general idea here is to enable the creation of a caps string that will enable encodebin to create the video we need. For fixed values they can just go into the caps, for others they need to be specified as a range and the program logic needs to handle it.
Using this simple format the profiles for PSP, Nokia devices, the computer, etc are almost identical to the above and require no further modifications to the element presets.
One question which needs further thought it how to deal with variations within a device type, maybe 'iPod' is too generic for instance. We could also add another gstreamer preset for variation values if needed.
Also - what about handling multiple passes - the above can handle it by defining more
We also need to come up with a nice, but hopefully not to verbose way of including information about all supported codecs and containers formats in addition to our recommended one.
This proposal is being discussed on the GNOME Multimedia mailing list
To reach the archive go here
Comments on the proposal should be sent there. The comments below will be moved to the mailing list and removed from the wiki. So do not add more comments here.