[MPlayer-dev-eng] [PATCH] Return actual current stream id in slave mode

Adrian Stutz adrian at sttz.ch
Wed Dec 16 01:00:35 CET 2009


On Tue, Dec 15, 2009 at 11:38 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de
> wrote:

> Seems wrong in the details.
> First, I think you have to check that mpctx->d_video (same for audio) is
> not NULL,
> I expect that can happen.
> Secondly, I think that it would be more useful to still return values < 0,
> since
> I think that allows to distinguish
> - a file without any video in principle (e.g. mp3 file)
> - a file with audio disabled (== -2)
> - a file for which no suitable stream has been found yet, e.g. a MPEG file
>  where audio only starts quite far in (== -1)
>
> MPlayer may not handle all these cases in a way that makes sense yet,
> but we should not just ignore them if it's easy to take them into account.
>

I first checked if d_(audio|video) is NULL but then. after looking at
demuxer.c and especially new_demuxer(). i came to the conclusion that the
structs are always initliaized and their id set. I did test with audio files
as well as with a video that has no audio stream and in neither case was
either NULL.

Though that's just scratching the surface and I don't know if the demuxer
could be initialized differently or could be reinitialized in a way that
would set the pointers to NULL so I don't mind adding an extra check if you
insist. I wanted to keep the patch as simple as possible.

With a value of -2 it returns M_PROPERTY_UNAVAILABLE which is equivalent to
having no audio or video stream. I don't see much point of returning -2
instead and would rather improve the slave mode with printing the actual
error (it currently only says "Failed to get value of property
'switch_audio'.").

As for the -1 case, I was a bit confused by -1 meaning stepping streams in
the demuxers and (audio|video)_id keeping -1 without updating. But now I
agree that it makes sense to return -1 from the d_(audio|video) structs as
this value will eventually be updated if a stream is found.

Updated patch attached.

Greetings
Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: property_get_actual_stream_id_v2.diff
Type: application/octet-stream
Size: 840 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20091216/5fea48f8/attachment.obj>


More information about the MPlayer-dev-eng mailing list