[FFmpeg-devel] [PATCH] libavcodec: Do not return encoding errors when -sub_charenc_mode is do_nothing
eelco at lempsink.nl
Thu Aug 29 16:03:34 CEST 2013
On 29 aug. 2013, at 14:03, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le duodi 12 fructidor, an CCXXI, Eelco Lempsink a écrit :
>> How about this:
>> - Rename the ‘do_nothing’ option to ‘assume_utf8’.
>> - Add a ‘passthrough’ option.
>> Would that be an acceptable patch?
> This is not how things are supposed to work in this case. Let me explain the
> plan once, because the whole thing is split in several mail discussions.
Thanks for your explanation. Now I understand the underlying idea, I would prefer that FFmpeg would exit with an error state, though, since now it’s unclear that data is missing when using FFmpeg in a larger workflow where warnings might get lost in the noise. It’s a matter of taste though, I like things threaten data integrity to fail as early and hard as possible.
I’m also curious to hear how you plan to handle the encoding detection (e.g. for an SRT file) or if you think that’s the responsibility of the user.
> But I suggest you describe your use case before that, because I suspect
> that, even right now, you can do what you need without this option.
Hmm, you might be correct. We’re using FFmpeg for two things: extracting embedded text-based subtitles as SRT and for normalizing SRTs.
For the normalizing (basically using the FFmpeg SRT parser to filter problems in the SRT) it would be possible to do the encoding detection on the input rather than the output. That way we can ensure UTF8 goes in and comes out, so that should be no problem.
As far as the extracting goes, I suppose the encoding information is either embedded in the format or defined in the format’s specification. I’m not entirely sure that all formats and tools can be trusted though. The solution would be to first dump the text-based subtitles in a raw format, do the encoding detection and then feed it back to FFmpeg to create the SRT, correct?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the ffmpeg-devel