i want to play ts data by receiving one frame. but hls.js play ts data by receiving one ts data.
Check this https://github.com/video-dev/hls.js/pull/783
The append method in tsdemuxer.js cannot resolve part of TS data. For example, this TS has 10000bytes, and only 1000 bytes is resolved in each stream loading process, and ten times are resolved.
well, first of all it really depends what you mean by "one frame". if it's an IDR frame that will be OK. But usually you just need at least a whole GOP to do anything. Only I and P frames can be decoded sequentially, for B frames you need the whole group of pictures. That can actually be a whole segment of several seconds.
Also, usually you just want to fill your buffer with just about such an amount of data (some sane multiple of the GOP size) in order to smooth out network variance.
Finally, it would be completely absurd trying to do a transaction for every single part of a GOP :)
What are your use-cases exactly? You aren't trying to do some real-time communication stuff here, aren't you? :)
At first, I got a m3u8 file, and I downloaded and got a series of TS files. The first TS file I download is loaded by fetch or moz-chunked. When the data is downloaded to the player, I find that tsdemuxer.js can not parse part of the TS data, and can only parse the whole TS data. This is my question, how to load data to the player through streaming fetch.i want to reduce firstbuffer time.
@1312543912
我在开发
我qq是 18897043
i have add your friends, you can agree. Thanks.
@1312543912 Yes, I guess you want to simply make smaller TS chunks :) And therefore smaller GOPs (group of picture), meaning a shorter IDR period.
This is something you can set on the encoder side, and where you mux/chunk your TS data.
You can go down to 0.3-0.5 seconds, then it becomes a ridiculous amount of HTTP requests you need to perform and a lot of overhead in transport layer.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
well, first of all it really depends what you mean by "one frame". if it's an IDR frame that will be OK. But usually you just need at least a whole GOP to do anything. Only I and P frames can be decoded sequentially, for B frames you need the whole group of pictures. That can actually be a whole segment of several seconds.
Also, usually you just want to fill your buffer with just about such an amount of data (some sane multiple of the GOP size) in order to smooth out network variance.
Finally, it would be completely absurd trying to do a transaction for every single part of a GOP :)
What are your use-cases exactly? You aren't trying to do some real-time communication stuff here, aren't you? :)