+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Python Add-on Development (/forumdisplay.php?fid=26)
+--- Thread: Hulu Plugin Development Thread - Developers only! (/showthread.php?tid=45888)
- jdeslip - 2009-06-03 20:26
Is the Hulu plugin (browser) boxee uses open-source? Can it be ported back to xbmc?
- rwparris2 - 2009-06-03 20:32
jdeslip Wrote:Is the Hulu plugin (browser) boxee uses open-source? Can it be ported back to xbmc?
Please don't post in this thread unless you have code or pseudo code (you also don't need to post to apologize, I know you're sorry
).To answer your question, no and no.
- highlandsun - 2009-07-11 08:11
For anyone curious, it looks like Hulu changed things again a few days ago; they used to only be using RTMPE on their H.264 streams but now they're using it on all of their streams. And they've changed the RTMPE protocol; the server is sending a packet that rtmpdump-1.6 doesn't recognize. Back to decoding packet dumps I guess.
edit: simple fix, rtmpdump was only decoding 1 out of up to 3 bytes of a packet's channel ID...
- andrewgee - 2009-07-30 10:10
highlandsun Wrote:For anyone curious, it looks like Hulu changed things again a few days ago; they used to only be using RTMPE on their H.264 streams but now they're using it on all of their streams. And they've changed the RTMPE protocol; the server is sending a packet that rtmpdump-1.6 doesn't recognize. Back to decoding packet dumps I guess.
edit: simple fix, rtmpdump was only decoding 1 out of up to 3 bytes of a packet's channel ID...
Great find highlandsun
For those not confident with C++, could you detail what changes we should make to fix the decoding the the channel ID?
Thanks.
- motd2k - 2009-07-30 10:41
No, please don't. We can't allow any discussion of reversing RTMPE here i'm afraid.
- highlandsun - 2009-07-31 04:40
motd2k: this is generic to RTMP, not specific to RTMPE. And the official RTMP spec from Adobe is now public info. http://www.adobe.com/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
The same bug exists in flvstreamer, last time I checked.
- motd2k - 2009-07-31 08:12
Yea its cool. RTMP is fine, i know its public - i've looked over librtmp alot recently.
If there's a bug (specific to rtmp) then thats fine. To what field are you refering by 'Channel ID' though? If you post a packet dump i'll get it fixed on SVN
motd
- highlandsun - 2009-07-31 09:57
In section 6.1.1 of the spec, the Chunk Stream ID can be 1 to 3 bytes long. The current code only handles a 1 byte ID (values 0-63).
Probably easier for me to just give you the patch...
Code:
diff -wur old/rtmp.cpp new/rtmp.cpp
--- old/rtmp.cpp 2009-05-14 10:13:54.000000000 -0700
+++ new/rtmp.cpp 2009-07-26 19:14:03.000000000 -0700
@@ -1026,6 +1129,28 @@
packet.m_headerType = (type & 0xc0) >> 6;
packet.m_nChannel = (type & 0x3f);
+ if ( packet.m_nChannel == 0 )
+ {
+ if (ReadN(&type,1) != 1)
+ {
+ Log(LOGERROR, "%s, failed to read RTMP packet header 2nd byte", __FUNCTION__);
+ return false;
+ }
+ packet.m_nChannel = (unsigned)type;
+ packet.m_nChannel += 64;
+ } else if ( packet.m_nChannel == 1 )
+ {
+ char t[2];
+ int tmp;
+ if (ReadN(t,2) != 2)
+ {
+ Log(LOGERROR, "%s, failed to read RTMP packet header 3rd byte", __FUNCTION__);
+ return false;
+ }
+ tmp = (((unsigned)t[0])<<8) + (unsigned)t[1];
+ packet.m_nChannel = tmp + 64;
+ Log(LOGDEBUG, "%s, m_nChannel: %0x", __FUNCTION__, packet.m_nChannel);
+ }
int nSize = packetSize[packet.m_headerType];
diff -wur old/rtmp.h new/rtmp.h
--- old/rtmp.h 2009-05-12 17:15:20.000000000 -0700
+++ new/rtmp.h 2009-07-26 19:56:43.000000000 -0700
@@ -205,14 +211,12 @@
char *m_pBuffer; // data read from socket
char *m_pBufferStart; // pointer into m_pBuffer of next byte to process
int m_nBufferSize; // number of unprocessed bytes in buffer
- RTMPPacket m_vecChannelsIn[64];
- RTMPPacket m_vecChannelsOut[64];
- int m_channelTimestamp[64]; // abs timestamp of last packet
+ RTMPPacket m_vecChannelsIn[65600];
+ RTMPPacket m_vecChannelsOut[65600];
+ int m_channelTimestamp[65600]; // abs timestamp of last packet
double m_fDuration; // duration of stream in seconds
};
};
#endif
-
-
diff -wur old/rtmppacket.h new/rtmppacket.h
--- old/rtmppacket.h 2009-05-14 09:45:32.000000000 -0700
+++ new/rtmppacket.h 2009-07-13 22:33:23.000000000 -0700
@@ -56,7 +56,7 @@
BYTE m_headerType;
BYTE m_packetType;
- BYTE m_nChannel;
+ int m_nChannel;
int32_t m_nInfoField1; // 3 first bytes
int32_t m_nInfoField2; // last 4 bytes in a long header, absolute timestamp for long headers, relative timestamp for short headers
bool m_hasAbsTimestamp; // timestamp absolute or relative?I should point out, it's possible I have the 3 byte decode wrong; the text says the 3rd byte is most significant, but the Figure implies that it's the 2nd byte. So maybe it should be t[0] + t[1] << 8 instead. I suspect though that the actual value doesn't matter to us...
- highlandsun - 2009-08-09 12:12
Cool, I see my patch has been added to flvstreamer's svn now.
- motd2k - 2009-08-10 00:18
The massive allocations were a problem, needed to convert to std vector but have had alot on the plate.