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

wm4 nfxjfg at googlemail.com
Thu Jun 27 20:43:38 CEST 2013


On Thu, 27 Jun 2013 20:05:14 +0200
Nicolas George <nicolas.george at normalesup.org> wrote:

> Le nonidi 9 messidor, an CCXXI, wm4 a écrit :
> > But it can't. ffmpeg just drops the event. The application doesn't
> > even know _what_ happened, unless it's grepping the log output.
> 
> That is not true. lavf returns an error code, that is exactly what it
> is supposed to do. The application is then free to handle the error
> code however it needs, including reconfiguring the decoder to bypass
> the error by using a catch-all encoding.

So it's supposed to retry decoding with other random codepages? I
wonder how well that works out with respect to getting correct output.
It's also complicated (decoding retry loops, ugh).

> Your proposal removes the error code, this is just plain wrong (bis).

Here's an alternative proposal: an option to disable the UTF-8 check
entirely. It can by default be disabled, so that the current behavior
is not changed by default. (Actually I wanted to write a patch for
this. I planned reusing the sub_charenc_mode option, but after
extending it, I couldn't find out how to actually set this option...)

> > Neither anything mplayer nor VLC do it by default.
> 
> This mailing-list is neither about MPlayer nor VLC.

I was just trying to bring in some software that has been dealing with
real-word subtitles for years. Conclusion: there is no nice solution.

> > Checking for UTF-8 is trivial (the application can do it with a
> > single function call), and ffmpeg indeed _forces_ a policy here:
> > that is, crash and burn on slightly broken input.
> 
> "Return an error code" and "crash and burn" are not the same thing.

They are equally impractical in some situations.


More information about the ffmpeg-devel mailing list