Re: Presets and profiles

hi,

Christian Fredrik Kalager Schaller schrieb:
> Let me reply to Stefans and also to MikeS comments from the Wiki (soon
> to be removed).
>
> I don't have any strong opinion on the formating of various values, but
> I guess making them as GStreamer like as possible is nice in terms of
> ease of use in the code and for people to make mental maps of how things
> in the profiles map to GStreamer code.
>
> So switching to MikeS proposed:
> <channels>[1,6]</channels> or <channels>{1,2,6}</channels>
>
> and Stefans
> width=[320, 640], height=[240, 480], framerate=(fraction)1/30
>
> would be fine with me.
>
> As for Stefan and MikeS comment about the two different formats for the
> presets themselves and the device profiles. The reason is that in both
> cases I simply went with what is already there. I do see however that
> the preset system support XML presets so we can use that if having the
> same file format for both is preferred. Personally I think it is a minor
> issue.
>   
Ack. I was merly pointing ou that gst has useful function to serialize
and deserialize things, but the xml format as it is could not benefit
from it.

> Mike claim that presets apply to only a specific element, which is
> wrong. Or at least it is supposed to be wrong. The whole idea about
> using presets is to be able to define equivalent presets to two
> different encoders for the same format. If we didn't care about that
> goal we don't need presets, we can just do what Arista do now and define
> the exact attributes we want to use in the device profile XML file.
>   
Imho Mike said one preset configure one element. There is
interoperability via preset metadata like tags or names.
> As for the comment on adjusting the bitrate, I don't think that is part
> of scope. I mean the point of these files is to suggest sensible
> defaults. If people want to override them that is fine, but I don't see
> the value of having a key for overide ability in the device profile
> file. I mean most values in there can be overridden, including the codec
> choices etc. Only reason I could see for having a bitrate value in the
> XML would be if some devices only allows specific bitrate ranges.
>   
Once we have all those things in place, we could think of a preset
editor (aka expert mode). Something like
http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/docs/help/bt-edit/C/figures/machine-properties.png
One sees all the useful properties on the left and the presets on the
right. Loading a presets shows the settings. One can modify them and
save it (as a new preset). If we go that way it would be nice to get
more hints from the elements to construct a sane ui.
For filtering properties:
http://bugzilla.gnome.org/show_bug.cgi?id=522205
Describing dependencies is tough though. We would need a mechanism to
tell which other properties to make sensitive/insensitive when one
property changes. Like we have a notify: signal for each property there
could be a sensitive: signal on gstobject.

Stefan
> Daniel explained the passes stuff in his email so I will not comment on
> that.
>
> One important aspect to mention here is that the XML file is not
> complete yet. We do want to add some kind of listing of ALL supported
> media format combinations on the device. So that applications can find
> out which formats it should allow setting if they have an option for
> choosing containers and codecs (like Transmageddon does).
>
> Christian
>
>
>
> On Tue, 2009-05-05 at 16:35 +0300, Stefan Kost wrote:
>   
>> 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
>>     
>
> _______________________________________________
> gnome-multimedia mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-multimedia
>