[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