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

[Michael Niedermayer]

On Sat, Jan 30, 2010 at 02:16:08AM -0800, 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.
> 
> 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. 

elaborate please, what is why not possible in the lavf framework?


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

what exactly is needed by the muxer?


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

elaborate please on what is supposed to be not possible


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

contributions are always welcome!


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

why do i have the feeling this is leading to a boat without paddles, a tunnel
that is flooded and a bridge with a missing section in the middle. 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100130/3ed65fc4/attachment.pgp>