[FFmpeg-devel] Google Summer of Code 2010 is coming
Sat Jan 30 22:27:04 CET 2010
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
> 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
Humm, I thought it required heavy x264 integration ?
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel