iptvtools
iptvtools copied to clipboard
huxuan
Discussion
ubuntu@raspberrypi:~/iptv/iptvtools$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
ubuntu@raspberrypi:~/iptv/iptvtools$ git config --list
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/huxuan/iptvtools.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
ubuntu@raspberrypi:~/iptv/iptvtools$ iptv-filter -v
0.1.8.dev1+g6f56d69
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.50.1:8888
Retrieving playlists from url: https://gist.githubusercontent.com/sdhzdmzzl/93cf74947770066743fff7c7f4fc5820/raw/0be4160f4024320f23daad65bce79e606da47995/bj-unicom-iptv.m3u
Traceback (most recent call last):
File "/usr/lib/python3.7/urllib/request.py", line 1317, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
File "/usr/lib/python3.7/http/client.py", line 1252, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1298, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1247, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1026, in _send_output
self.send(msg)
File "/usr/lib/python3.7/http/client.py", line 966, in send
self.connect()
File "/usr/lib/python3.7/http/client.py", line 1414, in connect
super().connect()
File "/usr/lib/python3.7/http/client.py", line 938, in connect
(self.host,self.port), self.timeout, self.source_address)
File "/usr/lib/python3.7/socket.py", line 727, in create_connection
raise err
File "/usr/lib/python3.7/socket.py", line 716, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/.local/bin/iptv-filter", line 10, in <module>
sys.exit(main())
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/iptv_filter.py", line 52, in main
playlist.parse(args)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/models.py", line 58, in parse
self._parse(args.input, udpxy=args.udpxy)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/models.py", line 64, in _parse
lines = parsers.parse_content_to_lines(source)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/parsers.py", line 20, in parse_content_to_lines
return _parse_from_url(content)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/parsers.py", line 48, in _parse_from_url
with urlopen(url) as response:
File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python3.7/urllib/request.py", line 525, in open
response = self._open(req, data)
File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
'_open', req)
File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
result = func(*args)
File "/usr/lib/python3.7/urllib/request.py", line 1360, in https_open
context=self._context, check_hostname=self._check_hostname)
File "/usr/lib/python3.7/urllib/request.py", line 1319, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 111] Connection refused>
ubuntu@raspberrypi:~/iptv/iptvtools$
啊？还判断这个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<?, ?it/s]Traceback (most recent call last):
File "/home/ubuntu/.local/bin/iptv-filter", line 10, in <module>
sys.exit(main())
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/iptv_filter.py", line 53, in main
playlist.filter(args)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/models.py", line 103, in filter
if not utils.check_stream(url, args):
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/utils.py", line 91, in check_stream
stream_info = probe(url, args.timeout)
File "/home/ubuntu/.local/lib/python3.7/site-packages/iptvtools/utils.py", line 76, in probe
proc = Popen(f'{PROBE_COMMAND} {url}'.split(), stdout=PIPE, stderr=PIPE)
File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.7/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'ffprobe': 'ffprobe'
0%| | 0/161 [00:00<?, ?it/s]
ubuntu@raspberrypi:~/iptv/iptvtools$
是的，如果有 udpxy 前缀的话是会直接用 udpxy 拼成的地址来判断的，也就是说判断的不是 rtp://239.X.X.X，而且http://192.168.X.X:XXXX/rtp/239.X.X.X
这个错误信息是说需要安装 ffprobe，也就是 ffmpeg，Mac 上可以直接用brew install ffmpeg就行了。
这个是因为设置了选项 --min-height 1080，如果要判断 stream 的 resolution，必须得有 ffmpeg，其中实际用到的是 ffprobe 命令
README 里面说了，可能还不够明显：https://github.com/huxuan/iptvtools#prerequisites
哈哈，原来是调用ffmpeg去获取视频源分辨率了，高级啊！ 建议： 此处报错时增加一个error 输出， 提醒安装ffmpeg也行！或者检测命令行是否存在，windows不确定ffprobe命令行是否在PATH里，linux和mac应该都ok
另外，你这就是直接把我之前手工调整和验证的工作全部automation了嘛，点赞！
但是压根没在文档里进行说明，建议增加一个脚本的功能说明：
- 下载m3u列表
- 通过ffmpeg检测rtp或udpxy的视频源地址，获取节目源分辨率（可以增加一下标识，4K,高清，标清等，反正都挨个探测一遍了）
- 根据节目源和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 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
6 Valid Channels: 11%|###################2 | 17/161 [01:47<15:10, 6.32s/it]7 Valid Channels: 17%|##############################5 | 27/161 [02:51<14:14, 6.37s/it]9 Valid Channels: 23%|#########################################8 | 37/161 [03:52<12:36, 6.10s/it]11 Valid Channels: 29%|###################################################7 | 46/161 [04:49<12:08, 6.33s/it]13 Valid Channels: 34%|#############################################################8 | 55/161 [05:47<11:19, 6.41s/it]15 Valid Channels: 40%|######################################################################### | 65/161 [06:50<10:08, 6.34s/it]20 Valid Channels: 46%|###################################################################################1 | 74/161 [07:47<09:06, 6.28s/it]23 Valid Channels: 52%|##############################################################################################4 | 84/161 [08:48<07:54, 6.16s/it]23 Valid Channels: 58%|#########################################################################################################6 | 94/161 [09:51<07:01, 6.29s/it]27 Valid Channels: 64%|###################################################################################################################1 | 103/161 [10:48<06:04, 6.29s/it]29 Valid Channels: 70%|##############################################################################################################################3 | 113/161 [11:51<05:08, 6.43s/it]34 Valid Channels: 76%|########################################################################################################################################3 | 122/161 [12:48<04:05, 6.28s/it]39 Valid Channels: 82%|###################################################################################################################################################5 | 132/161 [13:51<03:03, 6.34s/it]41 Valid Channels: 88%|#############################################################################################################################################################6 | 141/161 [14:48<02:06, 6.32s/it]47 Valid Channels: 94%|########################################################################################################################################################################8 | 151/161 [15:52<01:03, 6.38s/it]50 Valid Channels: 99%|##################################################################################################################################################################################8 | 160/161 [16:49<00:06, 6.40s/it]50 Valid Channels: 100%|####################################################################################################################################################################################| 161/161 [16:55<00:00, 6.31s/it]
Invalid Urls:
http://192.168.2.1:8012/rtp/239.3.1.10:8228
http://192.168.2.1:8012/rtp/239.3.1.11:8040
http://192.168.2.1:8012/rtp/239.3.1.12:8232
http://192.168.2.1:8012/rtp/239.3.1.13:8048
http://192.168.2.1:8012/rtp/239.3.1.143:4120
http://192.168.2.1:8012/rtp/239.3.1.144:4120
http://192.168.2.1:8012/rtp/239.3.1.146:4120
http://192.168.2.1:8012/rtp/239.3.1.147:9268
http://192.168.2.1:8012/rtp/239.3.1.14:8236
http://192.168.2.1:8012/rtp/239.3.1.150:8064
http://192.168.2.1:8012/rtp/239.3.1.155:4120
http://192.168.2.1:8012/rtp/239.3.1.15:8052
http://192.168.2.1:8012/rtp/239.3.1.161:8001
http://192.168.2.1:8012/rtp/239.3.1.162:8001
http://192.168.2.1:8012/rtp/239.3.1.163:8001
http://192.168.2.1:8012/rtp/239.3.1.16:8056
http://192.168.2.1:8012/rtp/239.3.1.18:8268
http://192.168.2.1:8012/rtp/239.3.1.193:8012
http://192.168.2.1:8012/rtp/239.3.1.194:9020
http://192.168.2.1:8012/rtp/239.3.1.195:9024
http://192.168.2.1:8012/rtp/239.3.1.196:9012
http://192.168.2.1:8012/rtp/239.3.1.197:9016
http://192.168.2.1:8012/rtp/239.3.1.198:9004
http://192.168.2.1:8012/rtp/239.3.1.199:9000
http://192.168.2.1:8012/rtp/239.3.1.19:8284
http://192.168.2.1:8012/rtp/239.3.1.1:8000
http://192.168.2.1:8012/rtp/239.3.1.200:9008
http://192.168.2.1:8012/rtp/239.3.1.201:8072
http://192.168.2.1:8012/rtp/239.3.1.20:8276
http://192.168.2.1:8012/rtp/239.3.1.21:8272
http://192.168.2.1:8012/rtp/239.3.1.225:8000
http://192.168.2.1:8012/rtp/239.3.1.226:8000
http://192.168.2.1:8012/rtp/239.3.1.227:8000
http://192.168.2.1:8012/rtp/239.3.1.228:8000
http://192.168.2.1:8012/rtp/239.3.1.229:8000
http://192.168.2.1:8012/rtp/239.3.1.230:8000
http://192.168.2.1:8012/rtp/239.3.1.231:8000
http://192.168.2.1:8012/rtp/239.3.1.232:8000
http://192.168.2.1:8012/rtp/239.3.1.233:8000
http://192.168.2.1:8012/rtp/239.3.1.234:8000
http://192.168.2.1:8012/rtp/239.3.1.235:8000
http://192.168.2.1:8012/rtp/239.3.1.23:8144
http://192.168.2.1:8012/rtp/239.3.1.240:8008
http://192.168.2.1:8012/rtp/239.3.1.244:8016
http://192.168.2.1:8012/rtp/239.3.1.245:8220
http://192.168.2.1:8012/rtp/239.3.1.246:8224
http://192.168.2.1:8012/rtp/239.3.1.249:8001
http://192.168.2.1:8012/rtp/239.3.1.24:8116
http://192.168.2.1:8012/rtp/239.3.1.25:8148
http://192.168.2.1:8012/rtp/239.3.1.26:8108
http://192.168.2.1:8012/rtp/239.3.1.27:8128
http://192.168.2.1:8012/rtp/239.3.1.28:8196
http://192.168.2.1:8012/rtp/239.3.1.29:8288
http://192.168.2.1:8012/rtp/239.3.1.2:8004
http://192.168.2.1:8012/rtp/239.3.1.30:8280
http://192.168.2.1:8012/rtp/239.3.1.31:8120
http://192.168.2.1:8012/rtp/239.3.1.32:9244
http://192.168.2.1:8012/rtp/239.3.1.33:8136
http://192.168.2.1:8012/rtp/239.3.1.34:8192
http://192.168.2.1:8012/rtp/239.3.1.35:8296
http://192.168.2.1:8012/rtp/239.3.1.36:8112
http://192.168.2.1:8012/rtp/239.3.1.37:8292
http://192.168.2.1:8012/rtp/239.3.1.38:8132
http://192.168.2.1:8012/rtp/239.3.1.39:8300
http://192.168.2.1:8012/rtp/239.3.1.40:8200
http://192.168.2.1:8012/rtp/239.3.1.41:8140
http://192.168.2.1:8012/rtp/239.3.1.42:8172
http://192.168.2.1:8012/rtp/239.3.1.43:8176
http://192.168.2.1:8012/rtp/239.3.1.44:8184
http://192.168.2.1:8012/rtp/239.3.1.45:8304
http://192.168.2.1:8012/rtp/239.3.1.46:8124
http://192.168.2.1:8012/rtp/239.3.1.47:8164
http://192.168.2.1:8012/rtp/239.3.1.48:8160
http://192.168.2.1:8012/rtp/239.3.1.49:8188
http://192.168.2.1:8012/rtp/239.3.1.4:8216
http://192.168.2.1:8012/rtp/239.3.1.51:9252
http://192.168.2.1:8012/rtp/239.3.1.52:4120
http://192.168.2.1:8012/rtp/239.3.1.53:9136
http://192.168.2.1:8012/rtp/239.3.1.54:4120
http://192.168.2.1:8012/rtp/239.3.1.55:4120
http://192.168.2.1:8012/rtp/239.3.1.56:4120
http://192.168.2.1:8012/rtp/239.3.1.67:4120
http://192.168.2.1:8012/rtp/239.3.1.68:4120
http://192.168.2.1:8012/rtp/239.3.1.69:4120
http://192.168.2.1:8012/rtp/239.3.1.70:4120
http://192.168.2.1:8012/rtp/239.3.1.71:4120
http://192.168.2.1:8012/rtp/239.3.1.72:4120
http://192.168.2.1:8012/rtp/239.3.1.73:4120
http://192.168.2.1:8012/rtp/239.3.1.74:4120
http://192.168.2.1:8012/rtp/239.3.1.75:4120
http://192.168.2.1:8012/rtp/239.3.1.76:4120
http://192.168.2.1:8012/rtp/239.3.1.77:4120
http://192.168.2.1:8012/rtp/239.3.1.78:4120
http://192.168.2.1:8012/rtp/239.3.1.79:4120
http://192.168.2.1:8012/rtp/239.3.1.7:8024
http://192.168.2.1:8012/rtp/239.3.1.80:4120
http://192.168.2.1:8012/rtp/239.3.1.81:4120
http://192.168.2.1:8012/rtp/239.3.1.82:4120
http://192.168.2.1:8012/rtp/239.3.1.83:4120
http://192.168.2.1:8012/rtp/239.3.1.84:4120
http://192.168.2.1:8012/rtp/239.3.1.85:4120
http://192.168.2.1:8012/rtp/239.3.1.86:4120
http://192.168.2.1:8012/rtp/239.3.1.87:4120
http://192.168.2.1:8012/rtp/239.3.1.88:4120
http://192.168.2.1:8012/rtp/239.3.1.89:4120
http://192.168.2.1:8012/rtp/239.3.1.90:4120
http://192.168.2.1:8012/rtp/239.3.1.91:4120
http://192.168.2.1:8012/rtp/239.3.1.92:4120
http://192.168.2.1:8012/rtp/239.3.1.93:4120
http://192.168.2.1:8012/rtp/239.3.1.94:4120
http://192.168.2.1:8012/rtp/239.3.1.9:8032
ubuntu@raspberrypi:~/iptv/iptvtools$
看你这个 log 应该是执行完了，输出还得优化一下 - -
tqdm 的最后输出是
50 Valid Channels: 100%|#################################| 161/161 [16:55<00:00, 6.31s/it]
说明 花了 16：55 的时间扫描完了 161 个所有频道，其中扫出来了 50 个 valid 的频道，如果没有指定输出文件，应该已经在当前目录下生成了一个 iptvtools.m3u。最后只是把筛掉的频道都打出来了，当时也是因为调试的时候用的，应该加个 debug 选项啥的。
前面 progressbar 输出混乱可能是因为 tqdm 对 terminal 的支持不是太好，我没树莓派可以重现，不过我可以试试加几个增加兼容性的设置看看能不能有效果。
谢谢你提的建议，我也在不断完善这个脚本，包括中英文说明啥的，还准备搞一些更多的功能，然而拖延症依旧，欢迎催更和提建议~
关于 ffmpeg 的说明我会尽快改进的，另外ffmpeg只有在设定 --min-height的时候才会执行，如果没有限制高度，脚本就只会检测tcp/udp连通性而不是用 ffprobe取 stream 的信息。
那个进度条的输出，实质显示是换行了的，应该和树莓派没啥关系，只是copy过来github就丢失格式了…… 看了一下，确实成功了！点赞，基本功能都算齐活了！ 不过发现CCTV-3不知道怎么个情况，生成的列表里没有了， gist页面好像有，不影响使用
那个进度条的输出，实质显示是换行了的，应该和树莓派没啥关系，只是copy过来github就丢失格式了……
那个进度条应该是 inplace 更新的，也有相关的 issue，因为在我的环境里面没有出现，所以最后没有加那个参数。
看了一下，确实成功了！点赞，基本功能都算齐活了！
是的，目前应该是能用，确实怎么搞成更好用的，还得花点功夫。
不过发现CCTV-3不知道怎么个情况，生成的列表里没有了， gist页面好像有，不影响使用
我也是发现好像爬取的太频繁，有些频道会取不到，可能联通那边也做了某种限制？主要有两个参数，一个是 -I Interval，表示每个请求之间的间隔，默认是 1，但是我后台运行的时候会设置成 10，还有一个是 -T TIMEOUT，是超时的设置，默认是10，后台运行我会设置成 30，这样运行可能会更久一点，但是会取的比较全，我本地用 -I 10 -T 30 是能取到全部 54 个高清台的，除了那个朝阳的
ok，大概知道原因和思路了！ python也会点，水平太菜，只会些基本的实用，主要用的少，还得多向你学习学习，后面有空再看看，继续了解一些具体功能和实现原理再说！
这样来说，整套最完整且一步到位的流程，其实应该如下:
- 扫描获取节目列表，这个会比较耗时
- 取到节目列表的时候，和你ffprobe一样，也是得建立连接并验证视频源是ok的，也是可以补充和完善的地方， 节目源地址有了，分辨率有了，再OCR识别画面，根据EPG台标即可识别出频道名称了（或者其他类似功能来确定频道名称？我不确定，这一块不大懂，了解的不多）
- 最终需要的：IP，Port, 频道名称, 分辨率，台标
- 根据规则来排序，生成最终m3u文件，一次齐活！
其实只需要个把月扫描一次即可，确认是文件否有修改或者变化即可！ 树莓派或者软路由这类小主机能很好胜任（1080p+4k视频对硬件要求还是有一些的），我基本就是拿来当玩具，做一些router上比较缺乏的功能，开着ddns，当太server在用。
如果自己定期用电脑手动跑也行，就是得想起来了才能去做这项任务
互相学习互相学习，你说的思路基本上没问题，我也是用路由器直接跑的，AC86U的配置还行，基本满足了我的所有需求（梯子+PT+DDNS+去广告），平时简单跑一些内存占用不高的脚本都还行，Python 环境和 ffmpeg 啥的也都有，这也是阻碍我没有去买树莓派的主要原因 - -
我的一些想法：
-
Scanner 那块确实没想好，一方面北京联通 IPTV 的那个列表还是挺稳定的，另外一方面目前我所知比较有效的发现方式只是穷举所有已知IP段 (239.3.1.0/24)和已知端口[1]，感觉可以在后台记录一个状态，每隔几秒钟甚至几分钟去explore一个可能的组合就可以了，我的思路是长期的持久战，哈哈哈。当然如果你有更好的方式也可以再讨论~
-
台标的话，我目前大致的思路是，获取 stream 信息的时候，似乎有些频道也能得到一个类似代称的 ID，比如执行
ffprobe rtp://239.3.1.211:8064返回的结果中有Metadata: service_name : AHHD，这个就是安徽卫视，这还是整理IPTV频道列表的大神提醒我的。可以总结一个 mapping 然后跟 [2] 里的频道列表对应上，就可以直接用别人整理好的台标和节目单了。CCTV 和地方卫视都搞定了，后面零星的台实在不行再自己手动整理啥的。 -
排序规则基本可以参考 [2]，现在匹配上的频道就是按照[2]中的顺序排列的，如果有细节不符合要求的话，也可以在它的基础上稍微调整一下。
[1] https://github.com/sdhzdmzzl/bj-unicom-iptv-scanner/blob/master/iptvsearch.py#L53 [2] http://epg.51zmt.top:8000/
节目单那个确实是挺稳定，也没顾上去抓包看看实际的数据，总之现在就是剩一些不疼不痒的东西，哈哈
借楼扯点不相干的：
- AC86U跑梯子，speedtest最快速度能到多少？或者油管速度？ 我是很早以前的6300V2，性能太low了，跑不上去，梯子在树莓派上，CPU不支持硬件AES加密，性能不如x86设备，speedtest跑200M左右问题不大，油管大概80M左右。
- 开各种服务以后，merlin的硬件NAT加速是否开启？查看：Tools---- HW acceleration 有三种：CTF+FA 或者CTF only或者disabled, incompatible with XXX 我的渣路由只有CTF only，不过带宽只有300M，基本足够跑满了
- AC86U跑梯子，speedtest最快速度能到多少？或者油管速度？
我家也是 300M 的，开全局代理跑 speedtest 基本能跑到 300，直连大概是 330 上下。油管速度没测过，这个主要取决于梯子本身吧，感觉 bottleneck 不是路由器了。梯子在香港，之前 ping 基本稳定 40ms 左右，最近线路好像又炸了，惨不忍睹搞得我都准备换机房/IP 了。
- 开各种服务以后，merlin的硬件NAT加速是否开启？查看：Tools---- HW acceleration
我这显示的是 Runner: Enabled - Flow Cache: Enabled AC86U 是 aarch64 架构，linux kernel 也是 4.1.27 的，有不少地方跟其他的稍微有点不一样 [1] [1] https://www.snbforums.com/threads/rt-ac86u-3-0-0-4-382-16466-ctf-and-fa-missing.41739/#post-353457
No, 路由器有非常大的瓶颈，梯子流量的加解密都是靠CPU处理，这是考验路由器硬件的最大性能问题…… 我的树莓派CPU在加解密方面都比较垃圾，只能说比路由器是强多了，目前勉强够用，据说是为了省钱，而没有购买ARM的AES授权，导致aes指令不可用…… 另外根据你提供的链接，我搜了一下，还是得益于你这块路由器，AC86u的CPU是增加了AES指令的！ cat /proc/cpuinfo里面应该有aes指令，所以你才没有速度和性能方面的感觉
硬件NAT看来AC86u应该也问题不大，估计解决了性能 vs 功能方面的影响 我再忍忍，随后直接wifi6了，哈哈
这样啊，我理解的是speedtest既然基本满速，访问油管对于路由器而言的行为应该差不多？如果理解有问题还望不吝指正。一不小心暴露了自己的姿势水平，惭愧惭愧。
我当时选路由器也犹豫过wifi 6，还有AC86U之上的型号，无赖价格都太贵了只好作罢。AC86U也算是觊觎很久了，双核512M内存不跑多余的东西也算够用了。当时想的也是先折腾梅林，不够用的话再折腾树莓派或者软路由啥的，对目前的状况还挺满意的。
我那个python的版本是最开始参考国外一个开源代码写的，然后把已知端口都加进去穷举ip段和端口号了。后来我嫌这个太慢，仔细研究了一下，发现完全没必要跟端口一起枚举，发送一个加入组播的请求，然后用pcap库抓这个ip的udp包就能抓到这个下对应的端口号(有些省份一个ip可以有2个端口号去分别提供不同频道)。这个可以参考我的windows代码，那个是最新的代码。思路就是1监听指定网卡上特定ip数据包，2发送加入组播的数据包，3分析抓到的前100个数据包，把端口号记下来。4发送退出组播的数据包。 关于识别频道名称，ffprobe的方式在北京联通的环境里并不友好。北京联通的元数据里并不是每个频道都有，而且格式也是乱七八糟，有几个频道的频道名是一样的。ocr识别是最靠谱的方式。
获取 Outlook for Androidhttps://aka.ms/ghei36
From: Xuan (Sean) Hu [email protected] Sent: Saturday, March 7, 2020 8:42:10 PM To: huxuan/iptvtools [email protected] Cc: Subscribed [email protected] Subject: Re: [huxuan/iptvtools] report Connection refused bug (#3)
互相学习互相学习，你说的思路基本上没问题，我也是用路由器直接跑的，AC86U的配置还行，基本满足了我的所有需求（梯子+PT+DDNS+去广告），平时简单跑一些内存占用不高的脚本都还行，Python 环境和 ffmpeg 啥的也都有，这也是阻碍我没有去买树莓派的主要原因 - -
我的一些想法：
-
Scanner 那块确实没想好，一方面北京联通 IPTV 的那个列表还是挺稳定的，另外一方面目前我所知比较有效的发现方式只是穷举所有已知IP段 (239.3.1.0/24)和已知端口[1]，感觉可以在后台记录一个状态，每隔几秒钟甚至几分钟去explore一个可能的组合就可以了，我的思路是长期的持久战，哈哈哈。当然如果你有更好的方式也可以再讨论~
-
台标的话，我目前大致的思路是，获取 stream 信息的时候，似乎有些频道也能得到一个类似代称的 ID，比如执行 ffprobe rtp://239.3.1.211:8064返回的结果中有Metadata: service_name : AHHD，这个就是安徽卫视，这还是整理IPTV频道列表的大神提醒我的。可以总结一个 mapping 然后跟 [2] 里的频道列表对应上，就可以直接用别人整理好的台标和节目单了。CCTV 和地方卫视都搞定了，后面零星的台实在不行再自己手动整理啥的。
-
排序规则基本可以参考 [2]，现在匹配上的频道就是按照[2]中的顺序排列的，如果有细节不符合要求的话，也可以在它的基础上稍微调整一下。
[1] https://github.com/sdhzdmzzl/bj-unicom-iptv-scanner/blob/master/iptvsearch.py#L53 [2] http://epg.51zmt.top:8000/
― You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/huxuan/iptvtools/issues/3?email_source=notifications&email_token=AIECIA6DEOAEPSII7V7JHODRGI6KFA5CNFSM4LDNOZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODYMWQ#issuecomment-596084314, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIECIA5LTNSSDU6XRALN42TRGI6KFANCNFSM4LDNOZXQ.
弱弱的确认一下，我理解的监听是说平时用电视盒子看 IPTV 时监听流量，对吗，如果不对的话尽管指正。如果是的话，这个方法我就没法用了，因为没有盒子……除了监听流量，我还试图用 nmap 来发现，后来没有成功也就不了了之了。
这个问题最终还是如何方便的收集和管理频道数据，当然像两位不同程度的人工校对我还是很赞赏的，确实这个列表也相对稳定。我一开始写这个脚本的初衷也不完全是为了北京联通的 IPTV，除此以外，个人感觉比较好的 IPTV 列表都整理在了这里 [1]，然后最大的问题是如何方便的 filter 掉无法连接以及清晰度不高的频道（在 4K TV 上看 720P 用户体验很差），所以才动手写了这个脚本，用这个脚本生成过好几份播放列表，结果发现还是 北京联通的 IPTV 香 - -
对于管理的问题，我一个比较简单粗暴的想法是用 sqlite 之类的轻数据库存一下，然后应该有很多社区现成的轮子，搞个 sqlite 的 GUI 或者是 web ui，再加上一个定期导出功能。这样维护起来相对简单容易一些，尤其是台标、节目单之类的信息。不过讲道理，gain 没有特别大，可能还不如直接文本编辑的直接痛快，所以一直也没付诸实践 - -
[1] https://github.com/huxuan/iptvtools/wiki/Well%E2%80%90maintained-playlists
这样啊，我理解的是speedtest既然基本满速，访问油管对于路由器而言的行为应该差不多？如果理解有问题还望不吝指正。一不小心暴露了自己的姿势水平，惭愧惭愧。
都一样，哈哈，大家也是在不断讨论，不断理清自己的想法和实际的区别，互相扯淡才能共同进步！ speedtest满速的话，基本上油管也问题不会太大，但实际二者还是有不少区别的
- 因为speedtest测试的原理是http/tcp测速，基本测速
- 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 Androidhttps://aka.ms/ghei36
为大神的工具和方法点赞，这样效率比盲目扫描的高太多了！ 但是我木有windows的环境，另外Mac的Type C转RJ45转接头扔在公司了，一直没去拿，所以就一直没怎么关注(还是懒） 主要是诸位大神们都造好一堆轮子了，更加懒得去重复做同样的事，哈哈哈
不过还是个人的需求，使用环境不同，例如识别分辨率，例如排序，例如识别节目频道，例如增加m3u台标文件等等，导致就出现了一堆不同的解决办法！
最后，我觉得，大部分人基本还是喜欢拿来就用，直接捡现成的（包括我，以及其他大部分人），不会去自己下载安装扫描节目单的软件或者工具，直接下载最终成品m3u即可，所以这才是最终需求，直接给出做好的饭即可，绝大部分人是都喜欢直接吃熟的，端起来就能吃，哈哈哈！
所以我就直接把您那个文件自己编辑，修改，排序了，当时想的就是，反正比较稳定，时间长了，如果有更新，时间长了，对比一下diff，看看变化，调整一下也没啥，反正有现成的饭吃就行了，扫描不扫描不重要，只要节目源稳定，可以播放即可，尤其是常见的主流节目稳定就行了
今天上午好像梯子的线路又稍微正常了一点，于是测试了一下speedtest 大概直连 300多一点，全局代理 250-270 这样，看了下路由器的 CPU 确实爆了，应该就是 @wuwentao 说的问题，之前我都没太注意到。试着在油管上找了几个 4K 的视频用最清晰的分辨率，大概 CPU 负载 10-20%，有点高但问题应该不大。YouTube 测速不知道你们怎么测的，用 Google 搜了几个关键字发现有这个网站 [1]，但是结果不是很稳定，最低只有 60+，最高 130+。
不过还是个人的需求，使用环境不同，例如识别分辨率，例如排序，例如识别节目频道，例如增加m3u台标文件等等，导致就出现了一堆不同的解决办法！
只要不是北京联通 IPTV 太 specific 的需求，我这边可以增加功能的，目前的大概总结一下：
- 给频道名称增加分辨率信息，这个不麻烦
- 排序的话目前的解决方案不知道还有没有什么改进意见吗？似乎只有北京卫视和其他地方卫视放在一起了，其他的都还行？
- 节目频道和台标我还是倾向于用别人已经整理好的，毕竟主流的频道都覆盖了，剩下的频道可以手动搞一下，代码自动化的方式感觉还是稍微麻烦了一些，毕竟很多台标不是简单的 OCR 就能识别出来的。
剩下的其他的还有啥我没 get 到的嘛？
[1] https://testmy.net/hoststats/youtube_llc
今天上午好像梯子的线路又稍微正常了一点，于是测试了一下speedtest 大概直连 300多一点，全局代理 250-270 这样，看了下路由器的 CPU 确实爆了，应该就是 @wuwentao 说的问题，之前我都没太注意到。试着在油管上找了几个 4K 的视频用最清晰的分辨率，大概 CPU 负载 10-20%，有点高但问题应该不大。YouTube 测速不知道你们怎么测的，用 Google 搜了几个关键字发现有这个网站 [1]，但是结果不是很稳定，最低只有 60+，最高 130+。
youtube测试就不必这种第三方的了，你那个第三方估计也可能是模拟的，所以cpu利用率比较低！ 简单粗暴，直接上youtube， 搜索8k 120fps，找出分辨率是8k的视频，直接播放即可了，在视频中间右键，显示详细信息，视频详细信息，网络连接速度就有了，这才是最标准的，然后看看CPU利用率即可，哈哈哈 第三方的测试感觉不一定符合实际情况，尤其chrome浏览器，flash/html等，QUIC协议这类的影响 另外，UDP/QUIC协议，是不会走梯子的，全局代理也只能代理TCP流量，所以如果全走QUIC协议，也有可能CPU没啥影响，毕竟既不加解密，也不走代理，直连了，哈哈 另外，你的梯子，加解密协议，试试用AES-GCM-XXX的，也许很多是用chacha20的，对比一下区别！ 我在树莓派上是跑v2ray+tls+ws了，trojan也有，但是这货要占用整个vps的443端口，我有好几个域名，配置起来毕竟复杂，放弃了，继续用v2ray，trojan用了一个备份端口8443独占
只要不是北京联通 IPTV 太 specific 的需求，我这边可以增加功能的，目前的大概总结一下：
- 给频道名称增加分辨率信息，这个不麻烦
- 排序的话目前的解决方案不知道还有没有什么改进意见吗？似乎只有北京卫视和其他地方卫视放在一起了，其他的都还行？
- 节目频道和台标我还是倾向于用别人已经整理好的，毕竟主流的频道都覆盖了，剩下的频道可以手动搞一下，代码自动化的方式感觉还是稍微麻烦了一些，毕竟很多台标不是简单的 OCR 就能识别出来的。
剩下的其他的还有啥我没 get 到的嘛？
关于识别频道名称，ffprobe的方式在北京联通的环境里并不友好。北京联通的元数据里并不是每个频道都有，而且格式也是乱七八糟，有几个频道的频道名是一样的。ocr识别是最靠谱的方式。
二位都是大神，搬砖能力都比我强，哈哈哈，我自叹不如！ 现在基本各方面功能都有了，只不过是零碎，分散，碎片化的存在，不同的角色有不同的需求，所以我整理一下:
- 目前基本只需要做好饭： 提供一份最终的m3u文件，大伙能直接吃
- m3u列表需要：
- 标识片源分辨率
- 适当排序，例如CCTV, BTV，卫视，IPTVxxx等等即可
- 增加EPG台标
- 其他的都是持续管理，维护，更新需要面临的问题，例如：
- 定期扫描，确认节目单变化，形成diff文件即可
- 片源识别OCR, 节目源识别， 这种属于一次性工作，貌似投资回报率确实太低了，不行可以先放弃呗。
- 扫描原理，扫描效率，多久扫描一次等等
- 不同的区是否会有不同的片源等
Owner：
- 普通用户： 只需要1和2的成品即可
- 维护更新者： 需要3
监听指的是监听本地数据包。因为是在本地发送的加入组播请求，那么如果这个组播地址上有频道的话，udp数据包就会到这个电脑上，就能在本地抓到了。当然，前提是路由器上已经配置过组播转发了。但如果你们本地电脑上可以看iptv的话，那么环境就没问题了。 关于漏频道的问题，加上timeout会不同程度地降低漏频道的概率。
获取 Outlook for Androidhttps://aka.ms/ghei36
From: Xuan (Sean) Hu [email protected] Sent: Sunday, March 8, 2020 11:26:27 AM To: huxuan/iptvtools [email protected] Cc: [email protected] [email protected]; Comment [email protected] Subject: Re: [huxuan/iptvtools] report Connection refused bug (#3)
弱弱的确认一下，我理解的监听是说平时用电视盒子看 IPTV 时监听流量，对吗，如果不对的话尽管指正。如果是的话，这个方法我就没法用了，因为没有盒子……除了监听流量，我还试图用 nmap 来发现，后来没有成功也就不了了之了。
这个问题最终还是如何方便的收集和管理频道数据，当然像两位不同程度的人工校对我还是很赞赏的，确实这个列表也相对稳定。我一开始写这个脚本的初衷也不完全是为了北京联通的 IPTV，除此以外，个人感觉比较好的 IPTV 列表都整理在了这里 [1]，然后最大的问题是如何方便的 filter 掉无法连接以及清晰度不高的频道（在 4K TV 上看 720P 用户体验很差），所以才动手写了这个脚本，用这个脚本生成过好几份播放列表，结果发现还是 北京联通的 IPTV 香 - -
对于管理的问题，我一个比较简单粗暴的想法是用 sqlite 之类的轻数据库存一下，然后应该有很多社区现成的轮子，搞个 sqlite 的 GUI 或者是 web ui，再加上一个定期导出功能。这样维护起来相对简单容易一些，尤其是台标、节目单之类的信息。不过讲道理，gain 没有特别大，可能还不如直接文本编辑的直接痛快，所以一直也没付诸实践 - -
[1] https://github.com/huxuan/iptvtools/wiki/Well%E2%80%90maintained-playlists
― You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/huxuan/iptvtools/issues/3?email_source=notifications&email_token=AIECIA3XPG5HR2LGIZIAWSDRGMF6HA5CNFSM4LDNOZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOELNCA#issuecomment-596162184, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIECIA6WRWESDNOK72FCIXTRGMF6HANCNFSM4LDNOZXQ.
1和2都是一次性的工作，基础工作做好之后，只需要维护新增频道和删除频道就可以了。 我一般2-3天会扫一遍频道，我本地的列表是按顺序写的，直接diff与上一次的频道列表就能找到新增或者删除，然后手动去看一下频道是啥确认一下就ok了
获取 Outlook for Androidhttps://aka.ms/ghei36
From: Wentao Wu [email protected] Sent: Sunday, March 8, 2020 12:47:03 PM To: huxuan/iptvtools [email protected] Cc: [email protected] [email protected]; Comment [email protected] Subject: Re: [huxuan/iptvtools] report Connection refused bug (#3)
只要不是北京联通 IPTV 太 specific 的需求，我这边可以增加功能的，目前的大概总结一下：
- 给频道名称增加分辨率信息，这个不麻烦
- 排序的话目前的解决方案不知道还有没有什么改进意见吗？似乎只有北京卫视和其他地方卫视放在一起了，其他的都还行？
- 节目频道和台标我还是倾向于用别人已经整理好的，毕竟主流的频道都覆盖了，剩下的频道可以手动搞一下，代码自动化的方式感觉还是稍微麻烦了一些，毕竟很多台标不是简单的 OCR 就能识别出来的。
剩下的其他的还有啥我没 get 到的嘛？
关于识别频道名称，ffprobe的方式在北京联通的环境里并不友好。北京联通的元数据里并不是每个频道都有，而且格式也是乱七八糟，有几个频道的频道名是一样的。ocr识别是最靠谱的方式。
二位都是大神，搬砖能力都比我强，哈哈哈，我自叹不如！ 现在基本各方面功能都有了，只不过是零碎，分散，碎片化的存在，不同的角色有不同的需求，所以我整理一下:
- 目前基本只需要做好饭： 提供一份最终的m3u文件，大伙能直接吃
- m3u列表需要： * 标识片源分辨率 * 适当排序，例如CCTV, BTV，卫视，IPTVxxx等等即可 * 增加EPG台标
- 其他的都是持续管理，维护，更新需要面临的问题，例如： * 定期扫描，确认节目单变化，形成diff文件即可
- 片源识别OCR, 节目源识别， 这种属于一次性工作，貌似投资回报率确实太低了，不行可以先放弃呗。
- 扫描原理，扫描效率，多久扫描一次等等
- 不同的区是否会有不同的片源等
Owner：
- 普通用户： 只需要1和2的成品即可
- 维护更新者： 需要3
― You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/huxuan/iptvtools/issues/3?email_source=notifications&email_token=AIECIA2H3KYJUK3VJ5XNJU3RGMPMPA5CNFSM4LDNOZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEMODQ#issuecomment-596166414, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIECIA75LPLBCRP4QXYUTALRGMPMPANCNFSM4LDNOZXQ.
我一般2-3天会扫一遍频道，我本地的列表是按顺序写的，直接diff与上一次的频道列表就能找到新增或者删除，然后手动去看一下频道是啥确认一下就ok了
是的， 您这个其实是教大伙如何自己做饭，菜基本已做熟了，但是没加调料…… 我们还需要自己看口味，自己加调料，但是大部分人还是“懒”，别说做饭了，连调料都不想加就直接吃现成的…… 这才是关键，哈哈
所以，最简单的就是您不仅要教大伙做饭（少部分人会关注饭是怎么做的，但不一定自己动手去做），还要额外增加一下把各种调料口味都加上，所有需求都一锅端了，这样就能完全没我们啥事了！
大部分人都不关注谁做的饭（不累死做饭的厨师就好），只需要有得吃，味道还不错就行啦，然后自己看口味，自己选现成的m3u，张嘴即吃！ 您这以前做好了熟食，但每次总是要自己加点调料，大伙就想着把缺少的调料再搞一搞就算了 ，所以当口味不符合自己要求时，就只能自己搞了，都是被“逼”的。
最后，gist那个也能用，就是确实不方便，毕竟这个不是小菜，而是大家真正想吃的主菜和最终成品，包括反馈issue，还有各种不想做饭的小伙伴们来评论吐槽一下，口味好不好吃，又有啥新调料该加了等等，哈哈
欢迎你们二位大佬们继续发力发光，目前看，我安心吃瓜，等你们做饭也挺好！哈哈哈 纯属娱乐，欢迎继续，互相推动，把“菜”做的更好吃！
监听指的是监听本地数据包。因为是在本地发送的加入组播请求，那么如果这个组播地址上有频道的话，udp数据包就会到这个电脑上，就能在本地抓到了。当然，前提是路由器上已经配置过组播转发了。但如果你们本地电脑上可以看iptv的话，那么环境就没问题了。
@sdhzdmzzl 你描述的我基本能理解，就是具体操作上还有什么 reference 可以分享一下嘛
@wuwentao 我新建了两个 issue #4 和 #5，如果你想到了什么具体的需求也尽管开 issue，语言啥的都随意~
@huxuan 哈哈，看 @sdhzdmzzl 提供的代码，说实话，我真看不懂C/C++了，确实是都忘光了！ 只会点简单的脚本语言if/else/for啥的，哈哈哈！ 我也看不懂具体内容和细节，大概看懂流程就够了，估计你仔细看看，也能看懂！
过程就是他上面写的那几步，我拿python简单调试模拟了一下，基本也ok，不复杂，把遍历端口改成抓包检测端口即可！
估计你也能搞定，你俩大神看代码都比我流弊多了，我是土八路，一般都直接捡现成的吃，哈哈
ubuntu@raspberrypi:~/iptv$ sudo python3 multicast.py
Bind to address: 239.3.1.13 passed
packets:
###[ Ethernet ]###
dst = dc:a6:32:xx:xx:xx
src = 78:1d:ba:xx:xx:xx
type = IPv4
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 1356
id = 5054
flags = DF
frag = 0
ttl = 124
proto = udp
chksum = 0x52d5
src = 61.135.xxx.xx
dst = 239.3.1.13
\options \
###[ UDP ]###
sport = 8042
dport = 8048
len = 1336
chksum = 0xa360
[IP].dst:
239.3.1.13
[UDP].dport:
8048
@wuwentao 我新建了两个 issue #4 和 #5，如果你想到了什么具体的需求也尽管开 issue，语言啥的都随意~
@huxuan 我想了想：
- 扫描节目单的，貌似有成品了, @sdhzdmzzl 有好几个版本的，这一块貌似问题不大
- 生产EPG的你这个脚本能搞定了
- 细节方面就是各种格式和小功能增加，大家的各种轮子基本都是已经造好了，够用且不影响整体使用了
- 最缺失的主力部分，也是人肉部分的一次性投入，还是那个OCR识别，这一块确实是投资回报率不大高的地方…… 你啃不啃这块硬骨头？用Python搞一个的话，我还能学习学习，哈哈哈，纯属娱乐！ 留着后面慢慢再说吧！
