[FFmpeg-devel] [PATCH] libavcodec: Do not return encoding errors when -sub_charenc_mode is do_nothing

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Aug 30 21:11:43 CEST 2013

On Fri, Aug 30, 2013 at 12:24:24PM +0200, Nicolas George wrote:
> Once again, exactly the same arguments that I have already discussed at
> least twice.
> Le tridi 13 fructidor, an CCXXI, wm4 a écrit :
> > Your simplistic patch (the text file one you sent to this list some
> > time ago) would be a disimprovement. It completely takes the control
> > over how charsets can be selected from the application, and replaces it
> Not true. The application can control the selected encoding, that is a core
> feature of the code.

You are only half-right, IMHO.
The application can only control it if it knows it ahead of time.
It cannot change it if it figures it only out after the fact.
This cannot even be helped by the currently available probing to my
knowledge, since the probe code cannot run the full subtitle decoder.
However there are other questions IMHO.
For example, why (API considerations and convenience aside) character
set conversion should even be part of the subtitle decoding.
We do not do sample format/color format conversion inside the
audio/video decoders either for example.
More importantly, why should we _hinder_ applications from doing
their own conversion, in their own way?
As far as I can see all that's requested is to allow applications
to do their own. We do not force applications to use libavformat
to use libavcodec, we do not force them to use libswscale in order
to be able to use libavcodec etc., why should they have to use
our charset conversion if they want to use libavcodec for subtitle
You say it would result in double conversion after the changes you
plan, well ok, but can't you do those changes in a way that allows
applications to still just get the data out as it is, instead of forcing
them both to use our charset conversion and to possibly know the charset before
even starting to decode?
While I understand you running out of patience, and also agree that some
of the proposals aren't really good, I don't really
understand why you so strongly resist giving (and to a reasonable
degree avoiding breaking) such an option?

More information about the ffmpeg-devel mailing list