Live WebM stream on web
1,255 views
Skip to first unread message
ziutek
Jul 27, 2011, 7:54:56 PM7/27/11
to golang-nuts
I'v just written example web application which generates live WebM
stream:
https://github.com/ziutek/gst/blob/master/examples/live_webm.go
I tested it with Firefox and it works fine (although buffering at the
beginning takes too much time).
This simple applications contains some hacks to use the same port for
HTML and WebM stream. Is there good way to do this with http package
or should I provide stream on different port?
During writing I probably find some bug in net package (weekly.
2011-07-19):
According to net.TCPConn.File documentation:
"File returns a copy of the underlying os.File, set to blocking mode.
It is the caller's responsibility to close f when finished. Closing c
does not affect f, and closing f does not affect c."
I need to Dup file descriptor and after this close f and c because
streaming is served by the gstreamer multifdsink thread, and I don't
need f and c any more. But I can only close f without affects to the
communication. If I close c (and f isn't closed) connection is closed
and multifdsink can't stream on file descriptor passed to it. So
closing c affects f.
Workaround is to save c in map and close it when multifdsink signal
that connection should be closed.
stream:
https://github.com/ziutek/gst/blob/master/examples/live_webm.go
I tested it with Firefox and it works fine (although buffering at the
beginning takes too much time).
This simple applications contains some hacks to use the same port for
HTML and WebM stream. Is there good way to do this with http package
or should I provide stream on different port?
During writing I probably find some bug in net package (weekly.
2011-07-19):
According to net.TCPConn.File documentation:
"File returns a copy of the underlying os.File, set to blocking mode.
It is the caller's responsibility to close f when finished. Closing c
does not affect f, and closing f does not affect c."
I need to Dup file descriptor and after this close f and c because
streaming is served by the gstreamer multifdsink thread, and I don't
need f and c any more. But I can only close f without affects to the
communication. If I close c (and f isn't closed) connection is closed
and multifdsink can't stream on file descriptor passed to it. So
closing c affects f.
Workaround is to save c in map and close it when multifdsink signal
that connection should be closed.
Andrew Gerrand
Jul 27, 2011, 9:00:55 PM7/27/11
to golan...@googlegroups.com
On Wednesday, July 27, 2011 4:54:56 PM UTC-7, ziutek wrote:
I'v just written example web application which generates live WebM
stream:
https://github.com/ziutek/gst/blob/master/examples/live_webm.go
I tested it with Firefox and it works fine (although buffering at the
beginning takes too much time).
This simple applications contains some hacks to use the same port for
HTML and WebM stream. Is there good way to do this with http package
or should I provide stream on different port?
Your general approach looks fine to me, but I wonder about lines 50-53 that are commented out:
/*wr.Header().Set("Content-Type", "video/webm")wr.Header().Set("Transfer-Encoding", "identity")wr.WriteHeader(http.StatusOK)wr.(http.Flusher).Flush()*/
Was there something wrong with that technique? It should work. I see you write the headers manually after hijacking the connection, instead. Why?
During writing I probably find some bug in net package (weekly.
2011-07-19):
According to net.TCPConn.File documentation:
"File returns a copy of the underlying os.File, set to blocking mode.
It is the caller's responsibility to close f when finished. Closing c
does not affect f, and closing f does not affect c."
I need to Dup file descriptor and after this close f and c because
streaming is served by the gstreamer multifdsink thread, and I don't
need f and c any more. But I can only close f without affects to the
communication. If I close c (and f isn't closed) connection is closed
and multifdsink can't stream on file descriptor passed to it. So
closing c affects f.
Workaround is to save c in map and close it when multifdsink signal
that connection should be closed.
This sounds like a bug. Please create an issue on the tracker (with a test case, if you can).
Thanks,
Andrew
ziutek
Jul 27, 2011, 9:18:48 PM7/27/11
to golang-nuts
> Your general approach looks fine to me, but I wonder about lines 50-53 that
> are commented out:
>
> /*wr.Header().Set("Content-Type", "video/webm")
> wr.Header().Set("Transfer-Encoding", "identity")
> wr.WriteHeader(http.StatusOK)
> wr.(http.Flusher).Flush()*/
>
> Was there something wrong with that technique? It should work. I see you write the headers manually after hijacking the connection, instead. Why?
I can disable chunked Transfer-Encoding - using:
> are commented out:
>
> /*wr.Header().Set("Content-Type", "video/webm")
> wr.Header().Set("Transfer-Encoding", "identity")
> wr.WriteHeader(http.StatusOK)
> wr.(http.Flusher).Flush()*/
>
> Was there something wrong with that technique? It should work. I see you write the headers manually after hijacking the connection, instead. Why?
wr.Header().Set("Transfer-Encoding", "identity")
(with unknown length) on the filedescriptor.
I have yet to test what happens if there will be some image after
video. Is the browser will download it if gstreamer take over the
whole HTTP/1.1 connection for streaming?
ziutek
Jul 27, 2011, 9:20:59 PM7/27/11
to golang-nuts
> I can disable chunked Transfer-Encoding - using:
Should be "I can't (...)"ziutek
Jul 27, 2011, 9:53:46 PM7/27/11
to golang-nuts
I added images before and after video and they are loaded, but I still
doubt.
I have to read more about HTTP/1.1.
doubt.
I have to read more about HTTP/1.1.
ziutek
Aug 1, 2011, 7:46:21 AM8/1/11
to golang-nuts
> > According to net.TCPConn.File documentation:
>
> > "File returns a copy of the underlying os.File, set to blocking mode.
> > It is the caller's responsibility to close f when finished. Closing c
> > does not affect f, and closing f does not affect c."
>
> > I need to Dup file descriptor and after this close f and c because
> > streaming is served by the gstreamer multifdsink thread, and I don't
> > need f and c any more. But I can only close f without affects to the
> > communication. If I close c (and f isn't closed) connection is closed
> > and multifdsink can't stream on file descriptor passed to it. So
> > closing c affects f.
>
>
> > "File returns a copy of the underlying os.File, set to blocking mode.
> > It is the caller's responsibility to close f when finished. Closing c
> > does not affect f, and closing f does not affect c."
>
> > I need to Dup file descriptor and after this close f and c because
> > streaming is served by the gstreamer multifdsink thread, and I don't
> > need f and c any more. But I can only close f without affects to the
> > communication. If I close c (and f isn't closed) connection is closed
> > and multifdsink can't stream on file descriptor passed to it. So
> > closing c affects f.
>
> This sounds like a bug. Please create an issue on the tracker (with a test
> case, if you can).
I've just created issue for this bug: http://code.google.com/p/go/issues/detail?id=2122
> case, if you can).
> wr.Header().Set("Transfer-Encoding", "identity")
HTTP connection?
Reply all
Reply to author
Forward
0 new messages