Bug 733306 – mpeg4parse assertion fails

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 733306 - mpeg4parse assertion fails


Summary:	mpeg4parse assertion fails


Status:	RESOLVED INCOMPLETE

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-bad
Version:	git master
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	NONE
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2014-07-17 10:58 UTC by Aleix Conchillo Flaqué
Modified:	2014-12-18 23:39 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Aleix Conchillo Flaqué 2014-07-17 10:58:41 UTC

Yesterday I updated to latest master changes (1 month since I didn't). I have an RTSP server based on gst-rtsp-server. From time to time I get the folllowing assertion:

CRITICAL **: gst_byte_reader_masked_scan_uint32: assertion '(guint64) offset + size <= reader->size - reader->byte' failed

The server keeps working an streaming.

The pipeline is something like:

   shmsrc ! x264enc ! rtph264pay

I'll try to reproduce this with gst-rtsp-server test-launch.

This is the backtrace:

(gdb) bt

+ Trace 233833

#0 g_logv
at gmessages.c line 1026
#1 g_log
at gmessages.c line 1059
#2 g_return_if_fail_warning
#3 gst_byte_reader_masked_scan_uint32
at gstbytereader.c line 848
#4 gst_mpeg4_parse
at gstmpeg4parser.c line 465
#5 gst_mpeg4vparse_handle_frame
at gstmpeg4videoparse.c line 496
#6 gst_base_parse_handle_buffer
at gstbaseparse.c line 1961
#7 gst_base_parse_chain
at gstbaseparse.c line 2894
#8 gst_pad_chain_data_unchecked
at gstpad.c line 3836
#9 gst_pad_push_data
at gstpad.c line 4069
#10 gst_pad_chain_data_unchecked
at gstpad.c line 3836
#11 gst_pad_push_data
at gstpad.c line 4069
#12 gst_pad_push
at gstpad.c line 4180
#13 gst_proxy_pad_chain_default
at gstghostpad.c line 126
#14 gst_pad_chain_data_unchecked
at gstpad.c line 3836
#15 gst_pad_push_data
at gstpad.c line 4069
#16 gst_single_queue_push_one
at gstmultiqueue.c line 1143
#17 gst_multi_queue_loop
at gstmultiqueue.c line 1392
#18 gst_task_func
at gsttask.c line 317
#19 g_thread_pool_thread_proxy
at gthreadpool.c line 309
#20 g_thread_proxy
at gthread.c line 798
#21 start_thread
at pthread_create.c line 309
#22 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Comment 1 Aleix Conchillo Flaqué 2014-07-17 11:02:20 UTC

No code from gstmpeg4parser.c or gstx264enc.c has changed for a while. Well, just trivial changes it seems.

I updated x264 library recently, so may be that's causing a problem.

Comment 2 Tim-Philipp Müller 2014-07-17 11:13:16 UTC

I'm a bit confused about where mpeg4videoparse enters the picture here (rather than h264parse).

Comment 3 Aleix Conchillo Flaqué 2014-07-17 11:15:37 UTC

(In reply to comment #2)
> I'm a bit confused about where mpeg4videoparse enters the picture here (rather
> than h264parse).

Good point. I have no idea. I'm not adding a parser manually. I'll see if I can find anything with GST_DEBUG.

Any suggestions to what I should look at?

Comment 4 Aleix Conchillo Flaqué 2014-07-17 11:19:56 UTC

Yes, mpeg4videoparse is what's being created:

 INFO     GST_ELEMENT_FACTORY gstelementfactory.c:364:gst_element_factory_create: creating element "mpeg4videoparse"

Sorry, I forgot to mention my pipeline has a decodebin.

Comment 5 Aleix Conchillo Flaqué 2014-07-17 11:26:26 UTC

And also forgot to mention that the input video (from the shmsrc)  has been encoded by avenc_mpeg4. That's where the error comes from.

Sorry for the confusion, I haven't used that video source for a while and didn't pay enough attention to it.

In any case, I guess the bug is still valid.

Comment 6 Sebastian Dröge (slomo) 2014-07-17 15:47:29 UTC

Do you have a testcase to reproduce this problem?

Comment 7 Aleix Conchillo Flaqué 2014-07-17 15:57:43 UTC

(In reply to comment #6)
> Do you have a testcase to reproduce this problem?

No, not yet. I tried with test-launch without any luck :-(.

The setup where I could reproduce the error is not something I usually use. It was a sporadic error and every thing kept going.

Not sure when I'll have more time to look into it.

May be set this as NEEDINFO?

Comment 8 Tim-Philipp Müller 2014-12-18 23:39:10 UTC

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!