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 711119 - RTSP streaming of MP4 stream doesn't display video
RTSP streaming of MP4 stream doesn't display video
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.31
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-30 05:27 UTC by Satish Kumar
Modified: 2018-05-05 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for fixing the issue (1.22 KB, patch)
2013-10-30 05:27 UTC, Satish Kumar
rejected Details | Review

Description Satish Kumar 2013-10-30 05:27:06 UTC
Created attachment 258516 [details] [review]
Patch for fixing the issue

The issue is that when we play mp4 files through RTSP streaming case then sometimes video is not visible, only audio is listened.

Analysis:
The issue is coming in new_manager_pad() in gstrtspsrc.c. In the streamed mp4 files, there are two streams( say stream0(audio) and stream1(video)) which calls new_manager_pad() during pipeline creation in rtpbin in differnt threads.

If stream1 calls first this function, stream1 is added, pad_added signalled to uridecodebin and while checking for all streams added, the stream0 is not added and it returns backs. Then stream0 calls this function again, then this is also added and checks for all streams added. Now both are added and hence it signals no_more_pads to uridecodebin to remove the  pad_added callbacks. Both video and audio pipelines are created succesfully.

But in failing case, stream0 comes first, it is added and checks for all streams. by this time, stream1 is not added but since container for stream1 is 1 which ends up signalling for all streams added to true which signals no_more_pads to uridecodebin. stream1 calls later to this function but its pad_added signal is not received by uridecodebin so video pipeline is not created.
Comment 1 Wim Taymans 2013-11-12 09:56:30 UTC
This is not correct, it would break RTSP on ASF files.

The idea is that when multiple streams have the same pt, they are part of a container and only one pad (the first) needs to be exposed.

If you have the same payload type twice for audio and video, you should check your server, it should generate different pt for audio and video.
Comment 2 Vivia Nikolaidou 2018-05-05 16:07:26 UTC
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!