Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> i also found this comment in a patch in my inbox:
>
> + /* When using Standard C input functions, also check if there
> + is anything in the buffer. After a call to such functions,
> + the input waiting in the pipe will be copied to the buffer,
> + and the call to PeekNamedPipe can indicate no input available.
> + Setting stdin to unbuffered was not enough, IIRC */
> + if (stdin->_cnt > 0)
> + {
> + char ch;
> + //Read it
> + read(0, &ch, 1);
> + return ch;
> + }
>
> This seems to explain what the code was intended to do
That was my guess.
This is ugly, and should be removed anyways. It is not possible to mix stdio
and low-level reading like that, period.
Fortunately, ffmpeg.c only uses stdin at one single place, a few lines below
the corresponding code:
}else
if(scanf("%d", &debug)!=1)
fprintf(stderr,"error parsing debug value\n");
It needs to be changed to read a line with the low-level function
(read_key()), exactly like 40 above for the 'c' case. I can not brew a patch
right now, sorry.
I suspect this would not work:
printf 'd42\nC ... fontfile ...\n' | ffmpeg ...
because the C will end up in the stdio buffer.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
