So yes, splitting composition objects can help to safe space in the decoding buffer, but there should be no reason to do this, because there is more than enough space in this buffer as long as you don't do very, very weird things within an Epoch.Īnyway, IMHO the source of the problem is somewhere else. This is kinda weird as usually there is only one subtitle per epoch and obviously one subtitle frame can't be larger than two full HD frames. The decoding buffer is valid within an epoch, so it can only overflow if there are multiple composition objects per epoch. AFAIK only the decoded bitmap data is stored in this buffer - palettes, and other composition information is stored in a separate buffer (composition buffer). Then again, this is enough to store two complete frames at full HD resolution (1920*1080 = 2073600 which is roughly 1.98MB). There is indeed a "decoded object buffer" defined for PG streams and it's 4MB (4*2^20 = 4194304) bytes in size. At least error reports from Scenarist, like this one, lead me to believe this: Empty space encoded quite efficiently, but the problems seem to exist after decoding. They just increase the initialization/decoding times a little which needs to be considered when calculating the PTS/DTS timestamps of the packets. In a nutshell: empty pixels don't need a considerable amount of bandwidth. This is about the maximum amount of bytes you can save per frame if you split an image into two composition objects. So for a maximum of 1080 lines, the gap can be encoded with 3*1080 bytes which equals about 3.1k. However even if the subs use the full height, the gap can always be encoded with three bytes per line. Japanese) since than no EOL markers can be used. With a correctly implemented RLE algorithm the size of an single subtitle shouldn't be increased by more than 2k (2*1080 = 2160 = 2.1k) just because one line is at the top of the screen and one at the bottom.Ī worse scenario is text at the left and right (e.g. With three bytes, you can encode up to 16384 empty pixels. An empty line can be encoded with 2 bytes. With Tsmuxer, you don't have to worry about this that much since it doesn't check the bandwidth whatsoever, the worst case is that you get some flickering subtitle, but Scenarist BD will complain and refuse to import.Īs noted before, bitmaps are RLE encoded in the PG stream. For a simple two sentences far apart with one sentence on the top of the screen and one on the bottom without splitting could easily spike as high as 9MB (the limit is only 4MB), while same picture splitting into two small regions occupy less than 1MB (well below the 4MB limit). As far as my experiments with Scenarist BD, splitting images into two windows could save bandwidth significantly.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |