<div>Hi all</div><div><br></div><div>We are using gstreamer for internet radious playback and face problems with blocked application thread.</div><div>The mms element uses libmms library and blocks application thread for networking activity.</div>

<div>Related bug:</div><div><a rel="nofollow" href="https://bugzilla.gnome.org/show_bug.cgi?id=403122" style="color:rgb(57,102,142);font-size:14px;font-family:Verdana,'Helvetica Neue',Helvetica,Arial,sans-serif;text-decoration:none" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=403122</a></div>

<div><br></div><div>Our  plan is to move the blocking IO to separate thread and close networking + thread on shutdown.</div><div><br></div><div>
We are not sure whether it makes sense to base such work on libmms library.</div><div>The FFMPEG library provides mms support with LGPL licence. </div><div>The source code in ffmpeg is smaller and seems better quality compared to libmms.</div>

<div>And we found at least one mms stream that plays nicely in mplayer and not in gstreamer using libmms.</div><div><br></div><div>Regarging non-blocking implementation, ... mms in ffmpef is blocking.</div><div>But given the small code size, the code can be refactored to nonblocking </div>
<div>and the changes may be accepted upstream in ffmpeg or forked.</div><div>But this is not our current target.</div><div><br></div><div>Do you have any comments? What solution gives us best hopes for being accepted upstream?</div>
<div><br></div><div>Kind regards</div><div> Brano</div>