Opened 8 months ago

Closed 8 months ago

Last modified 8 months 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 8 months 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 8 months 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 8 months ago by happyboy678 (previous) (diff)

comment:3 Changed 8 months 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 8 months 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 8 months 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 8 months 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.