GNOME Bugzilla – Bug 754375
tagdemux/id3demux: Validate change state intensive fails for mp3 with ID3 tags
Last modified: 2018-01-20 14:33:37 UTC
When i run change state intensive validate scenario for mp3 files with ID3 tags GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0 playbin uri=file:///home/user/gst/master/temp/10sec.mp3 i get the below error sometimes(1 out of 10 times) Critical error Got error: Could not detect type of contents -- Debug message: gsttagdemux.c(1417): gst_tag_demux_element_find (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/GstID3Demux:id3demux1 The same becomes an always issue with fake sink GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0 playbin uri=file:///home/vineethtm/gst/master/temp/10sec.mp3 audio-sink='fakesink' Sometimes the above error message will come, and at times it will be Critical error Got error: Could not get start and/or end tag -- Debug message: gsttagdemux.c(1403): gst_tag_demux_element_find (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/GstID3Demux:id3demux1 This seems to be more of a timing issue.. basesrc seems to be in flushing mode, so whenever tagdemux calls gst_pad_pull_range on its sinkpad, it returns flushing and it is not able to typefind the element. 0:00:00.813397698 [332m 9625[00m 0x8282000 [36mINFO [00m [00m tagdemux gsttagdemux.c:1373:gst_tag_demux_element_find:<id3demux1>[00m Found type (NULL) with a probability of 0
You might be interested in trying the patch I submitted in bug #755123, it *might* fix this issue.
tried the patch.. and it is not helping :)...
Could you try whether this helps: commit 7c1a32e28b9d145ee25e3d3141dee7821ba8a7e2 Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Dec 6 16:29:23 2016 +0200 tagdemux: Fix crash when shutting down element during getrange() Ensure that nothing is in any of the streaming thread functions anymore when going from PAUSED to READY. While the parent's state change function has deactivated all pads, there is nothing preventing downstream from activating our srcpad again and calling the getrange() function. Although we're in READY! https://bugzilla.gnome.org/show_bug.cgi?id=775687
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!