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

Derek Buitenhuis derek.buitenhuis at gmail.com
Thu Jun 27 20:27:41 CEST 2013

On 2013-06-27 2:05 PM, Nicolas George wrote:
>> 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.

Sorry, I agree with wm4 here. A generic error code like AVERROR_INVALIDDATA
is utterly useless to an application that wants to display subtitles.

I am inclined to agree with his patch -- it should be a warning, not an

Furthermore, is our subtitle code so incredibly bad that its only choice
upon finding such a subtitle to drop it? Really? That's both sad and retarded.

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


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

No, but you sure need to take into account what uses your API
and what a sane way to behave for these are, when you are designing
the way an API behaves. I know it's unfashionable to make usable
API decisions for libav*, but come on.

>> 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.

It may as well be.

>> When was the last time you had a text editor remove a line and print a
>> log messages on the terminal if a line contained broken data?
> A text editor is not a library. For what it is worth, my text editor
> occasionally refuses to save files because of encoding problems that I need
> to resolve manually. This is the only reasonable behaviour.

I think you'll find most normal (non-UNIX-neckbeard) people will disagree.

- Derek

More information about the ffmpeg-devel mailing list