[FFmpeg-devel] DVBSUBS and TXTSUBS

[Clément Bœsch]

On Tue, May 22, 2012 at 08:19:18PM +0200, Michael Niedermayer wrote:
> On Tue, May 22, 2012 at 06:52:54PM +0200, Clément Bœsch wrote:
> > On Tue, May 22, 2012 at 04:45:43PM +0200, Michael Niedermayer wrote:
> > > On Fri, May 18, 2012 at 07:43:51AM +0100, JULIAN GARDNER wrote:
> > > > I was wondering what the current situation is with regards to the decode chain, is there any point in my re-porting my "HARD SUBS" to the current git, we are still using 33000 on channels that need burned in subtitles.
> > > > 
> > > > I was also looking at getting subtitles working but the source would be teletext, a simple txt decoder, just for the subtitle pages.
> > > 
> > > i think there where no major changes, but maybe ubitux, iive or some
> > > other subtitle experts could comment ?
> > > 
> > 
> > This comment from Nicolas in the Trac summarizes pretty well the
> > situation: https://ffmpeg.org/trac/ffmpeg/ticket/1305#comment:2
> > 
> > Now that things seem to calm down with the audio in lavfi, we might want
> > to consider working again on subtitles to do the burning in lavfi (and
> > various other changes).
> >
> 
> > But before I start working on "architecture" stuff like this, I'd like to
> > check if Libav won't plan to rewrite everything differently in a few
> > months, like they did for the audio processing, audio filtering and now
> > writers in ffprobe.
> 
> i can tell you already now libav will probably
> 
> but why is this a problem ?
> 
> Code and design is written in ffmpeg to the best of our abilities.
> We are human and not everything will be perfect. "Libav" will take
> our code a few month later and change it randomly (while loosing some
> names from copyright statements).
> Some of these changes will be improvments, some
> will be just equivalent changes and some will be worse.
> We will merge the ones that are better and the ones that are equivalent
> to keep differences small.

This is OK as long as we are not messing with the public API like what
happens with audio filtering. It's really annoying for the users...

> This certainly isnt perfect and manpower could be used more efficiently
> but libav is working for ffmpeg and they have no choice at all.
> Whenever they do something better than we i switch to their code.
> Whenever they are worse i dont
> So, its not that bad IMO
> 

> OTOH if we stop working on some part and just leave it to libav, do
> you really think quality will be at the same level ?
> 

I agree with this, we should continue improving FFmpeg the best we can.

I'm just a bit reluctant to do design stuff that is likely to be trashed
because Libav "prefers it this way", but don't understand this as a "no I
won't do it". That stupid Libav behaviour just strengthen my choice of
working for FFmpeg, even though that's f** frustrating.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120522/3a586b50/attachment.asc>