GNOME Bugzilla – Bug 681111
Bad librtmp return value treatment
Last modified: 2012-10-12 22:40:05 UTC
Created attachment 220208 [details] [review] rtmpsink librtmp return value In ext/rtmp/gstrtmpsink.c around line 244: if (!RTMP_Write (sink->rtmp, (char *) map.data, map.size)) goto write_failed; But RTMP_Write may return: - 0 if packet is to small - FALSE (0) on memory allocation error - -1 if a packet failed to be sent - bytes sent in all other cases So -1 must be considered as an error and previous return value test should be: if (0 >= RTMP_Write (sink->rtmp, (char *) map.data, map.size)) goto write_failed; I attached a patch against commit: 955e50449e471e8431664f5f8db304ffeb79ae16
Out of curiosity - what did this fix for you exactly? Did it loop endlessly while not actually sending any packets? Should -1 be fatal or could it be a temporary issue?
I use gstreamer+rtmpsink over an unstable dsl line. When the line disconnects and reconnects my software doesn't report any problem and the pipeline is still in PLAYING state without any message/event. No message is sent because -1 is returned and not considered as an error. RTMP_Write returns -1 when send() return -1. From my point of view -1 should be fatal. But I'm not sure 0 should be considered as an error, curl only returns an error if RTMP_Write return -1: static ssize_t rtmp_send(struct connectdata *conn, int sockindex, const void *buf, size_t len, CURLcode *err) { RTMP *r = conn->proto.generic; ssize_t num; (void)sockindex; /* unused */ num = RTMP_Write(r, (char *)buf, len); if(num < 0) *err = CURLE_SEND_ERROR; return num; }
Alright, thanks for the explanation. This should be fixed now in git. Sorry I took the other person's patch, because it was already in git format-patch format, which makes things easier to me, and it also puts the <= 0 to the right which is more in line with existing GStreamer style. Hope you don't mind too much. *** This bug has been marked as a duplicate of bug 686009 ***