Trying to stream video from Amiko Mini HD SE to Windows
- Thread starter N6BY
- Start date
- Latest activity Latest activity:
- Replies 81
- Views 31K
- Status
It should work don't have my dish setup yet to try but i installed the amiko app and it found my mini had se
I posted it here for the others with working setups to try
I posted it here for the others with working setups to try
I've ran bluestacks before, it is mostly for gaming type apps. You need a decent computer for bluestacks or it will cause you massive problems and headaches. As I recall there are some fine print things with it. Don't remember exactly what but bundleware or limitations or having to pay after a period or some other undesirable catch. I won't touch it again personally.
Well been messing with this the last hour or so. With blue stacks, the BIG2small or the AMIKO streamer either one load up fine and find the MINI HD SE and load up my channel list. Gets you all exited, but MXPlayer keeps crashing with bluestacks.Did it work or is this supposed to work?
So working on a different approach right now.
BTW with bluestacks I could not get anything web related to work, satguys app fb etc, unless I pulled my wired connection to the computer and switched to WIFI. I guess it is emulating a phone and those don't have Ethernet jacks.
Installed Bluestacks on Windows 7 then installed Big2Small and MX Player. Selected the channel from the list that the Amiko was already tuned to for simplicity. I get a message saying that it will take 5 to 20 seconds and a spinning circle appears with hard drive activity but that's as far as it goes. Definitely promising so I'll try again tomorrow. May also try it under a Windows virtual machine in Linux. Thanks for the program tip jmc98, it's the farthest I've gotten so far.
Definitely promising so I'll try again tomorrow. May also try it under a Windows virtual machine in Linux. Thanks for the program tip jmc98, it's the farthest I've gotten so far.
I have gathered a few clues from the last few packet captures I did. It really helps me having a hardware ethernet tap so I can watch the traffic and get a sense of what is happening with both the client and server in real-time.
I didn't find any documentation or user manual for 'Big2Small'. Having that would help a lot, because I don't even know the full capabilities of either the client or the server. I can only guess unless someone can tell me where to find the user manual. Is there one?
The following is what I observed in some packet capture sessions:
1) It appears that you can start a stream from one android device and at least try to play or resume it on another device, not necessarily android. For example, I can start a stream the normal way (using Big2Small on a phone). This effectively "Opens" the stream and assigns it a stream number. Then I can reference the stream by the stream number and send a request from VLC to ask to play the particular stream. I entered "rtsp://192.168.2.101:554/stream=1" in VLC's Open Network URL field. Looking at the subsequent captured packets in WireShark, the Amiko Mini HD server responds 'OK' to VLC's request to play the stream! In summary, I think VLC successfully opened existing stream 1 that was defined by the SAT channel that Big2Small
So the server 'OK' means that everything is good as far as it is concerned. But on the client side, VLC on Windows said it was unable to play the stream. My guess is that VLC now finally sees the stream, open and being fed to it, but doesn't understand its contents. It seems now that we either need to find the appropriate video codec, or try to play the stream from another program.
2) I saw a new GET request on the most recent packet capture session. The request was similar to 'get_channel_list' as I saw yesterday, but it this time it did a 'get_pvr_list'. This is probably the IP addresses of all the Amiko servers on the network. I have not listed out the contents of the pvr list yet.
Anyway, the above is part observsation and part speculation. I will attempt to verify and duplicate these results after work today (my real job).
Brett
I didn't find any documentation or user manual for 'Big2Small'. Having that would help a lot, because I don't even know the full capabilities of either the client or the server. I can only guess unless someone can tell me where to find the user manual. Is there one?
The following is what I observed in some packet capture sessions:
1) It appears that you can start a stream from one android device and at least try to play or resume it on another device, not necessarily android. For example, I can start a stream the normal way (using Big2Small on a phone). This effectively "Opens" the stream and assigns it a stream number. Then I can reference the stream by the stream number and send a request from VLC to ask to play the particular stream. I entered "rtsp://192.168.2.101:554/stream=1" in VLC's Open Network URL field. Looking at the subsequent captured packets in WireShark, the Amiko Mini HD server responds 'OK' to VLC's request to play the stream! In summary, I think VLC successfully opened existing stream 1 that was defined by the SAT channel that Big2Small
So the server 'OK' means that everything is good as far as it is concerned. But on the client side, VLC on Windows said it was unable to play the stream. My guess is that VLC now finally sees the stream, open and being fed to it, but doesn't understand its contents. It seems now that we either need to find the appropriate video codec, or try to play the stream from another program.
2) I saw a new GET request on the most recent packet capture session. The request was similar to 'get_channel_list' as I saw yesterday, but it this time it did a 'get_pvr_list'. This is probably the IP addresses of all the Amiko servers on the network. I have not listed out the contents of the pvr list yet.
Anyway, the above is part observsation and part speculation. I will attempt to verify and duplicate these results after work today (my real job).
Brett
Installed Bluestacks on Windows 7 then installed Big2Small and MX Player. Selected the channel from the list that the Amiko was already tuned to for simplicity. I get a message saying that it will take 5 to 20 seconds and a spinning circle appears with hard drive activity but that's as far as it goes.
Don't forget to make sure your receiver is in a menu that is not playing video to your TV. The processor doesn't have the power to send to your TV and over network at the same time.
This is where the OPENRSTP i believe can come into play. The open rstp will take the place of big2small android client and setup the stream and once you get the OK response from the Amiko, you then you call VLC to call the waiting stream.
I will be out of commission today and tomorrow. We are going to be cleaning house and getting ready for hosting a Christmas party, so I will not be able to put any real time into this until Sunday.
I envision 3 entities to make this work. A program written by us to decode and arrange the channel information from the Amiko to the user. The user will select the channel, and the program will call the openrstp (command line program) with the command lines to setup and call the stream. Once the openrstp receives an OK (stream is ready) from the Amiko, our program will then call VLC with the appropriate RSTP call to request the waiting stream.
Nice work NCBY. I'm going to try and make a few hours next week to duplicate what you've done and go from there. If it in fact is sending an open rtsp stream I should be able to get it to work in VLC 2.04 with little to no mods. However, I did similar testing with HDhomerun attempting to get its RTP stream to work on Alien/Alien2. The problem with that device is I can open the stream on the computer. Once open I can use the RTP URL/port in any player I want....on the computer. If I attempt to open on another computer, Android or A1/A2 nothing happens. Long story short, the HDhomerun targets the RTP stream at the device that starts it and won't let you access the open stream from anything else. Hopefully Big2Small server does not act like this but it is a possibility. I'll be able to tell once I have time to test myself and see what packets are being sent between the Mini and the computer.
Once someone gets a raw stream playing on the computer without using an Android VM I think we are 90% there. Figuring out some sort of control system won't be difficult.
Once someone gets a raw stream playing on the computer without using an Android VM I think we are 90% there. Figuring out some sort of control system won't be difficult.
I had a chance to do a few packet captures this morning. Here is what I observed:
'get_pvr_list' -- I saw it once in a packet capture when I originally reported it on 12/19 and have not seen it since. Possibly the phone cached the pvr list and does not need it again?
'get_channel_list' -- In case anyone wants to study it, here is a link to a channel list of my Mini HD: http://www.naturalgfx.com/channel_list.txt This file is easy to obtain by simply by issuing the following from a command console: "curl -o channel_list.txt 192.168.2.101:8080/cfg/get_channel_list.cgi" (just substitute your own Mini's local network address). As you can see, it's a text file.
Finally, I read the satip specification provided by 'iBoston' in post #3 here and from what I've seen the Mini HD adheres to it, except for its unexplainable hiding of the '<presentationURL>' field in the XML file. The lack of a valid presentation URL field ***might*** be the reason that the Windows streaming video players don't play the stream.
If anyone wants to continue this, it seems to me like the documentation 'iBoston' linked to in post #3 is a must read. Also, I highly recommend getting a network tap. It's extremely useful for things like this, diagnosing your own network's problems, and keeping your network secure.
'get_pvr_list' -- I saw it once in a packet capture when I originally reported it on 12/19 and have not seen it since. Possibly the phone cached the pvr list and does not need it again?
'get_channel_list' -- In case anyone wants to study it, here is a link to a channel list of my Mini HD: http://www.naturalgfx.com/channel_list.txt This file is easy to obtain by simply by issuing the following from a command console: "curl -o channel_list.txt 192.168.2.101:8080/cfg/get_channel_list.cgi" (just substitute your own Mini's local network address). As you can see, it's a text file.
Finally, I read the satip specification provided by 'iBoston' in post #3 here and from what I've seen the Mini HD adheres to it, except for its unexplainable hiding of the '<presentationURL>' field in the XML file. The lack of a valid presentation URL field ***might*** be the reason that the Windows streaming video players don't play the stream.
If anyone wants to continue this, it seems to me like the documentation 'iBoston' linked to in post #3 is a must read. Also, I highly recommend getting a network tap. It's extremely useful for things like this, diagnosing your own network's problems, and keeping your network secure.
Last edited:
Well, i don't know a lot about streaming, and I am trying to educate myself, but If i am understanding things correctly, it is not at all what i thought it was.
I thought that the big2small client program was setting up and initiating the stream so that MxPlayer (video player) could then stream it directly from the Amiko Big2Small server.. I've come to realize that it appears to be that the big2small client app actually creates a .ts (embedded stream file) and the amiko streams it directly to Big2small client, and then the mxplayer is launched to play the big2small.ts file created by the big2small client app.
This again leads me back to OPENRTSP. I believe it has functionality to be able to save the stream to a file in which case then i can call a media player to play that .ts file.
My confusion lies in how does it write and erase a ts file on the fly. If it is creating the .ts file and then your calling that .ts file from a media program, eventually as your watching your stream, you would run out of harddrive space. So, i would assume it has to only keep a certain size of file.
This whole process seems bizarre, but this is what my research has dug up... My research so far entails :
I wrote a simple tcp communication program to talk directly with the Amiko Big2Small server. I made several attempts to direct the stream to allow another device to access it. Amiko didn't seem to bend to my will. Then through port scanning i checked the agent variable to see if at any time the communication was being handled by MxPlayer. It was not. The entire time, the communication was done via the big2small client app. I was also able to determine that MxPlayer was playing the stream from /data/data/com.ali.big2small folder and loading Big2Small.ts file. I copied the ts file from the android big2small data folder onto my windows7 desktop. I then used the windows media program to successfully play that .ts file. (actual (not live) portion of video/audio stream of what i was watching on tv played.)
My Eyes are blood shot, and I need a break. Can someone deny or confirm my train of thought.
I thought that the big2small client program was setting up and initiating the stream so that MxPlayer (video player) could then stream it directly from the Amiko Big2Small server.. I've come to realize that it appears to be that the big2small client app actually creates a .ts (embedded stream file) and the amiko streams it directly to Big2small client, and then the mxplayer is launched to play the big2small.ts file created by the big2small client app.
This again leads me back to OPENRTSP. I believe it has functionality to be able to save the stream to a file in which case then i can call a media player to play that .ts file.
My confusion lies in how does it write and erase a ts file on the fly. If it is creating the .ts file and then your calling that .ts file from a media program, eventually as your watching your stream, you would run out of harddrive space. So, i would assume it has to only keep a certain size of file.
This whole process seems bizarre, but this is what my research has dug up... My research so far entails :
I wrote a simple tcp communication program to talk directly with the Amiko Big2Small server. I made several attempts to direct the stream to allow another device to access it. Amiko didn't seem to bend to my will. Then through port scanning i checked the agent variable to see if at any time the communication was being handled by MxPlayer. It was not. The entire time, the communication was done via the big2small client app. I was also able to determine that MxPlayer was playing the stream from /data/data/com.ali.big2small folder and loading Big2Small.ts file. I copied the ts file from the android big2small data folder onto my windows7 desktop. I then used the windows media program to successfully play that .ts file. (actual (not live) portion of video/audio stream of what i was watching on tv played.)
My Eyes are blood shot, and I need a break. Can someone deny or confirm my train of thought.
Okay, i made another attempt to stream it live instead of through the .TS file. I don't know if they did that to create compatibility or if VLC cannot handle it.
With VLC, I started a UDP/Unicast Stream.
Open Network Stream : rtp://@:62894
I then told my RTSP client to tell Amiko to send stream to port 62894. I can confirm that Big2Small server is sending it to VLC and VLC is receiving it.
Here is the OUTPUT debug window from VLC :
main debug: `rtp://@:62894' successfully opened
qt4 debug: IM: Setting an input
rtp debug: detected MPEG2 TS
rtp debug: added payload type 33 (f = 90000 Hz)
rtp debug: added RTP source (29fa4e0e)
main debug: creating demux: access='' demux='ts' location='' file='(null)'
main debug: looking for demux module matching "ts": 63 candidates
ts debug: pid[110] unknown
ts debug: pid[100] unknown
ts debug: pid[5001] unknown
As you can see, VLC opens port and then detects a MPEG2 TS stream. BUT, no video or audio is displayed. Of course i would try and use MXplayer, but it isn't offered in a Windows Binary. So, because i cannot use MXplayer, i don't know if the problem lies in VLC not supporting something, or Big2Small Server not being 100% compliant. I worry about the 2nd part being Big2Small client was creating a .TS file stream under normal operations instead of trying to stream live.
I hope someone can add input....
With VLC, I started a UDP/Unicast Stream.
Open Network Stream : rtp://@:62894
I then told my RTSP client to tell Amiko to send stream to port 62894. I can confirm that Big2Small server is sending it to VLC and VLC is receiving it.
Here is the OUTPUT debug window from VLC :
main debug: `rtp://@:62894' successfully opened
qt4 debug: IM: Setting an input
rtp debug: detected MPEG2 TS
rtp debug: added payload type 33 (f = 90000 Hz)
rtp debug: added RTP source (29fa4e0e)
main debug: creating demux: access='' demux='ts' location='' file='(null)'
main debug: looking for demux module matching "ts": 63 candidates
ts debug: pid[110] unknown
ts debug: pid[100] unknown
ts debug: pid[5001] unknown
As you can see, VLC opens port and then detects a MPEG2 TS stream. BUT, no video or audio is displayed. Of course i would try and use MXplayer, but it isn't offered in a Windows Binary. So, because i cannot use MXplayer, i don't know if the problem lies in VLC not supporting something, or Big2Small Server not being 100% compliant. I worry about the 2nd part being Big2Small client was creating a .TS file stream under normal operations instead of trying to stream live.
I hope someone can add input....
From what I have seen so far in Wireshark captures, the stream only goes to the device that requested to start it. However, this is not a show stopper because we can initiate the stream from Windows, Mac, etc. on our own (with some easy coding) without needing the Big2Small android client program.
Thanks iBoston for the VLC debug log. It looks like VLC is having trouble around the line I highlighted in bold. This line is a good clue in determining whether VLC can deal with Amiko's stream. So, like you said, is the problem with VLC not supporting this type of stream or is it a non-compliant stream from the Amiko's server?
To try to answer the above question I have been studying the VLC source code so that when it reports an error I know more in-depth information about the issue its having. The key module in VLC which handles streaming media is 'live555.cpp'. You can find it here: https://github.com/videolan/vlc/blob/master/modules/access/live555.cpp
My plan for now is to look at the VLC source code and try to determine if it was designed to play this TS stream.
The VLC source code is a quite old, so I shifted my focus to OPENRTSP as mentioned by iBoston....
Meanwhile, on my Mac here I compiled OPENRTSP and it's streaming libraries. I ran it and verified that Amiko's server in its current form says that it supports the DESCRIBE command.
Here is what I saw after I entered the command 'openRTSP rtsp://192.168.2.101' on my Mac:
Office-iMac:BasicUsageEnvironment brettbolt$ openRTSP rtsp://192.168.2.101
Opening connection to 192.168.2.101, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://192.168.2.101 RTSP/1.0
CSeq: 2
User-Agent: openRTSP (LIVE555 Streaming Media v2014.12.17)
Received 148 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Server: ALi feng/2.1.0_rc1
Public: OPTIONS,DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN
Date: Week 4, 1 Mon0 0070 08:01:47 GMT
Sending request: DESCRIBE rtsp://192.168.2.101 RTSP/1.0
CSeq: 3
User-Agent: openRTSP (LIVE555 Streaming Media v2014.12.17)
Accept: application/sdp
Received 105 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 400 Bad Request
CSeq: 3
Server: ALi feng/2.1.0_rc1
Date: Week 4, 1 Mon0 0070 08:01:47 GMT
Failed to get a SDP description for the URL "rtsp://192.168.2.101": 400 Bad Request
Office-iMac:BasicUsageEnvironment brettbolt$
The interesting parts are bolded. I verified this RTSP session in Wireshark and this is indeed what is being sent and received. OPENRTSP is designed to send OPTIONS followed by DESCRIBE. If it gets a valid DESCRIBE it will then PLAY.
My best guess is that OPENRTSP got a DESCRIBE response of 'bad request' because it didn't do a proper SETUP first.
Next I will try a proper setup with all the channel/transponder info as given many posts ago and will see if I can get a good response for DESCRIBE.
I read through all the options for OPENRTSP (there are many), and it does have the ability to save to a file or a buffered file. It is a very powerful program along with the accompanying C++ libraries for multimedia streaming.
I'm guessing that Big2Small's 'file' is really a circular buffer of a fixed size. Big2Small probably writes to the circular buffer while MXplayer is reading and displaying the buffered video. That's how it doesn't run out of drive space. I believe that many DVRs work in a similar manner.
Meanwhile, on my Mac here I compiled OPENRTSP and it's streaming libraries. I ran it and verified that Amiko's server in its current form says that it supports the DESCRIBE command.
Here is what I saw after I entered the command 'openRTSP rtsp://192.168.2.101' on my Mac:
Office-iMac:BasicUsageEnvironment brettbolt$ openRTSP rtsp://192.168.2.101
Opening connection to 192.168.2.101, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://192.168.2.101 RTSP/1.0
CSeq: 2
User-Agent: openRTSP (LIVE555 Streaming Media v2014.12.17)
Received 148 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Server: ALi feng/2.1.0_rc1
Public: OPTIONS,DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN
Date: Week 4, 1 Mon0 0070 08:01:47 GMT
Sending request: DESCRIBE rtsp://192.168.2.101 RTSP/1.0
CSeq: 3
User-Agent: openRTSP (LIVE555 Streaming Media v2014.12.17)
Accept: application/sdp
Received 105 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 400 Bad Request
CSeq: 3
Server: ALi feng/2.1.0_rc1
Date: Week 4, 1 Mon0 0070 08:01:47 GMT
Failed to get a SDP description for the URL "rtsp://192.168.2.101": 400 Bad Request
Office-iMac:BasicUsageEnvironment brettbolt$
The interesting parts are bolded. I verified this RTSP session in Wireshark and this is indeed what is being sent and received. OPENRTSP is designed to send OPTIONS followed by DESCRIBE. If it gets a valid DESCRIBE it will then PLAY.
My best guess is that OPENRTSP got a DESCRIBE response of 'bad request' because it didn't do a proper SETUP first.
Next I will try a proper setup with all the channel/transponder info as given many posts ago and will see if I can get a good response for DESCRIBE.
It appears that I may need to modify OPENRTSP to send a proper SETUP before it attempts to do the DESCRIBE. It's 3:20 AM now in Calif. and I might not get this done before I fall asleep here.
Exactly, we will NOT be using the Big2Small client. When i did my testing, It was the same machine that it sent the stream too. You tell it what port to send the stream too, and Big2Small server will send the Mpeg stream via UDP on what ever port you specified. The OPENRTSP or the (simple rtsp program I wrote) basically is a com channel that has to stay open. Setup command tells server Amiko what to send. Describe command tells amiko to send a description of what it is sending. Play command sends stream. As I'm sure you know N6BY, the big2small client NEVER issues a DESRIBE command. So, does that mean that the stream file can be created without this information "OR" did big2small client take a short cut, knowing what type of stream amiko is always sending and only handle that situation in the first place.
The problem with the OPENRTSP working with Big2small server, is that openrtsp will never issue a TEARDOWN command. Command which tells the stream to stop, along with the other commands like PAUSE. We may not be able to enhance the system beyond what the Amiko SERVER has enabled.
I have NOT seen any proof and i don't think it is happening. MxPlayer just plays the TS file stream. I don't believe it does any communication with the big2small client and i don't think the big2small client issues any other commands other then setup and play. The problem being, that in the current Android implementation, you cannot truly pause your playback or properly stop a stream. -- I have noticed this in the real world operation of the android playing. I can only stop and play different channels so many times . ( around 1/2 dozen) and then the Amiko requires a reboot. I also noticed the same thing with my testing. Being my own little RTSP program has not been programmed to issue a TEARDOWN message, after about calling about 1/2 dozen stream sessions, Big2Small server starts returning a 902 error.
ASSUMING the server will handle TEARDOWN messages and possibly PAUSE messages correctly, its the jop of the rtsp client to remain connected. So, there are two connections at all times to the big2small amiko server. The TCP communication channel (ie rtsp channel) and the RTP (stream channel) where the big2small sends via UDP packets. It is then the job of the RTSP client to issue PAUSE, PLAY AND eventually a TEARDOWN message which properly stops the stream.
I agree you are on the right track. The SETUP command must be sent first. Then the DESCRIBE command which hopefully tells the OPENRTSP how to create the stream parameters. Then , through command line options, have OPENRTSP create the stream file. Then if VLC or some other player will play the stream, we are off to a good foundation.
I have tried to compile OPENRTSP for windows binaries and have not had luck so far. I am running visual studio 6.0 which should support it.
Also, another thing i forgot to mention in my testing why i think the DESCRIBE command is needed and where I might have fallen short. I modified my rtsp program to listen on the specified UDP port. When i issued the PLAY command, sure enough, big2small server started sending massive amounts of data to that specified UDP port. I then dumped that data into a binary file.
Unfortunately, again VLC wouldn't play it ( same as when i sent the stream directly to VLC). SOOOOO, this leads me to believe that big2small client is putting additional information into the file stream as a header BEFORE that actual stream. I would guess that is the same information that is sent via the describe command ( or at least the necessary information to create a proper header). Being big2small never issues a DESCRIBE command (this makes it a educated guess).
I have verified through WireShark logs, that Amiko server handles the DESCRIBE command and sends back data to that command.
Unfortunately, again VLC wouldn't play it ( same as when i sent the stream directly to VLC). SOOOOO, this leads me to believe that big2small client is putting additional information into the file stream as a header BEFORE that actual stream. I would guess that is the same information that is sent via the describe command ( or at least the necessary information to create a proper header). Being big2small never issues a DESCRIBE command (this makes it a educated guess).
I have verified through WireShark logs, that Amiko server handles the DESCRIBE command and sends back data to that command.
I no longer remember the reason, but I used to have a lot of video files with broken or missing headers. There was something, not VLC, that would play them just fine, starting with the first complete frame of video it found. I think it was MPlayer. It might be worth checking out whether it still does that.
- Status
Similar threads
