Reply to thread

Message

I'm sorry to butt in, but I have to pick up on this point. The only extra hardware requirement for timeshifting client side would be maybe 2-10Gb more hard drive space (depending on how long you want the timeshift buffer to be).

I've noticed a few comments in this thread that point towards using a more powerful server and a less powerful client with what seem to me to be little understanding of what actually happens in each part of the process.

The most cpu intensive part of the process by far is actually decoding and displaying the video, especially for HD. For HD without DxVA you'll need at the very least a 2Ghz machine. With DxVA or for SD you can get away with less cpu power, but you still need a decent video card that supports DirectX 9.

Capturing from the Tuner/Capture Device to Timeshift Buffer uses almost no cpu power. The most intensive part of the capture process would be disk access. It requires the hard disk to write at up to the same data rate as full transport stream. That's about 2.5 Mb/s from memory, which is far less than the limit of hard drives. You can easily save several transport streams to disk simultaneously.

Assuming that the sever is just saving the timeshifting buffers not decoding or display the video then you would get away with using quite a low end system. The only requirement might be to make sure the hard drives are fast enough if you want to capture lots of streams at once.

As pointed out already, the most limiting factor is going to be network bandwidth so there needs to be an effort to reduce the number of streams going across the network at once. I think bear's idea offers the best way to reduce network load. The problem raised is how to timeshift to a time before the client starts watching. I would suggest that the easiest way to fix this is to have the client always running in the background saving it's own timeshift buffer. Then when the user starts watching they already have a timeshift buffer built up.

Nate

<blockquote data-quote="nate" data-source="post: 44363" data-attributes="member: 10474">I'm sorry to butt in, but I have to pick up on this point. The only extra hardware requirement for timeshifting client side would be maybe 2-10Gb more hard drive space (depending on how long you want the timeshift buffer to be).I've noticed a few comments in this thread that point towards using a more powerful server and a less powerful client with what seem to me to be little understanding of what actually happens in each part of the process.The most cpu intensive part of the process by far is actually decoding and displaying the video, especially for HD. For HD without DxVA you'll need at the very least a 2Ghz machine. With DxVA or for SD you can get away with less cpu power, but you still need a decent video card that supports DirectX 9. Capturing from the Tuner/Capture Device to Timeshift Buffer uses almost no cpu power. The most intensive part of the capture process would be disk access. It requires the hard disk to write at up to the same data rate as full transport stream. That's about 2.5 Mb/s from memory, which is far less than the limit of hard drives. You can easily save several transport streams to disk simultaneously.Assuming that the sever is just saving the timeshifting buffers not decoding or display the video then you would get away with using quite a low end system. The only requirement might be to make sure the hard drives are fast enough if you want to capture lots of streams at once.As pointed out already, the most limiting factor is going to be network bandwidth so there needs to be an effort to reduce the number of streams going across the network at once. I think bear's idea offers the best way to reduce network load. The problem raised is how to timeshift to a time before the client starts watching. I would suggest that the easiest way to fix this is to have the client always running in the background saving it's own timeshift buffer. Then when the user starts watching they already have a timeshift buffer built up.Nate</blockquote>

[QUOTE="nate, post: 44363, member: 10474"] I'm sorry to butt in, but I have to pick up on this point. The only extra hardware requirement for timeshifting client side would be maybe 2-10Gb more hard drive space (depending on how long you want the timeshift buffer to be). I've noticed a few comments in this thread that point towards using a more powerful server and a less powerful client with what seem to me to be little understanding of what actually happens in each part of the process. The most cpu intensive part of the process by far is actually decoding and displaying the video, especially for HD. For HD without DxVA you'll need at the very least a 2Ghz machine. With DxVA or for SD you can get away with less cpu power, but you still need a decent video card that supports DirectX 9. Capturing from the Tuner/Capture Device to Timeshift Buffer uses almost no cpu power. The most intensive part of the capture process would be disk access. It requires the hard disk to write at up to the same data rate as full transport stream. That's about 2.5 Mb/s from memory, which is far less than the limit of hard drives. You can easily save several transport streams to disk simultaneously. Assuming that the sever is just saving the timeshifting buffers not decoding or display the video then you would get away with using quite a low end system. The only requirement might be to make sure the hard drives are fast enough if you want to capture lots of streams at once. As pointed out already, the most limiting factor is going to be network bandwidth so there needs to be an effort to reduce the number of streams going across the network at once. I think bear's idea offers the best way to reduce network load. The problem raised is how to timeshift to a time before the client starts watching. I would suggest that the easiest way to fix this is to have the client always running in the background saving it's own timeshift buffer. Then when the user starts watching they already have a timeshift buffer built up. Nate [/QUOTE]