+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Add-on Support (https://forum.kodi.tv/forumdisplay.php?fid=27)
+---- Forum: Video Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=154)
+---- Thread: [SUPPORT] Hulu Video Plugin (/showthread.php?tid=121023)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
RE: [SUPPORT] Hulu Video Plugin - Romey-Rome - 2014-03-24
(2014-03-24, 03:40)mattmartinolc Wrote:(2014-03-24, 03:36)lewis.donofrio Wrote:(2014-03-24, 02:26)frieten Wrote: Yep will sucks for them, this is the only thing I use my hulu plus sub on, so without a way to watch I won't renew. I'm sure I'm not the only one so they will lose money
how do I bump up my local version number - because these repositories are returning "dependance not met" when I try to install...)-:
I get the same if I try to use the Hulu non-beta ... use Hulu Beta addon and the dependencies error will go away. But after that it won't work anyway right now.
(2014-03-24, 03:33)Romey-Rome Wrote: Well PlayOn is OK in a bind. Transcoding quality drop is obvious even with the HD add-on. Fast navigation, but Artwork quality is garbage. No seeking. Think it'll resume though.
I wonder if it's possible to run a variant of rtmpsrv/rtmpdumphelper on a Windows box, and act that as a proxy between Hulu > XBMC. But I don't know. I think they use the same libs at the core.
There has got to be a way on grab the raw video stream on a legitimate player (Window in this case) and do as you please with it.
Just pissin' in the wind. I Don't mess with Windows much.
I didn't renew my PlayOn licence because Hulu was working on the Pi. Netflix was the only thing left to solve and they claimed to have a fix for that with the upcoming linXBMC so I was happy to wait. The transcoding is choppy playback from PlayOn even with my Phenom Quad Core processor and 16GB of RAM. Looks like I will have to renew the license for now. Sad.
I'm running PlayON in a KVM on my Ubuntu server with 2 assigned cores & 2GB on WinXP. Very Occasional stutter.
RE: [SUPPORT] Hulu Video Plugin - abmoraz - 2014-03-24
What is the github repository for this project? I do some python development and wouldn't mind looking at the problem (if that's ok by the maintainers).
RE: [SUPPORT] Hulu Video Plugin - bab9e9 - 2014-03-24
Moneymaker posted links in Post: #1668
http://forum.xbmc.org/showthread.php?tid=121023&pid=1660320#pid1660320
RE: [SUPPORT] Hulu Video Plugin - learningit - 2014-03-24
IMHO. Be patient. Messing with things right now is a waste of time and may shut down some solutions. Wait until the current server config settles down. A lot of new things are in test, so whatever is going on right now is under a lot of scrutiny and review. It is not a time to be experimenting, it's a time to watch. Let's not blindly help them improve an already difficult situation.
RE: [SUPPORT] Hulu Video Plugin - Romey-Rome - 2014-03-24
It goes beyond just the add-on itself. Librtmp no longer works on the streams Hulu is sending. Seems like all other Hulu rippers stopped working as well.
RE: [SUPPORT] Hulu Video Plugin - mattmartinolc - 2014-03-24
Looks like they want to keep their content exclusive to only devices that they make money off of licensing from.... greed.
RE: [SUPPORT] Hulu Video Plugin - learningit - 2014-03-24
Just be patient. Posts about rippers or use beyond what Hulu provides are really not helpful to the XBMC community, which has a strong no piracy stance. Technically, it looks like they are actually trying to expand and improve the service. The ability to expand beyond the US will most likely require additional measures to prevent content downloading and distribution into territories where they do not have IP rights, as well as new CDNs to bear the loads. So long as the addon doesn't go beyond the functionality of a browser (possibly one with an ad-blocker) it shouldn't be an issue. They continue to provide a free SD service which you don't even have to log into on a browser in territories where they have rights to distribute. The fact is that ffmeg, which forms the player core in XBMC, is behind in some of the features which they are currently implementing. They are doing a lot of experimentation to get the mix of feeds for SD and HD right. With their current set of CDNs, they clearly have the ability to encrypt all feeds which is not a good thing for an addon. If the feed situation stabilizes to where it is currently, I am quite optimistic that in the future the addon will have at least 480 support in territories where they are providing the service. Anything beyond that will most likely be for an addon which shouldn't be on an official XBMC forum from what I see the service and feeds are evolving towards. Some folks are going to be upset with this. I would encourage them to develop the skills to try to craft an addon which caters to their personal needs. I am trying to set a realistic expectation about where things may go. TNSTAAFL.
RE: [SUPPORT] Hulu Video Plugin - toejam - 2014-03-24
(2014-03-24, 07:08)learningit Wrote: Just be patient. Posts about rippers or use beyond what Hulu provides are really not helpful to the XBMC community, which has a strong no piracy stance.I appreciate the spirit of your post, but the addon is and has always been a "ripper". Any method that transits through rtmpdump (or anything other than the hulu swf player) is a "ripper", whether it pipes the output to a video player or writes it to a file. That is what SWFVerification Type 2 is all about, to ensure that the hulu provided swf player is what is being used to play the stream.
(2014-03-24, 07:08)learningit Wrote: So long as the addon doesn't go beyond the functionality of a browser (possibly one with an ad-blocker) it shouldn't be an issue.The only options that comply with this requirement are screen capture or a chrome launcher type addon.
(2014-03-24, 07:08)learningit Wrote: With their current set of CDNs, they clearly have the ability to encrypt all feeds which is not a good thing for an addon.There is no new video encryption. The only sort of pseudo-encryption involved is that of the rtmpe protocol, which has been their exclusive method for the web broswer player for years and years.
(2014-03-24, 07:08)learningit Wrote: If the feed situation stabilizes to where it is currently, I am quite optimistic that in the future the addon will have at least 480 support in territories where they are providing the service. Anything beyond that will most likely be for an addon which shouldn't be on an official XBMC forum from what I see the service and feeds are evolving towards.If a cdn implements SWFVerification Type 2, it applies to all of the qualities, including 480p and lower. Currently it seems that only one cdn is not using SWFVerification Type 2, if that one goes, the only answers for a addon of the same type is to exploit mobile app transit methods, or solve SWFVerification Type 2. An addon of a different type might emerge, ala Amazon Instant.
RE: [SUPPORT] Hulu Video Plugin - Romey-Rome - 2014-03-24
Well - found rtmpdump_2.5-0ubuntu2~precise_amd64.deb + source - with the elusive handshake 10 patches (which are indeed there), etc, but it makes XBMC take a dump. Tried it both ways - install deb & built my own.
RE: [SUPPORT] Hulu Video Plugin - learningit - 2014-03-24
(2014-03-24, 08:43)toejam Wrote:I agree with your first two statements in a technical myopic sense, I struggle with this issue as can be seen elsewhere. The second two are wrong or at least I've seen testing to contrary and at this current moment in time both statements are wrong. Time will tell.(2014-03-24, 07:08)learningit Wrote: Just be patient. Posts about rippers or use beyond what Hulu provides are really not helpful to the XBMC community, which has a strong no piracy stance.I appreciate the spirit of your post, but the addon is and has always been a "ripper". Any method that transits through rtmpdump (or anything other than the hulu swf player) is a "ripper", whether it pipes the output to a video player or writes it to a file. That is what SWFVerification Type 2 is all about, to ensure that the hulu provided swf player is what is being used to play the stream.
(2014-03-24, 07:08)learningit Wrote: So long as the addon doesn't go beyond the functionality of a browser (possibly one with an ad-blocker) it shouldn't be an issue.The only options that comply with this requirement are screen capture or a chrome launcher type addon.
(2014-03-24, 07:08)learningit Wrote: With their current set of CDNs, they clearly have the ability to encrypt all feeds which is not a good thing for an addon.There is no new video encryption. The only sort of pseudo-encryption involved is that of the rtmpe protocol, which has been their exclusive method for the web broswer player for years and years.
(2014-03-24, 07:08)learningit Wrote: If the feed situation stabilizes to where it is currently, I am quite optimistic that in the future the addon will have at least 480 support in territories where they are providing the service. Anything beyond that will most likely be for an addon which shouldn't be on an official XBMC forum from what I see the service and feeds are evolving towards.If a cdn implements SWFVerification Type 2, it applies to all of the qualities, including 480p and lower. Currently it seems that only one cdn is not using SWFVerification Type 2, if that one goes, the only answers for a addon of the same type is to exploit mobile app transit methods, or solve SWFVerification Type 2. An addon of a different type might emerge, ala Amazon Instant.
RE: [SUPPORT] Hulu Video Plugin - mattmartinolc - 2014-03-24
(2014-03-24, 12:25)Romey-Rome Wrote: Well - found rtmpdump_2.5-0ubuntu2~precise_amd64.deb + source - with the elusive handshake 10 patches (which are indeed there), etc, but it makes XBMC take a dump. Tried it both ways - install deb & built my own.
Any version of this compatible with ARM architecture?
RE: [SUPPORT] Hulu Video Plugin - toejam - 2014-03-24
(2014-03-24, 16:29)learningit Wrote: I agree with your first two statements in a technical myopic sense, I struggle with this issue as can be seen elsewhere.Well, I was speaking in purely a technical sense, because I believe (apparently myopically) that is all that can decide what is a "ripper".
(2014-03-24, 16:29)learningit Wrote: The second two are wrong or at least I've seen testing to contrary and at this current moment in time both statements are wrong. Time will tell.I suppose that we will just have to agree to disagree until time tells.
The only change in the "problem" cdns is Type 2 SWFVerification. I suppose that some argument could be made that Type 2 SWFVerification is encryption in some sort of exceedingly loose sense of the term, and I'd be happy to hear any of your arguments to that effect or hear more about the testing you've seen to the contrary. My understanding is that it is a hash function transaction at post-handshake but pre-data transfer. If Type 2 SWFVerification passes, the rtmpe tunnel is open for data transfer, much like for Type 1.
In extensive testing, I've seen all Type 2 or all Type 1 per cdn. For example, non-plus or non-logged-in users who were getting some cdns to work for a while a few days ago, if the cdn did change when they logged in, it would be all Type 2 or Type 1 per cdn, not mixed Type 2 and Type 1 on the same cdn. If your testing reveals results contrary to this, please provide details.
RE: [SUPPORT] Hulu Video Plugin - Romey-Rome - 2014-03-24
2.5 core dumps from xbmc or rtmpdump...
Code:
RTMPDump v2.5 GIT-2012-03-31 (Handshake 10 support by Xeebo)
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
DEBUG: Protocol : RTMPE
DEBUG: Hostname : viacomccstrmfs.fplive.net
DEBUG: Port : 1935
DEBUG: Playpath : mp4:gsp.comedystor/com/colbert/season_08/exclusive/colbchella_carryon_960x540_2200_m31.mp4
DEBUG: tcUrl : rtmpe://viacomccstrmfs.fplive.net:1935/viacomccstrm
DEBUG: swfUrl : http://media.mtvnservices.com/player/prime/mediaplayerprime.1.12.1.swf
DEBUG: app : viacomccstrm
DEBUG: live : no
DEBUG: timeout : 30 sec
DEBUG: SWFSHA256:
DEBUG: f2 0c 33 a3 46 15 65 12 ef 8a 98 06 7f 9a 7e 22
DEBUG: e0 e2 db e4 6b b1 aa 3e 7e 36 6a 04 25 73 24 bf
DEBUG: SWFSize : 2091449
DEBUG: Setting buffer time to: 36000000ms
Connecting ...
DEBUG: RTMP_Connect1, ... connected, handshaking
DEBUG: HandShake: Client type: 06
DEBUG: HandShake: DH pubkey position: 472
DEBUG: HandShake: Client digest offset: 1383
DEBUG: HandShake: Initial client digest:
DEBUG: 82 3c ea c3 a8 38 07 85 6b 11 d3 14 ba 9b 2a ca
DEBUG: 38 ad a7 94 e6 85 4e 27 0b 4e 1f 07 36 eb 74 99
DEBUG: HandShake: Type Answer : 0A
WARNING: HandShake: Type mismatch: client sent 6, server answered 10
DEBUG: HandShake: Server Uptime : 1512867683
DEBUG: HandShake: FMS Version : 4.5.3.1
DEBUG: HandShake: Server DH public key offset: 518
DEBUG: HandShake: Secret key:
DEBUG: 68 a8 64 f2 8d 78 0d 89 33 c1 db b2 81 57 aa cd
DEBUG: 87 ba 40 90 cb 60 16 46 83 d0 7c cd fe a5 cd d4
DEBUG: 96 61 d6 dd a3 e0 b7 08 4c a3 e6 03 e5 b3 b5 bd
DEBUG: fa ad ed 92 c2 37 61 c4 ef 26 52 39 e7 3f 52 80
DEBUG: 50 fe ed 3b 43 b9 65 c5 e9 b3 bb 8a 7c ce 11 21
DEBUG: e4 1a 0a 2a 67 f7 97 c7 16 9d f4 69 4b d5 62 20
DEBUG: 6e c1 ef ef 60 2f 7a 18 99 af bc fe ba c1 bd b8
DEBUG: d9 3b a1 a7 28 e0 0a d5 4c 4d ca 80 b0 e7 8a 87
DEBUG: RC4 Out Key:
DEBUG: 79 16 bb 6f 52 11 11 8e 0e f7 8e 8e 1f 28 40 bd
DEBUG: RC4 In Key:
DEBUG: 2b e1 87 de 0e 7c 17 8f f4 c1 62 f2 fc 32 31 a1
DEBUG: HandShake: Calculated digest key from secure key and server digest:
DEBUG: b0 fc ef 6a c9 02 ab ce 0e 8a 97 6a 7e a2 2f 0c
DEBUG: b2 c4 b3 b3 0e 25 35 f9 49 ee 97 70 31 62 f7 9d
Segmentation fault (core dumped)(2014-03-24, 16:50)mattmartinolc Wrote:(2014-03-24, 12:25)Romey-Rome Wrote: Well - found rtmpdump_2.5-0ubuntu2~precise_amd64.deb + source - with the elusive handshake 10 patches (which are indeed there), etc, but it makes XBMC take a dump. Tried it both ways - install deb & built my own.
Any version of this compatible with ARM architecture?
Not the .deb, but the source is in the same place as the deb. Just google it. It's in the top results. I'm not posting the link because they seem to have gotten DMCAed everywhere else. It's in some obscure ppa "deleted" archive.
RE: [SUPPORT] Hulu Video Plugin - toejam - 2014-03-24
(2014-03-24, 18:13)Romey-Rome Wrote: Not the .deb, but the source is in the same place as the deb. Just google it. It's in the top results. I'm not posting the link because they seem to have gotten DMCAed everywhere else. It's in some obscure ppa "deleted" archive.I could be wrong, but I'm under the impression that handshake 10 is one thing, while Type 2 SWFVerification is yet another (pretty much unrelated) thing. Can someone say for sure? Also, were you just testing with colbert? I don't think that site uses either method.
rtmp-part-10-handshake
RE: [SUPPORT] Hulu Video Plugin - Romey-Rome - 2014-03-24
(2014-03-24, 18:24)toejam Wrote:(2014-03-24, 18:13)Romey-Rome Wrote: Not the .deb, but the source is in the same place as the deb. Just google it. It's in the top results. I'm not posting the link because they seem to have gotten DMCAed everywhere else. It's in some obscure ppa "deleted" archive.I could be wrong, but I'm under the impression that handshake 10 is one thing, while Type 2 SWFVerification is yet another (pretty much unrelated) thing. Can someone say for sure? Also, were you just testing with colbert? I don't think that site uses either method.
You may be right on Type2 vs Handshake. I haven't got an answer yet, but I didn't go reading specs either.
I was just testing it from cli in the output above. XBMC in debug gives the same output on Hulu, and crashes with a seg fault on the handshake.