playbin2 with MJPEG streams over http: long delay before playback starts, and buffering delays on each frame

Hoyt, David hoyt6 at
Tue Jul 5 11:27:15 PDT 2011

> Thanks a lot!  I was able to apply your patch to gst-plugins-good-0.10.30, and patch the QtMobility QGStreamerPlayerSession class to set the property.  That fixed it!

Glad to hear it! Congrats!

> 1) Inside a player application that uses playbin2, is there any disadvantage to always setting the "single-stream" property to true? For example, are there any cases where making 'single-stream=true' the default would be undesirable?  Does it break, for example, playing a mpeg4 movie with sound and video from a local file?

It's not likely, but in theory it could if you had some container that contained muxed (audio + video) multipart content and you tried to play it back -- whichever media type it found first in the file would be the only one likely to be played (w/ "single-stream" turned on by default). Most (I would guess the vast majority) formats do *not* contain multipart content and therefore the multipartdemux element would not likely be created and added. In my own program, I knew and had control over the types of content being produced so it wasn't a problem turning that flag on if a multipartdemux element was added to the pipeline since I knew there would never be a src that produced audio + video muxed. YMMV.

I think the issue would be changing expected default behavior in the 0.10 series. If it can be avoided, that's a plus -- and I don't think this is considered a major issue worth changing default behavior over. Especially with a known workaround. :/ 

Now, however, would be a good time to get this changed for the 0.11 work. I'd be in favor of the opposite behavior -- you have to explicitly enable support for multiple streams (e.g. a "multiple-streams" property instead of a "single-stream" property). You could write a patch to do this -- it should be fairly straight forward and easy -- and then submit it against the 0.11 series.

> 2) Should it be considered a bug that, by default, playbin2 and decodebin2 can't play from HTTP MJPEG sources (at least without excessively long delays on playback start, and messed-up buffering)?

I pretty much agree with you because I figure that most people using gstreamer in conjunction w/ HTTP and MJPEG are doing what you and I have done so in the typical use case it seems problematic. However, there may be other use cases where the existing behavior is the correct one and at the time it was written, it was the most applicable solution. But I don't think the gstreamer devs would agree that it's a "bug" -- it simply was not the expected behavior that you or I had when we first started using it. But I think it's reasonable behavior to expect so it should be defendable (IMO). But others may disagree.

More information about the gstreamer-devel mailing list