On Sat, 13 Dec 2014 12:34:28 +0100 Nicolas George <geo...@nsup.org> wrote:
> First, your patch seems to happen after the text demuxers have parsed the > text files. Therefore, this can not work for non-ASCII-compatible encodings, > such as UTF-16. You might say that UTF-16 already works, but its > implementation is bogus and leads to user-visible problems (see trac ticket > #4059). But even if it was not, we would not want two competing detection > layers. For someone who complains about "bickering and lack of enthusiasm" you sure bicker and discourage a lot. What about it is bogus? #4059 is a problem with ffmpeg.c and the stuff in lavc, not the general approach. In fact, the UTF-16 change made UTF-16 just work with any API user. Recoding in the demuxer is unacceptable, because it makes it impossible to change the codepage later or get any kind of user interaction. Doing it on file opening unnecessarily complicates these things. Detection can't be done in lavc (and the way lavc does recoding, with fatal errors on failure, is also plain unacceptable). I agree with the comment though that ffmpeg isn't going to be linked to all these fancy detection mechanisms. This is mostly because you have to enable external libraries explicitly when compiling, so usually they won't be picked up. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
