[FFmpeg-devel] [PATCH] lavc: make invalid UTF-8 in subtitle output a non-fatal error

Nicolas George nicolas.george at normalesup.org
Thu Aug 8 10:05:34 CEST 2013


Le primidi 21 thermidor, an CCXXI, Clement Boesch a écrit :
> > Please elaborate. Auto-detection is not the solution, but it is part of the
> > solution. Software that ignore errors, like you propose, are part of the
> > problem.
> I think it's not a complete solution, because it's likely not reliable.

It is not a complete solution, it is part of the solution, that is exactly
what I wrote.

> Also note that currently, a build without iconv will prevent playback for
> some apps, and that solution will not solve anything.

That is easy to solve: build with iconv.

If someone has time to waste to support users too lazy to install libiconv
if necessary, they can implement a built-in support for basic conversion:
ISO-8859-1 and UTF-16 should be easy enough to implement in less than a few
hours, testing included.

> Now, what about the solution of making use of -strict experimental or
> whatever -sub_opt can_generate_broken_files so we can be done with the
> issue in third party playback apps and still keep the nazi behaviour in
> our transcoding app by default?

If your suggestion includes allowing lavc to return invalid UTF-8 data to
the application, then I am rather against it.

I have already explained, I believe, what I would consider not only an
acceptable solution, but actually a good default behaviour: implement the
equivalent for character encoding of error resilience.

It is pretty easy: it just requires to catch iconv errors and replace the
offending byte by a replacement character in the output string (the obvious
choice would be U+FFFD REPLACEMENT CHARACTER, a reverse-video question mark
in most fonts) before starting again the conversion.

I intend to implement that at some point, but after I finished the text file
API (note that I have started working on it again, despite having more
urgent things to take care of). If someone wants to do it right now, I have
no objection, quite the contrary.

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/20130808/e896af9f/attachment.asc>


More information about the ffmpeg-devel mailing list