Opened 2 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#6883 closed defect (invalid)

[Bug] drawtext ... text='%{localtime}' get wrong second

Reported by: happyboy678 Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
How to reproduce:

Hi Sir,

OS:MS Windows 7 X64.
Ver:
2017/11/28 PM 09:46 11,267,072 ffmpeg.exe
ffmpeg version N-89310-g86cead5256

When i use drawtext ... text='%{localtime}' get wrong second.

Thank you.

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (6)

comment:1 Changed 2 weeks ago by cehoyos

Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

comment:2 Changed 2 weeks ago by happyboy678

command line:

ffmpeg -i TEST.mp4 -c:v libx265 -c:a copy -vf "drawtext=fontfile=tahoma.ttf:fontsize=50:fontcolor=Red:x=10:y=10:text='%{localtime}'" TEST_Out.mp4

ffmpeg -i TEST.mp4 -vf "drawtext=fontfile=tahoma.ttf:fontsize=50:fontcolor=Red:x=10:y=10:text='%{localtime}'" TEST_Out.mp4

Last edited 2 weeks ago by happyboy678 (previous) (diff)

comment:3 Changed 2 weeks ago by llogan

You forgot to include the complete console output from your ffmpeg command as requested. What exactly is wrong with the localtime output?

comment:4 Changed 2 weeks ago by happyboy678

I can NOT upload picture file.

1.command line 1
When -c:v libx265,the second is very very FAST.

2.command line 2
"Sometime" the second is fast,it is not stable.

comment:5 Changed 2 weeks ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

Please reopen this ticket if you can provide (paste) the command you tested together with the complete, uncut console output.

comment:6 Changed 2 weeks ago by llogan

  • Resolution changed from needs_more_info to invalid

localtime is the "time at which the filter is running". If your process is not occurring at realtime then the printed output will be faster or slower depending on the speed of the filter process. This is the documented and expected behavior so I believe this is not a bug.

Feel free to ask the ffmpeg-user mailing list if you need help to print whatever timestamp you need.

Note: See TracTickets for help on using tickets.