On 10/4/07, Michael Müller <[EMAIL PROTECTED]> wrote:
>
> Hi Francesco,
>
> I just subscribed to continue our discussion here.
>
Hi Michael, nice to see you here :)
when I read 'started some month ago' I thought there already should
> > something that does at least most of what I'll need. But when I read README
> > from MPEGlib I saw that it's older than just some month; the date for
> > v0.1.0 is 2005-09-05.
> > Yes it is quite old. My bad, I've just missed the 's' in 'months'
> > (typo).
> >
> The typo was on my side (see your original quote) but still 'some months'
> sounded like re-inventing the wheel because in general the topic MPEG is not
> new.
>
Yes definitively this topic is not new. But I was always unable to find a
clean, lean and simple
muxing/demuxing library for MPEG (of course now I'm expecting a flood of
links from readers :) ).
> Yes, partly. libmpeg2 decodes a (video) stream. It not deals with
> demuxing.
> mpeglib was designed to be complementary to libmpeg2: mpeglib will handle
> the demuxing (and muxing), and libmpeg2 will handle the decoding.
> Speaking of libmpeg3, I know very little about it.
>
> I'm new in this MPEG topic. Can you describe in a few words what the
> difference between demuxing and decoding is?
>
I'll explain. Please let me know if you find some parts unclear (or plain
wrong :) ).
In a nutshell,
a multimedia file (AVI, VOB, OGM) is (usually) composed by two or more
streams, say audio
and video. For performance reasons (avoiding seeks that is slow and thrashes
caches), the
streams are multiplexed. So, we DO NOT have first the whole audio track then
the video one, but
more likely something like
N video packets, N audio packets, N video packets, N audio packets ... until
the end of file.
"demuxing" is the process that, given the multiplexed file as input, returns
as output only the
packets belonging to a selected stream, effectively reconstructing it.
That's roughly what tcextract does.
"decoding", on the other hand, is the process that transform a given stream
in another stream,
from compressed to uncompressed.
In MPEG terms,
given a TS (Transport Stream) or PS (Program Stream), multiplexed, demuxing
produces (usually)
two or more ES (Elementary stream),
given an ES, decoding produces a sequence of human-enjoyable pictures or
sound samples :)
Let's try to see again in a ASCII-art form
[multiplexed file] -> (demuxer) -+-> [video track] -> (decoder) ->
[pictures]
`-> [audio track] -> (decoder)
-> [sound]
demuxing is propedeuthic to decoding.
And is one a substask of the other or can it completely handled separate so
> that it makes sense to have them in two different libraries?
>
Generally speaking, yes it makes fully sense. We have a plenty of examples.
In ffmpeg camp, libavformat takes care of muxing/demuxing, while libavcodec
takes care of encoding/decoding. avilib, in transcode, takes care of
demuxing/muxing AVI streams, but does
not encoding/decoding at all. libmpeg2 just handles decoding. in OGG camp,
libogg takes care
of muxing/demuxing, while libvorbis and libtheora do decoding/encoding
respectively for audio
and video.
The problem, in MPEG camp, is stream layer (es: demuxer) isn't completely
separated from the
upper (decoder). There are some interdependencies.
>From libmepg3 home page:
>
[...]
> MPEG-1 program streams
> MPEG-2 program streams
> MPEG-2 transport streams
> AC3 Audio
> MPEG-2 Video
> MPEG-1 Video
> IFO files
> VOB files
> Is it still the wrong library because it decodes instead of demuxing?
>
I just don't know, but the (snipped) quote above looks promising. What we
need
in transcode as base requisite is a clean separation between demuxing and
decoding.
I'll take a look to the API as soon as is possible.
Yesterday it come into my mind that mplayer prints the timestamp from video
> and audio and the offset. If I open my MPEG PS file with mplayer is starts
> with -3.8 s offset. This offset changes continuously to 0 over around 20
> s. Do you know if this is a mplayer feature to correct such an offset online
> or does this means that only the first 20 s are corrupt?
>
Generally speaking mplayer is very very resilient to corrupted/incorrect
streams,
and this looks like an automatic correction more than a corruption.
Bests,
--
Francesco Romani // Ikitt
