[FFmpeg-devel] ts mux satus ?

[Michael Niedermayer]

On Tue, Apr 16, 2013 at 06:41:24PM +0100, Kieran Kunhya wrote:
> On Tue, Apr 16, 2013 at 5:21 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Apr 16, 2013 at 04:11:36PM +0100, Kieran Kunhya wrote:
> >> On Tue, Apr 16, 2013 at 3:36 PM, Daniel SERCY <daniel.sercy at st.com> wrote:
> >> > Hello,
> >> >
> >> > Is there a status available about ffmpeg ts mux ? maturity, limitations ? know bugs ?
> >> >
> >> > Thanks & Regards,
> >> > Daniel
> >>
> >> It is only really useful for streaming where you don't need spec
> >> compliance.
> >
> >> Fixing would require making a new API specifically for
> >> MPEG-TS so the mux can interleave ts packets; this something that is
> >> against the flow of codec/container abstraction that is going on in
> >> libavformat right now.
> >
> > This sounds very odd and wrong. Please elaborate, iam not sure if i
> > misunderstand you or not.
> >
> > Its the muxers job to take the data it gets from a encoder, a demuxer,
> > a file or the network and split and package it according to the
> > specification of the container. And i dont see why TS would be a
> > special case here
> 
> The current API as far as I can tell, lets you mux audio/video/data
> packets, A,B,C, sequentially as ABC.

Thats not true in that way, you submit packets to the muxer, thats
not "muxing" them in the file like that though. Many muxers buffer
packets, sometimes in byte based fifos. What actually gets muxed can
be quite different from what was submited to libavformat.


> In ts you would need to chop each packet into 188 byte packets (after
> headers, PES etc) to make (aaabbbccc) and then interleave those as:
> 
> abcabcabc
> 
> over a given time period with the interleaving determined by the ts
> buffer model.

yes


> There is no way of interleaving packets at a mux level
> like that temporally in libavformat.

I cant make sense of this sentance


> This is the main reason why the
> ts mux has never been spec compliant. (I await some form of glorious
> hack to fit in with the current API)

IMHO mpeg-TS is not spec compliant because
1. the code is not maintained (yeah noone working on it kind of
   means noone working on it)
2. There are practically no bug reports that would allow
   fixing issues without having access to some kind of stream analyzer
   that I dont have. Or said differently, if we know where _exactly_
   in the bitstream we break which part of the spec, it shouldnt be
   hard to fix.

Iam still quite curious what the problem with the API is and how a
different API could help?
That is when theres no volunteer to fix the incorrect interleaving
in the mpeg-ts muxer.
One surely can find a different way to submit packets, bytes, bits
or other to the muxer but ultimately the muxer has to interleave it
in line with the specification.
If a change to the API makes fixing the muxer simpler iam all for it.
but i disagere that theres a big issue in the API and a small issue
in the muxer. Actually iam still curious how a change to the API
can help at all? Could you elaborate on what issue the API has and
what alternative API would be in which way better?

Thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130416/886bfe58/attachment.asc>