If more than 60 frames are created and not returned, the implementation will crash.
I420BufferPool are currently used by the VP8 decoder, Quality scaler and VideoFrameFactory.
BUG=b/31390397
NOTRY=true // Because of failing gclient runhooks on some bots
Review-Url: https://codereview.webrtc.org/2370653003
Cr-Commit-Position: refs/heads/master@{#14395}
This cl is in preparation for https://codereview.webrtc.org/2060403002/ Add task queue to Call.
In the coming cl the video_sender, and i420_buffer_pool will be used on a task queue and therefore SequencedTaskChecker is needed instead of a ThreadChecker.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2149553002
Cr-Commit-Position: refs/heads/master@{#13474}
This affects the webrtc::VideoFrameBuffer and cricket::VideoFrame
classes.
To make this work, VideoFrameFactory is changed to use an
I420BufferPool rather than a plain VideoFrame to cache allocated
frames.
The I420BufferPool is reorganized to return an I420Buffer,
rather than a proxy object.
BUG=webrtc:5921, webrtc:5682
Review-Url: https://codereview.webrtc.org/2009193002
Cr-Commit-Position: refs/heads/master@{#12919}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
Eliminate most uses of the old methods.
To continue on this path, once we agree the new methods make sense,
the next step is to rename cricket::VideoFrame::GetVideoFrameBuffer
--> video_frame_buffer, to match the name in webrtc::VideoFrame (if we
think that name is ok?). And then start updating all code to access
planes via the VideoFrameBuffer, and delete corresponding methods in
both cricket::VideoFrame and webrtc::VideoFrame.
BUG=webrtc:5682
Review URL: https://codereview.webrtc.org/1878623002
Cr-Commit-Position: refs/heads/master@{#12407}
Reason for revert:
This is breaking all FYI bots.
The new virtual method is not implemented on the Chromium side yet.
Original issue's description:
> Introduce an IsMutable method on VideoFrameBuffer.
>
> Unlike HasOneRef, it can be overridden to always return false in
> immutable subclasses.
>
> I'm also investigating overiding it in PooledI420Buffer, to directly
> inherit I420Buffer but ignore the reference from the pool. Still
> unclear if that will work out.
>
> BUG=webrtc:5682
>
> Committed: https://crrev.com/6bd10f2c1ac912cbe5addd880e559d59274c60e6
> Cr-Commit-Position: refs/heads/master@{#12365}
TBR=magjed@webrtc.org,perkj@webrtc.org,pbos@webrtc.org,nisse@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5682
Review URL: https://codereview.webrtc.org/1885943004
Cr-Commit-Position: refs/heads/master@{#12366}
Unlike HasOneRef, it can be overridden to always return false in
immutable subclasses.
I'm also investigating overiding it in PooledI420Buffer, to directly
inherit I420Buffer but ignore the reference from the pool. Still
unclear if that will work out.
BUG=webrtc:5682
Review URL: https://codereview.webrtc.org/1881933004
Cr-Commit-Position: refs/heads/master@{#12365}
To avoid breaking downstream, the "interface" directories were copied
into a new "common_video/include" dir. The old headers got pragma
warnings added about deprecation (a very short deprecation since I plan
to remove them as soon downstream is updated).
The header guards are also identical to avoid mixing them up in the transition.
BUG=webrtc:5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
Review URL: https://codereview.webrtc.org/1418913006
Cr-Commit-Position: refs/heads/master@{#10659}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
VideoFrameBuffer currently has two overloaded data() functions for pixel access, one for const and one for non-const. Unfortunately, it will default to the non-const version, even when 'const scoped_refptr<VideoFrameBuffer>&' is used. This is a problem, because many subclasses use RTC_NOTREACHED() in the non-const version.
This CL makes the non-const version of data() explicit with a different, longer function name MutableData().
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1304143003 .
Cr-Commit-Position: refs/heads/master@{#9787}
Now when we don't use SwapFrame consistently anymore, we need to recycle allocations with a buffer pool instead. This CL adds a buffer pool class, and updates the vp8 decoder to use it. If this CL lands successfully I will update the other video producers as well.
BUG=1128
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41189004
Cr-Commit-Position: refs/heads/master@{#8748}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8748 4adac7df-926f-26a2-2b94-8c16560cd09d
