On Fri, Nov 06, 2015 at 10:16:51PM +0000, Tom Marecek wrote: > Hello, I have no experience with submitting patches to ffmpeg yet and so I am > sorry if I am going about this the wrong way but I wanted to discuss a change > that I made to print_report which is related to this bug: > https://trac.ffmpeg.org/ticket/1446
1446 is about bitrate being 0, can you reproduce that ? > > We are using stdout from ffmpeg to monitor rtmp streams. Currently the FPS > and bitrate numbers which print_report outputs are calculated as a running > average - the total number of frames divided by the elapsed time and the > total size in bits divided by elapsed time. > > This might make sense for files but for live streams it is not very useful > since over time the changes in the streams are reflected less and less. > My change is to output the actual frame rate and bit rate each time > print_report is called (every half a second or so). Also instead of using the > file size to calculate the bit rate, I use the sum of the data sizes written > to each stream which is giving me more consistent numbers.. > > Here is the diff, thank you for your feedback.. iam not sure what is the best solution but changing print_report for your use case seems wrong if you want to know the packet sizes and timestamps through moitoring ffmpeg throug stdout, see check_keyboard_interaction() there are features like packet hexdumps in there. An addition there somewhere would be cleaner or maybe you could add a bitstream filter that exports such packet statistics by some means [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
