Skip to main content

What effect should Accept-Encoding have on a stream?

1 reply [Last post]
howardteece
Offline
Joined: 2010-06-17
Points: 0

If I try to stream to a PS3 with the default settings, the Transfer-Encoding field is set to Chunked and streaming fails with the PS3 closing the socket after about 100kB

If I force non-chunked encoding via MPEENV.INI, the streaming works.

However, the PS3 sets the Accept-Encoding header to 'identity', does that mean we should not use chunked encoding at this point? I can't see Accept-Encoding being parsed anywhere.

Also, if a client identifies itself as HTTP/1.0 what happens to chunk encoding then?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mkorzen
Offline
Joined: 2008-03-05
Points: 0

There are known problems with some clients that are unable to ignore/skip unknown HTTP chunk extensions. By default, the RI adds "npt" and "bytes" chunk header fields when streaming content out using chunked encoding. Per RFC2616, HTTP clients must be able to ignore/skip chunk extension fields that they do not recognize. You can disable that feature via mpeenv.ini:
HN.EXCLUDE.EXTRA.CHUNK.HEADERS=true

That should allow you streaming content out from RI to other third-party DLNA clients using chunked transfer encoding.

Per DLNA guidelines, when a client identifies itself as HTTP/1.0, then the server must respond using non-chunked encoding. It can still omit the "Content-Length" header, depending on the type of content that is streamed.

As far as I know, "Accept-Encoding" is an HTTP header that does not need to be processed by UPnP or DLNA servers. Looking at RFC2616 (14.3), it looks like that setting refers to the _format_ of the content being streamed (i.e. compression, image/audio/video content types) rather than the actual HTTP transfer encoding (chunked vs. non-chunked).

Hope this helps -
Marcin