Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bob]

Ok, let's wait for the OP's response.

But just for the record, I gave him a test build of my DMRA test application to push test files with Content-Length and without; and it proved that without a Content-Length the push always failed; this was a problem generic to the missing Http header, not linked to a specific media type (i.e. not specific to just audio or just video ..)

Audio is different because it always gives a content length transcoding or not.

[AndrewFG]

Audio is different because it always gives a content length transcoding or not.

Ahah. Can you please talk to Hendrik? 

[bob]

Ahah. Can you please talk to Hendrik? 

The difference is that we can know in advance the exact size of a transcoded audio file (at least to the formats we transcode to).

[AndrewFG]

Yes. In short my point is that for video you could do that too; to a reasonable degree of approximation..

[bob]

Yes. In short my point is that for video you could do that too; to a reasonable degree of approximation..

And of course the key here is "reasonable degree of approximation.." which some renderers will simply not accept.

[AndrewFG]

Ok I surrender; you have convinced me that it is impossible; and JRiver should not waste any time on trying to fix this problem..

[JimH]

We will try.  It may take some time.

Like you, we find the lack of tight standards to be a challenge.

[bob]

Ok I surrender; you have convinced me that it is impossible; and JRiver should not waste any time on trying to fix this problem..

I'm not trying to convince you to surrender. I'm just pointing out the difference between audio and video and how the boatload of renderers I've had to deal with act.
We will try something.
It will likely work for most but not all renderers.
I'd like to add that I ALWAYS appreciate your thoughtful analysis!

[AndrewFG]

I'm not trying to convince you to surrender. I'm just pointing out the difference between audio and video and how the boatload of renderers I've had to deal with act. We will try something. It will likely work for most but not all renderers.
I'd like to add that I ALWAYS appreciate your thoughtful analysis!

Ah Ok bob, many thanks for the gracious comment.

I think the issue breaks down into the following sub topics:

1) How to calculate Content-Length as accurately as possible in the first place? I suggest to set the transcoder maxRate and minRate switches both to a value N and then set Content-Length := N X (duration X (1 + F)) -- where F := 3% extra safety factor (say)

2) How to handle a regular GET on the transcoded stream? Keep serving the content stream until the transcoder is done and then close the socket. Depending on the accuracy of N and the safety factor F above, you might actually serve fewer bytes (or in extreme cases more bytes) than the calculated Content-Length. Some renderers keep pulling bytes until the server closes the socket (in which case there is usually no problem). Some renderers keep pulling bytes until the played duration has expired, and some only pull the Content-Length number of bytes and then close the socket themselves (in both these cases it is important that the safety factor F is greater than zero).

EDIT: apropos "keep serving the content stream until the transcoder is done and then close the socket", if the MC server is pushing the track, the alternative approach could be "keep serving the content stream until the transcoder is done and then send the Seek(Next) and/or Stop() command" -- however I have not tested that myself...

3) How to handle a GET with a Range-bytes offset? If the byte offset is within the previously announced Content-Length, then always respond with Http 206 Partial Content and deliver the requested number of bytes from approximately the right part of the track. If the Range-bytes window is close to the end of the track, (i.e. if the window would lie inside the safety factor F of the putative Content-Length) then tweak the Range-bytes offset by an amount such that the request can always be satisfied with real bytes from before the end of the transcoded stream. Basic rules: never fail a valid Range-bytes request; always deliver some valid stream bytes. (Keep in mind that the renderer has no way of knowing if the stream bytes are from the exact part of the stream that it requested; and even the user would in general be satisfied if the stream bytes are not too far away from the perfect requested location..)

[AndrewFG]

PS use my DMR Analyser to test the capabilities of your renderer (see my sig below); and please email me the report to add to the database.