On Tue, Mar 10, 2015 at 02:09:10PM +0100, Nicolas George wrote: > Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit : > > Please add a reference to ticket #3268 > > to the commit message. > > I was about to reply "locally added", but no, because it does not fix that > ticket.
what is the problem ? can you elaborate? > > Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This > part of the code is an API, not an UI, so it is better if it is strict. I > will try to propose another patch for pure validation. > > Regarding the trac ticket itself, I wrote this, and I stick to it: > > # I am not in favour of fixing the shortcomings of the user's shell in > # FFmpeg's libraries > > # If we are talking about end-user interface, the changes should happen in > # cmdutils.c. > > In other words, I vote for closing #3268 as WONTFIX and suggesting windows > users to use a better shell (maybe the so-called powershell introduced in > the recent windows versions can do it). theres a bug in OUR code it should be fixed in our code. The line ending characters differ between platforms and users do in general not know about these differences nor should they need to. the command line input will in the overwhelming number of cases be in the platforms native "line ending encoding". the strings passed on API level will certainly often be in the platforms native encoding as well, in the case of headers they might be in the CRLF encoding too, and considering that these are generic options, some applications will export them generically and not have special cases to re encode the strings, and i think quite independant of the option passing API. > > If people really want to fix microsoft's shortcomings in FFmpeg, then it > must happen in the UI, not the API, i.e. in cmdutils.c. Maybe something like > that: "ffmpeg ... -expand -headers 'Cookies: chocolate\r\n'" (-expand being > a new option meaning "perform escape-character expansion on the following > option argument"). But I do not intend to work on it, because anybody can > get a shell where $'\r\n' works. I think thats alot of effort on the users part you ask here for IMO User interfaces should be designed so they do what the user wants with minimun effort on the users part. Aka i belive its not the human who should have to adapt to interface to a computer (in the extreemest case that would be flipping bits one by one in memory) but rather the computer should adapt to how humans interact where it is possible and works reliable [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
