[FFmpeg-trac] #5476(ffmpeg:new): Feature: Separate Real-Time Console Status Output For Audio/Video Bitrate

[FFmpeg]

#5476: Feature: Separate Real-Time Console Status Output For Audio/Video Bitrate
-------------------------------------+-------------------------------------
             Reporter:  wader8       |                     Type:
               Status:  new          |  enhancement
            Component:  ffmpeg       |                 Priority:  minor
             Keywords:  status,      |                  Version:  git-
  console, bitrate                   |  master
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------
 Currently the real-time encoding status bitrate number shows the bitrate
 of the whole file, video, audio, muxing overhead, all other substreams.

 The video bitrate alone is reported only in offline form at the end of the
 whole encoding process in the form of INFO-ERRORLEVEL message from the
 encoder itself (CYAN color), to clear this out, that is not considered
 real-time, so that is not what I'm talking about. The realtime status
 isn't logged into a text file, what is logged to a text file is only the
 last change when the process finishes. Also do not confuse this, I do not
 want realtime to be also logged into a textfile, that would amount to a
 ton of extra lines, I know.

 This would help in situations when tinkering with mostly video and
 producing short trial&error samples of the project config, where I find
 myself a lot in, as it is not necessary to , but I do like to have a trial
 run for some minutes and I like to watch how the video bitrate behaves as
 it goes over still, moving, and black areas of the video.

 When using CRF values for video quality it does behave differently at
 different presets and also whether or not the encoding process starts from
 a completely black point in the video ..etc, it does mess with the CRF a
 bit so my trials are a bit off as I try to do my first trials at the
 middle of the video with 1 minute samle of moving and still images, I also
 use these trials to calculate the approximate total size of the final
 output file, anyways there is no need to try to fix that CRF behavior deep
 within each encoder, it is easier to simply have me see what the current
 video-only bitrate of the encoding process is in real-time by appending it
 to the current total bitrate and I can adjust the CRF much quicker and
 more accurately without having to be confused with deducing the audio
 bitrate and having to always keep that in mind during sample trials, it
 may ofcourse not be an issue for one or two projects but it adds up over
 the months, years, I have realized it now, it has been bugging me for
 years and it was just subtle enough that I didn't get myself to report it.

 It doesn't have to be separate for default errorlevel, but I am using
 maximum errorlevel and verbose console output modes, it would be welcome
 at least there.

 {{{
 % ffmpeg -errorlevel verbose -v 9 -i N/A
 ffmpeg version N/A
 built on ... N/A
 }}}
 Patches should be submitted to the ffmpeg-devel mailing list and not this
 bug tracker.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5476>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker