Open nitrocode opened 6 years ago
I usually work around it by playing the video in a new tab pointing to the mp4 directly (i.e. just paste the mp4 url in the omnibar and play it using chrome's built in video player). Then when you try to cast the extension will pick up the URL.
As you mentioned using dev tools introspection to find the request url seems to be more robust. If you'd like to try a hand at switching out the libvget base to something more reliable, that would be a good place to start!
When I'm debugging the extension, my issue is I can only access background.js and some more files when going through chrome://extensions or by inspecting the html page that renders when clicking the button. I cannot seem to debug through libvget which seems needed in order to track down where video
and src
are coming from. If you have any tips to help me over the learning curve, I'd love to hack it.
Ok I did some shoddy reverse engineering (the chrome debugger is really nice for this!) and it appears the key function is
function f(a, b) {
chrome.runtime.sendMessage({
type: a
, data: b
})
}
in contentScript.js, where the the sent message has data & type elements like so:
{
"data": [
{
"frameId": "4yhyeals04",
"id": 1,
"isYoutube": false,
"origin": "http://camendesign.com/code/video_for_everybody/test.html",
"referer": "http://camendesign.com/code/video_for_everybody/test.html",
"sources": [
{
"url": "http://clips.vorwaerts-gmbh.de/VfE_html5.mp4"
},
{
"url": "http://clips.vorwaerts-gmbh.de/VfE.webm"
},
{
"url": "http://clips.vorwaerts-gmbh.de/VfE.ogv"
}
],
"type": "html5"
}
],
"type": "videoList"
}
The corresponding listener is in fullapp.js
function h(a) {
var b = a.type
, c = a.data;
switch (b) {
case "videoDetected":
e(c);
break;
case "videoList":
k(c);
break;
case "register":
g(c);
break;
case "unload":
f(c)
}
}
and calls
b.detectedVideos.push.apply(b.detectedVideos, a), b.$apply()
which seems to add videos to detectedVideos[]
and call some angular function to update the UI.
So it seems it should be sufficient to chuck out contentScript.js
and replace it with your own logic that ultimately calls runtime.sendMessage
Although it'd probably would ultimately be a good idea to get rid of fullapp.js too and rewrite it so it's more maintainable. Unfortunately I don't have much experience in JS
How did you step through that?? For someone who doesn't have that much experience in js you certainly have me convinced. My Chrome doesn't even recognize that libvget, contentScript, or fullapp are even loaded so I cannot figure out how to step through it. Any tips would help.
So it seems it should be sufficient to chuck out contentScript.js and replace it with your own logic that ultimately calls runtime.sendMessage
Nice work! If we want to refine this extension, I think you're right the libvget needs to go and also I'd argue the angular piece.
and call some angular function to update the UI.
Is the angular piece also not fully understood? Usually angular is used for larger projects so I was surprised to see it used for this one.
How did you step through that?
Just setting a lot of breakpoints. Some sort of static analysis would probably give an easier way of seeing how (and where) the called functions are defined [perhaps loading it in one of jetbrain's IDEs?] but I have little experience in that land.
My Chrome doesn't even recognize that libvget, contentScript, or fullapp are even loaded so I cannot figure out how to step through it. Any tips would help.
You're opening up devtools on the extension popover window right? (index.html as opposed to background.html).
s the angular piece also not fully understood? Usually angular is used for larger projects so I was surprised to see it used for this one.
The angular function to update the UI I was referring to was b.$apply()
which from cursory googling appears to be an angular built-in that tells angular something has changed and to update the UI accordingly. All I really know about angular is that it allows for specifying directives directly in html that help bind the view to your underlying model and abstracts out the DOM manipulation (<div class="sourceItem" data-ng-repeat="src in video.sources">
). There appears to be a lot of other stuff in fullapp.js which appears to be angular boilerplate, although I'm not too sure (and i'm not really sure how all those modules and controllers fit together).
Interesting. I do see fullapp.js
but having trouble stepping through it. PITA. I'll keep trying to try to decouple / remove it to make it easier to debug.
A nice feature to the extension would be to override the autodetected link by libvget. Another nice item would be to check if the autodetected url is invalid i.e.
blob: https://asdadas
and show a message e.g.What do you think @pranav-prakash ?
This came up because I noticed on vidlock.tv, a specific link was showing up as a blob when an mp4 was playing. I noticed it was a blob when I moused over the cast link in the extension. I imagine it was due to an incorrect extraction by libvget where the wrong url was collected and it was prefixed with
blob:
so the url was invalid.I pressed the cast button and it failed to send the POST request as expected and so the XHR didn't show up in network tools and an error wasn't logged. Changing the user agent to a mobile browser also didn't work. I searched network connections to find the correct link to the mp4. With debugging enabled, I was able to overwrite
msg.sentLink
with the correct link to make the POST request work.