Suppose there is a Silverlight streaming video player on a random web site. How can I intercept the video stream and for example save it to file - i.e. the real source of the file.
I know some of the sites embed the source in tag - or at least that was the case with Flash. But sometimes, players are smarter than that and call some logic via web service. It is still possible to figure everything out by analyzing the .dll with reflector, but that is hardcore! Every player may have a different logic, so I figured out it would be easier to just get the current stream somehow.
Any thoughts?
Ooook! Got me an answer that could be used as a nice workaround. With the use of fiddler I was able to capture the traffic and figure out what's going on. Now I'm happily watchin the same video as before only using the uber feature of WMP that lets me play videos faster.
Related
I am running an apache2 graphite host from an Orange Pi One, having written a service to translate and send data from sensors on the GPIO to the carbon line receiver. My project is to incorporate all the I/O from the device into a dashboard.
There are loads of graphite dashboards, but I can't find one that has a simple video stream applet/plugin.
I have searched graphite-web github and can easily adapt dashboard.html, but I am not sure whether the entire file is a placeholder, and whether any additions would render properly after all the javascript has run and rendered the page. It would seem I might need to reverse engineer the javascript, which seems quite an effort for the simple task I want.
If I can figure out the video stream code for the CSI camera, then I can adapt it to modify the dashboard with all the other data I want to display.
So, I am really looking for some guidance on getting started with dashboard code modification?
You can use the text panel to add HTML content to the dashboard.
in short: i have some audio files in my local sqlitedatabse and want to play with with the native media player from android.
reffered to the documentation i can play an audio either by placing my audio file on the sd card or by streaming from server or by an URI.
There is no way to play an audio file by giving an byte array to the media player.
so my solution would be to build an CONTENTPROVIDER which lets my media player access the audio file in the database via an URI. I came up with that idea through this tutorial
http://www.vogella.com/articles/AndroidSQLite/article.html
Is this possible? Are there better ways to implement my issue?
If I understand your question correctly, you are proposing creating an artificial URL that you are then passing to the android system to be read, and you supply the data backing the URL by reading it from SQLite. That will probably work, and it solves some issues with content decoding, but it requires the creation of awkward URLs and sockets within the system. All that might not be the most reliable or efficient way to go.
The alternative is to decode the data yourself into PCM, and supply it to Android via an Audio Track. This would be superior because you aren't trying to create a hacked (and artificial) URL just to pipe a stream of data through, but it may require you to parse the data yourself and convert it to PCM. Depending on what formats you have in your database, this may be difficult and not worth it because Android libraries for these kinds of conversions are not as accessible. So, which way is best depends on your goals, but I think those are your two options.
I have a MediaElement that plays video. I have my video stored, in binary, in my SQL Server database.
The way this works out for me is that the Silverlight app reads ALL the binary data from a web service. The web service returns a byte[] that I turn into a stream, and set as source for the MediaElement.
The big problem with this is that it needs to read all the data before the MediaElement's source can be set. With large videos, this takes a long time.
So, I was hoping to somehow take chunks, and buffer as I go, like any online video player does.
Any clues on how I can actually do that?
I ended up doing this a bit different.
I couldn't figure out buffering from the DB, so we setup a mediaserver, and used the silverlight app, to stream from that instead.
I found this article on the Silverlight Forums, which has a similar question (audio instead of video).
The solution states:
"You can try to create a ASX file to hold the playlist and set the ASX file as the source of the MediaElement."
One of the links provided in the solution goes on to say:
"An ASX file is simply an XML file that specifies the media files in the playlist. Playlists provide, among other things, a central entry point for a group of media."
It sounds like you should be able set the source of your MediaElement to a Silverlight Playlist, or ASX File, and then download your video, in chunks (possibly as separate "files"), to that Playlist.
Hope this helps!
Does anyone know of a Silverlight Video player that permits "seeking" to a particular offset of the stream without having to download the whole thing?
I'm a bit new to this Silverlight gig, so will appreciate anything you can point me to to get me up to speed.
I come from a flash background, but I think this may apply to silverlight too.
Generally speaking, It's not the player that determines whether you can jump to a point in video but how the video is delivered.
Generally speaking - If you are downloading the video progressively over http, you will have to wait until the section of the video you want to skip to has been downloaded before you can jump to it. This is not always the case, YouTube, for example serve their content progressively. Also, this guy came up with another solution - http://www.flashcomguru.com/index.cfm/2005/11/2/Streaming-flv-video-via-PHP-take-two You may be able to find a similar workaround using dot net rather than php.
An easier way to achieve your goal, although not as cheap, would be to use a streaming server. You can use specific severs to allow actual video streaming, where you will be able to jump to various points in the video. I've found wowza quite good - http://www.wowzamedia.com/ Or to use a service like limelight or streamzilla. However they can be very very expensive.
I'm writing a pair of applications for distributing audio (among other features). I have a WPF program that allows an artist to record and edit audio. Clicking a button then uploads this to a silverlight-powered website. A consumer visiting this website can then listen to the audio. Simple. It works. But I'd like it to be better: I need an audio format that works seamlessly on both the recording and playback sides.
I'm currently using mp3 format, and I'm not happy with it. For the recording/editing, I use the Alvas Audio c# library. It works ok, but for MP3 recording requires that the artist goes into his registry to change msacm.l3acm to l3codecp.acm. That's a lot to ask of an end-user. Furthermore mp3 recording seems rather fragile when I install on a new machine. (Sometimes it randomly just doesn't work until you've fiddled around for a while. I still don't know why.) I've been told that unless I want to pay royalties to the mp3 patent holders, I always need to rely on this type of registry change.
So what other audio format could I use instead? I need something compressed. Alvas audio can also record to GSM, for example, but that won't play back in silverlight. Silverlight will play WMA, but I don't know how to record in that format - Alvas Audio won't. I'd be open to using another recording library instead, but I haven't managed to find one.
Am I missing something obvious, or is there really no user-friendly way to record audio in WPF and play it back in Silverlight? It seems like there should be...
Any suggestions greatly appreciated.
Thanks.
IMO, WMA would be your best bet. I'm not sure how your application is setup or how low level you want to go, but the Windows Media Format SDK is a great way to encode WMA and the runtimes come with Windows. There are .NET PIAs and samples for it here: http://windowsmedianet.sourceforge.net/
Given that Ogg Vorbis is being adopted for the new HTML audio tag in (cough) some browsers, it's probably worth checking it out. You won't get bitten by any licensing concerns if you follow this route. If ease of deployment is top of your list, then go with WMA.
[tries hard not to start ranting about fragmented state of codec options in browsers and the commercial interests that scupper any concensus]