Hi -
How would that work? (in theory)
Pretty simple from what I understand. You simply assume the worst case scenario: (speaking in h264/hevc tongue) that would mean every frame is an reference frame (IIRC the terminology) and multiply by the number of frames you expect plus the overall encoding overhead. LZW-type encoders do it this way:
https://github.com/Cyan4973/lz4/blob/master/lib/lz4.h#L106
Either you did set an (average) bitrate when starting the encoder, then you know which value you chose and if you also know the length of the input, you can calculate the size of the output file.
In my use case, this is not possible as I am after the highest encoding bitrate possible and on top, I do know the number of frames to come.
FFmpeg generally cannot know the length of the input.
Well, because the API is built around a frame/packet concept rather then a complete input buffer. If I demux/convert a video, I also know the the length/size of the incoming video. It's only if you stream from a recording device that you don't know the length of the recording to come.
If you did not set a bitrate (but constant quality) then it is impossible to calculate the output file size.
I doubt that. But feel free to prove me wrong. Of course, it will be hard to predict the exact size of the encoded buffer. But that is not what I am after. I would love to have an upper bound with some degree of confidence.
Best, P _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
