search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.68k stars 2.93k forks source link

DVB playback broken #239

Closed ghost closed 9 years ago

ghost commented 11 years ago

Someone told me that someone told him that dvb playback was far worse than with mplayer/mplayer2. I don't know details, and I can't test the DVB code, so more information would be nice.

If anyone actually wants to use DVB, and experiences problems, please tell.

This is probably in part caused by dropping the internal TS demuxer, which was default for DVB.

olifre commented 9 years ago

Then, it does NOT make use of the full analyzeduration, playback starts almost instantaneously.

Let me revert that statement - it just exceeded the probesize VERY fast. Increasing probesize to something large, it runs into the maximum analyzeduration again. This at least clears up that I am not missing any important PID in the filtering (there are also some metadata-pids, e.g. the NIT (network information table), but they should not be needed in the decoding).

I guess the fastest way then is to ask the ffmpeg-DVB-experts as to how ffmpeg learns about these stream-ids, and how to tell ffmpeg to not try to probe unwanted ones...

olifre commented 9 years ago

Right now, I believe it is a good idea to read through the mpeg-ts parser (and stream-info finding) in ffmpeg code. I will play a bit with this to learn more about the gory details, and as to why ffmpeg uses the full analyzeduration. My last commits in #1409 are already a result of this (ffmpeg can parse the SDT, so we should give it to ffmpeg).

There also seems to be code to ignore PIDs, and also code to continue analysis until all programs are matched with a PMT. I might take until tomorrow or so to have a larger understanding.

olifre commented 9 years ago

I read through the code, it was more readable than I expected. ffmpeg really learns the stream-IDs from PAT, so it also looks for streams even if they are not muxed into the TS. I mis-assumed it can do that without PAT before, since szap-s2 has a bug (it also adds the PAT to the TS even if told not to do so). I confirmed that, using a stream without PAT and PMT, ffmpeg only sees the streams which we give to it (but is unable to decode dvbsub and teletext due to missing PAT / PMT).

The expected, but not-really-present streams seem to cause it to use the full analyzeduration. I have opened a ticket here: https://trac.ffmpeg.org/ticket/4228 with the proposal to add a whitelist.

As mpv does not know these other PIDs, all other solutions are more complicated; we would have to parse the PAT ourselves more completely (to extract these PIDs) to add them to the TS, too. Even then, ffmpeg would need to learn to detect and ignore these formats. Of course this is also a good solution, I'll wait for the answer to the ticket and follow their suggestion.

I guess you already saw that current git HEAD of ffmpeg has dvbsub-detection now with all the hacks (i.e. also without PMT)? Only teletext still needs the PMT, but of course as we have the PMT now, this is the much cleaner solution.

ghost commented 9 years ago

The expected, but not-really-present streams seem to cause it to use the full analyzeduration. I have opened a ticket here: https://trac.ffmpeg.org/ticket/4228 with the proposal to add a whitelist.

You should probably bring this up on the ffmpeg-devel mailing list or IRC channel. Trac is mostly used for bug reports only. While ffmpeg-devel is for developers and not users, and user question are unwanted, this topic is already close enough to ffmpeg internals and development.

I guess you already saw that current git HEAD of ffmpeg has dvbsub-detection now with all the hacks (i.e. also without PMT)?

No.

Only teletext still needs the PMT, but of course as we have the PMT now, this is the much cleaner solution.

Yes. Also, ideally mpv (especially --stream-dump) should produce valid streams, not streams ffmpeg happens to handle.

ghost commented 9 years ago

Looks like we never found the cause. I still blame libavformat though.