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

[Nicolas George]

Le quintidi 15 nivôse, an CCXXI, Clement Boesch a écrit :
> I fail to see how it is more elegant; the codec properties sounds like the
> best place to declare such generalities.

It is hard tu put elegance considerations into words. Looking at the various
existing CODEC_CAP, I find they are usually more universal and/or more
relevant to the API user, although I realize there are already exceptions.

>					   Using the context structure is
> only a necessity if we need on the fly changes, which don't sound common
> at all. And if we find such insanity, I'd suggest to fix that mess in the
> decoder or the demuxer itself.

What about this, that I thought of this morning:

Sometimes, the recoding will be perforce be done by the demuxer. At other
times, it will be done by lavc. In any case, the original encoding should be
exposed to the API caller, so that this:

ffmpeg -ss 5 -i file.fmt [ -sub_charenc copy ] shifted_file.fmt

can work. And for convenience and compatibility reasons, it is probably be
best if the original encoding is exported in the same field.

Thus my proposal with sub_charenc_mode and the first component that decides
it can do the work sets it. That would work like that:

1. If the demuxer knows the character encoding, it sets sub_charenc.
2. If the demuxer does the recoding, then it sets sub_charenc_mode to DONE,
   otherwise it leaves it to its default 0.
3. If mode is still 0, the codec init function sets it to either PRE, POST
   or INTERNAL depending on its need.
4. If mode is still 0 after codec init and a character encoding is set, lavc
   reports an error.

You could add the rule:

2.9. If mode is still 0 and the codec has CAP_PRE_RECODE, set mode to PRE.

That would obviously work, but that seems more API-disruptive, and that
makes more places that can set the mode, thus more code to understand for an
outsider.

> I'd better hear about someone implementing it instead of trying to
> suppose how crazy it can be.

I agree that too much speculating is not good, but if we have two solutions
that are more or less equivalent in terms of complexity, choosing the one
that will be able to deal with crazy situations seems a good way of solving
the dilemma.

> Well, I see it more like a postproc filter (which has in mplayer a mode
> where it is automatically disabled if the cpu is too slow). In a lot of
> cases, not doing the character re-encoding doesn't hurt that much
> readability.

You are obviously neither Greek, Russian or Japanese ;-)

>	       That is the logic I followed, but of course I get your point
> and that will be fixed.

Thanks.

Regards,

-- 
  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/20130105/d704be63/attachment.asc>