Incorrect Content-Type for outgoing HTTP streams
When offering a HTTP stream, VLC always replies with the "Content-Type" header set to "application/octet-stream".
Apart from that mime type probably being incorrect for anything VLC ever streams, this causes problems when trying to embed a livestream in a web page.
Here's my wireshark log of Chromium attempting to access a webcam stream on localhost.
GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP/1.0 200 OK
Content-type: application/octet-stream
Cache-Control: no-cache
.E..........B...B...B...B...B..webmB...B....S.g.............................................andsoonandsoon
If the mime type was set to "video/webm", chrome would probably play the file inside the browser.
This bug is present in Master Git VLC on Linux (Ubuntu 12.04 precise 64bit here)
Activity
assigned to @Courmisch
added Difficulty::easy + 1 deleted label
changed milestone to %2.0.4
Fixed by b0fb30cb
added Status::fixed label
Issue still exists in 2.1.2
:dshow-vdev=none :dshow-adev=C-Media Wave Device :live-caching=300
:sout=#transcode{vcodec=none,acodec=mp3,ab=128,channels=2,samplerate=44100}:http{mux=ts,dst=:4001/} :sout-keep
6 02.02.2014 10:38:10 GET / HTTP/1.0 User-Agent: Download Master Accept: / Referer: http://192.168.1.33:4001/ Pragma: no-cache Cache-Control: no-cache Host: 192.168.1.33
7 02.02.2014 10:38:10 HTTP/1.0 200 OK Content-type: application/octet-stream Cache-Control: no-cache
removed Status::fixed label
added Status::fixed label
What should I do? Create another copy of the same bug? I see no comments on bug reopening on wiki https://wiki.videolan.org/Report_bugs
I am running into the same issue. I think the bug reporter said all container types have this problem and only mentioned webm as an example.
I am not using webm, because I want to stream from a live source and I think webm does not support this. This appears to be so because VLC sends the response with correct Content-type, but then never sends any data because the source data doesn't end. A type live flv or ts isn't streamed with the correct Content-type, so a browser doesn't accept it. If it would, I also suspect it would just play it (like the reporter). Which is a pretty neat feature to have.
So, should I now create a bug report for .ts, one for .ps and one for .flv? I don't understand why the code that generates the Content-type header doesn't just check what type is streamed and generate a proper response. Please enlighten me.
-
If you want to add automatic Content-Type generation to muxer, be my guest. Patches are welcome.
But I doubt that would really work that well. For example, how do you, a priori, determine if a mux will contain video or only audio? That changes the Content-Type.
Also in some cases, there are many different Content-Type values that could describe the media. One part of the problem is that Content-Type is not very well suited to multimedia container. Another part is that Content-Type's for multimedia containers are poorly standardized.
Would it be possible then to add the content types for streams based on the mux, like ts, flv ? The muxers that can mux video could output a video content type, and if there is only audio that is probably not a big problem. application/octet-stream can be the fall-back type. But I think often the muxer that is selected tells a lot already about the content type.
Muxer Content-type flv video/x-flv mp4 video/mp4 mpeg1 video/mpeg mp3 audio/mp3 ts video/MP2T ps video/MP2P 3gp video/3gpp ogg video/ogg asf video/asf avi video/x-msvideo wav audio/wav webm video/webm
