[FFmpeg-user] Drawtext filter
shop at open-t.co.uk
Mon Mar 28 01:50:27 CEST 2011
On 03/27/2011 06:07 PM, Stefano Sabatini wrote:
> On date Sunday 2011-03-27 16:36:59 +0100, Sebastian Arcus encoded:
>>>> 3. If I use "text" and "fontfile" and "x" and "y" arguments, still
>>>> no error and still no snow.
>>> Same, x and y are optional, and default to 0.
>> That's exactly my point. It doesn't seem that the defaults work
>> properly. Above, I meant, even if I give appropriate values to
>> "text", "fontfile", "x" and "y" arguments - the text still doesn't
>> show in the video - but there is no error either.
> Are you sure that x and y don't specify a position *outside* the
x was 30 and y was 50. On a 640x480 video that should work fine,
shouldn't it? I will re-run the tests again and make doubly sure.
>>>> Also - the text shows upside down in the video - I have no idea why.
>>> Please provide commandline so that I can reproduce it.
>> ffmpeg -fflags +genpts -t 600 -f mjpeg -r 5 -s 640x480 \
>> -i http://localhost:808$4/?action=stream -vcodec mpeg4 \
>> -vf drawtext="fontfile=mitra.ttf:x=40:y=430: \
>> text='test': \
>> fontcolor=0xFFFFFFFF:fontsize=22: \
>> shadowcolor=0x000000EE:shadowx=2:shadowy=2" \
>> -b 1000000 -r 5 /var/myapp/testvideo.avi
>> The input for the above is an mjpeg stream from mjpg_streamer (which
>> comes from a usb webcam).
> I can't reproduce here (the "upside down" issue). Are you sure that
> there is not a problem in the input file in the first place?
I think I have figured out the upside down problem. The mjpeg stream
comes from mjpg_streamer - from a webcam which actually *is* upside
down. In my calculations, because the camera was upside down, I figured
that the text overlay by drawtext should have been upside down as well.
So when I saw that it was the right way up (on an upside down video) - I
thought it was wrong. But, I think, it is right, because the overlay
doesn't happen at the point of capture (in the camera) - so the camera
video and the overlay don't need to be sync in terms of which way is up.
Or at least I think it is correct - I find it all very confusing now -
which way it should be. I will re-run the tests with the camera the
right way up.
I will find some time tomorrow and double check all the problems I've
mentioned - and log bugs for the ones which can't be explained any other
Thanks again for taking the time to look into these problems.
> Can you show a minimal command which issue the problem, whatever the
> input file is?
> Thanks for the report.
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user