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

Nicolas George nicolas.george at normalesup.org
Mon Feb 4 17:56:49 CET 2013


Le quintidi 15 pluviôse, an CCXXI, Alexander Strasser a écrit :
>   I think Clément's last patch minus the removals in the attached
> patch would be ready for commit. Did you think about this specific
> use case again? Converting text sub encoding prior decoding in lavc?
> The changes I suggest just remove the mode stuff for now. Maybe we
> will not need it. Seems to brittle to me at this point. Also if it
> is only meant to be used internally we could add it again once we
> need it.
> 
>   The functionality would only be exposed via API so far. Integrating
> in ffmpeg tools would still have to be discussed.
> 
>   I would suggest further changes, but I think they could go on
> top later.
> 
>   I tested as it is now it allows API users to recode e.g. subs in
> mkv files that have been stored in say UTF-16. I know this is against
> Matroska spec but it might happen and the container format is not the
> point of this functionality anway. I am just using it as an example,
> the container could well be something completely different.
> 
>   I am not suggesting to immediately commit or something, I just want
> to know if you agree to this route in princinple and would not have
> concerns about the mentioned code going into git master at some point.

Your solution does not allow to demux subtitles packets from a UTF-16 SRT
file, keep the information of the original encoding in the proper field but
not recode the subtitles twice. That is exactly what the mode stuff is for,
and I think this is mandatory for a correctly designed API.

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/20130204/f217aee3/attachment.asc>


More information about the ffmpeg-devel mailing list