docs/random/bbb/subtitles: Add some first mind rumblings on proper subtitle support.

Original commit message from CVS:
* docs/random/bbb/subtitles:
Add some first mind rumblings on proper subtitle support.

diff --git a/docs/random/bbb/subtitles b/docs/random/bbb/subtitles
index fafd531..6cbe204 100644 (file)
--- a/docs/random/bbb/subtitles
+++ b/docs/random/bbb/subtitles
@@ -66,3 +66,40 @@ hard, but someone has to do it.
 
 3. Written by
 Ronald S. Bultje <rbultje@ronald.bitfreak.net>, Dec. 25th, 2004
+
+
+Appendix A: random IRC addition
+<Company> intersting question: would it be a good idea to have a "max-buffer-length" property?
+<Company> that way demuxewrs would now how often they'd need to generate filler events
+<Company> s/now/know/
+<BBB> hm...
+<BBB> I don't think it's good to make that variable
+<Company> dunno
+<Company> (i'm btw always looking at this from the midi perspective, too)
+<Company> (because both subtitles and midi are basically the same in this regard)
+<BBB> and do you mean 'after the stream has advanced <time> and we didn't read a new subtitle in this mkv stream, we should send a filler'?
+<Company> yeah
+<BBB> it goes for avi with large init_delay values, too
+<Company> so you don't need to send fillers every frame
+<BBB> right
+<BBB> cant' we just set that to, for example, 1s?
+<BBB> it's fairly random, but still
+<Company> that's another option, too
+<Company> though you could write all file parsers with max-delay=MAXINT
+<Company> would make them a lot easier
+<BBB> it's true that queue size, for example, depends on this value
+<BBB> e.g. if you make this 5s and set queue size to 1s, it'll hang
+<Company> right
+<BBB> whereas if you set it to 1s and queue size to 5s, you waste space
+<BBB> :)
+<BBB> you ought to set it to max-delay * (n_streams + 1)
+<BBB> or so
+<BBB> or -1
+<BBB> I forgot
+<BBB> ohwell
+<Company> if you'd use filtercaps and queue sizes in your app, you could at least work around deadlocks
+<BBB> yeah
+<Company> though ideally it should just work of course...
+<BBB> good point...
+
+