BizUser
22nd January 2003, 09:06
I've just done a bunch of tests using TMPG to encode two test streams; one video only, encoded to elemental stream, the other video+audio, encoded into a system stream.
The results are largely predictable, but become very strange when bitrate goes below 1,000 kbps or so for system streams. Same problem does NOT occur for elemental (video only) streams. I can't find anything documented to explain this. Are my results to be expected? I realize my bitrates are non-standard; I'm looking at compressing some video clips way down, for PC viewing only (hence standards are less important).
Samples:
Clip length = 40 seconds.
Encode elemental stream, video only.
CBR 2520 kbps.
File size predicted = 2520 * 40 / 8 = 12,600. Actual - 12,318k (close)
CBR 1150 kbps.
File size predicted = 1150 * 40 / 8 = 5,750. Actual - 5,622k (close)
CBR 500 kbps.
File size predicted = 500 * 40 / 8 = 2,500. Actual - 2,445k (close)
All above as expected.
Now generate a 'system' stream, with audio at 224kpbs, same video bitrates as above, same clip length:
Encode System stream, video+audio.
CBR 2520 kbps
File size predicted = (2520+224) * 40 / 8 = 13,720. Actual - 12,593 (close)
CBR 1150 kbps
File size predicted = (1150+224) * 40 / 8 = 6,870. Actual - 6,854 (close)
CBR 500 kbps
File size predicted = (500+224) * 40 / 8 = 3,620. Actual - 6,854 (way off)
Note how 'actual' file size at 500 kbps is the same as for 1150 kbps.
Repeated the above tests with VBR (2-pass), setting the 'average' value for VBR to match the above values for CBR. Essentially, the same results. I also tried values of 1,000, 900, 800, etc for bitrate, and in general, it seems that: for system streams (with or without audio) the file size does not drop once bitrate goes below 1,100 kbps. But if you deal with an elemental stream, the file size goes down linearly and predictably with bitrate.
Any ideas why this is so? Did I fail to read some obvious document somewhere? Thanks!
The results are largely predictable, but become very strange when bitrate goes below 1,000 kbps or so for system streams. Same problem does NOT occur for elemental (video only) streams. I can't find anything documented to explain this. Are my results to be expected? I realize my bitrates are non-standard; I'm looking at compressing some video clips way down, for PC viewing only (hence standards are less important).
Samples:
Clip length = 40 seconds.
Encode elemental stream, video only.
CBR 2520 kbps.
File size predicted = 2520 * 40 / 8 = 12,600. Actual - 12,318k (close)
CBR 1150 kbps.
File size predicted = 1150 * 40 / 8 = 5,750. Actual - 5,622k (close)
CBR 500 kbps.
File size predicted = 500 * 40 / 8 = 2,500. Actual - 2,445k (close)
All above as expected.
Now generate a 'system' stream, with audio at 224kpbs, same video bitrates as above, same clip length:
Encode System stream, video+audio.
CBR 2520 kbps
File size predicted = (2520+224) * 40 / 8 = 13,720. Actual - 12,593 (close)
CBR 1150 kbps
File size predicted = (1150+224) * 40 / 8 = 6,870. Actual - 6,854 (close)
CBR 500 kbps
File size predicted = (500+224) * 40 / 8 = 3,620. Actual - 6,854 (way off)
Note how 'actual' file size at 500 kbps is the same as for 1150 kbps.
Repeated the above tests with VBR (2-pass), setting the 'average' value for VBR to match the above values for CBR. Essentially, the same results. I also tried values of 1,000, 900, 800, etc for bitrate, and in general, it seems that: for system streams (with or without audio) the file size does not drop once bitrate goes below 1,100 kbps. But if you deal with an elemental stream, the file size goes down linearly and predictably with bitrate.
Any ideas why this is so? Did I fail to read some obvious document somewhere? Thanks!