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

[Paul B Mahol]

On 8/30/13, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le tridi 13 fructidor, an CCXXI, Reimar Doeffinger a ecrit :
>> 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.

Oh, it already happened multiple times.

>
> Regards,
>
> --
>   Nicolas George
>