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

[Nicolas George]

Le tridi 13 fructidor, an CCXXI, Reimar Döffinger a écrit :
> 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.

I am not sure I understand correctly the scenario you are suggesting.

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

That is true to some extent, but not completely: for sample formats, there
are no endianness variants: all samples are in native endianness, and raw
PCM is byte-swapped as needed.

The API would be much more convenient if all the pixel and sample formats
were hidden, if there was a single type for all operations. But for various
reasons (performance, accuracy), it is absolutely not possible. These
considerations do not apply to text.

> 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
> decoding?
> 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

They can. They already can, and I do not intend to change that. All they
have to do is do it properly, which means (1) taking sub_charenc_mode into
consideration and updating its value and (2) working on the packet payload
and not on the decoded text.

> to possibly know the charset before even starting to decode?

Again, I do not know what problem you are thinking of. The UTF-8 check
performed by lavc is very simple, any application can duplicate it (I
proposed to make it public, but you were against it).

> 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

I am running out of patience with some people in this discussion, but you
are absolutely not one of them.

> strongly resist giving (and to a reasonable degree avoiding breaking) such
> an option?

I resist giving this option because I believe this option is unnecessary:
all needs are already met by the lavc API without it. It's like asking for a
crowbar to open a box when there is already a lid on the other side.

I will completely stop objecting to this kind of option if someone shows a
situation where it is necessary. It has not happened yet.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130830/94c1b3e9/attachment.asc>