I`m making a WinRT application which includes video streaming. Now I ended at VLC as streaming server and MJPEGDecoder lib (http://mjpeg.codeplex.com/) on client to decode video.
But after creating HTTP stream and connecting to it from client, MJPEGDecoder says that header is invalid (it expects multipart stream). VLC-to-VLC works normal.
Question 1 : how can it be fixed?
Question 2 : what alternatives to create video streaming for WinRT?
Just to elaborate on your question/answer a bit further.
The posted answer links just to an example but doesn't explain it, niether does the example itself. So I would like to complete this answer in case someone else stumbles across it.
When you defined your vlc stream, which you forgot to share in your question you most likely didn't specify any options from the access parameter http and had the vlc standard module defined as such. (just like I did when I ran into the same problem)
standard{access=http,mux=mpjpeg,dst=< address >:< port >/< path >}
You are using VLC to create a mjpeg stream delivered over http.
Thanks to osgx reply in another question, here is the wikipedia link describing MPJEG over HTTP. Basically:
M-JPEG over HTTP informs the client using a special mime-type multipart/x-mixed-replace with parameter boundary=*< boundary >*****, that you will be sending a series of JPEG images separated by the < boundary >.
The rules that apply to < boundary > have been stated in this post by
Gumbo and some other guidelines, perhaps now obsoleted by a newer one, are defined in the RFC2046
Mixed-replaced media types are explained in the wikipedia article on MIME
As the example you placed has included the definition of mime of the media content streamed over http can be defined as an optional parameter with the http access definition.
standard{access=http{mime=multipart/x-mixed-replace;boundary=--myboudary},mux=mpjpeg,dst=< address >:< port >/< path >}
Figured it out. With help of http://tumblr.martinml.com/post/2108887785/how-to-broadcast-a-mjpeg-stream-from-your-webcam-with
VLC has options to set mime type and boundary. Example of configuration from link
:sout=#transcode{vcodec=MJPG,vb=400,width=640,height=480}
:duplicate{dst=std{access=http{mime=multipart/x-mixed-replace;
boundary=--7b3cc56e5f51db803f790dad720ed50a},mux=mpjpeg,dst=:1234/webcam.mjpg}}
Related
When I'm checking web requests in Chrome's DevTools on Mac (Network tab), I've got the Payload in the following format:
7|0|6|https://www.example.com/app/Basic/|00D1D071AC218DFE91521C012683E911|com.optionfair.client.common.services.nongenerated.RefreshService|getCometUpdates|I|J|1|2|3|4|3|5|6|6|173|VvAwAqy|o$UN|
which is basically separated by vertical bar character (|).
How I can copy or convert above payload from Chrome into some meaningful format such as JSON? Any ideas?
Btw. In this question it looks fine on the screenshot, but in my case, I don't have view parsed and it doesn't look like JSON format at all.
Using Google Chrome on Mac (Version 57.0.2987.133, 64-bit).
Reproducible steps:
Go to this page.
Open DevTools on Network/XHR tab and look for refresh requests.
My goal is to reuse/replicate the POST data in Request Payload in the command-line tool such as curl so it can be recognized (not necessary on the page mentioned above, but I'd like to know the general approach to deal with this blob format). I would expect JSON format, but it's not.
Here you need to look at the request header content-type to determine how this request was encoded before knowing what might parse it:
This is GWT RPC, so it can include serializations of built-in and custom Java Objects, where knowledge of the class is in both server-side Java and transpiled Java running on the client via Google Web Toolkit.
There is no reason for Chrome to understand this format directly, and it need not have a JSON or XML cannonicalization. Fully interpreting these calls to the extent it is possible on the client may require disassembly or introspection tricks against the transpiled client code, assuming the program wasn't transpiled with source maps.
Without digging into the client code, one can interpret the literal rpc while guessing at or probing the definition of classes and their methods by modifying the call.
Please clarify for me:
Does web browser support only GET method, not POST?
Is there any way to upload the sound file using POST request in address bar (without using CURL, or any add-ons)?
Thanks for your help in advance.
Web browsers only allow you to make GET requests though the address bar UI. There is no way to trigger a POST request using it.
In theory, you could encode audio as a text string (e.g. using base64) and pass that through the URL in a GET request … but that isn't really in the spirit of HTTP and you will run into URL length limits for all but the smallest audio files.
I'm using Node.js, Express (and connect), and fluent-ffmpeg.
We want to stream audio files that are stored on Amazon S3 through http.
We have all working, except that we would like to add a feature, the on-the-fly conversion of the stream through ffmpeg.
This is working well, the problem is that some browsers checks in advance before actually getting the file.
Incoming requests containing the Range header, for which we reply with a 206 with all the info from S3, have a fundamental problem: we need to know in advance the content-length of the file.
We don't know that since it is going through ffmpeg.
One solution might be to write out the resulting content-length directly on S3 when storing the file (in a special header), but this means we have to go through the pain of having queues to encode after upload just to know the size for future requests.
It also means that if we change compressor or preset we have to go through all this over again, so it is not a viable solution.
We also noticed big differencies in the way Chrome and Safari request the audio tag src, but this may be discussion for another topic.
Fact is that without a proper content-length header in response everything seems to break or browsers goes in an infinite loop or restart the stream at pleasure.
Ideas?
This seems to be working for me.
It would be great if you could confirm whether it gives the expect results in your browsers too.
res.writeHead(200, {
'Transfer-Encoding': 'chunked'
, 'Content-Type': 'audio/mpeg'
, 'Accept-Ranges': 'bytes' //just to please some players, we do not actually allow seeking
});
Basically, you tell the browser that you are going to stream using chunked encoding. An issue may be that some browsers do not like streaming without know how much bytes they should expect in total.
My informatics teacher explained that HTTP can really be used exclusively to transfer unencoded ASCII, and as soon as an image or the like have to be downloaded from the server, FTP is used instead.
Is this true?
No, it isn't. HTTP contains a header and data part, the latter gets interpreted by the receipent according to the CONTENT-TYPE header. HTTP can transfer arbitrary data.
If you want any more specific information about the HTTP protocol, the full RFC (request for comments) document is available here: http://www.w3.org/Protocols/rfc2616/rfc2616.html
An RFC is where the various different parties who have a stake in these protocols are presented the current version and invited to give their opinion. It's the method by which most of the internet has been built :)
I put together an applet that uploads images via as3httpclientlib to a servlet. The applet works fine in debug mode (through flash builder) and until today it worked when deployed.
From the servlet logs, it appears the servlet never receives the image(s) byte stream, therefore my hunch is the applet is not posting the multipart data.
Can anyone suggest what I should do next to find the cause of the problem?
I suppose you ran into problem described here:
In Flash Player 10 and later, if you
use a multipart Content-Type (for
example "multipart/form-data") that
contains an upload (indicated by a
"filename" parameter in a
"content-disposition" header within
the POST body), the POST operation is
subject to the security rules applied
to uploads:
The POST operation must be performed
in response to a user-initiated
action, such as a mouse click or key
press.
If the POST operation is
cross-domain (the POST target is not
on the same server as the SWF file
that is sending the POST request), the
target server must provide a URL
policy file that permits cross-domain
access.
So I think you should run your application using debugger and check Flex client logs for exceptions described above.