After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 677810 - [0.10] DVD menus broken
[0.10] DVD menus broken
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.x
Other Linux
: Normal blocker
: 0.10.20
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-10 13:28 UTC by Tim-Philipp Müller
Modified: 2012-10-02 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
autoconvert: Drop the 'priming' new segment event differently. (9.33 KB, patch)
2012-06-11 13:33 UTC, Jan Schmidt
none Details | Review

Description Tim-Philipp Müller 2012-06-10 13:28:20 UTC
Testing with  gst-launch-0.10 playbin2 uri=dvd:///path/to/Dvds/foo/

Menus either don't come up, or are stuck on the first frame for ages (8-10 seconds). Highlighting doesn't seem to work either.
Comment 1 Jan Schmidt 2012-06-11 09:45:03 UTC
To fix this for me, I need to revert a52dec and mpeg2dec to the version from 0.10.19. Specifically, the port to the decoder base classes causes problems. I suspect a bug handling seamless segments.
Comment 2 Jan Schmidt 2012-06-11 13:28:49 UTC
I think the problems are around segment handling at the start of the disc.

With the new audio decoder implementation, there is an extra newsegment event received at the sink before any other on my test disc. With the old a52dec, this doesn't exist:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event   ******* (fakesink0:sink) E (type: 102, GstEventNewsegment, update=(boolean)true, rate=(
double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, start=(gint64)10000000000, stop=(gint64)-1, position=(gint64)0;) 0xe51e80"

After that, the sequence is the same for both:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event   ******* (fakesink0:sink) E (type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, start=(gint64)10000000000, stop=(gint64)-1, position=(gint64)0;) 0xe51f20"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event   ******* (fakesink0:sink) E (type: 118, taglist, audio-codec=(string)\"DVD\\ AC-3\\ \\(ATSC\\ A/52\\)\", bitrate=(uint)192000;) 0x7f538c00f000"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* (fakesink0:sink) (12288 bytes, timestamp: 0:00:10.000000000, duration: 0:00:00.032000000, offset: 0, offset_end: -1, flags: 32 discont ) 0x1032d40"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* (fakesink0:sink) (12288 bytes, timestamp: 0:00:10.032000000, duration: 0:00:00.032000000, offset: 0, offset_end: -1, flags: 0 ) 0x1032e80"

This spurious segment update is being generated inside autoconvert when it inserts the decoder element, in order to prime it with segment information. autoconvert wraps pushing the event with a 'drop new segment event' flag. With the old decoder implementation, new segment events are immediately forwarded, and therefore dropped within autoconvert. With the new implementation, the new segment event is cached in a list and output once data is ready - presumably to wait until caps are available.

Patch for autoconvert follows
Comment 3 Jan Schmidt 2012-06-11 13:33:27 UTC
Created attachment 216114 [details] [review]
autoconvert: Drop the 'priming' new segment event differently.

Make sure the new segmeent event is drop when the internal element
caches it, by marking a flag on the element. Rearrange the
data that is stored in quarks on the element to accomodate the
new flag cleanly.
Comment 4 Jan Schmidt 2012-06-11 13:35:01 UTC
With this patch, I can use a52dec from 0.10 HEAD, but I still need to use the old mpeg2dec. There's a different problem with video
Comment 5 Jan Schmidt 2012-06-11 13:55:08 UTC
I don't know what's wrong with video yet, but I note that it starts working again as soon as I revert the port to the VideoDecoder base class:

commit 1f6da3f8cf43da5314b5bd8da03270f38cc61b2b
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date:   Fri Apr 13 19:06:52 2012 -0400

    mpeg2dec: Port to GstVideoDecoder base class

With that commit, I get no video frames emitted from the decoder, from 3-4 test discs, and the pipeline never pre-rolls. Playing the VOB files directly does work though - so the ported decoder *can* handle the video in some scenarios.
Comment 6 Not Used 2012-06-11 21:54:16 UTC
One regression of porting to the video base class is that we loose the parser in mpeg2dec (an API incompatibility). I checked dvddemux, and it does not output parsed buffer like other demuxers. The final solution is still to be defined, but so far I tested adding a mpegvideoparse element in resindvdbin and that seems to mostly work. (Menu are not animated, not sure why, no visible error).
Comment 7 Tim-Philipp Müller 2012-06-11 22:07:16 UTC
In 0.10 the parsing will need to be added back then I'm afraid. People have static pipelines for mpeg stuff in applications, we can't just break those.
Comment 8 Jan Schmidt 2012-06-11 23:25:00 UTC
Right a lack of parsing certainly explains the dilemma. It would be prudent to put 'parsed=true' in the sink caps for 0.11, to make this kind of issue obvious.

As Tim says though, it's not possible to change it in 0.10.
Comment 9 Sebastian Dröge (slomo) 2012-06-12 10:13:40 UTC
Agreed, the parsing functionality should be added to mpeg2dec (but in 0.10 only!). Best probably by having a private copy of the mpeg parsing functions from gst-plugins-bad/gst-libs/gst/codecparsers.
Comment 10 Jan Schmidt 2012-06-12 11:46:41 UTC
Or, you know, revert to the version that wasn't broken.
Comment 11 Jan Schmidt 2012-10-02 14:11:37 UTC
In the absence of any further comment / fixes, I reverted mpeg2dec in 0.10 to the version before it was ported to the base video decoder.