Open jazzmanro opened 9 years ago
thanks for reporting @jazzmanro plz check with latest flashls/dev, it should be fixed
Thank you, it does seem to look indeed much much better. Not sure if issue is completely solved though, there still are some switching glitches with some playlists but I assume it is also due to improper level alignments. For example, for sure there are issues if levels are misaligned by a few seconds (level 2 segments start in the middle of level 1 segments), it seems to skip ahead on switch. I've also encountered some very small skips like ~100ms maybe at some points.
This brings me to the questions:
There are two kind of mis-alignement.
overlapping
frag 51 level 0 K-------------
frag 52 level 1 K------------
hole
frag 51 level 0 K-------------
frag 52 level 1 K------------
my feeling is that Flash/NetStream should be able to cope with overlapping, i.e. it should be able to detect frames with overlapping timestamps and use the latest one, ie replace the overlapping frames from the old fragment by the ones from the new fragment. but not 100% confident.
However, for hole, it cannot invent frames ... I guess that in case iOS faces this case, it will download frag 51 level 1 to decode the missing frames and fill the hole.
do you know which case you are facing on your side ? overlap or hole ?
for perfect switching you should have contiguous PTS at fragment boundary. for example, if last video frame PTS at end of frag 51 level 0 is 50980ms, frame lasting for 20ms, (50fps) then first video frame PTS at beginning of frag 52 level 1 should be 51000ms
Hello,
Sorry for delayed answer, I tried to gather all data for my reply to provide best-possible help.
Regarding misalignment, I am talking about overlapping. Let's discuss based on an example that I've created: http://www.flashls.org/latest/examples/osmf/GrindPlayer.html?src=http%3A%2F%2F176.9.1.233%2Fflashlstest2%2Ftest3.m3u8
There are two levels in the example and they have two misalignment issues:
This is the rough I-frame structure of the levels (I-frame PTS in s for each segment in parallel):
./test31/1447155226000.ts 10.780000 11.540000 15.780000 18.820000
./test33/1447155230000.ts 15.367000 18.407000 20.367000
./test31/1447155236000.ts 20.780000 25.780000
./test33/1447155240000.ts 25.367000 30.367000
./test31/1447155246000.ts 30.780000 35.780000
./test33/1447155250000.ts 35.367000 40.367000 43.087000
./test31/1447155256000.ts 40.780000 43.500000 45.780000
./test33/1447155260000.ts 45.367000 50.367000 51.447000
./test31/1447155266000.ts 50.780000 51.860000 55.780000 56.460000 59.580000
./test33/1447155270000.ts 55.367000 56.047000 59.167000 60.367000 64.767000
./test31/1447155276000.ts 60.780000 65.180000 65.780000 67.060000 69.220000
./test33/1447155280000.ts 65.367000 66.647000 68.807000 70.367000 70.927000 75.327000
./test31/1447155286000.ts 70.780000 71.340000 75.740000 75.780000
./test33/1447155290000.ts 75.367000 80.367000 85.127000
./test31/1447155296000.ts 80.780000 85.540000 85.780000 87.180000
./test33/1447155300000.ts 85.367000 86.767000 90.367000 95.127000
./test31/1447155306000.ts 90.780000 95.540000 95.780000 99.700000
./test33/1447155311000.ts 95.367000 99.287000 100.367000
./test31/1447155316000.ts 100.780000 105.780000 108.460000
./test33/1447155320000.ts 105.367000 108.047000 110.367000 113.327000
./test31/1447155326000.ts 110.780000 113.740000 115.780000 116.660000
./test33/1447155330000.ts 115.367000 116.247000
You can see the I-frames are actually 'aligned' but displaced exactly 0.413s apart. Also second level (test33) has segments starting somewhere in the middle of first level ones. The naming of those segments actually corresponds to second-rounded timestamps of segment creation-time, thus, they aren't aligned either :)
Running this via mediastreamvalidator gives a warning indeed but no errors and iOS still plays this perfectly in my tests as much as I could force switches. iOS doesn't even have a problem with the small 0.413 displacement, there is no noticeable playback glitch due to unaligned PTS on boundaries.
You can see that FlasHls unfortunately doesn't cope well with this example and jumps ahead/behind on up/down-switch. And if they would had been segment-aligned, the second displacement issue would surely manifest due to PTS misalignments at boundary. At least this is my experience with other streams.
I do agree though, segmenting like this probably shouldn't be done :)
Thanks much for your help and hopefully this report and sample helps.
Hello,
Firstly, really congrats for this work and doing something that changes the online video community! It's such a pity HLS isn't implemented natively on desktop.. Anyway.
I am having issues with FlasHls's level switching logic. What usually happens is that audio skips one segment behind with freezing image when an AUTO level switch or manual via HLS.nextLevel = index is being made. This doesn't happen on every switch though but it is often enough. Of course it is very disturbing.
I reproduce it on a custom Clappr build with level control UI support that uses smooth switching (HLS.nextLevel) but this issue also reproduces for example here with AUTO: http://www.flashls.org/latest/examples/osmf/GrindPlayer.html?src=http%3A%2F%2F176.9.1.233%2Fflashlstest%2Ftest.m3u8
The source, http://176.9.1.233/flashlstest/test.m3u8 seems to run perfectly on iOS/OS X, no issues at switching points. also latest mediastreamvalidator reports everything good.
I assume there is something wrong with the logic in StreamBuffer.nextLevel at least for manual switches but my knowledge is still to low to figure out how that code works. Is this actually used also for AUTO?
Thanks again.