[MPlayer-dev-eng] Bluray input with -demuxer lavf

[Reimar Döffinger]

On 18 September 2014 00:40:14 CEST, Andy Furniss <adf.lists at gmail.com> wrote:
>Reimar Döffinger wrote:
>> On Wed, Sep 17, 2014 at 07:42:39PM +0200, Reimar Döffinger wrote:
>>> On Sun, Sep 14, 2014 at 09:34:48PM +0100, Andy Furniss wrote:
>>>> Grozdan wrote:
>>>>> Hi,
>>>>>
>>>>> I've noticed a problem when using Blu-ray input together with
>>>>> demuxer lavf. The MPlayer cmd is as follows
>>>>>
>>>>> mplayer br:// -bluray-device disc.br -vo null -vc dummy
>>>>> -demuxer lavf -frames 1
>>>>>
>>>>> The problem is that MPlayer does not stop after reading one
>>>>> frame (-frames 1) but goes on to read the *full* Blu-ray, until
>>>>> the end. You can imagine doing this on a 30-50GB bluray input.
>>>>> It trashes the disk until it reaches the end of the BD
>>>>>
>>>>> The same goes if you use something simple as: mplayer br://
>>>>> -bluray-device disc.br -demuxer lavf
>>>>>
>>>>> I've tried to get it work but was not able to do it. The only
>>>>> option is to omit -demuxer lavf which then "works" but the
>>>>> terminal gets spammed with error messages and playback is
>>>>> virtually impossible!
>>>>
>>>> Hmm, so it does - there is a workaround though -
>>>>
>>>> -cache 20000 "fixes" -demuxer lavf for me testing with an
>>>> encrypted disc dumped on HD (for which I have the vuk of
>>>> course).
>>>
>>> I think there are at least 2 bugs :(. MPlayer asks bd_seek to seek
>>> to a completely nonsense position: s->pos=548000
>>> newpos=7F94F8105800  new_bufpos=7F94F8106179  buflen=0 However
>>> instead of either seeking to EOF or returning an error, bd_seek
>>> just does nothing. The bd_seek documentation unfortunately says
>>> nothing at all about what happens for errors.
>>
>> I fixed a good bunch of issues, hopefully all this works more
>> reasonably now.
>
>Almost, but not quite for me.
>
>On all 3 of my disks (on HD) lavf now works without cache and seeking
>works on 2 of them.
>
>One just gets EOF when seeking with lavf with or without cache, it
>works
>without lavf.
>
>There are two differences from the working - it's encrypted and it's
>also made up of lots of small .m2ts for multilingual reasons I guess
>whereas the other 2 the main film is just one large .m2ts.

I would bet that if you dumpstream'd the title and tried to seek in ffplay you'd get the same issue.
I'd expect the problem is a combination of two things:
1) the demuxer deals badly with timestamp resets which probably happen at the start of each file
2) it for some unknown reason does not use the stream's read_seek function which would use the proper bluray timestamps

We could probably avoid it by just not using the demuxer's seek function, but that is more a hack than proper solution.