很快啊，几乎没有犹豫，啪的一下就选了 wpf

没写过 c++的团队，还是建议 wpf 好用。
不是担心不好写啥的，大多数情况 c with class 硬搞都可以搞。
但是所有人都摸石头过河，没有规范到头来一堆问题。
不仅仅是开发成本，维护成本也是成本。
如果有得选当然选 wpf ，人生苦短。
当然如果只有一个人写，养老的那么选 c++ (doge ，狗头保命

哈哈哈哈哈 确实挺复杂的
去年闲时捡起了很多年前 python ，随便折腾也折腾了一下午 docker+uwsgi+django
https://github.com/nevermoreluo/kitchen/blob/main/docker-compose.yml
祝你好运吧

@4Each4
说实话，考虑百万日活的前提是考虑游戏类型，到底是什么类型的游戏。
网游吗能分场景服务吗，场景服务能自动扩容吗，角色服务有必要再拆分吗，彼此之间数据同步怎么做。
或者不要考虑那么多，经典华夏滚服，几千人一个服务器，人满了开新的不好吗。。。

说句不好听的，单纯论语言没啥用。。。
c++嵌 lua 都被 lua 的 gc 坑过，真的要百万量级，还不分服应该是有点东西的。
游戏服务其实不像传统 HTTP 服务，还是有区别的。而且有些实现也都不一样。
比如网关服务(降低延迟分发用户)，角色服务(角色逻辑)，场景服务(场景交互逻辑)，数据服务(数据逻辑)等等。

想清楚要干啥，或者找个一样游戏类型的人问下
真的考虑百万日活，棋牌游戏，网游，页游，这些架构上可能就不一样。

最后：
别想太多，轻装上路，我们的征途是星辰大海。

@4Each4
不要用什么 netfromwork, 用.Net core 6 以上就行 现在好像都 8.0 了

之前的项目做过一些 netformwork 转 core 的工作，基本 99%的代码都是一样的
以下几种不一样:
- 很底层的 socket 接口部分参数（ keepalive ）不一样
- 一些微软专有的框架 wcf 之类的， .Net core 是没有的，当时自己拿 grpc 替换掉了 wcf 实现的功能
其他的都一样，开发在 win 上开发(别问，问就是关卡策划也写代码)，部署在 linux 上一切正常

叠甲，以下是曾经断续看过两周各种奇怪资料的个人理解，如有不对还请大佬指正:

1. 差别是网络延迟、缓存、编解码(甚至转码，有的时候软解还要组回去喂给 canvas 或者 mse)。因为这些问题会导致视频甚至无法在 video 标签里面播放，例如 avi 。定位文件从那个字节播放有点想当然了，视频编码不是平铺直叙的，文件指针 seek 到相应位置并不一定等于视频播放 seek 到对应位置。举个例子，音频流和视频流是两组信息，就算你强行 seek 过去大概率会在视频上。夫人，你也不想播放光渲染画面，没有声音吧。。。

2. 解复用是把封装在容器文件中的音视频流分离出来，就像上面说的特例，假设就只有一个视频流和一个音频流，实际可能有很多。字节的 range 也是依赖 mp4 特定格式的 meta 信息，解析出索引和时间戳找到对应的数据组回 mse 播放的。也就是说限定 mp4 支持了 range

3. 这个我也不太了解，就不强答了。

@Goat121
CDN 好像现在支持了？ 要不要把方案转回来 23333
https://help.aliyun.com/zh/cdn/user-guide/object-chunking
https://support.huaweicloud.com/usermanual-cdn/cdn_01_0027.html
https://cloud.tencent.com/document/product/228/7184

1. 多数音视频格式是无法通过头上一段字节推断流内容的，mp4 除外
2. hls 有现有库支持浏览器播放，video 标签支持 mp4
3. H265 解码问题，浏览器多数还不支持硬解，软解实现操蛋，流媒体在服务器上就解决了
4. 即使 range 也要再经过一系列的解复用才可以拖进度条，不过有现成的库，例如字节的 https://github.com/bytedance/xgplayer

本质是人的原因跟换不换行业可能没关系。
我有段时间也这样，极度崩溃。但是其实换了行业也只能保持几个月的新鲜感，不过可能是因为我是向下兼容的厌倦的比较快。
找事情填满日子，看看这个页面最下面那句。

♥ Do have faith in what you're doing.

对接的对象多写文档能有效降低沟通成本。
不过，维护时更新就很麻烦，所以我一般都是不写，要写就项目注释通过 ci 生成文档，文档跟着项目走。
有新的项目对接直接给文档地址，降低很多沟通成本。
doxygen+swagger 再给提供一些小的测试工具可以自定义发包的基本够用了

三个都用过，以下是个人感觉
易用性上 pm2 好，端口复用, 程序多开，日志分割统统都可以用 pm2 解决
稳妥上还是 systemd
supervisor ，咋说呢，好几年前用过，稳定也挺稳定的，配置完之后也没太多改动，但是状态查看/管理，确实比 PM2 差很多

youtube 上有个 CodeAesthetic ，感觉可以看下。有一期讲的 Never Nester ，还是有部分道理的

像我这种野路子常年代码畸形的人，时常要翻出来再看下
找到了，https://www.youtube.com/watch?v=CFRhGnuXG-4

233333 没看到，大概是大家都在忙于解决各种编译 bug 吧。。。。

先叠甲，本人至今都不敢说自己会 C++，我就是个调包侠。
但是 C++写 web ，确实都是眼泪，对于我这种水平一般啥啥脚本语言都调一点的调包侠而言。
C++的 webframework ，就方便易用性而言离其他语言的 web 框架真的还差好远。
什么 orm, db merge, middleware, doc 都是稀罕玩意儿，别问公司前辈，问就是之前项目用到很少都是自己手组 HTTP 协议包。。。

其实就我这种调包侠而言，最痛苦的是至今没有一个合适的包管理。
注意我说的不是说现在市面上没有包管理，而是百花齐放，vcpkg ，conan ，甚至啥都没有直接 cmake ，make ，grunt 都很好，虽然很多库构建起来有千奇百怪的问题，但我自己开发够用了。
但是当所有人都统一用一个包管理的时候，我想大抵会减少很多 5 个项目 6 个 json 库 4 个网络库这种奇葩场景了吧
大抵不会有 grunt 里面大佬 git clone 一把梭，拉下来发现拉到最新的编译不过的问题了吧


总之，我感觉这东西适合有非常详尽的规范，才好用，其实公司业务使用语言特性 10%都用不到，所以我觉得写代码都是其次的，规范才是重要的，但是我这种非科班自学的，自己的一套都要摸索权衡，遑论规范前辈同事了。
像我这种调包侠就算会了 C++活少也是有道理的，大佬们给的包调的不舒服，自己写出货又很慢，公司再一催 deadline ，只好简单实现功能了事，后来者看到想扩展怕是难的。

写这么多其实就是吐槽罢了，我也没啥能力改变现状，只能尽量写好文档，搞好 dev flow 省的 n 年后来的人和我一样，拿到项目编译都要一堆事难搞。
还是学点 rust ，修(死)身(去)养(活)性(来)吧

@Peek 哈哈哈哈哈 如果你是个人使用的话，我探索过程中发现一个 https://www.plex.tv/ ，他支持各种格式的音视频，在线激活一回可以离线，感觉适用你的媒体整理的需求，感觉你可以试试

@tuimaochang 其他组的同事说这个他试过 avi 的播不了，不过我看了下文档，感觉没提到。等下我自己再试验下 谢啦

@flyqie 其实自己折腾试过 ffmpeg wasm 逐帧解画面->yuv->canvas, 十几分钟的小文件试了下倒是也能播（文件大了效果也还不确定）
不过播放器控件+音频解析+seek+倍速 路好长而且这么长的路自己搞也就算了，公司的业务还不太敢路太长了 bug 多

其实想找下大哥们有啥前辈走过的路没有

@janus77 有很多设备录制回来的影像资源需要播放。但是设备什么牌子的都有，没法控制输入是什么格式的。
主要是 mp4+少量 avi ，但是有些确实给了 mov 的

海康讯飞都有现成的，就是比较贵
单就识别而言，自己拿 opencv+dlib 也能写吧 就折腾