【 以下文字转载自 Programming 讨论区 】
发信人: itgirl (程序媛), 信区: Programming
标 题: [合集] 要用HTML + CSS + JS实现所有的App
发信站: 水木社区 (Wed Oct 3 13:53:23 2012), 站内
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Thu Sep 27 20:13:53 2012) 提到:
现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 21:19:06 2012) 提到:
我已经尝试过好多次了...每次都在视频这方面吃瘪...
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
zeus2615 (zeuslord·呆猫) 于 (Thu Sep 27 21:21:03 2012) 提到:
弱弱的问，HTML5不是可以用来解决视频的吗？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 我已经尝试过好多次了...每次都在视频这方面吃瘪...
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 21:23:42 2012) 提到:
只能解决视频文件的播放，流媒体解决不了。
而且这里几个大佬都在打架，局面比较的混乱～
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: 弱弱的问，HTML5不是可以用来解决视频的吗？
☆─────────────────────────────────────☆
zeus2615 (zeuslord·呆猫) 于 (Thu Sep 27 21:53:00 2012) 提到:
html5牛逼吹好久了，前两天看到新闻我才知道要到14年才能定标准，这不扯淡呢嘛。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 只能解决视频文件的播放，流媒体解决不了。
: 而且这里几个大佬都在打架，局面比较的混乱～
☆─────────────────────────────────────☆
CN10086 (雏鸟) 于 (Thu Sep 27 22:21:04 2012) 提到:
说明你无知,很多html5的功能早就用上了.
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: html5牛逼吹好久了，前两天看到新闻我才知道要到14年才能定标准，这不扯淡呢嘛。
☆─────────────────────────────────────☆
zeus2615 (zeuslord·呆猫) 于 (Thu Sep 27 22:24:17 2012) 提到:
某些ID的帖子我是不可能回的
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: html5牛逼吹好久了，前两天看到新闻我才知道要到14年才能定标准，这不扯淡呢嘛。
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 22:25:34 2012) 提到:
背后涉及到大量利益啊，几家扯皮快不起来的。
firefox不支持h.264（因为这些是要授权费的），只支持webm
safari不支持webm，只支持h.264
chrome 2个都支持
-----
没有一个支持rtsp的
safari用了一套很山寨的做法来支持流媒体，还取了个名字叫HLS Stream...
chrome需要webm的封装才能支持流媒体
我后来尝试用chrome+ native client来支持，都可耻的失败了...
其实成功应该没问题，但是即使成功也意义不大了。
被阉割的太厉害了。
native client下的网络走的是websocket，不支持组播也就算了，连binary都不行，只
能把数据流base64编码之后再传...流量直接增加33%，太坑爹了...
然后native client下的ffmpeg不支持mmx/sse/3dnow...总之扩展指令一个都不支持，
就算能解码效率也不行。
看来看去，flash相比之下已经是长得比较顺眼的了...
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: html5牛逼吹好久了，前两天看到新闻我才知道要到14年才能定标准，这不扯淡呢嘛。
☆─────────────────────────────────────☆
sunseraphic (この世界がいつかは幻に変わると) 于 (Thu Sep 27 22:27:50 2012) 提到:
你为什么故意漏了IE啊
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: ...................
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 22:30:32 2012) 提到:
从来就不考虑为IE做web...
【 在 sunseraphic (この世界がいつかは幻に変わると) 的大作中提到: 】
: 你为什么故意漏了IE啊
☆─────────────────────────────────────☆
CN10086 (雏鸟) 于 (Thu Sep 27 22:48:33 2012) 提到:
回不回都是一种无知的表现.
就象有人住在地下室说什么钓鱼岛是中国的一样的脑残.
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: 某些ID的帖子我是不可能回的
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 22:53:14 2012) 提到:
好像我用下来软解还可以接受。
市面上主流的播放器们大都也是软解的。。。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: chrome 2个都支持
: -----
: 没有一个支持rtsp的
: safari用了一套很山寨的做法来支持流媒体，还取了个名字叫HLS Stream...
: chrome需要webm的封装才能支持流媒体
: 我后来尝试用chrome+ native client来支持，都可耻的失败了...
: 其实成功应该没问题，但是即使成功也意义不大了。
: 被阉割的太厉害了。
: native client下的网络走的是websocket，不支持组播也就算了，连binary都不行，只
: 能把数据流base64编码之后再传...流量直接增加33%，太坑爹了...
: 然后native client下的ffmpeg不支持mmx/sse/3dnow...总之扩展指令一个都不支持，
: 就算能解码效率也不行。
: 看来看去，flash相比之下已经是长得比较顺眼的了...
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 22:55:03 2012) 提到:
还可以？
那我有继续下去的动力了...
我现在都懒得把那个plugin调通...
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 好像我用下来软解还可以接受。
: 市面上主流的播放器们大都也是软解的。。。
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 23:08:39 2012) 提到:
供你参考，我的atom270上网本能流畅软解720p的h264影像。
在win下面，ffmpeg的h264解码器的cpu占用比flash少，
而flash在linux下的性能更糟糕，
所以native方案应该性能是过得去的。
不过按照浏览器们目前的状态，
你的这个项目需求最好还是flash，
等html5普及了再上个h264啥的。
呵呵。。。总之很辛苦。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 还可以？
: 那我有继续下去的动力了...
: 我现在都懒得把那个plugin调通...
: ...................
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 23:15:16 2012) 提到:
不是...CPU软解还是要靠扩展指令集的。
ffmpeg的h.264经过这么长时间的优化效率已经很不错了。
但是如果去掉扩展指令集，等于这些优化统统不存在了...
只能用c写的最简单最直白的代码去跑那些原本用SIMD指令优化的代码...
坦白的说我表示很不乐观...
我觉得在搞不好用i7都不一定能搞定h.264 720p的实时解码...
我以为你说的软解是指这种在native client下不用SSE指令级的...
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 供你参考，我的atom270上网本能流畅软解720p的h264影像。
: 在win下面，ffmpeg的h264解码器的cpu占用比flash少，
: 而flash在linux下的性能更糟糕，
: ...................
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 23:20:39 2012) 提到:
好吧，我之前不知道chrome native client...
我还以为是plugin之类的东西。
不能用sse指令集挺奇怪的，是为了兼容不同的芯片构架？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 不是...CPU软解还是要靠扩展指令集的。
: ffmpeg的h.264经过这么长时间的优化效率已经很不错了。
: 但是如果去掉扩展指令集，等于这些优化统统不存在了...
: 只能用c写的最简单最直白的代码去跑那些原本用SIMD指令优化的代码...
: 坦白的说我表示很不乐观...
: 我觉得在搞不好用i7都不一定能搞定h.264 720p的实时解码...
: 我以为你说的软解是指这种在native client下不用SSE指令级的...
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 23:23:28 2012) 提到:
您每次闪亮登场的时候都要放霰弹枪的嘛。。。
【 在 CN10086 (雏鸟) 的大作中提到: 】
: 说明你无知,很多html5的功能早就用上了.
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 23:25:32 2012) 提到:
native client我没有深入研究过其底层，但据说是基于RISC结构的设计，
然后再转换成x86-32/x86-64/arm。
为了实现二进制code的sandbox环境。与真正的native code相比，损失大概5%的性能。
native client在developer看来可以认为是一个特殊的虚拟CPU，用的gcc和glibc都是
cross compiler环境。所以虽然是用c写code，但依然是受很多限制。
据说也是支持SSE／MMX／3Dnow等等的，但也许是未来吧。反正看ffmpeg的port是铁定
不支持的～
其实可以直接用NPAPI写，但是我不想折腾这么旧的，没有未来的API了。
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 好吧，我之前不知道chrome native client...
: 我还以为是plugin之类的东西。
: 不能用sse指令集挺奇怪的，是为了兼容不同的芯片构架？
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 23:34:52 2012) 提到:
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: native client我没有深入研究过其底层，但据说是基于RISC结构的设计，
: 然后再转换成x86-32/x86-64/arm。
: 为了实现二进制code的sandbox环境。与真正的native code相比，损失大概5%的性能。
: native client在developer看来可以认为是一个特殊的虚拟CPU，用的gcc和glibc都是
: cross compiler环境。所以虽然是用c写code，但依然是受很多限制。
Google可真有想法。。。
: 据说也是支持SSE／MMX／3Dnow等等的，但也许是未来吧。反正看ffmpeg的port是铁定
: 不支持的～
: 其实可以直接用NPAPI写，但是我不想折腾这么旧的，没有未来的API了。
啊如果让我选我肯定选npapi+activex套餐的。
功能上不受限制，想做啥都行。虽然累一点 :)
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 23:43:38 2012) 提到:
native client其实还是很不错的～
如果是做游戏的话...opengl和音频都集成的挺好了。
普通的C代码也没有多少移植成本～
然后你不用操心平台问题...32/64/arm,win/linux/android都是一次搞定...
性能基本逼近native code，又是sandbox环境不需要担心搞崩系统...
第三方库的移植google也在做，我贴下...
其实现在已经可以做点事情了～
agg-2.5
boost_1_47_0
bzip2-1.0.6
cairo-1.8.8
cfitsio
dreadthread
expat-2.0.1
faac-1.28
faad2-2.7
ffmpeg-0.5
fftw-3.2.2
flac-1.2.1
fontconfig-2.7.3
FreeImage-3.14.1
freetype-2.1.10
gc6.8
glib-2.28.8
glibc-compat
gmock-1.5.0
gsl-1.9
gtest-1.5.0
hterm
ImageMagick-6.5.4-10
jpeg-6b
jsoncpp-0.5.0
lame-398-2
ld
libmikmod-3.1.11
libmodplug-0.8.7
libogg-1.1.4
libpng-1.2.40
libtheora-1.1.1
libtomcrypt-1.17
libtommath-0.41
libvorbis-1.2.3
lua-5.1.4
Mesa-7.6
nacl-mounts
ncurses-5.9
openal-soft-1.13
OpenSceneGraph-2.9.7
openssl-1.0.0e
pango-1.29.3
pixman-0.16.2
protobuf-2.3.0
SDL-1.2.14
SDL_image-1.2.10
SDL_mixer-1.2.11
SDL_net-1.2.7
SDL_ttf-2.0.10
speex-1.2rc1
tiff-3.9.1
tinyxml
x264-snapshot-20091023-2245
zlib-1.2.3
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: Google可真有想法。。。
: 啊如果让我选我肯定选npapi+activex套餐的。
: 功能上不受限制，想做啥都行。虽然累一点 :)
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Thu Sep 27 23:49:45 2012) 提到:
哇库是挺全的。我去研究一下看看。
顺便问问，它是不是chrome only的？
不能链接个runtime自己embed一个的吧？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: native client其实还是很不错的～
: 如果是做游戏的话...opengl和音频都集成的挺好了。
: 普通的C代码也没有多少移植成本～
: 然后你不用操心平台问题...32/64/arm,win/linux/android都是一次搞定...
: 性能基本逼近native code，又是sandbox环境不需要担心搞崩系统...
: 第三方库的移植google也在做，我贴下...
: 其实现在已经可以做点事情了～
: agg-2.5
: boost_1_47_0
: bzip2-1.0.6
: cairo-1.8.8
: cfitsio
: dreadthread
: expat-2.0.1
: faac-1.28
: faad2-2.7
: ffmpeg-0.5
: fftw-3.2.2
: flac-1.2.1
: fontconfig-2.7.3
: FreeImage-3.14.1
: freetype-2.1.10
: gc6.8
: glib-2.28.8
: glibc-compat
: gmock-1.5.0
: gsl-1.9
: gtest-1.5.0
: hterm
: ImageMagick-6.5.4-10
: jpeg-6b
: jsoncpp-0.5.0
: lame-398-2
: ld
: libmikmod-3.1.11
: libmodplug-0.8.7
: libogg-1.1.4
: libpng-1.2.40
: libtheora-1.1.1
: libtomcrypt-1.17
: libtommath-0.41
: libvorbis-1.2.3
: lua-5.1.4
: Mesa-7.6
: nacl-mounts
: ncurses-5.9
: openal-soft-1.13
: OpenSceneGraph-2.9.7
: openssl-1.0.0e
: pango-1.29.3
: pixman-0.16.2
: protobuf-2.3.0
: SDL-1.2.14
: SDL_image-1.2.10
: SDL_mixer-1.2.11
: SDL_net-1.2.7
: SDL_ttf-2.0.10
: speex-1.2rc1
: tiff-3.9.1
: tinyxml
: x264-snapshot-20091023-2245
: zlib-1.2.3
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Thu Sep 27 23:54:49 2012) 提到:
是开放的～
不过目前只有chrome实现了nacl～
我的建议是现在差不多可以了解下～真拿来做项目还是有点风险的～
我比较不爽的是C API的example只有个hello world...
其他的都是C++的。
这个也太坑爹了...实在是不太想写C++的代码...
然后似乎在某个版本之后发生比较重大的lib迁移，从glibc迁移到newlib上（这个名字
感觉也挺山寨的...总有种临时取的感觉）
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 哇库是挺全的。我去研究一下看看。
: 顺便问问，它是不是chrome only的？
: 不能链接个runtime自己embed一个的吧？
☆─────────────────────────────────────☆
pyer (那啥那啥都被抢注了) 于 (Fri Sep 28 00:00:25 2012) 提到:
可以base128编码啊
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: ...................
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Fri Sep 28 00:07:19 2012) 提到:
看了一下项目主页和wikipedia，
感觉它就是个sandboxed libc。。。
好像现在阶段nacl在各个架构上还是用不同的指令集，
这些指令集应该是没有限制的。
你说的不能用sse可能是ffmpeg的port还没做完吧。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 是开放的～
: 不过目前只有chrome实现了nacl～
: 我的建议是现在差不多可以了解下～真拿来做项目还是有点风险的～
: 我比较不爽的是C API的example只有个hello world...
: 其他的都是C++的。
: 这个也太坑爹了...实在是不太想写C++的代码...
: 然后似乎在某个版本之后发生比较重大的lib迁移，从glibc迁移到newlib上（这个名字
: 感觉也挺山寨的...总有种临时取的感觉）
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Fri Sep 28 00:10:51 2012) 提到:
Native Client currently has the following limitations:
no direct IDE integration (see debugging options)
no support for hardware exceptions
no support for process creation / subprocesses
no support for raw TCP/UDP sockets
(analogus versions - web sockets for TCP and peer connect for UDP - are in the works and will be available soon)
no support for synchronous (blocking) I/O
no support for query to available memory
inline assembly must be compatible with the Native Client validator
(you can use the ncval utility in the SDK to check)
Pepper API calls (described below) must come from the main thread
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 看了一下项目主页和wikipedia，
: 感觉它就是个sandboxed libc。。。
: 好像现在阶段nacl在各个架构上还是用不同的指令集，
: ...................
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 00:14:37 2012) 提到:
最终的确是在各个不同平台上跑native的指令集。
你写的程序可以编译成3个nexe。分别对应x86-32/x86-64/arm～
但是这应该是分2步走的过程，有个用来做validate的中间层～
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 看了一下项目主页和wikipedia，
: 感觉它就是个sandboxed libc。。。
: 好像现在阶段nacl在各个架构上还是用不同的指令集，
: ...................
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 00:19:16 2012) 提到:
http://loda.hala01.com/2012/07/%E5%BE%9Ellvm%E8%AB%87-portable-native-
client-software-fault-isolation%E6%8A%80%E8%A1%93/
这篇文章讲的比较详细，可以看看～
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 最终的确是在各个不同平台上跑native的指令集。
: 你写的程序可以编译成3个nexe。分别对应x86-32/x86-64/arm～
: 但是这应该是分2步走的过程，有个用来做validate的中间层～
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Fri Sep 28 00:21:11 2012) 提到:
俺瞅瞅哈
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
:
http://loda.hala01.com/2012/07/%E5%BE%9Ellvm%E8%AB%87-portable-native-: client-software-fault-isolation%E6%8A%80%E8%A1%93/
: 这篇文章讲的比较详细，可以看看～
: ...................
☆─────────────────────────────────────☆
tcper (男性身体的女权主义者) 于 (Fri Sep 28 01:53:58 2012) 提到:
目前我遇到的问题是一些app页面的转换效果fade in/out这类的，效率极低，没法看的那种
还有就是CSS的实现，在各个平台上有差异，导致界面不一致，甚至有很久没解决的bug，反正就是各种暗坑等你踩
【 在 Tux 的大作中提到: 】
: 现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
fnxu (EVER) 于 (Fri Sep 28 04:58:30 2012) 提到:
HTML + CSS + JS在特定场景下比较方便。
随便说几个：
1）访问底层硬件API，比如gps数据，比如陀螺仪数据，这些对于比如游戏，或者某些app至关重要，能提供很有创造性的功能。
2) 从之前的定义来说，HTML,CSS,JS更侧重于展示.HTML5加了矢量图，好东西，但是也只是在某些方面增强了一些。
3)HTML5是一个标准，每家的实现都不一样，这也会导致你app实现过程中带来一些很难解决的，或者不得不用一些非常2b的解决方案。
总体来说，我觉得希望用这种前台语言来实现所有app，在目前这个阶段是不可能的。有没有可能？有。什么时候有？我感觉未来2年看不到。另外一个就是效率。HTML总归是解释类型的语言。解释类型的语言效率在哪里摆着，很难做到比native的效率高。这些会带来功耗问题，会来在同一个时间内不同实现的app性能差异比较大问题。
HTML的好处在于：部署容易，修改发布相对简单，跨平台性好一些。但是坏处在于对家厂商实现，一些具体的实现细节会带来很多麻烦的事情。
还是权衡来做选择。
【 在 Tux 的大作中提到: 】
: 现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 07:24:16 2012) 提到:
哦，问题这么多啊，不过基本也是意料之中的，连css支持各家都差别这么大，别说这些东西了
我主要是觉得html这套玩意儿其实还是挺好的，就UI来说，HTML/CSS/JS这套应该算MVC的架构灵活性很高，也可以实现很强大的效果，可能比Qt什么的强多了。而且，这套玩意儿在各平台能取得统一的体验，这在linux这种GUI比较烂的系统下还是挺有用的。
当然，如果能直接调用native的东西就更好了。。。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: ...................
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 07:28:15 2012) 提到:
这些倒是问题不大吧，大家都用chrome/fx好了（当然做产品问题比较大，我说的是自己用用）。CSS的话比较麻烦，不过现在也有compass，写跨浏览器的也比以前容易一点了
【 在 tcper (男性身体的女权主义者) 的大作中提到: 】
: 目前我遇到的问题是一些app页面的转换效果fade in/out这类的，效率极低，没法看的那种
: 还有就是CSS的实现，在各个平台上有差异，导致界面不一致，甚至有很久没解决的bug，反正就是各种暗坑等你踩
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 07:30:44 2012) 提到:
嗯，你关注的比较多是移动的App的，类似于phonegap这样的，其实我希望桌面的app也用这个实现...性能可能是个问题，不过js的性能现在也提高了很多吧，还有上面说的native扩展，等成熟了可能还有希望
【 在 fnxu (EVER) 的大作中提到: 】
: HTML + CSS + JS在特定场景下比较方便。
: 随便说几个：
: 1）访问底层硬件API，比如gps数据，比如陀螺仪数据，这些对于比如游戏，或者某些app至关重要，能提供很有创造性的功能。
: ...................
☆─────────────────────────────────────☆
zli07 (Anonymous) 于 (Fri Sep 28 08:48:44 2012) 提到:
base64之后gzip一下，不会变大的; 计算能力才是瓶颈
【 在 lvsoft 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: ...................
☆─────────────────────────────────────☆
tcper (男性身体的女权主义者) 于 (Fri Sep 28 09:03:43 2012) 提到:
你这个不是在移动端？如果都是desktop的浏览器的话，我说的这些基本问题也不大
【 在 Tux 的大作中提到: 】
: 这些倒是问题不大吧，大家都用chrome/fx好了（当然做产品问题比较大，我说的是自己用用）。CSS的话比较麻烦，不过现在也有compass，写跨浏览器的也比以前容易一点了
:
:
☆─────────────────────────────────────☆
mouxiaofeng (我爱生活) 于 (Fri Sep 28 09:07:05 2012) 提到:
【 在 Tux 的大作中提到: 】
: 现在最大的障碍是什么？是效率吗？
不要指望
☆─────────────────────────────────────☆
fnxu (EVER) 于 (Fri Sep 28 09:30:00 2012) 提到:
是这样的，关注性能不是说只看我运行的快不快，还有个效率问题。比如同一个任务，native需要3秒计算出来，在1g cpu上，但是js需要1秒出来就需要 1.5g cpu，这里面就有个效率问题。效率最后会转化成为耗电。也许桌面对这个还好，但是考虑到移动办公需求，即使桌面app也还是要估计这些。
还有很多，比如js的线程问题。目前很多都是多线程的。js来实现很困难。如果js完整支持这些，甚至包括扩展以后，就不是现在的js了，就变成另外一个东西。那个东西搞不好会比现在用的java,c#,c++还复杂。
html/js的优势，总体来说，我觉得没有足够的吸引力去做这种事情，甚至有些事情更本就做不到。
另外一个思路是native app,但是html js来开发ux。
简单的说，我认为没有一个万金油，还是选择不同的东西，扬长避短：）
【 在 Tux 的大作中提到: 】
: 嗯，你关注的比较多是移动的App的，类似于phonegap这样的，其实我希望桌面的app也用这个实现...性能可能是个问题，不过js的性能现在也提高了很多吧，还有上面说的native扩展，等成熟了可能还有希望
:
☆─────────────────────────────────────☆
RuralHunter (乡村猎人) 于 (Fri Sep 28 09:41:05 2012) 提到:
复杂一点的各种浏览器兼容就能搞死人吧
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
cytokine (Cyt.) 于 (Fri Sep 28 09:44:46 2012) 提到:
这种方法呢？
https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG9ztQTdGF48hQYpjQHR_d1WsI
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: ...................
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 09:52:29 2012) 提到:
这样太hack了，回到原始状态了，像视频编码里哪些帧预测什么的压缩方法就不能用了吧？搞个小视频还行，如果视频很大呢...
【 在 cytokine (Cyt.) 的大作中提到: 】
: 这种方法呢？
:
https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG9ztQTdGF48hQYpjQHR_d1WsI☆─────────────────────────────────────☆
cytokine (Cyt.) 于 (Fri Sep 28 09:56:55 2012) 提到:
"It looks like Apple is working on a new version of this script that encodes the
manifest in a PNG image, instead of base64 strings in JSON. Because PNG is
lossless, and <canvas> support is pretty good, it turns out to be a good format
for encoding lots of bytes of data, even if it's not actually an image, and reading
it back into the browser. It will be interesting to see how this PNG format affects
performance and filesize of this animation technique."
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 这样太hack了，回到原始状态了，像视频编码里哪些帧预测什么的压缩方法就不能用了
吧？搞个小视频还行，如果视频很大呢...
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 10:08:14 2012) 提到:
嗯，意思是apple其实是用了一堆的jpg来表示视频，如果初始是I0，那么下一帧I1其实只需更新改变的部分就行了，这些更新信息是用base64存储在json里面的（新版本用png保存）。我的意思是，对于这样变化较小的小视频可能有用，不过对于一般的视频可能就不行了吧（比如影片中具有动态背景的）
【 在 cytokine (Cyt.) 的大作中提到: 】
: "It looks like Apple is working on a new version of this script that encodes the
: manifest in a PNG image, instead of base64 strings in JSON. Because PNG is
: lossless, and <canvas> support is pretty good, it turns out to be a good format
: ...................
☆─────────────────────────────────────☆
pumpwater (pumpwater) 于 (Fri Sep 28 11:16:49 2012) 提到:
我喜欢用flex开发web 或者桌面程序
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 16:05:50 2012) 提到:
这种trick早想过了，没用的。
【 在 cytokine 的大作中提到: 】
: 这种方法呢？
:
https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG9ztQTdGF48hQYpjQHR_d1WsI☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 16:07:24 2012) 提到:
gzip压出来的东西能直接传过来的话，我为什么不直接传h.264 stream？
【 在 zli07 的大作中提到: 】
: base64之后gzip一下，不会变大的; 计算能力才是瓶颈
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 16:13:15 2012) 提到:
我倒是没确认过base128行不行～
不过base128只是缓解了问题～离我的期望还是相去甚远～～
【 在 pyer (那啥那啥都被抢注了) 的大作中提到: 】
: 可以base128编码啊
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 16:25:46 2012) 提到:
这条路一直走到底就是基于纯js来做h.264 decoder～
你别说，还真有...
https://github.com/mbebenita/Broadway
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 嗯，意思是apple其实是用了一堆的jpg来表示视频，如果初始是I0，那么下一帧I1其实
只需更新改变的部分就行了，这些更新信息是用base64存储在json里面的（新版本用png
保存）。我的意思是，对于这样变化较小的小视频可能有用，不过对于一般的视频可能就
不行了吧（比如影片中具有动态背景的）
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Fri Sep 28 16:51:08 2012) 提到:
有做过3D方面的吗？HTML5 处理3D有没有标准了？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 我已经尝试过好多次了...每次都在视频这方面吃瘪...
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 16:55:54 2012) 提到:
webgl
【 在 Madlee (无竹居士) 的大作中提到: 】
: 有做过3D方面的吗？HTML5 处理3D有没有标准了？
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Fri Sep 28 16:57:37 2012) 提到:
支持度如何啊？
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: webgl
☆─────────────────────────────────────☆
Tux (蓝色幽灵) 于 (Fri Sep 28 17:03:33 2012) 提到:
据说Chrome和Firefox支持的不错，不错还没测试过，正在看HTML5 Canvas...
【 在 Madlee (无竹居士) 的大作中提到: 】
: 支持度如何啊？
☆─────────────────────────────────────☆
javaboy (喝了咖啡就话多-_-;) 于 (Fri Sep 28 17:08:42 2012) 提到:
自从js派成功跑上了linux kernel，
我觉得世界上没什么项目他们不敢用js做了。
当然有没有前途是另一回事情 呵呵。。
你在做什么video streaming 的项目啊？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 这条路一直走到底就是基于纯js来做h.264 decoder～
: 你别说，还真有...
:
https://github.com/mbebenita/Broadway: ...................
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 17:54:01 2012) 提到:
webgl
nacl对opengl支持也比较完善。
【 在 Madlee (无竹居士) 的大作中提到: 】
: 有做过3D方面的吗？HTML5 处理3D有没有标准了？
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 17:55:13 2012) 提到:
我有计划要把很久很久以前的做的视频监控的东西重构下～
所以要找个好的起点～
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 自从js派成功跑上了linux kernel，
: 我觉得世界上没什么项目他们不敢用js做了。
: 当然有没有前途是另一回事情 呵呵。。
: ...................
☆─────────────────────────────────────☆
bakeyboy (小苹果) 于 (Fri Sep 28 19:15:27 2012) 提到:
你在啥公司？
感觉做得很高端
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 我有计划要把很久很久以前的做的视频监控的东西重构下～
: 所以要找个好的起点～
☆─────────────────────────────────────☆
zli07 (Anonymous) 于 (Fri Sep 28 19:21:03 2012) 提到:
我是说，http支持gzip，对文本进行编码传输
【 在 lvsoft 的大作中提到: 】
: gzip压出来的东西能直接传过来的话，我为什么不直接传h.264 stream？
☆─────────────────────────────────────☆
CN10086 (雏鸟) 于 (Fri Sep 28 19:49:38 2012) 提到:
总比不懂也不会讲的好.
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 您每次闪亮登场的时候都要放霰弹枪的嘛。。。
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Fri Sep 28 20:02:30 2012) 提到:
好,决定投身html5的事业了。
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 据说Chrome和Firefox支持的不错，不错还没测试过，正在看HTML5 Canvas...
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Fri Sep 28 20:03:27 2012) 提到:
这个，也太牛了。汗。以后浏览器上就可以开多个Linux虚拟机了？
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 自从js派成功跑上了linux kernel，
: 我觉得世界上没什么项目他们不敢用js做了。
: 当然有没有前途是另一回事情 呵呵。。
: ...................
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Fri Sep 28 20:06:08 2012) 提到:
你的视频流是自己在服务器端做编码的吗？不能根据客户端决定编码的格式吗？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 我有计划要把很久很久以前的做的视频监控的东西重构下～
: 所以要找个好的起点～
☆─────────────────────────────────────☆
redbird314 (苦逼100年啊100年) 于 (Fri Sep 28 20:06:38 2012) 提到:
你是盛大的？
【 在 tcper 的大作中提到: 】
:目前我遇到的问题是一些app页面的转换效果fade in/out这类的，效率极低，没法看的那种
:还有就是CSS的实现，在各个平台上有差异，导致界面不一致，甚至有很久没解决的bug，反正就是各种暗坑等你踩
:【 在 Tux 的大作中提到: 】
:: 现在最大的障碍是什么？是效率吗？
☆─────────────────────────────────────☆
redbird314 (苦逼100年啊100年) 于 (Fri Sep 28 20:11:11 2012) 提到:
webgl？
【 在 Madlee 的大作中提到: 】
:有做过3D方面的吗？HTML5 处理3D有没有标准了？
:【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
:: 我已经尝试过好多次了...每次都在视频这方面吃瘪...
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 20:18:42 2012) 提到:
不能～
监控行业，编码器输出的都是h264，没法用webm的东西，转码也不可能～
【 在 Madlee (无竹居士) 的大作中提到: 】
: 你的视频流是自己在服务器端做编码的吗？不能根据客户端决定编码的格式吗？
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 20:19:47 2012) 提到:
用js虚拟了一个简化版的486～
演示的意义大于实际的意义～
【 在 Madlee (无竹居士) 的大作中提到: 】
: 这个，也太牛了。汗。以后浏览器上就可以开多个Linux虚拟机了？
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Fri Sep 28 20:22:48 2012) 提到:
不高端吧，视频监控现在已经是做烂掉了的行业了。
事实上我更新系统的动力都不大，只是探索下做点储备而已。
【 在 bakeyboy (小苹果) 的大作中提到: 】
: 你在啥公司？
: 感觉做得很高端
☆─────────────────────────────────────☆
BigCarrot (大萝卜1号) 于 (Sat Sep 29 03:55:21 2012) 提到:
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: native client我没有深入研究过其底层，但据说是基于RISC结构的设计，
llvm bitcode
https://docs.google.com/viewer?a=v&q=cache:JBx2HyM4bXoJ:nativeclient.googlecode.com/svn/data/site/pnacl.pdf+nacl+llvm&hl=en&gl=us&pid=bl&srcid=ADGEEShqyCm6PlqsNcdP6IC2hbegRTkFdMbsrDSX7f_3-8z4tfSDUQDKIWIXb4QhAenRcsTi9XNbn9RGSfPSOhAjdFJD-JxdhhmialtY4-czeeC_XAtp6aqFXZ69-2R5EhOjZR7ZwWvn&sig=AHIEtbSKHbpkTSChNsVXX6lflSjDTYoLBg
: 然后再转换成x86-32/x86-64/arm。
: 为了实现二进制code的sandbox环境。与真正的native code相比，损失大概5%的性能。
: ...................
☆─────────────────────────────────────☆
Madlee (无竹居士) 于 (Sat Sep 29 12:44:41 2012) 提到:
试了下，FireFox一定要硬件支持，用intel芯片的话就显示不了了。
而且，显卡驱动不够新的话还容易死机。看来兼容性还是狠成问题。
显示的慢点差点还可以通融，但你不能要求客户换机器啊。
【 在 Tux (蓝色幽灵) 的大作中提到: 】
: 据说Chrome和Firefox支持的不错，不错还没测试过，正在看HTML5 Canvas...
☆─────────────────────────────────────☆
DreamDreams (光风霁月) 于 (Sat Sep 29 13:55:51 2012) 提到:
WebSocket应该是已经支持binary了，你用的是哪一版的协议?
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 标 题: Re: 要用HTML + CSS + JS实现所有的App
: 发信站: 水木社区 (Thu Sep 27 22:25:34 2012), 站内
:
: 背后涉及到大量利益啊，几家扯皮快不起来的。
: firefox不支持h.264（因为这些是要授权费的），只支持webm
: safari不支持webm，只支持h.264
: chrome 2个都支持
: -----
: 没有一个支持rtsp的
: safari用了一套很山寨的做法来支持流媒体，还取了个名字叫HLS Stream...
: chrome需要webm的封装才能支持流媒体
:
: 我后来尝试用chrome+ native client来支持，都可耻的失败了...
: 其实成功应该没问题，但是即使成功也意义不大了。
: 被阉割的太厉害了。
: native client下的网络走的是websocket，不支持组播也就算了，连binary都不行，只
: 能把数据流base64编码之后再传...流量直接增加33%，太坑爹了...
: 然后native client下的ffmpeg不支持mmx/sse/3dnow...总之扩展指令一个都不支持，
: 就算能解码效率也不行。
:
: 看来看去，flash相比之下已经是长得比较顺眼的了...
:
: 【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: : html5牛逼吹好久了，前两天看到新闻我才知道要到14年才能定标准，这不扯淡呢嘛。
: --
:
: ※ 修改:·lvsoft 于 Sep 27 22:26:27 2012 修改本文·[FROM: 101.80.75.*]
: ※ 来源:·水木社区
http://newsmth.net·[FROM: 101.80.75.*]
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Sat Sep 29 14:04:58 2012) 提到:
我当时没去测试那个草案～
chrome 23.x版现在支持不？
【 在 DreamDreams (光风霁月) 的大作中提到: 】
: WebSocket应该是已经支持binary了，你用的是哪一版的协议?
☆─────────────────────────────────────☆
DreamDreams (光风霁月) 于 (Sat Sep 29 16:28:20 2012) 提到:
http://websocketstest.com/
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 标 题: Re: 要用HTML + CSS + JS实现所有的App
: 发信站: 水木社区 (Sat Sep 29 14:04:58 2012), 站内
:
: 我当时没去测试那个草案～
:
: chrome 23.x版现在支持不？
:
: 【 在 DreamDreams (光风霁月) 的大作中提到: 】
: : WebSocket应该是已经支持binary了，你用的是哪一版的协议?
: --
:
: ※ 来源:·水木社区
http://newsmth.net·[FROM: 58.38.143.*]
☆─────────────────────────────────────☆
lvsoft (Lv(The Last Guardian)) 于 (Sat Sep 29 18:06:34 2012) 提到:
good~
【 在 DreamDreams (光风霁月) 的大作中提到: 】
:
http://websocketstest.com/☆─────────────────────────────────────☆
CN10086 (雏鸟) 于 (Sun Sep 30 15:27:35 2012) 提到:
支持binary将是恶梦的开始.
多少http因为binary而被菜鸟们搞出来问题.
【 在 DreamDreams (光风霁月) 的大作中提到: 】
: WebSocket应该是已经支持binary了，你用的是哪一版的协议?
☆─────────────────────────────────────☆
CN10086 (雏鸟) 于 (Sun Sep 30 15:28:38 2012) 提到:
这难道有什么不可能的吗?
【 在 Madlee (无竹居士) 的大作中提到: 】
: 这个，也太牛了。汗。以后浏览器上就可以开多个Linux虚拟机了？
修改:lvsoft FROM 101.80.75.*
FROM 58.38.143.*