Skip to main content
Added note about disabling stdio buffering in pipeline
Source Link
Adrian
  • 2.8k
  • 1
  • 12
  • 11

Unfortunately, this means the entire set of progress updates looks to grep, ack and all other line-oriented tools as a single line. That's why they seem to "lock up" and print nothing until ffmpeg finishes.

Also unfortunately, and I can't think of a similar highlighting tool that operates on anything but a standard Unix line basis. 

You could try something like:

frame=   85 fps=0.0 q=28.0 size=       0kB time=00:00:03.79 bitrate=   0.1kbits/s dup=1 drop=0 speed=7.55x    
frame=  129 fps=129 q=28.0 size=       0kB time=00:00:05.65 bitrate=   0.1kbits/s dup=1 drop=0 speed=5.64x    
frame=  172 fps=111 q=28.0 size=     256kB time=00:00:07.42 bitrate= 282.6kbits/s dup=1 drop=0 speed=4.81x    
frame=  213 fps=104 q=28.0 size=     512kB time=00:00:09.17 bitrate= 457.3kbits/s dup=1 drop=0 speed=4.49x    
frame=  254 fps= 99 q=28.0 size=     512kB time=00:00:10.85 bitrate= 386.3kbits/s dup=1 drop=0 speed=4.22x    
frame=  295 fps= 96 q=28.0 size=     768kB time=00:00:12.56 bitrate= 500.7kbits/s dup=1 drop=0 speed=4.08x    
frame=  333 fps= 93 q=28.0 size=    1024kB time=00:00:14.14 bitrate= 593.1kbits/s dup=1 drop=0 speed=3.94x    
frame=  382 fps= 93 q=28.0 size=    1024kB time=00:00:16.19 bitrate= 518.1kbits/s dup=1 drop=0 speed=3.93x    
frame=  428 fps= 93 q=28.0 size=    1280kB time=00:00:18.11 bitrate= 579.0kbits/s dup=1 drop=0 speed=3.92x    
frame=  473 fps= 92 q=28.0 size=    1536kB time=00:00:20.00 bitrate= 628.9kbits/s dup=1 drop=0 speed=3.91x    
frame=  519 fps= 92 q=28.0 size=    1536kB time=00:00:21.93 bitrate= 573.8kbits/s dup=1 drop=0 speed= 3.9x    
frame=  567 fps= 92 q=28.0 size=    1792kB time=00:00:23.91 bitrate= 613.9kbits/s dup=1 drop=0 speed=3.89x    
frame=  601 fps= 90 q=28.0 size=    2048kB time=00:00:25.32 bitrate= 662.6kbits/s dup=1 drop=0 speed= 3.8x    
frame=  637 fps= 89 q=28.0 size=    2304kB time=00:00:26.83 bitrate= 703.3kbits/s dup=1 drop=0 speed=3.75x    
frame=  684 fps= 89 q=28.0 size=    2304kB time=00:00:28.77 bitrate= 655.9kbits/s dup=1 drop=0 speed=3.74x    
frame=  720 fps= 84 q=-1.0 size=    2924kB time=00:00:30.01 bitrate= 798.0kbits/s dup=1 drop=0 speed= 3.5x    
...

You'd probably also want to disable stdio buffering between the components in this pipeline for maximum responsivness:

stdbuf -o0 ffmpeg ... 2>&1 | stdbuf -i0 -o0 tr \\015 \\012 | stdbuf -i0 -o0 grep ...

Unfortunately, this means the entire set of progress updates looks to grep, ack and all other line-oriented tools as a single line. That's why they seem to "lock up" and print nothing until ffmpeg finishes.

Also unfortunately, I can't think of a similar highlighting tool that operates on anything but a standard Unix line basis. You could try something like:

frame=   85 fps=0.0 q=28.0 size=       0kB time=00:00:03.79 bitrate=   0.1kbits/s dup=1 drop=0 speed=7.55x    
frame=  129 fps=129 q=28.0 size=       0kB time=00:00:05.65 bitrate=   0.1kbits/s dup=1 drop=0 speed=5.64x    
frame=  172 fps=111 q=28.0 size=     256kB time=00:00:07.42 bitrate= 282.6kbits/s dup=1 drop=0 speed=4.81x    
frame=  213 fps=104 q=28.0 size=     512kB time=00:00:09.17 bitrate= 457.3kbits/s dup=1 drop=0 speed=4.49x    
frame=  254 fps= 99 q=28.0 size=     512kB time=00:00:10.85 bitrate= 386.3kbits/s dup=1 drop=0 speed=4.22x    
frame=  295 fps= 96 q=28.0 size=     768kB time=00:00:12.56 bitrate= 500.7kbits/s dup=1 drop=0 speed=4.08x    
frame=  333 fps= 93 q=28.0 size=    1024kB time=00:00:14.14 bitrate= 593.1kbits/s dup=1 drop=0 speed=3.94x    
frame=  382 fps= 93 q=28.0 size=    1024kB time=00:00:16.19 bitrate= 518.1kbits/s dup=1 drop=0 speed=3.93x    
frame=  428 fps= 93 q=28.0 size=    1280kB time=00:00:18.11 bitrate= 579.0kbits/s dup=1 drop=0 speed=3.92x    
frame=  473 fps= 92 q=28.0 size=    1536kB time=00:00:20.00 bitrate= 628.9kbits/s dup=1 drop=0 speed=3.91x    
frame=  519 fps= 92 q=28.0 size=    1536kB time=00:00:21.93 bitrate= 573.8kbits/s dup=1 drop=0 speed= 3.9x    
frame=  567 fps= 92 q=28.0 size=    1792kB time=00:00:23.91 bitrate= 613.9kbits/s dup=1 drop=0 speed=3.89x    
frame=  601 fps= 90 q=28.0 size=    2048kB time=00:00:25.32 bitrate= 662.6kbits/s dup=1 drop=0 speed= 3.8x    
frame=  637 fps= 89 q=28.0 size=    2304kB time=00:00:26.83 bitrate= 703.3kbits/s dup=1 drop=0 speed=3.75x    
frame=  684 fps= 89 q=28.0 size=    2304kB time=00:00:28.77 bitrate= 655.9kbits/s dup=1 drop=0 speed=3.74x    
frame=  720 fps= 84 q=-1.0 size=    2924kB time=00:00:30.01 bitrate= 798.0kbits/s dup=1 drop=0 speed= 3.5x    
...

Unfortunately, this means the entire set of progress updates looks to grep, ack and all other line-oriented tools as a single line. That's why they seem to "lock up" and print nothing until ffmpeg finishes, and I can't think of a similar highlighting tool that operates on anything but a standard Unix line basis. 

You could try something like:

frame=   85 fps=0.0 q=28.0 size=       0kB time=00:00:03.79 bitrate=   0.1kbits/s dup=1 drop=0 speed=7.55x    
frame=  129 fps=129 q=28.0 size=       0kB time=00:00:05.65 bitrate=   0.1kbits/s dup=1 drop=0 speed=5.64x    
frame=  172 fps=111 q=28.0 size=     256kB time=00:00:07.42 bitrate= 282.6kbits/s dup=1 drop=0 speed=4.81x    
frame=  213 fps=104 q=28.0 size=     512kB time=00:00:09.17 bitrate= 457.3kbits/s dup=1 drop=0 speed=4.49x    
frame=  254 fps= 99 q=28.0 size=     512kB time=00:00:10.85 bitrate= 386.3kbits/s dup=1 drop=0 speed=4.22x    
frame=  295 fps= 96 q=28.0 size=     768kB time=00:00:12.56 bitrate= 500.7kbits/s dup=1 drop=0 speed=4.08x    
frame=  333 fps= 93 q=28.0 size=    1024kB time=00:00:14.14 bitrate= 593.1kbits/s dup=1 drop=0 speed=3.94x    
frame=  382 fps= 93 q=28.0 size=    1024kB time=00:00:16.19 bitrate= 518.1kbits/s dup=1 drop=0 speed=3.93x    
frame=  428 fps= 93 q=28.0 size=    1280kB time=00:00:18.11 bitrate= 579.0kbits/s dup=1 drop=0 speed=3.92x    
frame=  473 fps= 92 q=28.0 size=    1536kB time=00:00:20.00 bitrate= 628.9kbits/s dup=1 drop=0 speed=3.91x    
frame=  519 fps= 92 q=28.0 size=    1536kB time=00:00:21.93 bitrate= 573.8kbits/s dup=1 drop=0 speed= 3.9x    
frame=  567 fps= 92 q=28.0 size=    1792kB time=00:00:23.91 bitrate= 613.9kbits/s dup=1 drop=0 speed=3.89x    
frame=  601 fps= 90 q=28.0 size=    2048kB time=00:00:25.32 bitrate= 662.6kbits/s dup=1 drop=0 speed= 3.8x    
frame=  637 fps= 89 q=28.0 size=    2304kB time=00:00:26.83 bitrate= 703.3kbits/s dup=1 drop=0 speed=3.75x    
frame=  684 fps= 89 q=28.0 size=    2304kB time=00:00:28.77 bitrate= 655.9kbits/s dup=1 drop=0 speed=3.74x    
frame=  720 fps= 84 q=-1.0 size=    2924kB time=00:00:30.01 bitrate= 798.0kbits/s dup=1 drop=0 speed= 3.5x    
...

You'd probably also want to disable stdio buffering between the components in this pipeline for maximum responsivness:

stdbuf -o0 ffmpeg ... 2>&1 | stdbuf -i0 -o0 tr \\015 \\012 | stdbuf -i0 -o0 grep ...
Source Link
Adrian
  • 2.8k
  • 1
  • 12
  • 11

The problem you're seeing is almost certainly due to the progress info being printed with CR (carriage-return, ASCII 13) line endings, instead of the traditional Unix LF (line-feed, ASCII 10). This is done to allow each new progress update to overprint the last.

Unfortunately, this means the entire set of progress updates looks to grep, ack and all other line-oriented tools as a single line. That's why they seem to "lock up" and print nothing until ffmpeg finishes.

Also unfortunately, I can't think of a similar highlighting tool that operates on anything but a standard Unix line basis. You could try something like:

ffmpeg ... | tr \\015 \\012 | grep ...

which transforms all CRs to LFs. This lets grep et al see each progress update as a separate line, at the cost of also seeing each update as a separate line, filling your terminal:

frame=   85 fps=0.0 q=28.0 size=       0kB time=00:00:03.79 bitrate=   0.1kbits/s dup=1 drop=0 speed=7.55x    
frame=  129 fps=129 q=28.0 size=       0kB time=00:00:05.65 bitrate=   0.1kbits/s dup=1 drop=0 speed=5.64x    
frame=  172 fps=111 q=28.0 size=     256kB time=00:00:07.42 bitrate= 282.6kbits/s dup=1 drop=0 speed=4.81x    
frame=  213 fps=104 q=28.0 size=     512kB time=00:00:09.17 bitrate= 457.3kbits/s dup=1 drop=0 speed=4.49x    
frame=  254 fps= 99 q=28.0 size=     512kB time=00:00:10.85 bitrate= 386.3kbits/s dup=1 drop=0 speed=4.22x    
frame=  295 fps= 96 q=28.0 size=     768kB time=00:00:12.56 bitrate= 500.7kbits/s dup=1 drop=0 speed=4.08x    
frame=  333 fps= 93 q=28.0 size=    1024kB time=00:00:14.14 bitrate= 593.1kbits/s dup=1 drop=0 speed=3.94x    
frame=  382 fps= 93 q=28.0 size=    1024kB time=00:00:16.19 bitrate= 518.1kbits/s dup=1 drop=0 speed=3.93x    
frame=  428 fps= 93 q=28.0 size=    1280kB time=00:00:18.11 bitrate= 579.0kbits/s dup=1 drop=0 speed=3.92x    
frame=  473 fps= 92 q=28.0 size=    1536kB time=00:00:20.00 bitrate= 628.9kbits/s dup=1 drop=0 speed=3.91x    
frame=  519 fps= 92 q=28.0 size=    1536kB time=00:00:21.93 bitrate= 573.8kbits/s dup=1 drop=0 speed= 3.9x    
frame=  567 fps= 92 q=28.0 size=    1792kB time=00:00:23.91 bitrate= 613.9kbits/s dup=1 drop=0 speed=3.89x    
frame=  601 fps= 90 q=28.0 size=    2048kB time=00:00:25.32 bitrate= 662.6kbits/s dup=1 drop=0 speed= 3.8x    
frame=  637 fps= 89 q=28.0 size=    2304kB time=00:00:26.83 bitrate= 703.3kbits/s dup=1 drop=0 speed=3.75x    
frame=  684 fps= 89 q=28.0 size=    2304kB time=00:00:28.77 bitrate= 655.9kbits/s dup=1 drop=0 speed=3.74x    
frame=  720 fps= 84 q=-1.0 size=    2924kB time=00:00:30.01 bitrate= 798.0kbits/s dup=1 drop=0 speed= 3.5x    
...