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

[Michael Niedermayer]

On Thu, Aug 08, 2013 at 10:05:34AM +0200, Nicolas George wrote:
> 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.

i maintain multiple fate clients that have no iconv, not that it
matters much for the discussion here


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

If theres a developer who wants/needs a feature and is willing to
implement & maintain it then i will merge his work. (given its clean,
not buggy and iam aware of its existence and all that)

(there are a few corner cases where i wont but "returning the data as
 it is without mangling" (invalid if thats how it is)) is not one of
them

No developer should be able to block anothers work.
I thought disros like debian had such a rule and wanted to quote it
but seems i cant find it. Doesnt matter as i can speak myself what i
mean and i hope/belive thats a "rule" almost everyone agrees with.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/7ba53976/attachment.asc>