[FFmpeg-devel] ts mux satus ?
Kieran Kunhya
kierank at ob-encoder.com
Tue Apr 16 19:41:24 CEST 2013
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.
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. There is no way of interleaving packets at a mux level
like that temporally in libavformat. 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)
There are other lesser issues with regards to PTS handling in MPEG
codecs but that's probably fixable whereas the above is an inherent
issue that makes ts the special case.
More information about the ffmpeg-devel
mailing list