Feature request: Support streaming input data

[rcombs]

This would allow for a number of additional use-cases. Basically:

• If neither subUrl nor subContent is set, create an empty track using ass_new_track
• Expose an API to pass in a string to call ass_process_data on (for streaming raw text)
• Expose an API to pass in a string to call ass_process_codec_private on, and one to pass in a string + timestamp + duration to call ass_process_chunk on
  • Alternately, you could have a member in the options object called e.g. subHeader that ass_process_codec_private is called on at startup, though I don't see a reason not to allow deferring it.

[ThaUnknown]

is there any need to do this? creating an empty track would be a step forward, but i dont understand why you'd expose ass_process_data, when the subtitle data embedded inside an mkv file is an object anyways this is all already possible thanks to #122 , see https://github.com/ThaUnknown/pwa-haven/blob/main/video-player/src/modules/subtitles.js for how I implemented subtitle streaming with JSO

[rcombs]

when the subtitle data embedded inside an mkv file is an object anyways

No, the data in an MKV is text, in the format that ass_process_chunk accepts. You're just currently using a library that parses that text into a JS object (and then doing some postprocessing to cram the result into an ASS_Event, some of which is subtly incorrect in edge cases).

It's not meant to be the caller's responsibility to parse ASS events for libass, and doing so complicates things for the caller substantially. For instance, Style is an int internally, and the handling for it is somewhat complex (e.g. leading *s are ignored, which your code doesn't currently have; it also case-normalizes Default). Meanwhile, handling streaming ASS text is a whole piece of work unto itself.

I don't see a reason for any of this to be the caller's responsibility when libass already has the ability to do it. It's reasonable enough for SRT or other formats libass doesn't handle itself, but not for ASS.

[ThaUnknown]

hm, that makes sense I assumed that's how EBML was formatted, as all the EBML parsing libraries that are out there for JS format things quite nicely, but I admit it's my oversight/laziness that I didn't check that

the style name mapping is kind of bothersome, as the styles and their ID's can currently be exported from libass using the getStyles function, but you can't check when the styles have been parsed, so you'd often call it before libass finishes parsing the header

I admit there's no argument against this, as it's functionality would be a bit different than createEvent's