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

[Kieran Kunhya]

(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.

The fact is that TS is an exceptionally flexible container 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. 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. 

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.

There's also the question of MPTSs which afaik isn't possible with the current 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.

Also I do intend to contribute to lavf/lavc; I am in the process of writing a "non-PCM audio stored in PCM" (smpte 337) demuxer as part of a Dolby E decoder and will do the same for the ts demuxer once I get a copy of the specs.

To follow on with your nice bridge analogy, people may want different bridges for different uses, perhaps some more aesthetically pleasing than others; others being simple footbridges while someone might want a tunnel or even a ferry.