[FFmpeg-devel] [PATCH] feature: xcbgrab single window

[Nicolas George]

Le duodi 22 brumaire, an CCXXV, Ing. Radomír Polách a écrit :
> I am not sure either, but I think it is better this way, because you can
> easily use it to pass result from a search script:
> ./ffmpeg -i $(./findmypaint.sh) ...
> Search script is a simple script which finds for you screen, focus window
> and grab window of some program.
> For example findmypaint.sh here finds this information about MyPaint. The
> search script just needs to produce output like this:
> :0/0x0580001b/parent2
> It is very flexible this way.

I see the point, but it could work with options too. Remember that
command substitutions $(...) are re-split (and re-expanded, but there
are no special characters here), and thus can contain several words.
Therefore, your findmypaint.sh script could output its findings like
this:

  -window 0x0580001b -focus parent2 -i :0

and you would be able to use the same way (almost: remove -i from the
command line).

> I tought so too, but I tested it with RTMP streaming and players
> disconnects without repeat_frame. I am not sure where the problem is.

I see. I suppose they consider it as a broken connection after a
reasonable timeout. Since you have a working RTMP setup, maybe you could
test: feed them from a plain file (using -re), and then suspend the
ffmpeg process: do the clients disconnect the same way?

If so, I think the solution should not belong in an individual device
but rather in the common parts of the code.

Still, I suspect the final code for frame duplication would be rather
small eventually while changes in the framework are not for today, so it
is not a real objection.

> Didn't know about existence of boolean there. Should I also take care of
> draw_mouse and follow_mouse in a separate patch?

You can if you want, and it will be appreciated. But do not feel
obligated to do it just because you are changing a nearby and similar
part of the code.

> > This looks strange. Was this made before my commit to disable
> > refcounting of the packets? If so, it will need to be rebased and
> > updated. But on the other hand, the logic to keep the current packet
> > should be much simpler.
> Could you point me out to your commit and the problem?

The problem is very simple: I made a non-trivial change to xcbgrab.c
recently, and it was applied. If you started working on your patch
before that, odds are it will not work now since we probably changed the
same lines in different ways.

The specific commit is:

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0bd1be65e88d6a4f367e698d7a2b105424eb1905

Before continuing working on your changes, you need to "rebase" your
work tree. There are plenty of tutorial, but the gist of it:

git fetch origin  (to download the recent changes)
git rebase origin/master

If it succeeds, good for you. But it will probably point you to
conflicts. Use "git diff" to see them, edit the files and fix them. Once
it works, use "git add" to prepare the commit, and finish with "git
rebase --continue" instead of "git commit".

This commit changes how packets are handled in the SHM case. With it,
duplicating frames should be trivial: just skip all the image reading
capture and skip directly to the part that outputs the packet. The
non-SHM case still needs to be handled, though.

> Maybe this is the reason for RTMP disconnects.

Possibly. I think empty packets may be handled quite inconsistently
across the code.

>						 Is there a way to not return
> any data? I thought this would work.

You cannot not return any data, because when the applications ask for
data, they want it. What you can do is return FFERROR_REDO: that will
tell the framework to re-call the function immediately, until it
actually returns something. It works exactly the same as putting all the
read_packet() code in a big loop.

From the applications' point of view, it means the function call to get
a packet will block until the window is focused again. This is similar
to network protocols: if an application is reading and you unplug the
cable, it will block until you plug the cable back. Most applications
run this part in a separate thread for that reason.

(There is also a non-blocking mode, but it is not implemented at all in
xcbgrab. And blocking mode is the default, so it needs to work.)

> > I do not think you are authorized to change filename like that.
> I can duplicate the variable, but didn't notice breaking of anything.

I think it would be wiser. But I would still prefer using individual
options and avoid the issue entirely and spare the parsing code.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161113/752e27e8/attachment.sig>