[opensuse] Who does graphics rendering with ssh?
Hi. I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth. Greetings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/07/2014 13:15, jcsl a écrit :
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
I think it's x forxarding that do this, try VNC or better freenix/nomachine n! jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El Miércoles, 23 de julio de 2014 13:19:03 jdd escribió:
Le 23/07/2014 13:15, jcsl a écrit :
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
I think it's x forxarding that do this, try VNC or better freenix/nomachine n!
jdd
I think I tried VNC (ssvnc?) some time ago and it was noticiably slower. It didn't sent audio IIRC. I've heard good things about freenx. Greetings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2014-07-23 a las 13:15 +0200, jcsl escribió:
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Display processing is done on your local machine, yes. The procedure does not work well with video intensive apps, you have to use a different method. I think it is sending the full bitmap image of each frame, so perhaps reducing frame rate of the video could help. Just a bit. Better use a protocol designed to send video remotely. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPPnHkACgkQja8UbcUWM1yNyQD/d05aSuWihyXumdFBq+jmqfes NNDV6zsepSS/AO2Mc4gA/0rJ9hgf47sjnrav3OgTfyL1VQnZQA4L5GiqJEzLvAhF =di4x -----END PGP SIGNATURE-----
Le 23/07/2014 13:28, Carlos E. R. a écrit :
Better use a protocol designed to send video remotely.
yes, some sort of VLC use jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/23/2014 07:28 AM, Carlos E. R. wrote:
El 2014-07-23 a las 13:15 +0200, jcsl escribió:
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Display processing is done on your local machine, yes.
Just so. This is what X is about, separating the display engine from the compute engine. In ancient of days it followed the hallowed tradition of regular 'glass ttys' which worked that wy. UIX was a multi-user system and the Old Iron did not have graphics engines per user. The PC driven by Microsoft Windows and Apple MAC is the other way round. It is dominated by the single user per machine model and integrates the graphics engine into the compute engine, even to the point of then sharing memory. There have been a number of protocols that allow for graphics to be communicated efficiently. One of the most obvious is the old 1980s era PDI used for a while by ATT for information terminals at hotels and airports using a 1200 baud link. It could deal with the basic shapes and colours and made great use of bandwidth for that era. When the X protocol works at the same level it is fast, but that's not how much of 'graphics as pictures' works today. Drawing a rectangular dialog box by sending "coordinates, 'square', color' and text overlays is one thing. We can see similar with the way HTML forms are described. But detailed graphics is another matter. Its one thing to have it handled by a memory mapped unit on the same machine; its another to convert it to a serial stream of information for transmission over a data links, be it high speed IP packets or a 1200 baud modem. Think of television. That too is a stream of bits. Yes we have protocols that can compress video, delta encoding. But they make a LOT of assumptions that may not be valid in this circumstance and don't deal well with the 'scene shifts' of movies.
The procedure does not work well with video intensive apps, you have to use a different method.
I think it is sending the full bitmap image of each frame, so perhaps reducing frame rate of the video could help. Just a bit.
Better use a protocol designed to send video remotely.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 23 of July 2014 13:15:47 jcsl wrote:
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Try running glxinfo, then check the OpenGL renderer and vendor. Mesa will resort to software rendering if the drivers for the graphics card in the Xorg server (which is the client in this case) are missing.
Greetings. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El Miércoles, 23 de julio de 2014 14:30:29 auxsvr@gmail.com escribió:
On Wednesday 23 of July 2014 13:15:47 jcsl wrote:
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Try running glxinfo, then check the OpenGL renderer and vendor. Mesa will resort to software rendering if the drivers for the graphics card in the Xorg server (which is the client in this case) are missing.
Greetings.
It says OpenGL renderer is Mesa DRI Intel (R) IGD and OpenGL vendor is Mesa DRI Intel(R) IGD. No direct rendering. Server glx vendor is SGI and client glx vendor is NVIDIA Corporation. So effectively it's netbook's video card who is rendering the content... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El Miércoles, 23 de julio de 2014 13:15:47 jcsl escribió:
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Greetings.
To explain it better, I'm not trying to use the netbook to play HD content. I'm checking how ssh works. Maybe I'd want to run some heavy app in the netbook or something similar. And yes, I may want to play a video without worrying about if it is HD or not, but it is not the use case. And I'm not trying to control the server remotely (isn't it what VNC is for?) Greetings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/07/2014 13:43, jcsl a écrit :
worrying about if it is HD or not, but it is not the use case. And I'm not trying to control the server remotely (isn't it what VNC is for?)
no VNC is done to see what happen on an other computer, speed depends of network speed http://en.wikipedia.org/wiki/Thin_client jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/23/2014 07:43 AM, jcsl wrote:
And I'm not trying to control the server remotely (isn't it what VNC is for?)
Whatever gave you that impression? No, vnc is a protocol for remotely viewing the screen of another computer. In many ways its more relevant in the Windows world than the UNIX world. As I've mentioned, UNIX had X and X was based on the screen not being on the computer in the first place. Its only with Linux-on-pcs that we are behaving like Windows and having the display engine on the same machine as the compute engine. ssh has nothing to do with viewing screens. Its just a means of setting up an encrypted link between two computers. X-over-shh is just that. No different from smtp-over-shh or, ${DEITY} forbid, telnet over shh. ssh is going to slow things down over a simple, unencrypted link because of the overhead of the encryption. That's the price you pay for that security. With modern CPUs its not bad; the encryption variant used in httpS, for example we don't really notice -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-23 14:43, Anton Aylward wrote:
On 07/23/2014 07:43 AM, jcsl wrote:
ssh is going to slow things down over a simple, unencrypted link because of the overhead of the encryption. That's the price you pay for that security. With modern CPUs its not bad; the encryption variant used in httpS, for example we don't really notice
It is not usually that important. More important is that hardware acceleration breaks, the drivers not necessarily support the needed features. And in the case of video, it has to send many bitmaps, encrypted. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-07-23 13:43, jcsl wrote:
El Miércoles, 23 de julio de 2014 13:15:47 jcsl escribió:
To explain it better, I'm not trying to use the netbook to play HD content. I'm checking how ssh works. Maybe I'd want to run some heavy app in the netbook or something similar. And yes, I may want to play a video without worrying about if it is HD or not, but it is not the use case. And I'm not trying to control the server remotely (isn't it what VNC is for?)
No :-) unix/Linux X is natively a network system. It was designed originally with the idea of a central powerful computer and several dumb graphical displays with keyboard. It does not need vnc or anything to display a desktop on a different machine. But you may. You have to use different tools for each thing. Ssh is good for running, securely and remotely, some application, even over Internet. Many people use it for administration. Video acceleration breaks; though. Sending video is heavy, each frame is sent separately as a bitmap, about 25 per second, and lightly compressed (it has to be fast), and encripted. There are other protocols better suited for video (the vlc people have one). Or you can simply share the file (plain http works) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/23/2014 10:25 AM, Carlos E. R. wrote:
Sending video is heavy, each frame is sent separately as a bitmap, about 25 per second, and lightly compressed (it has to be fast), and encripted. There are other protocols better suited for video (the vlc people have one). Or you can simply share the file (plain http works)
Let's see: 1 full-frame = 1920x1080 = 2,073,600 bytes or ~2M at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video Bad idea to test how ssh works with that... I don't know if this helps the thread, but the way I would think of ssh (from an abstract point of view) is that ssh just gives you a terminal on the remote machine. It provides the connection. Just like an xterm connecting to your local machine, but instead of localhost, you are connected to a remote host. With ssh, you can basically run any app, manage the remote just like you would on your local machine. When you add X11Forwarding (ssh -x) you then have added the ability to run graphical applications on the remote and have them display locally. You are just adding a communication layer to what the basic ssh connection provides. Take a simple image display program like `feh`. If you `ssh -x` into the remote machine you can run `feh filename.jpg` and the display of the image will occur on your local machine. The image data still has to be read on the remote machine transferred to your local machine to display, so there are size consideration on what you want to attempt. Full HD video isn't a good idea over a normal 10M WAN connection. Sure ssh does a lot of other things, but for testing out ssh purposes and graphics rendering, that's pretty much it for the standard case. As far as connecting to a remote display or remote desktop, you still have a basic connection (ssh or otherwise), but X provides a means for you to interact with the remote system at the display or desktop level. Just an additional layer on top of your basic connection. For that, I have always liked rdesktop. Simple, but capable of giving you the remote display on your local screen. Flexible, you can run it full-screen or set the geometry as you like. You can choose the type of connection and tailor the amount of information you transfer back and forth to help with the speed of the connection. If you don't have it installed, then `sudo zypper in rdesktop`. Test them all out, but be mindful of what you are trying to pull over your connection. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 25, 2014 2:43:53 AM EDT, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 07/23/2014 10:25 AM, Carlos E. R. wrote:
Sending video is heavy, each frame is sent separately as a bitmap, about 25 per second, and lightly compressed (it has to be fast), and encripted. There are other protocols better suited for video (the vlc people have one). Or you can simply share the file (plain http works)
Let's see:
1 full-frame = 1920x1080 = 2,073,600 bytes or ~2M
at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video
8 bit color on a HD display! -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/25/2014 06:59 AM, Greg Freemyer wrote:
at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video 8 bit color on a HD display!
Oh... Wasn't that already in the mix? 1 full-frame = 1920x1080 = 2,073,600 *bytes* (8 bits per byte/pixel) or ~2M at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video I guess my abbreviations were confusing. If we were taking about bits, or Mega bits, per sec, then then ~50 M/s * 8 bits/pixel => ~400 Mbits/s :) I can never remember the standard for transmittal units, whether to give them in bits or bytes. I always end up having to divide the numbers out to confirm throughput.... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jul 25, 2014 at 11:52 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 07/25/2014 06:59 AM, Greg Freemyer wrote:
at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video
8 bit color on a HD display!
Oh...
Wasn't that already in the mix?
1 full-frame = 1920x1080 = 2,073,600 *bytes* (8 bits per byte/pixel) or ~2M
at 25 frames per sec, that's ~50 M/s needed for uncompressed HD video
I guess my abbreviations were confusing. If we were taking about bits, or Mega bits, per sec, then
then ~50 M/s * 8 bits/pixel => ~400 Mbits/s :)
I can never remember the standard for transmittal units, whether to give them in bits or bytes. I always end up having to divide the numbers out to confirm throughput....
David, You missed my point. It is 50 million pixels of color information per second as you say, but you are using 8-bits per pixel, that is pretty shabby for a HD display. RGB often uses 24-bits. The HDMI interface requires at least 30-bits: http://en.wikipedia.org/wiki/Color_depth#Industry_support So it is ~50 M pixels/s * 30 bits/pixel => ~1.5 Gbits / sec So a 1 Gigabit NIC can't keep up with the needs of the display even ignoring overhead concerns. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/25/2014 02:00 PM, Greg Freemyer wrote:
David,
You missed my point.
It sailed silently overhead in the flight-levels.
It is 50 million pixels of color information per second as you say, but you are using 8-bits per pixel, that is pretty shabby for a HD display.
RGB often uses 24-bits. The HDMI interface requires at least 30-bits:
http://en.wikipedia.org/wiki/Color_depth#Industry_support
So it is ~50 M pixels/s * 30 bits/pixel => ~1.5 Gbits / sec
Damn, video is just huge. When I shoot in widescreen (1280x720) the uncompressed dvi is just over 158 Mb/s. From a bit standpoint that would be 1.26 Gbits/s. I cringe each time I have to download another hour of tape. That was a good link. I still thought true-color was the biggest hog. They might as well go ahead and define color depth as 'uint32_t' and get it over with...
So a 1 Gigabit NIC can't keep up with the needs of the display even ignoring overhead concerns.
So that's probably not a good idea to try it over my 100TX segments? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El Miércoles, 23 de julio de 2014 13:15:47 jcsl escribió:
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Greetings.
Ok. Thank you all for your answers. Greetings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jcsl wrote:
El Miércoles, 23 de julio de 2014 13:15:47 jcsl escribió:
Hi.
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video....
Math? 1920x1080x3 (assuming 24bits/pixel for color x 30 frames / second = 186624000 = 186.6 Mb/s. Your fast speed on your ethernet is 100Mb/s. Not gonna happen to decode on player and then display. Best case would be if the compressed stream from disk was sent to your laptop and it could do the decoding and display in real time. BUT, it's still going to be a pain to make it fit. I wouldn't go over 720p in your case and at >82Mb/s that's still be REALLY pushing it, but if your laptop can decode it the source 720p is probably small enough. Sorry no better news. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2014-07-24 a las 08:13 -0700, Linda Walsh escribió:
Best case would be if the compressed stream from disk was sent to your laptop and it could do the decoding and display in real time. BUT, it's still going to be a pain to make it fit.
Not really. I do it with my "mediacenter" device. In one mode it pulls the file from my desktop, via samba, and displays it on the TV. It has a very slow network speed, about 1 MB/S top, yet it works at TV resolution just fine: Video ID : 224 (0xE0) Format : MPEG Video Format version : Version 2 Format profile : Main@Main Format settings, BVOP : Yes Format settings, Matrix : Custom Format settings, GOP : M=3, N=21 Duration : 1h 33mn Bit rate mode : Variable Bit rate : 3 048 Kbps Maximum bit rate : 15.0 Mbps Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate : 25.000 fps Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 0.294 Stream size : 1.99 GiB (90%) It is about 3 GB file size per hour, not difficult to send over the local network at all, or USB disk. It is not 1080 res, though, in my case. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPRT0AACgkQja8UbcUWM1yftwD/XDCFE6OCLi/FwRmwt38F6CHP ma9TISye5WYfjfhNlNgA/1BqVi+TY0/0t3x2OdyymOA3DndL6q9Ieyo2PwoZVf1f =vkD/ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
El 2014-07-24 a las 08:13 -0700, Linda Walsh escribió:
Best case would be if the compressed stream from disk was sent to your laptop and it could do the decoding and display in real time. BUT, it's still going to be a pain to make it fit.
Not really.
---- REALLY! You are taking about encoded streams ... and that's not what the original author was talking about -- he was talking about decoding on his server, then watching the video, transfered "raw" (undecoded) on a remote device. That isn't what your media center is doing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2014-07-24 a las 20:07 -0700, Linda Walsh escribió:
Carlos E. R. wrote:
El 2014-07-24 a las 08:13 -0700, Linda Walsh escribió:
Best case would be if the compressed stream from disk was sent to your laptop and it could do the decoding and display in real time. BUT, it's still going to be a pain to make it fit.
Not really.
---- REALLY!
You are taking about encoded streams ... and that's not what the original author was talking about -- he was talking about decoding on his server, then watching the video, transfered "raw" (undecoded) on a remote device.
That isn't what your media center is doing.
I know it is not what the OP was doing. It is what YOU are suggesting to do instead ;-) That is, send the compressed stream, compressed, from one machine to a second machine, via network, and this second machine doing the decompressing and precessing necesary to show on its own display. And that is what my media center does, in one of the possible modes it has. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPTFY0ACgkQja8UbcUWM1xjoQD9HWTxT6H6ZOSQXGI7rb3CXl91 N8AZB3TmlFUOkQ/zTM4A/0m6Lh3LkfKu8B7lZU2IvV4FljpvyIUcI75Av9EZ3GTg =UgPm -----END PGP SIGNATURE-----
Carlos E. R. wrote:
El 2014-07-24 a las 08:13 -0700, Linda Walsh escribió:
Best case would be if the compressed stream from disk was sent to your laptop and it could do the decoding and display in real time. BUT, it's still going to be a pain to make it fit.
Not really.
---- REALLY!
You are taking about encoded streams ... and that's not what the original author was talking about -- he was talking about decoding on his server, then watching the video, transfered "raw" (undecoded) on a remote device.
That isn't what your media center is doing.
I know it is not what the OP was doing. It is what YOU are suggesting to do instead ;-)
Oh frack. Talk about confused on multiple levels... Am having one of those weeks/months... The month before the Ides of August isn't a great time for me "historically"... (increases in stupid mistakes... larger chance of injury... sigh...)... guess it's that time of the year for me... ;-/ I try to be careful when I give out tech advice, I really do... takes me hours to write 1 email some times. I'll "re-research" stuff that I think I know to make sure things haven't changed and such. But when it comes to doing BW calculations off the top of my head... I should have written a script ... grrr... I do watch 1080p video read from disk and decoded on PC... Shouldn't be too much of a stretch for most modern HW, but some people on lower end machines or older ones have reported problems with some of the new 10bit formats. Of course the video makers keep upping the bitrates w/lower compresssion. Noticed a recent anime offering from Coalgirls... overall bitrate 11.1Mbps. They excel in oversize .mkv's. P.s. sorry for my confusion... time to move to triple check mode...;-( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/07/2014 05:21, Linda Walsh a écrit :
I do watch 1080p video read from disk and decoded on PC... Shouldn't be
sorry, I coudn't read the hole thread (not at home), but do not forget there are different kind of compression, some much less asking to the processor than others, and HD video content is sent over the air by TV, so it's not that difficult, and receiving TV are often very cheap, so certainly no very complicated hardware involved. jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2014-07-26 a las 08:03 +0200, jdd escribió:
Le 26/07/2014 05:21, Linda Walsh a écrit :
I do watch 1080p video read from disk and decoded on PC... Shouldn't be
sorry, I coudn't read the hole thread (not at home), but do not forget there are different kind of compression, some much less asking to the processor than others, and HD video content is sent over the air by TV, so it's not that difficult, and receiving TV are often very cheap, so certainly no very complicated hardware involved.
Absolutely. And these same things have dificulties decoding a simple .avi file. Mine can not, at all. I believe my TV "multimedia" center has some decoding in hardware. I'm using another device now, made by Philips, which sometimes stutters with very same files recorded from TV on my device mentioned above. Avis I have to "expand" somewhat so that they work better. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPThaUACgkQja8UbcUWM1wwrQEAjB11v8aYRddcZHCtiJM4UI1D fGgBx41m/HGBqIQMQ7EA/2ZD/0fb+Jgq4Ra7GmlMhSVx7Bq673gNVJqgN2JPWsKU =KY2/ -----END PGP SIGNATURE-----
On 07/24/2014 10:13 AM, Linda Walsh wrote:
Math?
1920x1080x3 (assuming 24bits/pixel for color x 30 frames / second = 186624000 = 186.6 Mb/s.
Your fast speed on your ethernet is 100Mb/s.
Linda, Are you talking about a 100TX or 1000TX connection? I'm guessing you are talking about the average real-world throughput over 1000TX, because on a 100TX segment, it would be about 1/10th that. Then, if the data is cached to disk before display, at times on the 1000TX connection, you bump up against the r/w capability of older sata drives/controllers of about 70 Mb/s. I guess that's part of what happens when the video freezes and our old friend: buffering..... is displayed :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 07/24/2014 10:13 AM, Linda Walsh wrote:
Math?
1920x1080x3 (assuming 24bits/pixel for color x 30 frames / second = 186624000 = 186.6 Mb/s.
Your fast speed on your ethernet is 100Mb/s.
Linda,
Are you talking about a 100TX or 1000TX connection? I'm guessing you are talking about the average real-world throughput over 1000TX, because on a 100TX segment, it would be about 1/10th that.
Actually at least a double error -- I went for "bytes" (the mul*3 @24bits/pixel) then used the wrong suffix, and then stupidly compared that to 100Mb (original author said his interface was a 10/100). So yeah... its even more impossible than I suggested. so the above should have been 1.49Gb, which as you point out, wouldn't even be possible on a 1000TX connection.
Then, if the data is cached to disk before display, at times on the 1000TX connection, you bump up against the r/w capability of older sata drives/controllers of about 70 Mb/s. I guess that's part of what happens when the video freezes and our old friend:
---- I'd be very surprised to see such rates on any HW still in service. to get speeds like that you'd have to go back to a low-density 5400RPM drive -- I was getting a bit over 100MB/s on a laptop drive 15 years ago (it was 7200RPM). Now, a single 4K SATA is spec'd at about 170-180MB/s sustained. But yeah... math and abbreviation errors != clear communication. Thanks for the catch! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
auxsvr＠gmail.com -
Carlos E. R. -
David C. Rankin -
Greg Freemyer -
jcsl -
jdd -
Linda Walsh