Friday, August 22, 2008

A gst bug?

I was trying these last two weeks, while I'm working in UI features, to figure out why sometimes my conversion freezes. I debugged a bit and found that, rarely, if I don't put a time.sleep(1) before playing the pipeline, the pipeline goes to READY state instead of going to PLAYING state. Query goes to position 0, and no error message, neither warning, are sent from bus. If I try to change again to PLAYING state, it stays in READY.

I posted a simple example at http://gstreamer.pastebin.com/m4fd1d90e , it's based in the decodebin.py example from pygst but I changed to convert to audio and do it 50 times. You can just run it on a terminal with a video as parameter, and check if all 50 videos passed ok. If they pass ok, try sometimes, it's very rarely to happen on this example, as it's a small program, but on gstms is giving many times. I want to know if this bug just happens on my computer or it's a gst bug - or if I'm forgetting something else. BTW, I'm using Ubuntu 8.04 and last stable gstreamer.

If you want to check the alpha version - which I didn't released yet because of this bug - you can download it from svn.

3 comments:

Anonymous said...

Not big help but: Do you know the order of the state changes? It goes NULL->READY->PAUSED->PLAYING. So in your code when you do a state-change your in NULL and you wanna go in PLAYING. But it automatically has to pass from null to ready to paused and then to playing. Mayde that's why you see the READY state?

And also(me = noob programmer) why do you do your state-change before runnig the mainloop and not after it?

Roberto Fagá said...

Nice to know it, maybe that's why I'm seeing the READY state as the last, but isn't supposed to stop there, right?

About before or after mainloop, I think this doesn't make so much difference, because the next calls of Decodebin are done after and freeze anyway.

Thanks!

Anonymous said...

No it isn't supposed to stop. It should go to the next state(assuming the elements are ready) until it is in the "desired" state. Maybe, when this happens again, you should check the state of the pipeline(if it has some problem), check maybe each element, or even check if the elements are connected correctly...(but I don't think it will help much)