[MPlayer-users] Playing DASH streams / .mpd files

[The Wanderer]

On 2021-03-17 at 16:06, Reimar Döffinger wrote:

> On Wed, Mar 17, 2021 at 03:39:28PM -0400, The Wanderer wrote:

>> That required moving the check after the ffmpeg_a (etc.) checks are
>> run, but that shouldn't be an issue, although it does bring back
>> my uncertainty about where best to position this.
> 
> It's the wild west, whereever works :)

I'm reflexively uncomfortable with that level of disorganization, to the
point where I kind of want to dig in and try to get the entire set of
checks et cetera organized according to some articulable scheme, but I'm
also lazy enough that I don't want to put in the effort to do that just
at the moment - plus I'm not confident that I'd get it right, without
introducing bugs based on subtle ordering requirements that I might
miss. So I'll leave it where I put it on this second pass, barring
further input.

>>> If adding a enable/disable option, this part probably should go
>>> outside of the "auto" if.
>> 
>> Are you sure? That'd be reasonable if we're doing detection when 
>> explicitly enabled, but at least as I recall matters, that's not
>> the usual MPlayer configure semantics; we usually assume that if
>> you pass an explicit --enable argument for something that has
>> autodetection, you're going to be passing the necessary
>> CFLAGS/LDFLAGS/etc. via other arguments, since you're overriding
>> autodetection anyway.

<snip>

>> So is this effectively a check for whether to enable that component
>> or not? I was treating it as a check for whether libxml2 is
>> present, with the idea that we could then add a check for DASH
>> which would itself reference the result of the libxml2 check.
> 
> Both questions kind of have the same answer. I guess I explained the
> lazy way, but I guess your are right. It should look approximately
> like (using Python style pseudocode)

<snip>

> I was suggesting the lazy way of just handling both the autodetect
> pass and the disabled/autodetect fail in a single if, but you are
> right it makes more sense to do it separately.

Done, I think. See attached patch. (I initially missed stripping out
DASH in the case where libxml2 detection fails, but I believe I have
that done cleanly now.)

> (also I admit that it might make more sense to have the dependent 
> features disabled by default and enable them if libxml2 is detected, 
> but I think that might be harder to do for FFmpeg components/features
> - but I've not checked)

If I'm parsing you correctly, I think you're right on both counts.

>> I suppose there's not much point to that as long as we don't have
>> any other code that would require libxml2, so we might as well put
>> it all together for now, and split it out with separate disabling
>> options later. I'll update things with that approach for now.
> 
> I don't think it makes sense to split out even further than that. 
> There is already --disable-demuxer= option, I guess if you want to be
> thorough you could test that it still works with whatever you 
> implement.

I meant, if we ever wind up with multiple features that would
individually rely on libxml2 being present, we could then add checks
(and flags) for those features, rather than having all of them or none
of them depending on whether libxml2 is enabled.

I don't have enough of an understanding of how --disable-demuxer= works
to be comfortable with trying to add that for DASH at the moment. If
it's straightforward to do at all, it should be equally straightforward
to do on top of this patch later on, if there's interest.

>> The patch with the above changes, except for letting --enable still
>> do autodetection of the necessary flags, has been compile-tested
>> without issues; I haven't tried running the result, and I don't
>> know any DASH streams to test with.
> 
> The original email starting all this has an example DASH stream :)

So it does! I hadn't examined the URL closely enough to realize that
that's what it was. I tested, and apart from brief choppiness every now
and then (accompanied by an ALSA "resetting soundcard" message in the
console), it seems to work flawlessly.

Patch attached for review.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw



-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure-test-for-libxml2_with-enable-disable-flags.diff
Type: text/x-diff
Size: 3217 bytes
Desc: not available
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20210317/9ebc571d/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20210317/9ebc571d/attachment-0001.sig>