Time to make Touch web Service less experimental

[reven]

fixed the issue of first jump being incorrect by removing the clearing of "SeekToPosition"

Code:

System.Web.HttpContext.Current.Application["SeekToPosition"] = 0;

basically the samsung player, closes the connection and creates a new one, but before a new one is created the seektoposition is set on the old connection and then clearing it. Then when the new connection is made, their is no SeekToPosition so it does the first incorrect jump.


the problem that stops you from jumping past the incorrect endtime, I believe is due to the fact the player thinks it really at xxx position, but in reality it is stream yyy bytes (which can be way off), so the player says, I can't jump any further.

Going to experiment with different byte ranges, or perhaps moving the end byte range in the response to see if that helps. Basically trial and error at the moment. But if this can be fixed, then we definitely have a workable solution, which is fantastic

took me a little while to get around that it was only making on request with the byte range and then the bytes were just constantly written to the response. Was thinking it was making lots of small requests (that why I was trying to correct the response headers at first), now I get why you just ignore those and send what you want to send.

[reven]

not having any joy changing the content-range or content-length.

tried getting the "fixed" byte range, getting the difference between the fixed + actual one requested then increasing the content-length + range end so it could jump past the end bytes (once the request came back in, it would correct the bytes by lowering them and should of worked).

however it just stops at the end point. removed the validation of the range in "CheckRangesRequested", but still nope.

Fred hopefully you have more luck than me. Just this one little thing to go

[fred250]

fixed the issue of first jump being incorrect by removing the clearing of "SeekToPosition"

Code:

System.Web.HttpContext.Current.Application["SeekToPosition"] = 0;

basically the samsung player, closes the connection and creates a new one, but before a new one is created the seektoposition is set on the old connection and then clearing it. Then when the new connection is made, their is no SeekToPosition so it does the first incorrect jump.

Yes, I put it there as a quick and dirty solution to that there might be a value set when you first request a stream causing an unintentional jump.
Before this can be used in real life we need to separate each clients SeekToPosition and probably add an expire time to minimize the risk of unintentional jumps.

the problem that stops you from jumping past the incorrect endtime, I believe is due to the fact the player thinks it really at xxx position, but in reality it is stream yyy bytes (which can be way off), so the player says, I can't jump any further.

I haven’t noticed this with the LG TV. I'll pay attention to this in the future.

Going to experiment with different byte ranges, or perhaps moving the end byte range in the response to see if that helps. Basically trial and error at the moment. But if this can be fixed, then we definitely have a workable solution, which is fantastic

Please do experiment. I haven’t had the need to experiment with headers yet. I also thought I'd confuse the player by putting a different range header than requested in the response. I guess this can work differently on different players.

took me a little while to get around that it was only making on request with the byte range and then the bytes were just constantly written to the response. Was thinking it was making lots of small requests (that why I was trying to correct the response headers at first), now I get why you just ignore those and send what you want to send.

I'm a newbie to this streaming too but thanks to the Internet any one can find bits and pieces here and there and put it together to make something useful.

/Fred

[fred250]

not having any joy changing the content-range or content-length.

tried getting the "fixed" byte range, getting the difference between the fixed + actual one requested then increasing the content-length + range end so it could jump past the end bytes (once the request came back in, it would correct the bytes by lowering them and should of worked).

however it just stops at the end point. removed the validation of the range in "CheckRangesRequested", but still nope.

Fred hopefully you have more luck than me. Just this one little thing to go

Not being an expert on ts-Streams and calculation of duration time I went to the Internet for answers.
I've found that your Samsung player probably uses one of these to methods of calculating duration time.

Parse the beginning and the end of the file looking for the PTS in the program's PES packets, and compute the difference.

http://social.msdn.microsoft.com/Forums/...ort-stream

An other way to calculate duration is by considering bitrate and filesize.
I guess constant bitrate is a must for this one.

You earlier mentioned that there were a lot of “About to stream..” in the log. Maybe this is the player trying to figure out duration time using method #1.
I would suggest you take a look at the headers of these requests to see if there are any trace of an initial byte range request for the end of the file.

If this is the case the reported duration comes from ts-timeline and changing the response headers won't be much help.

In the streamer, you may be able to recognize these requests, ignore them, and maybe this would cause the player to calculate duration based on bitrate and filesize instead.

I haven’t had the time to set up a development environment for Samung yet so I can't really help you out on this one for now.

/Fred

[BrettB]

In the streamer, you may be able to recognize these requests, ignore them, and maybe this would cause the player to calculate duration based on bitrate and filesize instead.

If broadcast .ts streams (at least here in the US) aren't constant bitrate (even if the change is only the commercials inserted), then to really work best, I think the streamer would need to be able to recognize these requests, and NOT ignore them, but rather modify the PTS values in the returned bytes to indicate the "true" length from the timing.info data.

[mvallevand]

I've found the changes aren't typically commercials, although with on demand broadcast it could go that way. I think the broadcast decoders reset the PTS to zero a lot. It's a 64 bit number and at 90khz it is a necessity from time to time.

Martin

[reven]

The streamer isnt processing the video its merely sending the raw bytes. The request comes in asking for a byte range and currently if it has a value sent to it saying secondswanted it ignores the byte range and just responds with the bytes from the actual seconds l.

So the player thinks its really say 500mb into a 1000mb file when really its 200mb. So when it gets to what it thinks is 1000mb, it wont skip ahead anymore even though its really at 700mb

[sub]

Yeah, unfortunately that sounds like a bit of fatal flaw to this approach. Bummer. Not entirely surprising though.

[mvallevand]

Yes, that is the problem with the player having its own smarts that I was trying to explain. Unless you can dumb it down, you will have problems. Since so many chip and firmware version are used by LG and Samsung I still think that building a smart streamer for them is challenging.

A complicated smart TSWriter during capture is really the best solution. Recording via the dvr-ms can potential because players would be able to use its built in accuracy, but it is proprietary and not supported by all players.

Martin

[reven]

I was trying to make it so the content-length end byte range would "grow" whenever it seeks, so the 1000MB file would become 1300MB (well reported to the player that size, not really that size), so it could continue to seek, but so far haven't had any success with this (I'm completely new to this stuff so might be doing it wrong).

Sub, what does nextpvr do when one plays a in progress recording? does it change those values as the file size changes?