[FFmpeg-user] Drawtext filter

Sebastian Arcus 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:

[/snip]

>>>
>>>> 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
> screen?

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.

[/snip]

>
>>>> 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 
way.

Thanks again for taking the time to look into these problems.

Sebastian

>
> 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
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>


More information about the ffmpeg-user mailing list