[Bug 778496] vtenc: should support GLMemory

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778496

--- Comment #9 from Nick Kallen <socialmediamaster9000 at gmail.com> ---
OK I'm going to deal with all these changes this week.


> Reason for going via the frame number here is that it can prevent access to already
> freed memory (or memory leaks if you pass a new reference here). When getting it 
> again later by integer, we can handle properly if the frame was freed already (can 
> probably happen during shutdown). (Or if you pass another reference, we can ensure 
> that the encoder is never keeping the reference forever but we can free the frame 
> when we want).

OK I'll revert this change. It seems unfortunate because when getting by
integer a lock is acquired, and you have all this deadlock avoidance code in
vtenc which as I discovered was missing several cases. The issue is you can
call apples encoder, and it will (sometimes) block, but it will actually do the
work in another thread. And if you call it with a lock which it will later need
in the other thread, you get a deadlock.

The code does a lot of this:

  GST_VIDEO_ENCODER_STREAM_UNLOCK (self);
      VTCompressionSessionCompleteFrames (self->session,
      kCMTimePositiveInfinity);
  GST_VIDEO_ENCODER_STREAM_LOCK (self);

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.