Re: Presets and profiles

[Christian Fredrik Kalager Schaller <uraeus linuxrising org>]

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.

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.

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.

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
> > gnome-multimedia gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-multimedia
> >   
> 
> _______________________________________________
> gnome-multimedia mailing list
> gnome-multimedia gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-multimedia