Re: [FFmpeg-devel] lavu: add text encoding conversion API

2015-09-24 Thread Nicolas George
Le duodi 2 vendémiaire, an CCXXIV, James Darnley a écrit :
> At first I was wondering how FFmpeg would have a non-optional part of
> the API if you depend on optional things such as iconv.  I was half
> prepared to rant about NIH and seriously wondering what was going to be
> proposed.
> 
> I think I see now that you are proposing a wrapper around other
> libraries.  Other than iconv I assume Windows has its own char encoding
> features which would likely be used here.

Well, I intend to have a built-in converter that handles UTF-8, ISO-8859-1,
UTF-16, UCS-2 and UCS-4, because that is very easy and quite convenient as a
fallback for systems lacking proper conversion libraries. But I definitely
do not intend to embed in lavu all the tables needed to convert from/to
legacy encodings.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] lavu: add text encoding conversion API

2015-09-23 Thread James Darnley
On 2015-09-23 19:28, Nicolas George wrote:
> Hi.
> 
> This is a proposal for an API in libavutil to perform text encoding
> conversions. I had it in mind to clean up the subtitles code initially, and
> now it could be useful for James' proposal about metadata. The issues are
> relying on the optional system feature iconv, clumsy and annoying buffer
> management, handling of errors and replacement characters.
> 
> For now, this is just the API, not as a patch with the code, but I suspect
> designing the API cleanly is way harder than implementing it.
> 
> The API would go in, probably, textconv.h, with the opaque parts in
> textconv.c. The structures are in logical order, not in the order required
> for compilation.
> 
> Please comment.

At first I was wondering how FFmpeg would have a non-optional part of
the API if you depend on optional things such as iconv.  I was half
prepared to rant about NIH and seriously wondering what was going to be
proposed.

I think I see now that you are proposing a wrapper around other
libraries.  Other than iconv I assume Windows has its own char encoding
features which would likely be used here.

I don't have much of an opinion just yet.  It looks fairly reasonable
and a decent wrapper around iconv.  One immediate problem I see comes
from trying to store negative numbers in an unsigned integer. :)




signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel