[Screeninvader] Goodbye Mr.Mplayer?

[Amir Hassan]

done :)

On Thu, 09 Apr 2015 18:41:56 +0200, phaer <hello at phaer.org> wrote:

>
> I don't have any reason against it, to the contrary, replacing it sounds
> like a very good idea, now that there's the vdpau support that
> ScreenInvader needs.
>
> An additional argument for the replacement would be mpv's lua api[1]
> which would probably be useful for advanced features, especially if we
> could connect it to zeromq. If not, JSON-based IPC[2] looks good enough
>
> [1]: https://github.com/mpv-player/mpv/blob/master/DOCS/man/lua.rst
> [2]: https://github.com/mpv-player/mpv/blob/master/DOCS/man/ipc.rst
>
> Amir Hassan <amir at viel-zu.org> writes:
>
>> Mplayer has been a (/the most?) vital component for the ScreenInvader  
>> from
>> the beginning, and as such the quality requirements have been pretty  
>> high
>> - and largely met. Anyway. during the ongoing rewrite of the  
>> ScreenInvader
>> several issue have been encountered they aren't easy to workaround:
>>
>> 1. missing https support for mplayer requires us to run proxy.py and
>> maintain a list of https only services.
>> 2. slave command "run" doesn't reap forks and generates zombie processes
>> 3. tracking player events and reading mplayer properties requires  
>> parsing
>> stdout
>>
>> I went through our new code base and looked out for the places where  
>> there
>> is still real ugly code and guess what?
>>
>> Anyway, I'm an early mplayer user ever since and so i reached out for  
>> help
>> in the mplayer community.
>>
>> first i tried to tackle the https issue and found following post with an
>> attempt to submit patches for https support:
>> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-February/049277.html
>> In short - the patch was rejected because it _uses_ fork ("... because
>> it's ugly, creates a mess, prevents certain things from working..."
>>
>> then i tracked down the "run" bug. i quickly found the pertaining code
>> section in commands.c
>>
>> 3370        case MP_CMD_RUN:
>> 3371	#ifndef __MINGW32__
>> 3372	            if (!fork()) {
>> 3373	                char *exp_cmd = property_expand_string(mpctx,
>> cmd->args[0].v.s);
>> 3374	                if (exp_cmd) {
>> 3375	                    execl("/bin/sh", "sh", "-c", exp_cmd, NULL);
>> 3376	                    free(exp_cmd);
>> 3377	                }
>> 3378	                exit(0);
>> 3379	            }
>> 3380	#endif
>> 3381	            break;
>>
>> the interesting part is it does _use_ fork. and it does it in a very bad
>> way - without waiting for the process to terminate and reaping its  
>> return
>> value. doing that generates zombie processes, which are usually no harm
>> unless e.g you generate lots of them on an embedded system or you run
>> mplayer as a daemon. we do both because we're are trying to workaround 3
>> by making mplayer print the time_pos and length to stdout every second.
>> that's a zombie per second that doesn't get reaped until mplayer exits
>> (which by design never should happen :p).
>> well, bugs happen and so i'm right now waiting for an answer to
>> https://lists.mplayerhq.hu/pipermail/mplayer-users/2015-April/087953.html.
>> _but_ while waiting for an answer i answered a request for help myself
>> (https://lists.mplayerhq.hu/pipermail/mplayer-users/2015-April/087956.html)
>> and in short - advised to use MPV :D
>>
>> So... there have been two reasons i haven't already switched our  
>> codebase
>> to MPV:
>> 1. It would require a rewrite of the ScreenInvader
>> 2. MPV's VDPAU acceleration doesn't work with libvdpau-sunxi
>>
>> Both reasons are the past since we're rewriting right now and
>> libvdpau-sunxi _does_ now support MPV:
>> https://github.com/linux-sunxi/libvdpau-sunxi/blob/master/README
>>
>> Can you come up with a real good reason why we shouldn't switch?
>>
>> greets,
>> amir
>>
>> _______________________________________________
>> Screeninvader mailing list
>> Screeninvader at lists.metalab.at
>> https://lists.metalab.at/mailman/listinfo/screeninvader
>
> --
> Sent with my mu4e
>
> _______________________________________________
> Screeninvader mailing list
> Screeninvader at lists.metalab.at
> https://lists.metalab.at/mailman/listinfo/screeninvader