Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Try putting the compiled rtmpdump in /usr/bin. You can't use the one in macports because it doesn't have my patch for live games. Speaking of which, make sure you run Patch.sh in rtmpdump-patches before you 'make' or run 'make clean' and then apply Patch.sh. The instructions are in REQUIREMENTS-2009.txt.
I've done what you suggested. I think the problem lies somewhere in compiling it. I don't have an executable "rtmpdump" (i.e, the one file simply named "rtmpdump" that runs as a program). Is that my problem?
Code:
g++ -Wall -c -o bytes.o bytes.cpp
In file included from bytes.cpp:23:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o log.o log.cpp
g++ -Wall -c -o rtmp.o rtmp.cpp
In file included from dh.h:28,
from rtmp.h:43,
from rtmp.cpp:36:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o AMFObject.o AMFObject.cpp
In file included from dh.h:28,
from rtmp.h:43,
from AMFObject.cpp:36:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o rtmppacket.o rtmppacket.cpp
g++ -Wall -c -o rtmpdump.o rtmpdump.cpp
In file included from dh.h:28,
from rtmp.h:43,
from rtmpdump.cpp:32:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o parseurl.o parseurl.cpp
In file included from dh.h:28,
from rtmp.h:43,
from parseurl.cpp:29:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o dh.o dh.cpp
In file included from dh.h:28,
from dh.cpp:28:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o handshake.o handshake.cpp
In file included from dh.h:28,
from rtmp.h:43,
from handshake.cpp:37:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
handshake.cpp: In function ‘void InitRC4Encryption(uint8_t*, uint8_t*, uint8_t*, RC4_KEY**, RC4_KEY**)’:
handshake.cpp:80: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:88: error: ‘EVP_sha256’ was not declared in this scope
handshake.cpp:90: error: ‘digest’ was not declared in this scope
handshake.cpp: In function ‘void HMACsha256(const char*, size_t, const char*, size_t, char*)’:
handshake.cpp:217: error: ‘EVP_sha256’ was not declared in this scope
handshake.cpp: In function ‘void CalculateDigest(unsigned int, char*, const char*, size_t, char*)’:
handshake.cpp:227: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp: In function ‘bool VerifyDigest(unsigned int, char*, const char*, size_t)’:
handshake.cpp:238: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:240: error: ‘calcDigest’ was not declared in this scope
handshake.cpp: In member function ‘bool RTMP_LIB::CRTMP::HandShake(bool)’:
handshake.cpp:356: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:417: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:494: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:495: error: size of array ‘digest’ has non-integral type ‘<type error>’
handshake.cpp:500: error: ‘signature’ was not declared in this scope
handshake.cpp:530: error: size of array ‘signatureResp’ has non-integral type ‘<type error>’
handshake.cpp:531: error: size of array ‘digestResp’ has non-integral type ‘<type error>’
make: *** [handshake.o] Error 1
Last edited by edouble312; 05-19-2009 at 01:31 PM.
Sorry to cut in on this thread, but is this the longest thread ever for Linuxquestions?
As daftcat said, it's probably not the longest thread. But it certainly shows the enthusiasm for a good cross-section of two typically very passionate and intellectual groups of people...LINUX USERS and BASEBALL FANS.
When I run stdout.py, I get this, with an archived game: http://pastebin.com/f8dbcdac Note that it just cuts out at the end and does nothing. There is nothing to wait for. No buffering, it gives me back a terminal. This is with xhost + run on his computer through vnc, and then x_display=:0.0
This is the EXACT same game which downlaos perfectly with soapevent.py.
So regardless of what *should* be working, it doesn't work with mlbviewer, or stdout.py, in a terminal opened over vnc or one opened through ssh. Note that the second output is exactly what I posted before. The 0% line makes it look like it is downloading and I just need to wait more, but This time, just like last time, it prints it out but then cuts to a terminal (I.E. crashes).
In order to make sure I did it right, I deleted my config, ran mlbviewer, and then added in my username, password, autosync to mplayer, favorite team, x_display, video_follow=nya use_nexdef=False.
and, part of the problem may be that TEE IS MESSING THINGS UP. When I run ./test/stdout.py blah I get DIFFERENT OUTPUT than ./test/stdout.py blah | tee /tmp/blah.txt as in it is somehow messing with what I am seeing. If you can figure that out, that may help you debug, as currently, everything I run beside soapevent.py crashes and cuts back to the terminal, meaning it is impossible that the issue is I am not waiting long enough for streaming Everything I have posted is a log of a completed command, so stuff like 0.0% or whatever at the bottom does not mean it is streaming, because it crashed. The same is true for mlbviewer. It just fails and exits.
Are you sure VNC is using display of :0.0. VNC sometimes creates virtual displays with an offset like :10.0. If at all possible, I would either pay your grandfather a visit and try directly on his machine. For "xhost +" to work, it MUST be executed on the machine itself (not remotely through ssh or vnc.) Xhost is a security measure to prevent remotely connected sessions from launching X applications on the local display. So xhost + has to be executed on the local display to allow remote clients to manipulate the local display from a remote session. The other option is to have your grandfather enter that command himself. Basically, you're running into a security issue and a non-standard configuration question. It's not an entirely unsupported configuration because I run it like you intend to all the time. But it's also not a default configuration.
So....before you get too impatient with me...
1a. Either pay grandfather a visit and verify the configuration on his machine directly (take the remote session out of the picture), or...
1b. Have grandfather type "xhost +":
Code:
$ xhost +
access control disabled, clients can connect from any host
2a. If you try with mlbviewer, x_display=:0.0 must be in the configuration.
2b. If you use stdout.py, you will need to set the DISPLAY variable manually before using stdout.py:
Code:
$ export DISPLAY=:0.0
Don't bother with soapevent.py. It's not a workable solution for your grandfather because of a bug in rtmpdump.
3. Remember I asked you to comment out the last two lines of stdout.py so that you could copy and paste the commands. Now uncomment those last two lines before you test (either directly on his machine) or after he has typed "xhost +".
I would personally prefer that you pay him a visit to take the whole remote session out of the picture but I'm not sure if that is feasible if you two are geographically separated by a considerable distance.
I've done what you suggested. I think the problem lies somewhere in compiling it. I don't have an executable "rtmpdump" (i.e, the one file simply named "rtmpdump" that runs as a program). Is that my problem?
Code:
g++ -Wall -c -o bytes.o bytes.cpp
In file included from bytes.cpp:23:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o log.o log.cpp
g++ -Wall -c -o rtmp.o rtmp.cpp
In file included from dh.h:28,
from rtmp.h:43,
from rtmp.cpp:36:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o AMFObject.o AMFObject.cpp
In file included from dh.h:28,
from rtmp.h:43,
from AMFObject.cpp:36:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o rtmppacket.o rtmppacket.cpp
g++ -Wall -c -o rtmpdump.o rtmpdump.cpp
In file included from dh.h:28,
from rtmp.h:43,
from rtmpdump.cpp:32:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o parseurl.o parseurl.cpp
In file included from dh.h:28,
from rtmp.h:43,
from parseurl.cpp:29:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o dh.o dh.cpp
In file included from dh.h:28,
from dh.cpp:28:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
g++ -Wall -c -o handshake.o handshake.cpp
In file included from dh.h:28,
from rtmp.h:43,
from handshake.cpp:37:
bytes.h:73:2: warning: #warning "Byte order not defined on your system, assuming little endian!"
bytes.h:79:2: warning: #warning "Float word order not defined, assuming the same as byte order!"
handshake.cpp: In function ‘void InitRC4Encryption(uint8_t*, uint8_t*, uint8_t*, RC4_KEY**, RC4_KEY**)’:
handshake.cpp:80: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:88: error: ‘EVP_sha256’ was not declared in this scope
handshake.cpp:90: error: ‘digest’ was not declared in this scope
handshake.cpp: In function ‘void HMACsha256(const char*, size_t, const char*, size_t, char*)’:
handshake.cpp:217: error: ‘EVP_sha256’ was not declared in this scope
handshake.cpp: In function ‘void CalculateDigest(unsigned int, char*, const char*, size_t, char*)’:
handshake.cpp:227: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp: In function ‘bool VerifyDigest(unsigned int, char*, const char*, size_t)’:
handshake.cpp:238: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:240: error: ‘calcDigest’ was not declared in this scope
handshake.cpp: In member function ‘bool RTMP_LIB::CRTMP::HandShake(bool)’:
handshake.cpp:356: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:417: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:494: error: ‘SHA256_DIGEST_LENGTH’ was not declared in this scope
handshake.cpp:495: error: size of array ‘digest’ has non-integral type ‘<type error>’
handshake.cpp:500: error: ‘signature’ was not declared in this scope
handshake.cpp:530: error: size of array ‘signatureResp’ has non-integral type ‘<type error>’
handshake.cpp:531: error: size of array ‘digestResp’ has non-integral type ‘<type error>’
make: *** [handshake.o] Error 1
There's a thread on rtmpdump support forums about compiling for OS X. I've asked them to supply the patch to MacPorts with the FCSubscribe patch (the one in rtmpdump-patches) I have provided to several people on the forums.
I'll let you know if/when macports accepts the patch.
I probably won't have access to an OS X machine until I visit my folks over Father's Day (late June.)
The problem you have with the macports version is that the original code (before my provided patch) doesn't allocate enough memory for one of the setup messages which contains a huge amount of information. I can try to pare down the amount of information I include but unless you can get it to compile following the patches in that thread (plus my FCSubscribe patch), you won't get live games.
There's a thread on rtmpdump support forums about compiling for OS X. I've asked them to supply the patch to MacPorts with the FCSubscribe patch (the one in rtmpdump-patches) I have provided to several people on the forums.
I'll let you know if/when macports accepts the patch.
I probably won't have access to an OS X machine until I visit my folks over Father's Day (late June.)
The problem you have with the macports version is that the original code (before my provided patch) doesn't allocate enough memory for one of the setup messages which contains a huge amount of information. I can try to pare down the amount of information I include but unless you can get it to compile following the patches in that thread (plus my FCSubscribe patch), you won't get live games.
thanks I might give it a go and see what happens. at least the nextdef works really well and wasn't much of a pain to set up
If you want to be even more low key I can make an edit...
Before you make an edit tell me how you run mlbviewer with windows? A friend of mine is very interested in mlbviewer but he doesn't use linux and doesn't have either the time nor the interest to learn. But he loved watching in mplayer instead of the flash play.
When I say I ran it over VNC, what that meant is that I took control of his mouse remotely and opened a terminal on his machine (and his display), and typed in the command, and the keystrokes were entered on his machine into a terminal running solely on his machine, and the command was executed. VNC just means there was no funky business, it was actually executed on his machine, exactly as if I had been moving his mouse and typing on his keyboard.
It was exactly as if he had typed xhost + into a terminal on his machine. (it did print out that exact message)
I did set x_display to :0.0
I didn't set the DISPLAY to :0.0
mlbviewer still didn't work, and using tee to log it made it give different output.
I will try stdout with DISPLAY set to :0.0 and post again.
EDIT:
No, stdout does not work when running it over ssh. It also does not work when running it from his computer. It does not work in both cases if the last two lines are removed and I manually copy the lines and execute them, or if they are not commented out. If the lines are there, I get "DEBUG: Set duration: 8338.670867
ERROR: main: Failed writing, exiting!
Closing connection... done!
"
If the lines are not and I execute the command manually, I get "DEBUG: Set duration: 8338.670867
0.752 KB (0.0%)user@hose:~/mlb/mlbviewer-svn$ " As in it cuts out partway through to a terminal without giving a newline. Both behave exactly the same if typed in on his computer or over ssh.
If you want to be even more low key I can make an edit...
I don't need to cover it up completely. I think the determined user should be rewarded. I just don't want to use their forums to tell them that we beat them.
Before you make an edit tell me how you run mlbviewer with windows? A friend of mine is very interested in mlbviewer but he doesn't use linux and doesn't have either the time nor the interest to learn. But he loved watching in mplayer instead of the flash play.
Install cygwin with gcc, make, subversion, wget, vi, and python. Don't assume any of these will be installed by default. Keep the setup.exe handy as cygwin has a tendency of leaving important things out.
Once you have a cygwin environment, you should be able to follow the same instructions in the REQUIREMENTS document. He has a choice of going with autobahn.jar or using the Windows nexdef exe. I recommend the exe if he has no interest in Linux. It keeps things simple.
Hey! 3000K stream is back! 1280x720 baby! Hadn't seen even the option for it for about 2 or 3 weeks, and now it's coming down smooth even. In facty, even browsing around and downloading stuff it works so smoothly that it just reinforces the idea that both my internet connection and computer are plenty fast for all they've got, the problems are all on MLB end.
When I say I ran it over VNC, what that meant is that I took control of his mouse remotely and opened a terminal on his machine (and his display), and typed in the command, and the keystrokes were entered on his machine into a terminal running solely on his machine, and the command was executed. VNC just means there was no funky business, it was actually executed on his machine, exactly as if I had been moving his mouse and typing on his keyboard.
It was exactly as if he had typed xhost + into a terminal on his machine. (it did print out that exact message)
I did set x_display to :0.0
I didn't set the DISPLAY to :0.0
mlbviewer still didn't work, and using tee to log it made it give different output.
I will try stdout with DISPLAY set to :0.0 and post again.
EDIT:
No, stdout does not work when running it over ssh. It also does not work when running it from his computer. It does not work in both cases if the last two lines are removed and I manually copy the lines and execute them, or if they are not commented out. If the lines are there, I get "DEBUG: Set duration: 8338.670867
ERROR: main: Failed writing, exiting!
Closing connection... done!
"
If the lines are not and I execute the command manually, I get "DEBUG: Set duration: 8338.670867
0.752 KB (0.0%)user@hose:~/mlb/mlbviewer-svn$ " As in it cuts out partway through to a terminal without giving a newline. Both behave exactly the same if typed in on his computer or over ssh.
The first time, without the commented lines sounds like rtmpdump is working except nothing is reading from the stdout channel. Can you verify that mplayer is installed, found in the default path, and working correctly?
Okay, quick test for X and display. From your ssh session, set the display to :0.0. Type xterm. If a new xterm appears on the VNC session than you have a) a VNC session that is indeed :0.0 and xhost + actually worked correctly. We can rule out xhost that way.
Next, use soapevent.py to record about 4 or 5 MB of a game and then use Ctrl-C to stop soapevent.py. You don't need to use tee for this. soapevent.py will dump to a file named after the event-id plus the mp4 suffix.
Now, it's doubtful that Xv extension will work over a VNC session, but you can try it anyway. If it doesn't work, then try the x11 video output. You probably won't get very good performance either through VNC or on the local display itsef, but at least you'll be able to tell that mplayer is working.
Finally, the one thing I haven't seen in any of your logs is mplayer output. So if you get this far (e.g. xhost is working because you spawned an xterm, mplayer is working because you played the dumped file), then remove the "-really-quiet" from the mplayer line and see what it's complaining about.
In other words, all the logs seem to indicate that rtmpdump is working just fine. There are (at least) two possibilities for not getting the video:
1. You still don't have permission to modify the local display despite what xhost is saying (xterm test will prove this one out)
-or-
2. Mplayer isn't found or isn't working.
Come to think of it, when you recompile mplayer, it defaults to /usr/local/bin for install which isn't (usually) in the default path. Thankfully, mplayer compiles everything it needs into the executable (statically linked libraries) so you can copy /usr/local/bin/mplayer to /usr/bin/mplayer.
In fact, try this first:
Code:
$ which mplayer
Then proceed from through the rest of the steps I laid out here.
Hey! 3000K stream is back! 1280x720 baby! Hadn't seen even the option for it for about 2 or 3 weeks, and now it's coming down smooth even. In facty, even browsing around and downloading stuff it works so smoothly that it just reinforces the idea that both my internet connection and computer are plenty fast for all they've got, the problems are all on MLB end.
which game are you getting it with? I'm watching yanks-o's (goodness a-rod is killing the ball) and still only have 2200
Install cygwin with gcc, make, subversion, wget, vi, and python. Don't assume any of these will be installed by default. Keep the setup.exe handy as cygwin has a tendency of leaving important things out.
Once you have a cygwin environment, you should be able to follow the same instructions in the REQUIREMENTS document. He has a choice of going with autobahn.jar or using the Windows nexdef exe. I recommend the exe if he has no interest in Linux. It keeps things simple.
Okay, Cygwin has to be installed. I was thinking that he was using it in straight windows... so there is much more to it. But even so I understand your point of not waving a red flag in front of a bull and enraging it.Flying below the radar is alway the smart way to go regardless of principal in the world we live in today.
Would the rtmpdump that works with linux work with Mac too? If so, I could email the guy the small file if it isn't compiling for him. God, I love being able to avoid NexDef. The stream never breaks up when I don't use it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.