Subtitle navigation for autogenerated subs broken

[mikavilpas]

Hi, just found out that if I enable autogenerated subs and navigate to one of the last subtitle lines, the video seems to start over in a weird manner instead of going to the end.

Tried it with this video on 0.12.1 beta
https://youtu.be/-i8Nl4zPq20

[arianneorpilla]

Hi, thanks for reaching out sp3ctum. This is an issue related to the flutter_vlc_player plugin I'm using -- seeking in a YouTube stream is very finicky. Sometimes it works, and sometimes, it's really weird. I'm not really sure I can do anything about this unless I migrate the app to another player.

I've found that by sticking to flutter_vlc_player, I can provide full HEVC support and can support any kind of video that users can throw at, with the trade-off that there are some player behaviors that I can't really debug myself.

Before I ported the app to use VLC, you could actually use the player in portrait mode and you wouldn't be restricted in landscape mode. So it's less buggy, I restrict the player in landscape. In this case, I believe only the flutter_vlc_player plugin I'm using can actually mux together YouTube's high quality audio and video which is split into two streams rather than in one muxed file.

This results in some unspecified behavior towards the end of a video and really weird seeking. It's a tradeoff I must deal with for the moment, and I've decided it's something most users can live with rather than being restricted to a poor quality YouTube video only in 360p or so. For now, I advise users not to trust seeks too much when streaming video.

Thanks again for the bug report, I really appreciate it. I will continue to investigate what I can do about this. I will leave this issue open as it is a legitimate concern.

[arianneorpilla]

I have recently released 0.12.4 as a quick mitigation for this issue. I now mix muxed and demuxed YouTube streams. You may find muxed YouTube streams marked as (seek friendly) in the quality menu. If you use those options, the video should buffer and seek properly.

I've found great success using these on more than an hour long videos (which I've found are typically problematic) where attempting to seek will return you to the beginning of the video. Muxed streams are very compatible with the player but are limited to 720p at the maximum quality however, so please be advised.

I think this is a pretty solid temporary solution while I get to the heart of the matter.

[mikavilpas]

Tested that release today with a couple of videos, seems to work nicely. It's a huge improvement, thank you 👍

[arianneorpilla]

After letting this issue stay open for months, I believe this is a deeply rooted VLC issue with the --input-slave parameter (documentation for that can be found here) that I use to mux individual video and audio streams from YouTube which is needed for higher resolutions. It seems that some codecs just do not work well with VLC, so I have applied a filter which makes only AVC1 video streams and audio only streams mux together for unmuxed streams to ensure compatibility.

I will keep the seek friendly tags for now and will consider a next point of action after seeing how compatibility goes after this change which I implemented in the 0.25.1 hotfix and may drop them at a later version. For compatibility purposes, I'll keep the seek friendly tags as the muxed streams are basically guaranteed to work very well. And maybe, at a later date if everything is basically working great, I will drop those tags.

As this is not really an issue with the app and this version of VLC that comes bundled with the video player package I use is all I can work with, making sure that it's as compatible as it can be with the codecs I feed into it is the best I can do. And from what I've tested with, there is a very significant improvement to seekability in highest resolution streams, so I am finally closing this issue. Sorry for the long wait.