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

[Eelco Lempsink]

Hi Nicolas,

On 28 aug. 2013, at 23:41, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le primidi 11 fructidor, an CCXXI, Eelco Lempsink a écrit :
>> Signed-off-by: Eelco Lempsink <eml at tupil.com>
>> ---
>> libavcodec/utils.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
> 
> This is not what « do nothing » is meant for. It is meant for situations
> where the muxer already did the job, and the check to ensure that the job
> was done properly is still relevant.
> 
> If you want to bypass the check, please add a dedicated option, and clearly
> document that any application that uses it is misdesigned and will not work
> once the full recoding API is implemented.

First off, I’m really happy to see FFmpeg taking character encodings into consideration.  I honestly thought that ‘do_nothing’ meant something else, I didn’t mean to send a snark-patch.  (I only saw the previous discussion after I send the patch.)

That said, the current implementation is incomplete and does not belong in a release version, in my opinion.  When using FFmpeg in part of a larger workflow where character encodings are not known in advance, you simply need all the bits to properly guess the encoding.  Even when the recoding API is fully implemented there will be cases where FFmpeg will make the wrong guess (the alternative would be to wait until all the data is known and then make the guess, which would be a problem for streams).

I have some experience doing character encoding detection using libicu (http://site.icu-project.org) since that is what we currently use to process the output of FFmpeg, and I’d be happy to offer advice and help, if wanted.

How about this:
- Rename the ‘do_nothing’ option to ‘assume_utf8’.
- Add a ‘passthrough’ option.

Would that be an acceptable patch?

Regards,

Eelco Lempsink
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130829/a6f013d6/attachment.asc>