[gst-devel] GstTuner

[Tim Müller]

On Mon, 2006-03-20 at 10:41 +0100, Andy Wingo wrote:

Hi,

> 1) GST_FORMAT_DEFAULT should be tracks on a CD source; there's no need
> for TRACKS (the same reason why we don't have a frames or samples
> format).

I am not particularly fond of that. The CD sources have raw audio caps
on their source pad, and so far the convention has been that the DEFAULT
format for raw audio is samples/audio frames. Why change that? It'll
just cause more confusion for no good reason. Also, how do you express
'samples' then when you really want the source to do things with
sample-precision (like play a loop from a CD title)? So then we'd need
to register a proper 'sample' format in the core.  Besides, I don't
think it could be changed in the 0.10 series anyway for API/ABI reasons.

I don't really see the similarity between a CD source and tardemux apart
from the fact that you want to select something from a number of
streams. Not that I've got anything against registering a "track" format
with the core (same as a "title" or "chapter" format), but I still don't
really see why tardemux contains "tracks".

Personally, I'd just make tardemux register a new format (e.g. "file" or
"file-number" or whatever), but that's just me.

> 2) GST_TAG_TRACK_NUMBER can be fine, but how will you specify the name
> of the file in the tarball? There is no tag that would be appropriate.

tardemux can register new tags of its own for that (or we can add them
to the core or to -base/gst-libs/tags/tags.h). Maybe we should add
something to the core so you can put taglist arrays into a taglist. That
might be quite useful for cd/dvd sources as well (e.g. there's commented
out code in cddabasesrc to post the meta data for ALL tracks on the bus
as a taglist array - that way the application can check TRACK_COUNT and
then loop over the track info and get the info for the entire disc, but
that still requires support from the core in some form, e.g. by adding a
new tag for that array).

 Cheers
  -Tim