Customized response for a page

  • Thread starter Thread starter Stefan Soljemo
  • Start date Start date
S

Stefan Soljemo

I need to send a MJPEG stream to clients from an asp.net page. This require
that content-length is not specified. Is it possible to create a customized
response for an asp.net page or can the Contents length specification be
disabled?

Response.ContentType = "multipart/x-mixed-replace; boundary=myboundary";

// Thanks
 
If with ASPX you have no way to suppress it, you could likely do that with a
custom handler.

See http://dotnetperls.com/ashx-handler (even if you can, by using an ASHX
handler you'll bypass the webform infrastructure you likely don't need in
this particular case so you may want to try directly a handler).
 
Thank you Patrice for fast answer!

The ASHX handler seems to work faster but as you wrote, it will not solve
the main problem with the ASP.NET headers. I did some tests and found that I
still have performance problem. ASP.NET is not able to deliver 30 JPEG frames
with 800*600 pixels / second. I still need to work with the HTTP stream
directly. Is there any way to handle the HTTP stream directly or do I need to
build a dll for ASP or an external web server?
Is there any existing solution or sample who handles MJPEG with ASP.NET?
I’m working with a server product that will capture MJPEG frames from an IP
camera and store this frames on a server. The frames will then be available
as a video on a Web page.

Here is a part of code used for tests:
oResponse.ClearContent();
oResponse.BufferOutput = true;
oResponse.ContentType = "multipart/x-mixed-replace; boundary=myboundary";
oResponse.CacheControl = "no-cache";
for( ix = 0; ix < iFramesInBuffer; ix++ )
{
sBundary = "--myboundary\r\nContent-Type: image/jpeg\r\nContent-Length: "
+ images[ ix ].FrameSize.ToString() + sSeparator;
boundary = Encoding.ASCII.GetBytes( sBundary );
oResponse.OutputStream.Write( boundary , 0 , boundary.Length );
oResponse.OutputStream.Write( images[ ix ].Frame , 0 , images[ ix
].FrameSize );
oResponse.Flush();
System.Threading.Thread.Sleep( 10 );
}

// Stefan
 
And the size of a frame is ?

800x600 with 30 frames per second looks quite demanding... I would try to
compute the needed bandwith to see if it looks realistics...

http://www.codeproject.com/KB/audio-video/cameraviewer.aspx?msg=2413900
could also perhaps help. also it seems that for some model the stream is
already exposed using http in whihc case you would have just to point to
this url ?

--
Patrice


Stefan Soljemo said:
Thank you Patrice for fast answer!

The ASHX handler seems to work faster but as you wrote, it will not solve
the main problem with the ASP.NET headers. I did some tests and found that
I
still have performance problem. ASP.NET is not able to deliver 30 JPEG
frames
with 800*600 pixels / second. I still need to work with the HTTP stream
directly. Is there any way to handle the HTTP stream directly or do I need
to
build a dll for ASP or an external web server?
Is there any existing solution or sample who handles MJPEG with ASP.NET?
I'm working with a server product that will capture MJPEG frames from an
IP
camera and store this frames on a server. The frames will then be
available
as a video on a Web page.

Here is a part of code used for tests:
oResponse.ClearContent();
oResponse.BufferOutput = true;
oResponse.ContentType = "multipart/x-mixed-replace; boundary=myboundary";
oResponse.CacheControl = "no-cache";
for( ix = 0; ix < iFramesInBuffer; ix++ )
{
sBundary = "--myboundary\r\nContent-Type: image/jpeg\r\nContent-Length: "
+ images[ ix ].FrameSize.ToString() + sSeparator;
boundary = Encoding.ASCII.GetBytes( sBundary );
oResponse.OutputStream.Write( boundary , 0 , boundary.Length );
oResponse.OutputStream.Write( images[ ix ].Frame , 0 , images[ ix
].FrameSize );
oResponse.Flush();
System.Threading.Thread.Sleep( 10 );
}

// Stefan

Patrice said:
If with ASPX you have no way to suppress it, you could likely do that
with a
custom handler.

See http://dotnetperls.com/ashx-handler (even if you can, by using an
ASHX
handler you'll bypass the webform infrastructure you likely don't need in
this particular case so you may want to try directly a handler).

--
Patrice


"Stefan Soljemo" <[email protected]> a écrit dans le message de
groupe de discussion :
(e-mail address removed)...

.
Click to expand...
Click to expand...
 
Back
Top