Hello World

今天更新了一下[IPTV中继原理](https://github.com/wuwentao/bj-unicom-iptv/blob/master/iptv.md)的说明，欢迎大佬们提供建议和错误更正！

I'm also have the same error result with Ubuntu 21.04 seems in latest Ubuntu 21.04 , there is no python link exist, only python3 exist. using `python3 -m serial.tools.list_ports` can...

啊？还判断这个udpxy地址是否有效？我还准备随后自己查找替换，哈哈，因为有2个udpxy地址 改完以后，结果是这个： ``` ubuntu@raspberrypi:~/iptv/iptvtools$ iptv-filter -i https://gist.githubusercontent.com/sdhzdmzzl/93cf74947770066743fff7c7f4fc5820/raw/0be4160f4024320f23daad65bce79e606da47995/bj-unicom-iptv.m3u -t http://epg.51zmt.top:8000/test.m3u --min-height 1080 -u http://192.168.2.1:8012 -c config.json Retrieving playlists from url: https://gist.githubusercontent.com/sdhzdmzzl/93cf74947770066743fff7c7f4fc5820/raw/0be4160f4024320f23daad65bce79e606da47995/bj-unicom-iptv.m3u Retrieving playlists from url: http://epg.51zmt.top:8000/test.m3u 0%| | 0/161 [00:00

哈哈，原来是调用ffmpeg去获取视频源分辨率了，高级啊！ 建议： 此处报错时增加一个error 输出， 提醒安装ffmpeg也行！或者检测命令行是否存在，windows不确定ffprobe命令行是否在PATH里，linux和mac应该都ok 另外，你这就是直接把我之前手工调整和验证的工作全部automation了嘛，点赞！ 但是压根没在文档里进行说明，建议增加一个脚本的功能说明： 1. 下载m3u列表 2. 通过ffmpeg检测rtp或udpxy的视频源地址，获取节目源分辨率（可以增加一下标识，4K,高清，标清等，反正都挨个探测一遍了） 3. 根据节目源和config.json重新分类并生成最终的m3u 这也是为啥一直没尝试脚本的原因，因为压根不知道有这些功能，我以为你就下载文件，转一下格式…… Mac的FFmpeg最近刚刚crash了，最新的OS出幺蛾子了 github里有issue： https://github.com/iina/iina/issues/2784 还没有fix，我是直接raspberry里面装了个FFmpeg 最后，继续report issue： ``` ubuntu@raspberrypi:~/iptv/iptvtools$ iptv-filter -i https://gist.githubusercontent.com/sdhzdmzzl/93cf74947770066743fff7c7f4fc5820/raw/0be4160f4024320f23daad65bce79e606da47995/bj-unicom-iptv.m3u -t http://epg.51zmt.top:8000/test.m3u --min-height 1080 -u...

那个进度条的输出，实质显示是换行了的，应该和树莓派没啥关系，只是copy过来github就丢失格式了…… 看了一下，确实成功了！点赞，基本功能都算齐活了！ 不过发现CCTV-3不知道怎么个情况，生成的列表里没有了， gist页面好像有，不影响使用

ok，大概知道原因和思路了！ python也会点，水平太菜，只会些基本的实用，主要用的少，还得多向你学习学习，后面有空再看看，继续了解一些具体功能和实现原理再说！ 这样来说，整套最完整且一步到位的流程，其实应该如下: 1. 扫描获取节目列表，这个会比较耗时 2. 取到节目列表的时候，和你ffprobe一样，也是得建立连接并验证视频源是ok的，也是可以补充和完善的地方， 节目源地址有了，分辨率有了，再OCR识别画面，根据EPG台标即可识别出频道名称了（或者其他类似功能来确定频道名称？我不确定，这一块不大懂，了解的不多） 3. 最终需要的：IP，Port, 频道名称, 分辨率，台标 4. 根据规则来排序，生成最终m3u文件，一次齐活！ 其实只需要个把月扫描一次即可，确认是文件否有修改或者变化即可！ 树莓派或者软路由这类小主机能很好胜任（1080p+4k视频对硬件要求还是有一些的），我基本就是拿来当玩具，做一些router上比较缺乏的功能，开着ddns，当太server在用。 如果自己定期用电脑手动跑也行，就是得想起来了才能去做这项任务

节目单那个确实是挺稳定，也没顾上去抓包看看实际的数据，总之现在就是剩一些不疼不痒的东西，哈哈 借楼扯点不相干的： 1. AC86U跑梯子，speedtest最快速度能到多少？或者油管速度？ 我是很早以前的6300V2，性能太low了，跑不上去，梯子在树莓派上，CPU不支持硬件AES加密，性能不如x86设备，speedtest跑200M左右问题不大，油管大概80M左右。 2. 开各种服务以后，merlin的硬件NAT加速是否开启？查看：Tools---- HW acceleration 有三种：CTF+FA 或者CTF only或者disabled, incompatible with XXX 我的渣路由只有CTF only，不过带宽只有300M，基本足够跑满了

No, 路由器有非常大的瓶颈，梯子流量的加解密都是靠CPU处理，这是考验路由器硬件的最大性能问题…… 我的树莓派CPU在加解密方面都比较垃圾，只能说比路由器是强多了，目前勉强够用，据说是为了省钱，而没有购买ARM的AES授权，导致aes指令不可用…… 另外根据你提供的链接，我搜了一下，还是得益于你这块路由器，AC86u的CPU是增加了AES指令的！ cat /proc/cpuinfo里面应该有aes指令，所以你才没有速度和性能方面的感觉 硬件NAT看来AC86u应该也问题不大，估计解决了性能 vs 功能方面的影响 我再忍忍，随后直接wifi6了，哈哈

> 这样啊，我理解的是speedtest既然基本满速，访问油管对于路由器而言的行为应该差不多？如果理解有问题还望不吝指正。一不小心暴露了自己的姿势水平，惭愧惭愧。 都一样，哈哈，大家也是在不断讨论，不断理清自己的想法和实际的区别，互相扯淡才能共同进步！ speedtest满速的话，基本上油管也问题不会太大，但实际二者还是有不少区别的 1. 因为speedtest测试的原理是http/tcp测速，基本测速 2. google youtube就套路很多了，例如油管是视频流，不仅仅是单纯的http测速，像html5播放，flash播放貌似都有不同区别，其次google流弊之处是改进了很多，例如，如果你用Chrome浏览器也会有很多针对自身协议的优化改进，其次，TCP，UDP协议来大量用来加速网络，打个比方TCP BBR加速，还有基于UDP协议的SPDY/QUIC协议等等，现在的youtube就是有UDP的QUIC协议在跑着的，有的连接是直接走UDP 443端口（QUIC）直连，这样就直接跳过梯子，跳过路由器加解密了，所以和单纯的speedtest，细节方面还是会有一部分区别的（据说UDP可能会被运营商限速） WIFI6现在还是贵了点，暂时还没得太多终端设备，不能为了换WIFI6路由器，把电脑手机都换了，哈哈，所以目前带宽300M的前提下暂时还算够用用了，没有形成瓶颈，只不过需要把部分服务移出去来避免成为负担（我是甩到树莓派4B上了）

> 我那个python的版本是最开始参考国外一个开源代码写的，然后把已知端口都加进去穷举ip段和端口号了。后来我嫌这个太慢，仔细研究了一下，发现完全没必要跟端口一起枚举，发送一个加入组播的请求，然后用pcap库抓这个ip的udp包就能抓到这个下对应的端口号(有些省份一个ip可以有2个端口号去分别提供不同频道)。这个可以参考我的windows代码，那个是最新的代码。思路就是1监听指定网卡上特定ip数据包，2发送加入组播的数据包，3分析抓到的前100个数据包，把端口号记下来。4发送退出组播的数据包。 关于识别频道名称，ffprobe的方式在北京联通的环境里并不友好。北京联通的元数据里并不是每个频道都有，而且格式也是乱七八糟，有几个频道的频道名是一样的。ocr识别是最靠谱的方式。 获取 Outlook for Android 为大神的工具和方法点赞，这样效率比盲目扫描的高太多了！ 但是我木有windows的环境，另外Mac的Type C转RJ45转接头扔在公司了，一直没去拿，所以就一直没怎么关注(还是懒） 主要是诸位大神们都造好一堆轮子了，更加懒得去重复做同样的事，哈哈哈 不过还是个人的需求，使用环境不同，例如识别分辨率，例如排序，例如识别节目频道，例如增加m3u台标文件等等，导致就出现了一堆不同的解决办法！ 最后，我觉得，大部分人基本还是喜欢拿来就用，直接捡现成的（包括我，以及其他大部分人），不会去自己下载安装扫描节目单的软件或者工具，直接下载最终成品m3u即可，所以这才是最终需求，直接给出做好的饭即可，绝大部分人是都喜欢直接吃熟的，端起来就能吃，哈哈哈！ 所以我就直接把您那个文件自己编辑，修改，排序了，当时想的就是，反正比较稳定，时间长了，如果有更新，时间长了，对比一下diff，看看变化，调整一下也没啥，反正有现成的饭吃就行了，扫描不扫描不重要，只要节目源稳定，可以播放即可，尤其是常见的主流节目稳定就行了