Side-problem with VFR content and subs (DVobSub and Matroska for instance)

[Kurosu]

I don't have a video handy right now (rather difficult to edit a VFR matroska stream as - haven't tried mmg or direct commandline yet), but here is what I noticed:
with very low framerate video due to heavy frame-dropping (say, still scenes in anime), the subs can hardly show up.

I guess it comes from the fact that DVobSub has no frame to write to at the time the subs should start displaying, and has to wait for the next frame (sometimes 1s late, which is a lot for subs lasting hardly more than 1s). Maybe inserting a dropped frame whenever a sub is to be displayed could help. I don't know at which stage it would be best to occur:
- if a dropped frame is passed by the matroska demuxer, would the following parts of the graph receive a copy of the previous frame, or plain nothing?
- if DVobSub stores one frame, use it whenever it is requested to display frames at a time where none is available, would that inserting a frame cause trouble to the rest of the filter chain?

It's probably a very minor problem by now, but with true VFR, it will only increase.

[jared1999]

Is this really a problem with VFR? Most sub formats are time-based, not frame-based, so as long as you are at a point in time that is within the duration of the subs in question they should show. I think your problem is more tied to the subtitle filter implementation than VFR in general.

[bill_baroud]

no jared1999, the subtitle's format isn't important here because every format is stored the same internaly in Dvobsub (well, yes it's timebased too ). But the problem Kurosu is pointing out is very likely to happen...you have to render the text somewhere, isn't it ?
So what's the simple way to do it ? To wait for the frame with the same timestamp, render text and overlay it to the picture and throw it to the graphic renderer for display.
And if you have a very VFR stream, you're not sure to have a frame to render when you want (because it's already rendered and just displayed on the screen).

Pretty naughty bug Kurosu :eek:

[Kurosu]

I wouldn't call that a bug: it works as intended. Just that the data on which it works isn't anymore of the same kind.

Finding a side-solution (generating a new frame just to overlay the new subs) can produce a side-side-problem: if a sub start never matches a frame timestamp, you'll end up generating many more frames. It only cost memory, but what if the display renderer can't cope with the added frames?

Sometimes you could have to update, for instance, the display 1ms (the minimal difference allowed by the timestamp syntax of the subs) after the previous inserted frame. Can all renderers manage this?

[robUx4]

It would be interresting to have Gabest's opinion on that.