[FFmpeg-devel] [PATCH] lavc: support subtitles charset conversion.
ubitux at gmail.com
Fri Jan 4 15:52:28 CET 2013
On Fri, Jan 04, 2013 at 11:58:51AM +0100, Nicolas George wrote:
> Le quintidi 15 nivôse, an CCXXI, Clement Boesch a écrit :
> > Adding a "support charset recoding" codec description property sounds like
> > the most simple and reliable thing to do.
> Simple, yes. Reliable... what if a codec supports several encodings in the
> same packet? Does it "support charset recoding" or not? And does it tell
> whether the conversion should be made PRE or POST (I strongly suspect that
> teletext will need POST)?
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).
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
> > Patch welcome? I'm not sure I want a fficonv…
> At some point, someone too lazy to install libiconv will propose it. But we
> are not obliged to encourage them.
> > av_new_packet does it
> I stand corrected.
> > Because it doesn't sound fatal.
> IMHO, silently writing garbage in the output is worse than fatal.
Writing garbage? The original packet data is maintained untouched.
> > And to be honest, because I need to do
> > larger changes to the code in this case (or use a goto, see the split
> > thing). It can be done in a later commit.
> At least, please add a warning and a comment.
Added a FIXME.
> > av_free_packet is used for the temporary packet created in the scope of
> > recode_subtitle in case of error, where its content is completely
> > unrelated to the local packet here. Here pkt_recoded is a copy of tmp, so
> > it shares also stuff like the extradata split, which we don't want to
> > destroy. The only thing that CAN differ from tmp is it's data/size,
> > allocated inside recode_subtitle. This is what we destroy here.
> Thanks for the explanation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the ffmpeg-devel