GNOME Bugzilla – Bug 666352
2bit DVB sub-pictures wrongly displayed
Last modified: 2012-07-09 16:23:45 UTC
2bit color DVB sub-pictures are not properly displayed. Characters are not readable easily. '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 ! ffdec_h264 ! ffmpegcolorspace ! r. d. ! // queue ! "subpicture/x-dvb" ! dvbsuboverlay name=r ! ffmpegcolorspace ! autovideosink While decoding, dvbs parser logged: WARNING **: Parsing 2bit color DVB sub-picture. This is not tested at all. If you see this message, please provide the developers with sample media with these subtitles, if possible.
No way to attach the sample here, so you'll find the sample here: http://dl.free.fr/kPrIJ2roZ
Created attachment 204024 [details] subtitle observation
Created attachment 204025 [details] expected behavior this is a snapshot from VLC
I think your connection is blocking PNG uploads and we got some sort of HTMLs here instead now. That said, I've already looked at the samples and visually seeing and can confirm the bug.
Created attachment 204027 [details] [review] dvbsuboverlay: Handle non_modifying_colour_flag correctly in the RLE handlers The check for when to not memset was checking on an undeterministic 'bits' variable value, which is only meant to be used inside the loop earlier when it is supposed to check if clut_index is 1 together with non_mod set, as per spec: "non_modifying_colour_flag: If set to '1' this indicates that the CLUT entry value '1' is a non modifying colour. When the non modifying colour is assigned to an object pixel, then the pixel of the underlying region background or object shall not be modified. This can be used to create "transparent holes" in objects."
After this patch the first subtitle in the sample referenced in comment #1 looks good. The two others are looking good as well now, as seen by my PNG outputting debug code within libdvbsub, but aren't shown on the screen correctly right now. I believe this is due to bug 660233, as the quick workaround to that solves this issue and the other two subtitles are displayed as well. I'll probably look at a proper fix to that soon.
Applying this patch has 3 subtitles coming up OK for me (and timing issues would then be another bug anyway), so considering this fixed: commit a908339fee1e641961764f3281720aca1e414630 Author: Mart Raudsepp <mart.raudsepp@collabora.com> Date: Wed Dec 21 13:00:27 2011 +0200 dvbsuboverlay: Handle non_modifying_colour_flag correctly in the RLE handlers The check for when to not memset was checking on an undeterministic 'bits' variable value, which is only meant to be used inside the loop earlier when it is supposed to check if clut_index is 1 together with non_mod set, as per spec: "non_modifying_colour_flag: If set to '1' this indicates that the CLUT entry value '1' is a non modifying colour. When the non modifying colour is assigned to an object pixel, then the pixel of the underlying region background or object shall not be modified. This can be used to create "transparent holes" in objects." https://bugzilla.gnome.org/show_bug.cgi?id=666352