GNOME Bugzilla – Bug 740565
dvdsub to kate subtitle transcoding fails after first subtitle for ogg container
Last modified: 2018-11-03 11:33:08 UTC
This command goes on showing output for all subtitle entries: gst-launch-1.0 filesrc location=Arigatou.Death.Note.Ep01.\[x264.AAC\]\[558F2901\].mkv ! matroskademux ! dvdsubparse ! kateenc category=spu-subtitles ! fakesink silent=false -v While this one stops immediately: gst-launch-1.0 filesrc location=Arigatou.Death.Note.Ep01.\[x264.AAC\]\[558F2901\].mkv ! matroskademux ! dvdsubparse ! kateenc category=spu-subtitles ! oggmux ! fakesink silent=false -v I can sink the former one into a file, but ogg tools can't merge it with the video. I think because it's not an ogg container itself. I'm guessing it's just a raw byte stream of kate? When I sink the latter to a file and merge it with video, I get the very first line of subtitle and then nothing else. Running version: 1.2.4-1~ubuntu1:amd64 on Linux Mint
Does it show any error in the output? Can you share a file that reproduces the issue for testing? Please attach a GST_DEBUG=6 log for investigation.
No errors that I can see. Where do I set GST_DEBUG? Is that just an environment variable? Here's the pastbin for the fakesink that stops: http://pastebin.com/yKanPKSY Here's a link to the file I'm trying to transcode the subs from: https://www.sendspace.com/file/oz3kq6
GST_DEBUG is an environment variable to trigger gst debug messages. Should work with any gstreamer application as long as your gstreamer has debug logs compiled into it. GST_DEBUG=6 gst-launch-1.0 <your pipeline> > gst.log 2>&1 compress that gst.log file and attach it here.
In case you are curious, I think this explains it really well :) http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html Thanks for your bug report!
Created attachment 291578 [details] debug output for failing pipeline Attaching the output of: GST_DEBUG=6 gst-launch-1.0 filesrc location=Arigatou.Death.Note.Ep01.\[x264.AAC\]\[558F2901\].mkv ! matroskademux ! dvdsubparse ! kateenc category=spu-subtitles ! oggmux ! filesink location=test.ogg > gst.log 2>&1
Pretty intricate issue in collectpads, it seems. I think the semantics of "queued" in collectpads were inconsistent. The attached patches fix the bug on the supplied command line and test file. It would be good if someone more familiar with collectpads could double check the patch. Additionally, a patch to oggmux was needed to ensure "free" pad buffer is replaced from collectpads, to avoid collectpads deadlocking, waiting for the colletpads buffer to be moved. Such a change to collectpads feels rather invasive, so may have side effects in other places. Passes core and -base tests, at least.
Created attachment 292903 [details] [review] collectpads fix for sparse pads
Created attachment 292904 [details] [review] oggmux fix for deadlock popping buffers from collectpads
These patches don't seem to apply to existent files in the source tree. What am I missing?
Created attachment 295364 [details] [review] fix deadlock when not pulling a buffer from collectpads - updated -base patch updated to latest master. The core patch still applies fine.
Ah - this was filed against -bad, but the issue actually was in core/-base, so you need to apply the patches to those trees instead of -bad. I'll change the component to -base, since that's where the main bug is.
I see now. One patch is against the gst-plugins-base tree and the other is for the core gstreamer tree. Are both these patches for the master branch or were the originals for release 1.2.4?
All for master, though I would expect they should apply to 1.2.4 without much trouble.
Installed on Gentoo using user patches. The first patches apply cleanly with release 1.4.5, and the problem is fixed. The patches fail to apply to 1.2.4 as is. I'm guessing we wait for someone else to mark this resolved when they commit these changes to the repository?
That's the idea, but the change to collectpads is fairly intrusive (and so possible source of regressions), and collectpads is apparently deprecated now, so I'm not sure what the maintainers think of pushing this. I'd like it to get a review first in any case.
Any gst maintainer with an opinion on whether this is fine to push, given the intrusiveness of the collectpads change ?
I'd prefer to just get it right with aggregator and stop touching collectpads.
Yes, let's not do major changes to collectpads at this point.
Comment on attachment 292903 [details] [review] collectpads fix for sparse pads It's dead, Jim.
Will encoding to kate be supported in future releases then? Or does the kate plugin need rewritten to match API changes or something?
It's oggmux that will be changed to use the new aggregator code, instead of the collectpads code. Anyway, if we apply just the oggmux patch, this fixes the issue for the main case of encoding subtitles along with another (non sparse) stream, such as Theora or Vorbis. The collectpads patch is only needed to fix the case of muxing just kate streams only. So after looking again at this, I'm tempted to push the oggmux patch alone, assuming maintainers have no objection.
The oggmux patch is now up (the collectpads one will not be). Transcoding of the file should now work, though transcoding only subtitles still fail. commit b590a843f4b2d452ad304acdcb3265a97181fe7b Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Dec 17 12:17:09 2014 +0000 oggmux: fix deadlock when not pulling a buffer from collectpads oggmux keeps a cached buffer per pad, and pulls buffers from collectpads to this cached buffer for all pads before processing the best pad. In some cases, the move from collectpads buffer to cached buffer is delayed till next call. However, when there is only one pad, this can't be delayed till next call as there will be a deadlock since collectpads has no other pad to push to. https://bugzilla.gnome.org/show_bug.cgi?id=740565
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/146.