On Thu, 23 Oct 2014 17:12:40 +0200 Michael Niedermayer <michae...@gmx.at> wrote:
> On Thu, Oct 23, 2014 at 04:18:29PM +0200, wm4 wrote: > > On Thu, 23 Oct 2014 16:12:52 +0200 > > Nicolas George <geo...@nsup.org> wrote: > > > > > Le duodi 2 brumaire, an CCXXIII, wm4 a écrit : > > > > I kind of disagree. > > > > > > I kind of have gathered that. > > > > > > > With your approach, all data gets (potentially) > > > > trashed on opening, and it's hard to change the encoding afterwards. > > > > You'd have to reopen the demuxer. And then you'd have to somehow cache > > > > all input data (but only when you open subs), unless you're fine with > > > > re-reading all data, etc.... > > > > > > I will ignore that irrelevant nonsense and all subsequent similar content, > > > as it only shows that you still have made no effort to understand the API > > > I > > > propose as it should be used instead of trying to map it on your incorrect > > > assumptions. > > > > I understand your API extremely well, and I'm telling you it's > > shortsighted. > > I dont understand either side or the proposed API nearly well enough > to really argue about this but iam concerned that this fight could > lead to a deadlock again and noone implementing any API, which would > be a loss to all. > > Do i understad correctly that the dispute here is about the following > scenario? > There is some input over a slow channel with interleaved subtitles No, plaintext subtitles. > There are subtitles in the first 10min but they use almost only > characters which have a identical encoding in multiple char-encodings > thus making distingushing the encoding&charset impossible. > at 11 minutes into the movie theres a subtitle with text that allows > identifying the encoding & charset > We need to demux, decode and display the subtitles before we have > enough information to finally know the exact encoding/charset and > once known update/set it. > ? > > and wm4s concern is that this would not work in the API that Nicolas > envissions, while Nicolas belives theres no problem and that will > just work fine once the API is finished ? > > Or maybe iam totally wrong. > But i think generally and IMHO > Whoever implements the API should decide how its implemented. > The oppinions, concerns and wishes of API users should be considered > and supported, and sometimes its easier and less work to support > something than to argue about it being useful. > API users are important > > This also reminds me a bit about AVFMT_FLAG_NOFILLIN, which ive always > had the feeling is not really usefull but many people wanted it, its > quite possible i was wrong and it is usefull for some. > > > Thanks > > [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel