Re: Presets and profiles


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
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:
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.

> 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:
>>>> The second is a device level description of the Device in XML:
>>>> 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
>>> gnome-multimedia gnome org
>> _______________________________________________
>> gnome-multimedia mailing list
>> gnome-multimedia gnome org
> _______________________________________________
> gnome-multimedia mailing list
> gnome-multimedia gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]