The VideoLAN Forums

mates,

when streaming from VLC - using the telnet interface with this code it will work, however... the stream it will send isn't recognized by the other players.

MPC will return this error

http://127.0.0.1:8090::Output

Media Type 0:
--------------------------
Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: Unknown GUID Name {08E22ADA-B715-45ED-9D20-7B87750301D4}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

looking up about this ID it's claimed to be a RealMedia type... RealMedia?? please help, I want to send some videos over the air to the iPhone. for some reason the iPhone doesn't reject the file, but it won't play either.

mates,

when streaming from VLC - using the telnet interface with this code

Code: Select all

new test vod enabled input "file:///d:\video.avi" output #transcode{vcodec=mp4v,vb=500,scale=1,width=480,height=320,acodec=mp4a,ab=128,channels=2,samplerate=44100}:std{access=http,mux=mp4,dst=:8090}

it will work, however... the stream it will send isn't recognized by the other players.

MPC will return this error

http://127.0.0.1:8090::Output

Media Type 0:
--------------------------
Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: Unknown GUID Name {08E22ADA-B715-45ED-9D20-7B87750301D4}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

looking up about this ID it's claimed to be a RealMedia type... RealMedia?? please help, I want to send some videos over the air to the iPhone. for some reason the iPhone doesn't reject the file, but it won't play either.

I think the problem is your player.. try a different Transcode or No Transcode

The output of VLC when mux=mp4 differs when access=http and when access=file. The same byte stream is not produced for both.

The access=file resulting file plays in a H264 HTML5 enabled browser, while the the access=http stream does not.

The only difference in these two examples is the access value is changed, and dst value is changed to a file name or ip address/port as appropriate.

these are the first bytes in hex when access=file (this plays)
00 00 00 14 66 74 79 70 69 73 6F 6D 00 00 00 00 6D 70 34 31 00 00 90 07 6D 6F 6F 76 00 00 00 6C
the 66 through 6D = ftypisom, the ftyp identifer

these are the first bytes in hex when access=http (this does not play)
the byte sequence for ftypisom (66 74 79 70 69 73 6F 6D) does not even exist.
byte: 0
byte: 0
byte: 0
byte: 2
byte: 9
byte: 30
byte: 0
byte: 0
byte: 1
byte: D8
byte: 41
byte: 9A
byte: 59
byte: 6C
byte: 13
byte: D4
byte: DA
byte: 97
byte: FA
byte: 6A
byte: 26
byte: 63
byte: ED
byte: 2
byte: D
byte: D6
byte: 79

I'm also working on getting iPhone streaming with VLC to work. This isn't necessarily related to your above problem, but you need to be segmenting the stream in order to live stream a file or other input.

See Apple's documentation:
http://developer.apple.com/iphone/libra ... n2224.html

Or a helpful Akamai whitepaper:
http://docs.google.com/viewer?a=v&q=cac ... WYTY_-GKHQ

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.