cubicibo
3rd March 2024, 13:24
You can have two distincts <event> with partially overlapping InTC and OutTC as long as:
- Each <Event> has a single <Graphic> (maximum of two concurrent <Graphic>)
- The <Graphic> do not spatially overlap.
- The palette of both <Graphic> are identical, or they can be combined as a single <256 colours palette.
This method has pros and cons:
- Better buffer management.
- Easy usage of inline effects like fade, position, color.
- More efficient stream encoding
- Limited to two objects
- PGS encoder is easy to implement: the BDN XML describes the data stream well enough.
- Limited to two overlapping event at any time.
- Palette has to be managed carefully in PNG generation logic.
- Palette management is constrained and hard to implement. The easy way out is to always use 127+1 colors per event. But this may not be enough for colorful subtitles.
Since the conditions above are just too much for most renderer, especially events sharing the same palette, most software rightfully use non overlapping <event>.
- Each <event> can have one or two <graphic>, whose content is irrelevant.
- No need to worry about spatial overlapping across different <event>.
- Each <event> has its own palette (which need to be shared by the two <graphic>). No need to consider neighbout events in time to generate the palette, only the active <graphic>(s).
- Cannot easily make use of BDN inline effects, as there's no logical <graphic> continuity in the <Events> timeline.
- Cannot encode PGS easily, as the BDN gives no helpful indication on the datastream structure, contiguous events, and so on.
- Way too many <graphic> generated, with often suboptimal splits and sizes.
And that's the shitty part.
- There's no smart BDN generators. The output is already too specific to the PGS format, differs too much from common subtitling needs to demotivate companies to implement it properly. Maybe Lemony Pro gets a few things right, but is still not ideal.
- "Stupid" BDN generators like avs2bdnxml or ass2bdnxml leave all the complexity to the PGS encoder. Scenarist and co do their best, but they all have their own issues. The main problem with Scenarist BDNImport is to allocate one buffer slot for every unique bitmap shape. It should just pad everything to the same size to reuse memory allocation. If your BDN is not nicely made, Scenarist won't be happy.
In essence, PGS encoders expect the BDN XML generators to address the complexities. And BDN generators wants PGS encoders to handle them. It is like politics, all blaming each others and not doing anything ;)
Anyway, just my brain dump on the matter raised by jpsdr.
- Each <Event> has a single <Graphic> (maximum of two concurrent <Graphic>)
- The <Graphic> do not spatially overlap.
- The palette of both <Graphic> are identical, or they can be combined as a single <256 colours palette.
This method has pros and cons:
- Better buffer management.
- Easy usage of inline effects like fade, position, color.
- More efficient stream encoding
- Limited to two objects
- PGS encoder is easy to implement: the BDN XML describes the data stream well enough.
- Limited to two overlapping event at any time.
- Palette has to be managed carefully in PNG generation logic.
- Palette management is constrained and hard to implement. The easy way out is to always use 127+1 colors per event. But this may not be enough for colorful subtitles.
Since the conditions above are just too much for most renderer, especially events sharing the same palette, most software rightfully use non overlapping <event>.
- Each <event> can have one or two <graphic>, whose content is irrelevant.
- No need to worry about spatial overlapping across different <event>.
- Each <event> has its own palette (which need to be shared by the two <graphic>). No need to consider neighbout events in time to generate the palette, only the active <graphic>(s).
- Cannot easily make use of BDN inline effects, as there's no logical <graphic> continuity in the <Events> timeline.
- Cannot encode PGS easily, as the BDN gives no helpful indication on the datastream structure, contiguous events, and so on.
- Way too many <graphic> generated, with often suboptimal splits and sizes.
And that's the shitty part.
- There's no smart BDN generators. The output is already too specific to the PGS format, differs too much from common subtitling needs to demotivate companies to implement it properly. Maybe Lemony Pro gets a few things right, but is still not ideal.
- "Stupid" BDN generators like avs2bdnxml or ass2bdnxml leave all the complexity to the PGS encoder. Scenarist and co do their best, but they all have their own issues. The main problem with Scenarist BDNImport is to allocate one buffer slot for every unique bitmap shape. It should just pad everything to the same size to reuse memory allocation. If your BDN is not nicely made, Scenarist won't be happy.
In essence, PGS encoders expect the BDN XML generators to address the complexities. And BDN generators wants PGS encoders to handle them. It is like politics, all blaming each others and not doing anything ;)
Anyway, just my brain dump on the matter raised by jpsdr.