-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DVB channel switching broken #2568
Comments
From what I can see, what it did on dvb channel switch before that commit was:
Now it does:
|
Mhhhm... |
I think it might have to do with destroying the stream state. |
Sorry, but I am still unsure on "where to look".
should do exactly the same as happens during mpv startup, which is also what seems to happen according to the gist... |
No, the stream gets completely destroyed. I'm not sure why it wouldn't just work. Maybe you could confirm with valgrind that the player code isn't doing anything stupid. Then all what's left is state within the kernel, I suppose? |
There's also another more fundamental issue I just found in the gist...
I.e. the channel switch does not actually work, which is actually expected, since the channel name and channel list are remembered in the stream which is now destroyed and recreated just after successful channel switching. So we have two problems here:
|
Yes, PVR is probably also broken then. I see some possible solutions:
|
I agree - my problem is that at the moment I have no development time, there might be some time around christmas / new year when I can probably contribute a bit... Concerning the options you listed:
I agree, that would not really be a good "solution".
Since the full "persistent" stream state might be a complex structure, I am not sure it will be easy to find a generic solution that works well for all kinds of streams which need some kind of persistency.
I think I am in favor of this option. At least for DVB, channel switching may mean opening and closing of several FDs (the demuxes for the several stream-IDs), while some may be reused (the device itself e.g.). Also, there is the channel list, the tuning state etc. In some cases, retuning might not even be needed.
That would be the nicest solution, probably, and - if a working way is found - come with the least overhead e.g. on channel switching. But I see it's the most complicated one...
I think this will not be sufficient to get a good user experience. If we only remember the current channel number, we lose all other state - reopening the device, re-parsing thousands of lines of channel list, re-tuning, re-extracting information from the live stream from the transponder etc. takes a significant amount of time, so at least for DVB, it would be best to be able to keep "more state". |
Not really. It just has to be dragged along somehow.
Yes, the problem is that the set of streams changes. But we also could try to make the stream switching required in this context part of the playback logic. So that means the stream would somehow notify the player that it has to select a new video/audio stream to get data. Isn't it actually so that there are well-defined mechanisms for transport streams how to do that? (And it could happen midstream too. E.g. isn't it allowed that even the video codec changes during receiving?)
Don't worry about that. Probably nobody uses that anyway. |
Ok - I'll have a look as soon as I have time, which may be still a few weeks ahead. The first step would be to separate out all state information which can (and should) be kept around, then maybe this can be kept in a set of structs (as it's done now) which are kept around for full process lifetime (since DVB is unique, maybe just static pointers to these structs which are null at first and then initialized during first DVB initialization with channel list, open FDs etc.).
All these funny things are allowed, but I also do not know the details. ffmpeg does a lot of magic here: |
I do have to say that the linux kernel PVR support is barely worth supporting. Most of the devices in this group are analog standard def MPEG2 encoder cards. Only modern device that works with it is the hauppauge HDPVR and I've dug around in the kernel code for this specific device and the generic PVR code and it's kind of hacked together to "just work" and not much else. Almost like a proof of concept, but is far too unstable and lacking in robustness to use in practice. I'd honestly say, if it gets in the way, drop support for it altogether. |
Looks like I'll just remove pvr:// then. |
You can always just use it through adjusting the parameters with the command line v4l2 utilities and opening the /dev/videoN device as a file. Handling mid-stream changes to video codec and resolution and so on would possibly fix some of the problems that PVR ends up having, though. MythTV I hear is fairly reliable with PVR devices so maybe looking in to what they do to handle changes in the MPEG-TS stream would be useful. |
Transport streams have well-defined mechanisms to handle such mid-stream changes, but I suppose neither mpv nor libavformat handle them correctly in all cases. |
I am currently looking at this. In https://github.com/mpv-player/mpv/blob/master/player/loadfile.c#L1253 I see the cancel_trigger is fired after reaching EOF, which is also the codepath we enter on channel-switch. So, if I do:
i.e. add an |
PT_RELOAD_FILE is a somewhat obscure case when using DVB or when switching Matroska editions. Both cases were broken, because the asynchronous playback abort mechanism was still triggered. This mechanism is used to force the demuxer and stream layers to exit immediately (instead of blocking on I/O possibly forever), and is normally disabled on playback start. The reopen path is a bit strange, and needs to reset it manually. Pointed out in #2568.
Yes, it's a bug. It also broke Matroska edition switching. |
There's one more, slightly separate issue which I found. Do you have a proposal on this?
|
I think I found out: Apparently I need to implement Finally let me say (as a C++ developer, normally) mpv code feels really readable and well organized (even more so the core parts). Even though I get to work a bit here just about only once a year, I usually get into it quickly. |
Sounds ok. That's what properties are for.
Sounds also ok.
This would probably be the cleanest. |
I was just made aware of the problem that DVB channel switching does not work anymore with current mpv.
A bisect shows the following commit broke it:
a609877
A gist from running mpv and switching a channel at that commit looks like:
https://gist.github.com/olifre/79758fa0c4473a4a4931
It seems lavf does not fully attempt to redetect everything, I don't see a second max-analyze-duration being reached etc.
Since I am unsure how to fix, but have the hardware to test: Please tell me any further information that could help!
The text was updated successfully, but these errors were encountered: