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

Michael Niedermayer michaelni at gmx.at
Fri Jun 28 23:22:29 CEST 2013


On Fri, Jun 28, 2013 at 10:00:14PM +0200, Nicolas George wrote:
> Le decadi 10 messidor, an CCXXI, Michael Niedermayer a écrit :
> > I cant awnser the question about the scenarios wm4 and others had in
> > mind but one scenario that i see is a simple player that displays
> > subtitles.
> > 
> > the user starts the player by clicking on a media file.
> > It displays subs as partial gibberish, like messed up umlauts, the
> > user sees that and hits the cycle encoding or choose encoding button
> > the user is able to guess from the messed up subtitles what the correct
> > encoding is
> > 
> > OTOH
> > if theres just an error return the user lacks feedback, if theres
> 
> The error return is from the library to the application, not to the user
> directly.

exactly, the user wuld by default not know at all whats wrong
the application would needs to check for that and tell the user.
The user would need to read and understand it.
Will any applications do that ?
Are there any application maintainers who like this approuch ?


> 
> > an error in the terminal window it will not be seen by 99% of the users
> > people use touch screens on theit phones there are no terminal windows
> > and the rest use mice with GUI based players.
> > A player would need specific code to detect this error case and
> > notify the user or take some automated action, that means extra code
> > in the player, while for the above case of simply displying giberish
> > no extra code is needed in the player
> 
> The player needs specific code to allow the user to select the character
> encoding.

not strictly but yes mostly


> The code to handle the error to open the corresponding popup is
> negligible with regards to that.

i disagree, its red tape that would be needed by litterally every
application. the API is complex enough as it is.
Also it complicates the problem for the user

With the solution proposed by wm4 wrong charset -> wrongly displayed
subs -> user sees that and acts based on what he sees, he can possibly
guess the encoding from the kind of gibberish seen.

With your solution (the way i understand it) theres a X chance that
an error is returned by the library that with a <X chance will cause
the application to show a popup or other player specific information
to the user that will give the user no easy indication of which encoding
is the correct one. And still theres a 1-X chance of wrongly displayed
subs. So there are 2 different instead of 1 results that the problem
can produce. And in some cases no indication of a problem at all when
the player doesnt hanlde the error
That doesnt look simpler or better at all.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20130628/8450226e/attachment.asc>


More information about the ffmpeg-devel mailing list