[FFmpeg-devel] [PATCH] lavc: support subtitles charset conversion.

Nicolas George nicolas.george at normalesup.org
Fri Jan 4 16:06:02 CET 2013

Le quintidi 15 nivôse, an CCXXI, Clement Boesch a écrit :
> I was simpling thinking of a flag saying that the pkt->data can be
> re-coded to UTF-8; basically what we will do for every simple text
> decoders, except those outputting UTF-8 only (like WebVTT iirc, or even
> TED, where nothing is needed).

I still find it a bit ad-hoc and inelegant to put inside the codec
structure. Setting a flag in the context structure from the codec init
function seems much more elegant.

Also, extending the AVCodec structure or using a bit in the capability field
has a larger risk of causing compatibility trouble with the fork, whereas we
already have the framework for this case in AVCodecContext.

> If a codec supports the several-encoding thing (wtf?), it should be
> handled inside the decoder itself IMO.


> Post conversion for teletext? I suggest the decoder should output directly
> in UTF-8.

Assuming it can. Teletext is an industrial standard, and as such probably
badly designed: I would not be surprised that some variant of it use legacy
encodings without declaration.

> Writing garbage? The original packet data is maintained untouched.

That is exactly the problem: the user asked to convert the encoding, and
lavc did not. You can expect decoding failures (if the decoder is not
capable of handling the data), truncated output (if a stray 0 stops the
decoder) or any thing of the sort. Worse: since the failure can happen for
some packets but not all, the output file may mix correctly transcoded
packets and garbled ones.

> Added a FIXME.



  Nicolas George
-------------- 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/20130104/b38176d9/attachment.asc>

More information about the ffmpeg-devel mailing list