GNOME Bugzilla – Bug 712643
qtdemux: couple of issues with vobsub
Last modified: 2014-05-26 07:45:46 UTC
First issue is that the demuxer seems to be outputting empty (2 byte) buffers, which should be ignored, they are supposed to be terminator samples. Second issue is that palette event is not created, resulting in the subtitles not being rendered correctly. I haven't found any specification of vobsub in MP4, but perhaps the way handbrake creates codec data might be helpful https://github.com/HandBrake/HandBrake/blob/master/libhb/muxmp4.c
Sample file https://s3.amazonaws.com/MatejK/Samples/mp4-vobsub.m4v There are only like 3 cues in the file, first one is several seconds in
The sample file is 403
Sorry, permissions should be fixed now. Also the dimensions might not match so the subtitles might get cropped, but that's different issue.
Fixed, in qtdemux and dvdspu: commit 81e2c8130a7a2a9316cd79d3f84d97979c7010b6 Author: Jan Schmidt <jan@centricular.com> Date: Thu Nov 21 02:28:27 2013 +1100 isomp4: Handle mp4s subpicture streams better. Clean up the handling of mp4s streams. Use the generic esds descriptor function to extract the palette, instead of hard coding a wrong magic offset. Add some more size safety checks when parsing ES descriptors, and replace magic numbers with the descriptive constants that are already defined. Enhance dump output for stsd atoms. Streams from both bug 712643 and historic bug 568278 now both work correctly. Fixes: #712643 commit c336f7642cd83a4521a91198e6c9ccee05c84f1d Author: Jan Schmidt <jan@centricular.com> Date: Wed Nov 20 12:46:23 2013 +1100 dvdspu: Handle vobsub packets smaller than 4 bytes In particular, handle the case of an empty packet with size 0 bytes. Partially fixes: #712643
I'm just wondering if the empty buffer shouldn't have been handled by the demuxer. I'd say it is a muxing details - since samples in MP4 don't have duration, an empty next sample is used to determine sample length.
Not sure it makes any difference, and handling it in the demux looked much harder - easier just to discard the packets, which the SPU should have been doing anyway. I'm not sure why they felt compelled to add the 0 byte packets in the first place - the SPU packet contents themselves should have all the relevant timing information.
My concern for the empty packets is remuxing.
OK, qtdemux changed to discard the terminator packets, after brief discussion on IRC: commit fdfc6a2a86dfd95f2d059b1b031e694cce09f67f Author: Jan Schmidt <jan@centricular.com> Date: Mon Nov 25 12:13:43 2013 +1100 qtdemux: Discard 2 byte subpicture packets As for text subtitles and as suggested in #712643, throw away the 2 byte terminator packets that some encoders insert. This will make things better when remuxing and causes generation of gap events.
Seems to work fine, except for the following GStreamer-Critical: void gst_buffer_unmap(GstBuffer *, GstMapInfo *): assertion `GST_IS_BUFFER (buffer)' failed Stacktrace
+ Trace 232826
gboolean gstspu_vobsub_execute_event (GstDVDSpu * dvdspu) { ... ... gst_dvd_spu_finish_spu_buf (dvdspu); ret = FALSE; } >>gst_buffer_unmap (state->vobsub.buf, &map); return ret; }
That looks like a local change of your own. git master has that code like this: if (next_blk != state->vobsub.cur_cmd_blk) { /* Advance to the next block of commands */ gst_dvd_spu_setup_cmd_blk (dvdspu, next_blk, start, end); } else { /* Next Block points to the current block, so we're finished with this * SPU buffer */ gst_buffer_unmap (state->vobsub.buf, &map); gst_dvd_spu_finish_spu_buf (dvdspu); return FALSE; } gst_buffer_unmap (state->vobsub.buf, &map);
Sorry, looks like it was broken by this commit http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=db915754c15009dfe61bbc016b801f5bb63b1e84
Matej, is there a problem still with latest GIT?