[FFmpeg-devel] [PATCH] libavcodec: Do not return encoding errors when -sub_charenc_mode is do_nothing
nicolas.george at normalesup.org
Fri Aug 30 21:35:33 CEST 2013
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel