GNOME Bugzilla – Bug 666674
2bit DVB sub-pictures too quickly displayed
Last modified: 2012-07-11 18:38:28 UTC
2bit color DVB sub-pictures are not displayed enough time to be readable. 'dvbsuboverlay' element is used in following pipeline like: // gst-launch -v filesrc location=video.mpg ! mpegtsdemux name=d ! // queue ! mp3parse ! mad ! audioconvert ! autoaudiosink d. ! // queue ! mpeg2dec ! ffmpegcolorspace ! r. d. ! // queue ! "subpicture/x-dvb" ! dvbsuboverlay name=r ! ffmpegcolorspace ! autovideosink Sample available for convenience here: http://dl.free.fr/cWzQqDilv
The file is no longer available. Could you provide it somewhere else ?
I still have it and can make it available if you feel like looking into this. (Same file as for bug #666352).
Still happens with 0.10 git btw, both with mpegtsdemux and tsdemux.
Could take a look at this, so if the file can be made available?
This seems to have to do with dvbsuboverlay not waiting for text data, which makes video run (partially) ahead and therefore subtitle only has a chance for display for a short time. It is moderately feasible to add some code for waiting, though it seems on the one hand that subtitleoverlay tends to disable such waiting (at least with textoverlay) and on the other hand that also needs segment updates (or gap events in 1.0) from demuxer (which do not seem to be coming from e.g. tsdemux).
While above comments are generally valid, the particular sample in question here (at least the one I got to examine) seems rather bogus. On the one hand, it might not be muxed properly in that subtitle data does not quite some to come out at the right time. ---- /GstPipeline:pipeline0/GstIdentity:vid: last-message = "chain ******* (vid:sink) (14412 bytes, timestamp: 0:00:06.7177555 56, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xfd58e0" /GstPipeline:pipeline0/GstIdentity:sub: last-message = "chain ******* (sub:sink) (17 bytes, timestamp: 0:00:03.972755556, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xfabbf0" /GstPipeline:pipeline0/GstIdentity:vid: last-message = "chain ******* (vid:sink) (16017 bytes, timestamp: 0:00:06.7577555 56, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xfabab0" .... /GstPipeline:pipeline0/GstIdentity:vid: last-message = "chain ******* (vid:sink) (11263 bytes, timestamp: 0:00:09.717755556, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x108fe50" /GstPipeline:pipeline0/GstIdentity:sub: last-message = "chain ******* (sub:sink) (1921 bytes, timestamp: 0:00:06.757755556, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x10b5520" /GstPipeline:pipeline0/GstIdentity:vid: last-message = "chain ******* (vid:sink) (13956 bytes, timestamp: 0:00:09.757755556, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x10b5340" ---- Also, there is at least one case of a subtitle with page_time_out 0 (which would then be shown hardly shown at all).
Looks like some tsdemux bug was causing subtitles to come out at a "wrong time". The page_time_out is still bogus in the stream itself (afaics), and may as such be responsible for some remaining "quick display" (where quick is presumably a matter of taste/reading): commit c80e1b14f9578dcb2e26704c0a21c28eaf35e552 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Jul 11 20:34:05 2012 +0200 tsdemux: correctly determine expected PES packet payload size Avoids consistently failing to detect that a packet is complete, which would then only be pushed upon the start of a next packet, which leads to quite a delay in case of a sparse (subtitle) stream. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=666674 commit b20de7abaa503876d08e395454d8ee96b3f145b8 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Jul 10 17:58:22 2012 +0200 dvbsuboverlay: ensure minimum page time out of 1 second ... to compensate for some bogus subtitle with a 0 timeout, which would result in only being shown for a very unreadable amount of time. See https://bugzilla.gnome.org/show_bug.cgi?id=666674