ofGstVideoPlayer doesn't handle HLS video stream size changes, and sometimes crashes on change.

I'm currently streaming from this HLS playlist.

http://iphone-streaming.ustream.tv/uhls/17074538/streams/live/iphone/playlist.m3u8

grabber.setPlayer(std::make_shared<ofGstVideoPlayer>());
grabber.load("http://iphone-streaming.ustream.tv/uhls/17074538/streams/live/iphone/playlist.m3u8");
grabber.play();

It's an HLS playlist. Initially it loads the first listed stream (RESOLUTION=854x480) and after a few seconds it (appears) to jump to the higher res stream (RESOLUTION=1280x720). But the pixels / texture do not appear to resize. The result is the 1280x720 video cropped to 854x480.

In some cases, which I have not been able to reproduce reliably (but I believe it has something to do with this resizing behavior), I will get back access exceptions in the buffer_cb when gst is trying to write an aligned pixels buffer to ofPixels.

There are plenty of interesting unhandled messages coming from ofGstUtils::gstHandleMessage() including GST_MESSAGE_STREAM_STATUS, GST_MESSAGE_ELEMENT, GST_MESSAGE_STREAM_START and others.

I'm happy to dig into this, but, wondering where to dig into this one. It seems to me that when a new buffer is processed, we should be able to simply inspect the meta-data and reallocate the player's ofPixels / ofTexture to match, but I'm not sure. Any thoughts are appreciated.

Start by tracing ofGstVideoPlayer's buffer_cb and the handling around ofPixels and ofTexture when the HLS stream changes resolution. Review ofGstUtils::gstHandleMessage() and the unhandled GStreamer messages mentioned in the report. Done means resolution changes resize the pixel and texture buffers correctly, the video is not cropped, and buffer_cb no longer causes access exceptions.