Tweet
Re: DEF CON 17 Audio and Video now available!
Thanks. :-)
I had another thought on what could cause the length to be removed:
If there is a filter between the server and the client that is compressing (or trying to compress) the video, audio, rar-files, iso, etc., then it would also, likely, compress content as a stream, and as a result, not have a total size of content being transmitted over http/https before it starts transmitting it. (Again, for efficiency, the server would not want to pre-compress and store an entire file before transmitting it.)
Usually, when compression is enabled for web servers to web browsers, a selection list of either extensions or MIME-types is provided to either specify:
* Items that should be compressed, with default compression disabled (or)
* What should NOT be compressed, with everything else being compressed.
Most of the time, web and network admins will disable compression for any 8-bit content, but leave it enabled for 7-bit content (as text such as .txt, .html, .js, and css.) This is especially important when looking to serve video, which is usually compressed with much *better compression than an inline gzip compression done with an emphasis for speed and low CPU use.
But is this the case?
wget --header="accept-encoding: gzip" http://media.defcon.org/dc-17/video/...d%20Slides.m4v
vs.
wget http://media.defcon.org/dc-17/video/...d%20Slides.m4v
And, what-do-you-know? When I specify compression as "ok" with wget, I get no time estimate for when it will be completed, but when I don't support compression, I see a time estimate.
Solution? Disable compression for 8-bit content, or at least for video, and audio, because you are probably not saving much, but you are taxing your CPU more than you need to.
Thanks. :-)
I had another thought on what could cause the length to be removed:
If there is a filter between the server and the client that is compressing (or trying to compress) the video, audio, rar-files, iso, etc., then it would also, likely, compress content as a stream, and as a result, not have a total size of content being transmitted over http/https before it starts transmitting it. (Again, for efficiency, the server would not want to pre-compress and store an entire file before transmitting it.)
Usually, when compression is enabled for web servers to web browsers, a selection list of either extensions or MIME-types is provided to either specify:
* Items that should be compressed, with default compression disabled (or)
* What should NOT be compressed, with everything else being compressed.
Most of the time, web and network admins will disable compression for any 8-bit content, but leave it enabled for 7-bit content (as text such as .txt, .html, .js, and css.) This is especially important when looking to serve video, which is usually compressed with much *better compression than an inline gzip compression done with an emphasis for speed and low CPU use.
But is this the case?
wget --header="accept-encoding: gzip" http://media.defcon.org/dc-17/video/...d%20Slides.m4v
vs.
wget http://media.defcon.org/dc-17/video/...d%20Slides.m4v
And, what-do-you-know? When I specify compression as "ok" with wget, I get no time estimate for when it will be completed, but when I don't support compression, I see a time estimate.
Solution? Disable compression for 8-bit content, or at least for video, and audio, because you are probably not saving much, but you are taxing your CPU more than you need to.
Comment