[FFmpeg-devel] Google Summer of Code 2010 is coming

[Baptiste Coudurier]

On 1/30/10 2:16 AM, Kieran Kunhya wrote:
> (please be nice, it's my first ffmpeg-devel flame) ;)
>
> I'm the person writing the ts muxer.
>
>> of course not, its pure medical issue of the psychology part.
>> Something about hatered, undermining of common efforts, NIH
>> syndrom, ape courtship behaviour in the sense of "Look i got the
>> bigger muxer" That just sounds better if you stand alone with your
>>  big muxer standing out.
>
> There is none of this. This is just something I wanted to work on. As
> you will read later it will not be specifically part of x264.

Oh yeah ?

> The fact is that TS is an exceptionally flexible container

Not exceptionally. Some containers are more flexible.

> and there are people out there with diverse needs who will use TS.
> Putting it in lavf within the current API won't do it justice and
> only a narrow subset of potential users could actually use it.

Oh yeah, because it completely impossible to change API ? I thought
ffmpeg was changing API too much ? Now not enough ?

Any reason for the FLV muxer which is _extremely_ flexible and requires
an heavily tight integration with the encoder.

> For example a large European IPTV company requested a few minor
> changes which they want to put into production ASAP which would be
> impossible within the current hardcoded constraints of the lavf ts
> muxer.

Please elaborate.

> Also to be quite honest I'm not interested in handling things like
> MPEG-2 or Dirac as well as making sure countless broken files are
> muxed correctly. Also there's much easier access to HRD timing
> information from within x264.

And here you are missing one important feature, remuxing.

> There's also the question of MPTSs which afaik isn't possible with
> the current API.

Again see above about the API.

>> we now can watch in real time the same thing repeating, x264 gets
>> their own muxer that is designed to never work with anything but
>> x264 and ours is neiher fixed, improved nor replaced by a better
>
> The only "dependency" it has is that it uses x264's bitstream writer,
> which you could change in ten minutes. The rest is written using a
> public API.
>
> Furthermore, I intend to split this muxer up into libtsmux or
> whatever you want to call it because there are people out there with
>  more interesting needs. However, I want to do this when it's ready,
>  but conversely there are people who'd like to use it without much
> effort.

Humm, I thought it required heavy x264 integration ?

[...]

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org