OK, I actually went to the trouble of creating a named pipe (a stream object that can be referenced as a file) and told VLC to access=file mux=mp4 to a real file and to the named pipe.
In the program that created the named pipe, I read data off the pipe and wrote it to a file. I figured that it should look just like the real file created directly from VLC.
It wasn't, if every byte of the file from first to last was written out in order, it would be, but not if part of the begining of the file is written, then later parts, then jump back near the beginning of the file and write something, etc.
Looking at the VLC docs, mux=mp4 and access=http is not a valid combination, it seems that VLC ignores the mux arg and does something else, it should throw up an error window in my opinion instead of letting people think it is doing what is asked, I'm sure it's in the logs, but without any other complaint by VLC, I for one am not likely to look there.
VLC Output method mux matrix
http://www.videolan.org/streaming-features.html
Looking at the container specification, it becomes apparent that this format cannot be created on the fly, there are sections near the beginning of the file that are not known until data is written out later (which frames are b frames, where the video and audio chunks are, etc).
Quicktime (mux=mp4) container reference
http://wiki.multimedia.cx/index.php?tit ... _container
So mux=mp4 is impossible to use for real time streaming, what other mux (container) format is usable for HTML5 H264 then?
An additional complication is the way different browsers request the data for HTML5 H264, Safari seems to ask for a regular HTTP GET and is happy just having bytes in order returned to it, Chome on the other hand, does one or more partial GET requests, for bytes 0-1599, then 1600 to end. The problem here is that a well formatted response to a partial GET includes the total file size (not known when real time) Chrome browser at least does not like -1 as an answer to total size. (-1 is often returned as content-length if it cannot be determined).
As an aside, HTML5 OGG does stream, but it does not seem like it is going to be supported in all browsers.
Notes on mux=ts:
If mux is set to ts and access = file a file is created that will play in Safari but not in Chrome. Streaming to Chrome seems particularly difficult, as mentioned above, Chrome does partial GET requests, I have seen Chrome ask for the last 128 bytes of a file after a previous partial GET reported a total file size. Chrome seems to be checking that the end of a video contains certain values or that it actually exists, if the latter case then Chrome seems to be determining if the video is pre existing or real time.
