基于现代浏览器,使用MJPEG over HTTP实现简单视讯网络广播
作者:V君 发布于:2015-9-21 9:39 Monday 分类:挖坑经验
TL;DR:
实现一个数据源来提供一系列帧图像数据(本例jpeg), 随便找个请求处理程序贴上以下代码,
用现代浏览器(Chrome/FF)访问即可
const string boundary = "frame";
Response.Buffer = false;
Response.BufferOutput = false;
Response.ContentType = "multipart/x-mixed-replace; boundary=" + boundary;
while (true)
{
byte[] buf;
while (null == (buf = VideoQueue.Pull()))
{
Thread.Sleep(100);
}
var output = Response.OutputStream;
output.WriteAscii("--" + boundary);
output.WriteAscii("\r\n");
output.WriteAscii("Content-Type: image/jpeg");
output.WriteAscii("\r\n");
output.WriteAscii("Content-Length: " + buf.Length);
output.WriteAscii("\r\n");
output.WriteAscii("\r\n");
output.Write(buf, 0, buf.Length);
output.WriteAscii("\r\n");
}
扯一扯:
要在浏览器实时查看摄像头画面,
然而摄像头在NAT背后, 只能搭一个平台来转发数据.
用AForge的DirectShow封装取得每一帧画面, 推到平台上.
那么剩下的就是如何在浏览器呈现了.
定时轮询? 感觉图样, 有没有以视频方式呈现? H5的Video标签好像可以用的样子.
然而并没有找到从一堆图像生成视频流的方式,AForge只能写文件,
用了各种关键字最后找到 MJPEG 方式,
参照 CodeProject 上面的一个例子写了这个长连接的请求处理程序.
只能在浏览器地址栏直接打或者给img标签的src, video标签并不支持.
你可以从多个浏览器访问视频画面, 就像广播一样 乂目
写了个屏幕录像并以 MJPEG 广播的 Demo, 泥可以从这里获取
[更新]使用WinDbg分析转储文件 找出C#程序内存占用过大的原因
作者:V君 发布于:2015-9-15 14:37 Tuesday 分类:填坑经验
TL;DR:
1)打开windbg载入dmp
2).loadby sos mscorwks
3)!dumpheap -stat
你写的程序你估计就知道为啥了
扯扯:
这次不是进程崩溃, 是另一个服务进程内存占用异常的大 , 超过4GB
原因诊断十分顺利, 然并卵,
因为某个环节需要调用第三方服务接口来解析数据,
这个接口似乎承受不住请求密度, 出现严重延迟现象
进程内部队列一直堆积着, 内存就撑大了 _(:з」∠)_
参考来源 调试内存泄漏问题的一些经验 by Dawei XU
参考来源 debugging.io
继续补充:
当不是你写的程序, 然而你又看到大量String而不知所措时
先用!strings命令来刷刷内存中的字符串, 适当的时候按暂停, 不然会卡死你
然后总结一下内容,看看有没有大片有规律的字符串
使用 !gcroot 每行前面的地址查看是什么地方引用了它 (参考来源: theartofdev.com)
再进一步: !mdt 出来的根对象地址, 如果是List<T> 还可以查看内容哟
顺着items进去,点击 expand first 40 items, 嗯嗯 这下真相大白啦
(我不会说之前的人真是丧心病狂, 60多万行1G以上内容,
居然直接查询出来放到内存里面去挨个处理) ‘皿’
[已解决]遭遇 clr20r3
作者:V君 发布于:2015-9-10 11:05 Thursday 分类:填坑经验
有个负责的老项目服务进程多次崩溃, 没有留下有价值的线索.
事件日志查到的信息不多
EventType clr20r3, P1 ******.exe, P2 1.0.0.0, P3 ******, P4 mscorlib, P5 2.0.0.0, P6 ******, P7 dc, P8 5, P9 a4dh5wwiwww1yjtmp0c0kv4zwcalu4in, P10 NIL.
咕狗过 a4dh5wwiwww1yjtmp0c0kv4zwcalu4in , 似乎是 KeyNotFoundException
然而并不知道是什么地方爆错,先上个 AppDomain.CurrentDomain.UnhandledException
看看能不能捕获“临终”前的异常.
-待更(等待下一次崩溃。。。)
-然而进程到现在还没崩溃。。。
-似乎是另一个进程把内存撑爆了才挂掉 _(:з」∠)_
结果更:
总算是等到崩溃了,临终遗言GET! 和查到的一样, 是 KeyNotFoundException
2015-11-26 **:**:**,** [**] FATAL
程序集: **.**.**, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
消息: System.Collections.Generic.KeyNotFoundException: 给定关键字不在字典中。
在 System.ThrowHelper.ThrowKeyNotFoundException()
在 System.Collections.Generic.Dictionary`2.get_Item(TKey key)
在 **()
在 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
在 System.Threading.ThreadHelper.ThreadStart()
额外信息: 发生严重错误导致进程崩溃
在C#中使用EPPlus创建Excel报表
作者:V君 发布于:2015-9-7 10:12 Monday 分类:挖坑经验
项目主页:
http://epplus.codeplex.com/
使用示例:
http://zeeshanumardotnet.blogspot.com/2011/06/creating-reports-in-excel-2007-using.html
爆栈好评:
http://stackoverflow.com/questions/2654932/create-excel-files-from-c-sharp-without-office
用法:
//创建实例
var excel = new ExcelPackage();
//创建工作表
var wb = excel.Workbook.Worksheets .Add(teamName);
//写表头, 设定列数据样式
wb.Cells[1, 1].Value = "id"; wb.Column(1).Style.Numberformat.Format = "0";
wb.Cells[1, 2].Value = "name";
//写数据
wb.Cells[2, 1].Value = "1";
wb.Cells[2, 2].Value = "zeus";
wb.Cells[2, 1].Value = "2";
wb.Cells[2, 2].Value = "suez";
//自动列宽
wb.Column(i).AutoFit();
//表头字体样式
wb.Cells[1, 1, 1, 2].Style.Font.Bold = true;
//保存
excel.Save(stream);
感想:
之前做excel要么用臃肿的interop,要么NPOI这个从java搬过来的东西, 今天抱着试一试的心态再找找, 结果就找到了 EPPlus
用起来感觉还不错!
//EOF
NGen并不能提升代码执行效率
作者:V君 发布于:2015-8-23 21:46 Sunday 分类:折腾手记
TL;DR: 看这里
实际上NGen.exe仅仅是加快应用程序的启动速度,执行时的性能并不比JITCompiler编译的代码快。主要原因是,编译代码时, NGen无法像JIT编译器那样对最终的执行环境作出许多假设,这会造成NGen.exe产生较差的代码。例如, NGen不能优化一些CPU指令, 对静态字段的访问需要间接的操作而不能直接访问,因为静态字段实际的地址需要在运行时刻才能知道。NGen到处插入代码来调用类的构造函数,因为它不知道代码执行的次序,不知道类的构造函数是否已经被调用。
听我扯扯:
一直用着SevenZipSharp(7z#), 这货相当方便, 然而现在我想设计自己的压缩归档,
需要选择压缩算法纯粹的对数据块进行压缩,
然而7z#似乎没有提供这样的接口, 算法的实现又在本地的7z.dll里...
最重要的是不跨平台, linux 没法用.(尽管7z#似乎在出mono版本, 但貌似已经熄火两年...)
于是又找到了个纯托管的实现 -- SharpCompress .
嗯嗯 这货很好的实现了各种算法的纯粹压缩流,
有 LZMA, LZMA2 (仅解压) ,Gzip, Bzip2, Deflate, PPMd .
在我设计的压缩归档里面,
首先将要压缩的数据挨个调用这些算法的极限压缩, 选择最高压缩比的算法,
以一个字节标识到压缩后数据块前面,
如果所有的算法输出都比原始数据大, 那么直接存储, 数据块前面的标识会注明
跑了一遍下来
Ppmd: 3,404
Deflate: 2,160
Store: 1,996
Lzma: 393
BZip2: 595
--------------
Total: 8,548
发现PPMd算法被使用次数最多, 然而PPMd每次执行都时间几乎都在秒级以上
欲让它执行得快一点. 于是想起JIT这回事,
咕狗搜索 Force JIT 找到 NGen 试着产生 SharpCompress 的 ni.dll
用 procexp 查看确实被加载后, 对压缩调用计时.
然并卵, 速度根本没有提升嘛! 更要命的是解压反而比压缩慢, 这是闹哪样?
接着查 NGen 性能, 这时才明白原来根本就是用错东西了...
打一下自己的脸, 找C或++的实现, 然后做个C++/CLI或者导出函数来pinvoke吧.
(我大mono可是支持pinvoke的哟)
blogger
Google Web Translator
热门日志
随机日志
最新日志
最新评论
- V君
@Quartz:(出现)... - Quartz
怎么不见人了呢... - V君
@Soar:DHCP 协议相... - V君
@Soar:当然是非... - Soar
@V君:谢谢 有空... - Soar
搞一个 1230v3+B85... - V君
@Soar:另外,也可... - V君
@Soar:iscsi服务端... - Soar
难怪这么卡,尤其... - Soar
clone了源码,提示...
分类
存档
- 2024年5月(1)
- 2023年7月(1)
- 2023年5月(1)
- 2022年11月(1)
- 2022年10月(1)
- 2022年9月(1)
- 2022年8月(1)
- 2022年7月(1)
- 2022年6月(1)
- 2022年5月(2)
- 2022年4月(1)
- 2022年3月(1)
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年11月(1)
- 2021年10月(1)
- 2021年9月(1)
- 2021年8月(1)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(1)
- 2021年4月(1)
- 2021年3月(1)
- 2021年2月(1)
- 2021年1月(1)
- 2020年12月(1)
- 2020年11月(1)
- 2020年10月(2)
- 2020年9月(1)
- 2020年8月(1)
- 2020年7月(1)
- 2020年6月(1)
- 2020年5月(1)
- 2020年4月(2)
- 2020年3月(3)
- 2020年2月(1)
- 2020年1月(1)
- 2019年12月(1)
- 2019年11月(1)
- 2019年10月(1)
- 2019年9月(1)
- 2019年8月(2)
- 2019年7月(1)
- 2019年6月(1)
- 2019年5月(1)
- 2019年4月(1)
- 2019年3月(1)
- 2019年2月(1)
- 2019年1月(2)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(3)
- 2018年9月(4)
- 2018年8月(6)
- 2018年7月(4)
- 2018年6月(1)
- 2018年5月(2)
- 2018年4月(2)
- 2018年3月(3)
- 2018年2月(1)
- 2018年1月(1)
- 2017年12月(1)
- 2017年10月(2)
- 2017年9月(1)
- 2017年8月(2)
- 2017年7月(1)
- 2017年6月(5)
- 2017年5月(2)
- 2017年4月(2)
- 2017年3月(3)
- 2017年2月(2)
- 2017年1月(2)
- 2016年12月(3)
- 2016年11月(2)
- 2016年10月(3)
- 2016年9月(4)
- 2016年8月(2)
- 2016年7月(4)
- 2016年6月(3)
- 2016年5月(1)
- 2016年4月(4)
- 2016年3月(3)
- 2016年2月(1)
- 2016年1月(5)
- 2015年12月(4)
- 2015年11月(5)
- 2015年10月(1)
- 2015年9月(6)
- 2015年8月(4)
- 2015年7月(1)
- 2015年6月(6)
- 2015年5月(3)
- 2015年4月(3)
- 2015年3月(2)
- 2015年2月(1)
- 2015年1月(3)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年9月(3)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(3)
- 2014年4月(1)
- 2014年3月(1)
- 2014年2月(2)
- 2014年1月(1)
- 2013年12月(2)
- 2013年11月(2)
- 2013年10月(1)
- 2013年9月(3)
- 2013年8月(14)
- 2013年7月(7)
- 2013年4月(1)
- 2013年3月(4)
- 2013年2月(6)
- 2013年1月(6)
- 2012年12月(8)
- 2012年11月(6)