[gst-devel] Tagging, media-info

[Benjamin Otte]

The problem is not that media-info is overengineered for media files, it
is overengineered for what GStreamer can do.
It supported tags way before GStreamer really supported them and it
supports tracks before GStreamer really does know how to solve that.
It's the topdown way this lib is developed that I don't like. I add needed
stuff bottom-up.

We need to come up with a general way to differentiate between "track" and
"URI", like GStreamer does now, which can be best seen in Rhythmbox.
Though that requires some thinking for a) definition, b) structuring and
c) querying.
a):
What are multiple tracks? When is something another track and when is it
just a marker of some position inside a track? Or can both be expressed
as the same thing? (This would require input from Iain about Marlin's use
of markers...) Do we reset the timestamps when a new track starts?
b):
The concept of multiple tracks exists in loads of streams, starting with
audio CDs, flac or vorbis for music. But you can also Add this for video
(DVD) and media-agnostic formats (directories, gzip, ...). And you can put
multiple layers inside each other with that. (like gzipping cuesheet flac
files).
c):
You need a way to find out if a file consists of multiple tracks. You need
to be able to store them in media-info or Rhythmbox and you need to seek
there. Maybe you even want to set them via gst-launch somehow?

Those are all things that need to be worked out, there probably need to be
tags and/or events added for all this, before we can really support
tracks.

At least that's my view of multitrack support...

Benjamin


On Fri, 19 Dec 2003, Thomas Vander Stichele wrote:

> El jue, 18-12-2003 a las 21:53, Benjamin Otte escribió:
> > On Thu, 18 Dec 2003, Andreas Rottmann wrote:
> >
> > > What do you mean by ported here?
> > >
> > Changed to use the new tagging system.
> >
> > > I'm don't have very much insight into the code yet, could you be a bit
> > > more verbose?
> > >
> > I didn't look at it for very long but for example it has a concept of
> > streams and tracks per file, which isn't reflected anywhere in GStreamer.
>
> It is.  For example, vorbisfile lets you seek to logical streams inside
> an ogg.  If we don't handle this in GStreamer it's because we didn't add
> it.  But all more modern container formats have a concept of
> streams/tracks per file, and for good reason.  This includes matroska
> and ogg.  Flac and shorten too IIRC.
>
> Two examples of problems it solves:
> a) Suppose you have ripped a CD to separate mp3 files.  There's no way
> to play back those mp3's the same way as the album.  This is incredibly
> annoying on, for example, live albums.  The way mp3 works it is
> impossible to make the mp3's itself follow each other gaplessly.  No
> amount of forensic hacking (adding mixing support, detecting silence,
> ...) will fix that.
>
> b) Suppose you want to transcode a DVD to a video file.  Right now,
> people either do one file per chapter, or one file for the whole video.
> Neither are satisfactory, and neither reflect the way you can play a
> DVD.
>
> So in the new media formats, which are treating the *user case*
> correctly IMO, you clearly see there is a two-dimensional structure.
> A file can consist of one or more frobs, where a frob is defined as "a
> logical coherent unit of the transported media".  For example, one song
> in a live set, or one chapter in a dvd.  Between frobs, it's even
> possible that certain parameters change (sample rate, frame rate,
> dimension, ...).
>
> Each frob by itself can contain of one or more thwarks.  A thwark is
> defined as "one unit of a base media type".  Thus, A frob could consist
> of a video-only thwark, two language-specific thwarks for that video, a
> PAL version of the video thwark, and five subtitle thwarks.
>
> Whatever realworld names you give to frobs and thwarks, it is clear that
> there is a very natural twodimensional structure to media formats today.
>
> Which is why I don't think media-info is overengineered at all.  Could
> it be better constructed than it is right now ? Sure.  But *please do
> suggest something to remedy the matter*.  Don't just stop at saying
> whether or not it is overengineered.  AFAIK, I've solicited actual
> comments on the API of media-info on a number of times.  My intentions
> to work with other people on this are pretty clear I would think :)
>
> Anyway, some people have taken an interest as of late, so I will put my
> plans for it online so we can work something out together.
>
> Thomas
>
>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
> Dave/Dina : future TV today ! - http://davedina.apestaart.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> I used to play with toy guns and knives with my daddy
> He never taught me how to kill
> <-*- thomas (at) apestaart (dot) org -*->
> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
>
>
>