Daniel G. Taylor schrieb: > On Mon, 2009-05-04 at 11:30 +0100, Christian Fredrik Kalager Schaller > wrote: > >> Hi everyone, >> > > Hey, > > >> Daniel G. Taylor and myself have been working on defining a >> specification for how we want to handle things like profiles and presets >> for transcoding to various devices. The initial usecase is for devices >> you do not have attached to your computer, but we love to get feedback >> on how we might want to adjust the current specifications to work better >> for that usecase too. >> >> There are two documents so far, the first one discussing element level >> presets using the GStreamer preset interface: >> http://gstreamer.freedesktop.org/wiki/PresetDesign >> >> The second is a device level description of the Device in XML: >> http://gstreamer.freedesktop.org/wiki/DeviceProfile >> >> Both documents will probably see quite some changes still, so please >> feel free to give feedback and suggestions. >> >> We do hope that this stuff ends up being used beyond Arista and >> Transmageddon once it matures a bit, for instance Sound Juicer could use >> the Audio information in here for example. >> > > Just thought I'd mention that there are some great comments on the wiki > left by Mike Smith. > > I agree that the use of two different formats for the files seems > unnecessary - I believe it's because of how the presets for GStreamer > are currently setup, right? I'd prefer one format and don't really care > which one, though obviously currently Arista is using XML (and the > format is not stable yet). > > In case anyone else misunderstands the passes section in both Arista and > the DeviceProfile wiki page: it's merely a way to define what should be > done for each pass of an encode. In the example we have only one pass > that is based on constant quality, but you could easily see where you'd > want two pass bitrate-constrained encodes (see Nokia N810 for example), > and the passes section allows you to define multiple passes to > accomplish this. As a working example, in Arista trunk it currently runs > through each pass one after another to produce the final file. In each > pass element you put the options for that pass (or in the DeviceProfiles > case the profiles that all elements must provide given the caps like > video/x-h264, which are defined on the PresetDesign page). > > I also agree that the syntax is not well defined in the wiki for certain > elements. Here is how it works in Arista: > > Each element that gives a constraint is allowed to be either a single > value (e.g. <param>10</param>) or an inclusive range (e.g. <param>10, > 30</param>). Internally the single parameter is turned into a range of > e.g. [10, 10] and all calculations in while setting up the transcoder > are done using those ranges (scaling, resampling, etc). I agree that one > shortcoming is not allowing a list of discrete values or allowing > something like e.g. <param>320, 720 % 16</param> to say that the value > can be between 320 and 720 but must be a multiple of 16. I'm working on > this for Arista and will probably be updating the GStreamer wiki with > more info soon as well. > > Perhaps it is more useful to direct people to post here rather than the > wiki? Having conversations on a wiki has never really been very > successful for me. > > Take care, >
Okay here are my comments (now removed from the wiki): Totally agree with Mike regarding the devce capabilities. What about even: video/x-h264, width=[320, 640], height=[240, 480], framerate=(fraction)1/30 you could e.g. reuse the capssrting and put it on a capsfilter as it is (except the media-type). Also agree that xml feature are slight overkill here. The purpose of the device profile is to describe the suggested format and limitation for a certain device. On IRC I was suggesting to also take os-versions into account, so that we end up with profiles like this: PC.WindowsXP // use avi with mpeg4 and mp3 PC.WindowsVista // use asf with wmv and wma PC.Linux // use ogg with theora and vorbis N8x0.Maemo4 // use avi with mpeg4 and mp3 N8x0.Maemo5 // use mp4 with h264 and aac It could be consided to have a unversioned fallback (N8x0 that even could be a symlink incase someone does not know the version). Stefan > ------------------------------------------------------------------------ > > _______________________________________________ > gnome-multimedia mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-multimedia > _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
