A New Subtitle Format

wswartzendruber · 14th February 2023, 04:39

Greetings.

I have two PGS projects on GitHub. One is written in Rust and seeks to crop subtitles and also adjust their brightness levels. It's basically in working order. The other is a .NET Standard 2.0 library that hopes to eventually support intuitive manipulation of PGS streams. Others could then incorporate it into their own applications.

Now for those who don't know, PGS uses RLE compression for the actual bitmap data. This isn't so efficient, and my experimentation shows that using PNG requires only 61% of the bytes needed.

Now to be honest, a lot of this is just the desire for a graphical subtitle format to appear that isn't as convoluted as PGS. I'm thinking that it could actually be quite simple. Each frame could have:

timestamp-ms: 4 bytes
duration-ms: 2 bytes
x-location: 2 bytes
y-location: 2 bytes
png-length: 4 bytes
png-buffer: [png-length] bytes

With the way subtitles are used to today, the above proposal should be the sum total for the new format's complexity. If this format could gain popularity within the ripping community, vendors could be incentivized to implement it due to its simplicity.

All right, now let's all have at it: Why wouldn't this work?

wswartzendruber · 16th February 2023, 15:47

To further elaborate, a simpler (much simpler) subtitle format could allow more competent editing utilities to proliferate since we as developers would no longer be working against an obfuscated format.

In short, I would like to get to a place where converting from PGS to (whatever this gets called) is synonymous with decrypting physical media. One shouldn't attempt to work with PGS anymore than they would attempt to work with encrypted bitstreams.

14th February 2023, 04:39	#1 \| Link
wswartzendruber hlg-tools Maintainer Join Date: Feb 2008 Posts: 371	A New Subtitle Format Greetings. I have two PGS projects on GitHub. One is written in Rust and seeks to crop subtitles and also adjust their brightness levels. It's basically in working order. The other is a .NET Standard 2.0 library that hopes to eventually support intuitive manipulation of PGS streams. Others could then incorporate it into their own applications. Now for those who don't know, PGS uses RLE compression for the actual bitmap data. This isn't so efficient, and my experimentation shows that using PNG requires only 61% of the bytes needed. Now to be honest, a lot of this is just the desire for a graphical subtitle format to appear that isn't as convoluted as PGS. I'm thinking that it could actually be quite simple. Each frame could have: timestamp-ms: 4 bytes duration-ms: 2 bytes x-location: 2 bytes y-location: 2 bytes png-length: 4 bytes png-buffer: [png-length] bytes With the way subtitles are used to today, the above proposal should be the sum total for the new format's complexity. If this format could gain popularity within the ripping community, vendors could be incentivized to implement it due to its simplicity. All right, now let's all have at it: Why wouldn't this work?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

16th February 2023, 15:47	#2 \| Link
wswartzendruber hlg-tools Maintainer Join Date: Feb 2008 Posts: 371	To further elaborate, a simpler (much simpler) subtitle format could allow more competent editing utilities to proliferate since we as developers would no longer be working against an obfuscated format. In short, I would like to get to a place where converting from PGS to (whatever this gets called) is synonymous with decrypting physical media. One shouldn't attempt to work with PGS anymore than they would attempt to work with encrypted bitstreams.