Answers.Body: <p>For 1080p, I often stick with.. (80 secs) - equals close to the 4gb limit. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-14T00:22:31.213Z
Answers.Text: It's realistic to assume so around 3.0 - 3.2 GB per min at 1080p I guess..
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-10T09:08:56.080Z
Answers.LastActivityDate: 2017-03-10T09:08:56.080Z
Answers.UserDisplayName: Michael
Answers.Body: <p>The answer is No. Besides the frame dimensions, there's the matter of content complexity. Without scanning the video and doing a first-pass as it were, it's not possible to predict the output size. A video consisting of a slideshow of very simple text slides will be much easier to compress than scenes of busy city life..etc.</p>
  
  <p>The closest you may come to making some sort of prediction is to encode a few representative segments from the source file and compare those bitrates. If there isn't a large difference among the bitrates of the various encoded segments, then you may assume a bitrate in that range for the final output. Of course, this method can't account for anomalous segments in the video of very high or low complexity compared to the rest of it, so sample selection is important.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T08:16:18.423Z
Answers.Text: I see, so in this case I think will be need a different approach: grab tons of segments of videos of any different kinds, all of the same size eg: full hd would be a good starting point. Batch convert them all with huffyuv for a small amount of time, let's say not more than 3 min, do a statistical analysis of the file sizes getting a plain average, a maximum and a sort of "flavored average" for video with text, heavy media, and different categories content. Get your coefficients, prepare a simple calculator based on this coefficients. :)
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T08:29:08.770Z
Answers.Text: My approach requires encoding multiple segments of the same duration from within the same video to a) check resulting bitrates and b) variance of bitrate across the segments. HuffYUV uses intraframe compression, so no need to use segment size of 3 minutes. In fact, make it closer to a few seconds.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T08:32:31.663Z
Answers.Text: Thank you for the suggestion, I'm tempted to bring some media here and do the tests. Yeah, your approach is the most correct for obtain the result of a single video, and better fit the original question. My final goal however was understand how in average a Huffyuv video will take.
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T11:38:08.127Z
Answers.Text: Would be nice if you could help me setup the test environment, what is your recommendation ? 5 seconds could work ? or 10 in order to sample more frames ? there's a way for start a chat here or i have to reach like 7-8 comments ?
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T11:54:24.397Z
Answers.Text: 5 seconds is good. I'm not a coder, but if you are, you can write a script to pick N random numbers from 0 to D-5 where D is the duration of your input file. Then just execute   ffmpeg -ss T -t 5 -i input -c:v huffyuv -an "input-T.avi"    where T are the numbers you generated, one by one. It's upto you what statistical analysis you wish to perform with the resulting files, but mean and SD comes to mind. Consult the stats SE, maybe.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T12:28:07.230Z
Answers.Text: So you talking about of using a single file but scraping randomly 5 seconds many times in order to obtain a consistent result? I was thinking about something like that, I mean avoiding take let's say 100 movies but the first 5 seconds because in the most of the cases will be just written text and black background because of initial credits. PS: Yes i can code something ;)
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T12:59:55.037Z
Answers.Text: The 100 files approach doesn't seem useful - it's like computing the nutritional value of a food item by averaging the nutritional values of fruits, meats, grains, nuts..etc. Even among fruits, there's significant difference in sugar levels, so it's just not that useful.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T14:00:50.363Z
Answers.Text: What I want to achieve is a bit broader average on what Huffyuv takes per minute, some people talk around 400MB in Full HD I want to check this theory and use this math info for predict a worst case scenario for storage requirements.
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T14:08:40.313Z
Answers.Text: Worst case scenario is a video with a lot of noise. Take any video, add random noise using ffmpeg filter and encode to HuffYUV. A text slideshow is best-case scenario. A static camera talking head video is low-moderate scenario.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-02T00:08:37.733Z
Answers.Text: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/30989/discussion-between-user3450548-and-mulvya).
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-01T05:30:44.643Z
Answers.LastActivityDate: 2015-11-01T06:11:38.840Z
Answers.LastEditDate: 2015-11-01T06:11:38.840Z
Answers.UserDisplayName: Gyan
Body: <p>I like to do many comparisons and check before picking a codec and selecting its settings.</p>
  
  <p>Settings with HuffYUV are few but more importantly I'm having trouble determining video file sizes.</p>
  
  <p>Given pixel width, height and pixel format, is it possible to predict a file size for a video encoded with the HuffYUV lossless codec?</p>
  
  <p>I would like to prepare a simple converter to get an estimate of how much space it takes hours, minutes, seconds ;)</p>
  
  <p>Which formula can I use? I'm OK even if you throw me out a complex model, I'm kinda a math guy.</p>
  
  <p>ps: I know my english is poor and is also a bit late so if you good guys think this question could be edited in a better way feel free to do it ;D</p>
  
Tags: <video><codec><huffyuv>
Title: Predict file size of a Huffyuv codec video stream
UserDisplayName: user3450548
ThreadText: # Predict file size of a Huffyuv codec video stream
  
  (Asked by: username_0 on 2015-11-01)
  
  I like to do many comparisons and check before picking a codec and selecting its settings.
  
  Settings with HuffYUV are few but more importantly I'm having trouble determining video file sizes.
  
  Given pixel width, height and pixel format, is it possible to predict a file size for a video encoded with the HuffYUV lossless codec?
  
  I would like to prepare a simple converter to get an estimate of how much space it takes hours, minutes, seconds ;)
  
  Which formula can I use? I'm OK even if you throw me out a complex model, I'm kinda a math guy.
  
  ps: I know my english is poor and is also a bit late so if you good guys think this question could be edited in a better way feel free to do it ;D
  
  **Tags:** video, codec, huffyuv
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-11-01. Score: 3 | Accepted answer
  
  The answer is No. Besides the frame dimensions, there's the matter of content complexity. Without scanning the video and doing a first-pass as it were, it's not possible to predict the output size. A video consisting of a slideshow of very simple text slides will be much easier to compress than scenes of busy city life..etc.
  
  The closest you may come to making some sort of prediction is to encode a few representative segments from the source file and compare those bitrates. If there isn't a large difference among the bitrates of the various encoded segments, then you may assume a bitrate in that range for the final output. Of course, this method can't account for anomalous segments in the video of very high or low complexity compared to the rest of it, so sample selection is important.
  
  > **Comments:**
  > **username_0**: I see, so in this case I think will be need a different approach: grab tons of segments of videos of any different kinds, all of the same size eg: full hd would be a good starting point. Batch convert them all with huffyuv for a small amount of time, let's say not more than 3 min, do a statistical analysis of the file sizes getting a plain average, a maximum and a sort of "flavored average" for video with text, heavy media, and different categories content. Get your coefficients, prepare a simple calculator based on this coefficients. :)  
  > **username_2**: My approach requires encoding multiple segments of the same duration from within the same video to a) check resulting bitrates and b) variance of bitrate across the segments. HuffYUV uses intraframe compression, so no need to use segment size of 3 minutes. In fact, make it closer to a few seconds.  
  > **username_0**: Thank you for the suggestion, I'm tempted to bring some media here and do the tests. Yeah, your approach is the most correct for obtain the result of a single video, and better fit the original question. My final goal however was understand how in average a Huffyuv video will take.  
  > **username_0**: Would be nice if you could help me setup the test environment, what is your recommendation ? 5 seconds could work ? or 10 in order to sample more frames ? there's a way for start a chat here or i have to reach like 7-8 comments ?  
  > **username_2**: 5 seconds is good. I'm not a coder, but if you are, you can write a script to pick N random numbers from 0 to D-5 where D is the duration of your input file. Then just execute   ffmpeg -ss T -t 5 -i input -c:v huffyuv -an "input-T.avi"    where T are the numbers you generated, one by one. It's upto you what statistical analysis you wish to perform with the resulting files, but mean and SD comes to mind. Consult the stats SE, maybe.  
  > **username_0**: So you talking about of using a single file but scraping randomly 5 seconds many times in order to obtain a consistent result? I was thinking about something like that, I mean avoiding take let's say 100 movies but the first 5 seconds because in the most of the cases will be just written text and black background because of initial credits. PS: Yes i can code something ;)  
  > **username_2**: The 100 files approach doesn't seem useful - it's like computing the nutritional value of a food item by averaging the nutritional values of fruits, meats, grains, nuts..etc. Even among fruits, there's significant difference in sugar levels, so it's just not that useful.  
  > **username_0**: What I want to achieve is a bit broader average on what Huffyuv takes per minute, some people talk around 400MB in Full HD I want to check this theory and use this math info for predict a worst case scenario for storage requirements.  
  > **username_2**: Worst case scenario is a video with a lot of noise. Take any video, add random noise using ffmpeg filter and encode to HuffYUV. A text slideshow is best-case scenario. A static camera talking head video is low-moderate scenario.  
  > **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/30989/discussion-between-username_0-and-mulvya).  
  
  ---
  
  ### Answer by username_1 on 2017-03-10. Score: 1
  
  For 1080p, I often stick with.. (80 secs) - equals close to the 4gb limit.
  
  > **Comments:**
  > **username_0**: It's realistic to assume so around 3.0 - 3.2 GB per min at 1080p I guess..  
  
  ---
  
  