When executing the command grep blackdetect 01.txt
on this file, the output I get depends on the width of the terminal, which seems kinda strange to me.
The output in zshell with a width of 79 or less gives:
frame= 1 fps=0.0 q=-0.0 size=N/A time=00:00:00.01 bitrate=N/A speed=0.671x frame= 358 fps=0.0 q=-0.0 size=N/A time=00:00:06.44 bitrate=N/A speed=12.2x [blackdetect @ 0x7fb809109300] black_start:6.7329 black_end:6.7689 black_duration:0.0360048
With a width of 80 it gives:
frame= 1 fps=0.0 q=-0.0 size=N/A time=00:00:00.01 bitrate=N/A speed=0.671x [blackdetect @ 0x7fb809109300] black_start:6.7329 black_end:6.7689 black_duration:0.0360048
With a width of 81 and above it gives the result that I think should be the correct one:
[blackdetect @ 0x7fb809109300] black_start:6.7329 black_end:6.7689 black_duration:0.0360048
I am very confused by this result, what is going on here and how can I fix this?
The *.txt
-file is created by running ffmpeg
and piping stderr to the file.
System details: Hardware: MacBook Pro 2015 Operating system: macOS Big Sur (version 11.5.2) (most recent update) Processor: Intel Core i7, 2,2GHz Quard-Core
My suspicion is that your output contains Carriage Return (CR) characters (0x0D
, \r
) which moves the cursor to the beginning of the line without advancing to the next line. This is the beginning of the line in the terminal, not the beginning of the output line. From your output, it looks like there is one in front of the word [blackdetect @ 0x7fb80909300]
but it is likely that there are more.
You can visualize the CR using cat -vET
where it will be converted to a ^M
combination.
$ command | cat -vET`
You can see the effects of a CR and the terminal width with the following simple example:
$ a=$(printf "%s" {0..9})
$ echo $a$a$a$'\r'$a
With a terminal width of 23, the output looks like:
012345678901234567890123
0123456789
where you clearly see that the characters 456789
are missing from the second line.
Related: How to replace carriage return without new line in FFmpeg output thanks to sed?