Open wuwentao opened 4 years ago
-u http://192.168.50.1:8888
这个是 udpxy 的地址前缀,需要改成自己的,这个地方改一下再试试呢?
啊?还判断这个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了嘛,点赞!
但是压根没在文档里进行说明,建议增加一个脚本的功能说明:
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也会点,水平太菜,只会些基本的实用,主要用的少,还得多向你学习学习,后面有空再看看,继续了解一些具体功能和实现原理再说!
这样来说,整套最完整且一步到位的流程,其实应该如下:
其实只需要个把月扫描一次即可,确认是文件否有修改或者变化即可! 树莓派或者软路由这类小主机能很好胜任(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最快速度能到多少?或者油管速度?
我家也是 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 notifications@github.com Sent: Saturday, March 7, 2020 8:42:10 PM To: huxuan/iptvtools iptvtools@noreply.github.com Cc: Subscribed subscribed@noreply.github.com 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满速的话,基本上油管也问题不会太大,但实际二者还是有不少区别的
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 的需求,我这边可以增加功能的,目前的大概总结一下:
剩下的其他的还有啥我没 get 到的嘛?
今天上午好像梯子的线路又稍微正常了一点,于是测试了一下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识别是最靠谱的方式。
二位都是大神,搬砖能力都比我强,哈哈哈,我自叹不如! 现在基本各方面功能都有了,只不过是零碎,分散,碎片化的存在,不同的角色有不同的需求,所以我整理一下:
Owner:
监听指的是监听本地数据包。因为是在本地发送的加入组播请求,那么如果这个组播地址上有频道的话,udp数据包就会到这个电脑上,就能在本地抓到了。当然,前提是路由器上已经配置过组播转发了。但如果你们本地电脑上可以看iptv的话,那么环境就没问题了。 关于漏频道的问题,加上timeout会不同程度地降低漏频道的概率。
获取 Outlook for Androidhttps://aka.ms/ghei36
From: Xuan (Sean) Hu notifications@github.com Sent: Sunday, March 8, 2020 11:26:27 AM To: huxuan/iptvtools iptvtools@noreply.github.com Cc: sdhzdmzzl@sina.com zhangzhilei@hotmail.com; Comment comment@noreply.github.com 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 notifications@github.com Sent: Sunday, March 8, 2020 12:47:03 PM To: huxuan/iptvtools iptvtools@noreply.github.com Cc: sdhzdmzzl@sina.com zhangzhilei@hotmail.com; Comment comment@noreply.github.com Subject: Re: [huxuan/iptvtools] report Connection refused bug (#3)
只要不是北京联通 IPTV 太 specific 的需求,我这边可以增加功能的,目前的大概总结一下:
剩下的其他的还有啥我没 get 到的嘛?
关于识别频道名称,ffprobe的方式在北京联通的环境里并不友好。北京联通的元数据里并不是每个频道都有,而且格式也是乱七八糟,有几个频道的频道名是一样的。ocr识别是最靠谱的方式。
二位都是大神,搬砖能力都比我强,哈哈哈,我自叹不如! 现在基本各方面功能都有了,只不过是零碎,分散,碎片化的存在,不同的角色有不同的需求,所以我整理一下:
其他的都是持续管理,维护,更新需要面临的问题,例如:
Owner:
― 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 我想了想:
来学习学习
http://ai.baidu.com/tech/imagerecognition/logo ,有个logo识别云服务