An rtc::Buffer is used to write output of RBSP parsing, usually one byte
at a time. It turns out that container will then expand its capacity one
byte at a time, for each byte reallocating the whole buffer and copying
the contents over, turning this into an O(n^2) operation.
Fix is for now only to preallocate the container storage. Longer term, I
think we should mull over if we really need custom containers...
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=
Review URL: https://codereview.webrtc.org/2073763002 .
Cr-Commit-Position: refs/heads/master@{#13167}
The function GetExecutablePath is a hack with poor portability. Delete
it and its caller GetTestFilePath. The latter was used in
videoframe_unittest.h, where it is replaced by
webrtc::test::ResourcePath.
Delete unused functions declared in base/testutils.h: ReadFile,
GetSiblingDirectory, GetGoogle3Directory, GetTalkDirectory,
CmpHelperFileEq, EXPECT_FILEEQ, ASSERT_FILEEQ.
Delete unused functions declared in media/base/testutils.h:
GetTestFilePath (see above), LoadPlanarYuvTestImage,
DumpPlanarYuvTestImage, ComputePSNR, ComputeSumSquareError.
The functions LoadPlanarYuvTestImage, DumpPlanarYuvTestImage were used
in yuvscaler_unittests.cc and planarfunctions_unittests.cc, under
webrtc/pc. However, these tests are never compiled or run, and appear
not to have been for the last few years, and are therefore deleted
rather than updated. It might make sense to check if libyuv have
comparable tests, and if not, resurrect them as part of libyuv
unittests.
BUG=
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2058043002 .
Cr-Commit-Position: refs/heads/master@{#13163}
And implement SampleRateHz in a bunch of mocks.
BUG=webrtc:5801
NOTRY=true
Review-Url: https://codereview.webrtc.org/2029543002
Cr-Commit-Position: refs/heads/master@{#13161}
The test sent a media packet, then verified it was sent by checking the
"last packet sent"'s ID. But the last packet sent may have been
a STUN packet that came *after* the media packet.
BUG=webrtc:5978
Review-Url: https://codereview.webrtc.org/2071573002
Cr-Commit-Position: refs/heads/master@{#13156}
This is a somewhat involved refactoring of this class. Here's an overview of the changes:
* FileWrapper can now be used as a regular class and instances allocated on the stack.
* The type now has support for move semantics and copy isn't allowed.
* New public ctor with FILE* that can be used instead of OpenFromFileHandle.
* New static Open() method. The intent of this is to allow opening a file and getting back a FileWrapper instance. Using this method instead of Create(), will allow us in the future to make the FILE* member pointer, to be const and simplify threading (get rid of the lock).
* Rename the Open() method to is_open() and make it inline.
* The FileWrapper interface is no longer a pure virtual interface. There's only one implementation so there's no need to go through a vtable for everything.
* Functionality offered by the class, is now reduced. No support for looping (not clear if that was actually useful to users of that flag), no need to implement the 'read_only_' functionality in the class, since file APIs implement that already, no support for *not* managing the file handle (this wasn't used). OpenFromFileHandle always "manages" the file.
* Delete the unused WriteText() method and don't support opening files in text mode. Text mode is only different on Windows and on Windows it translates \n to \r\n, which means that files such as log files, could have a slightly different format on Windows than other platforms. Besides, tools on Windows can handle UNIX line endings.
* Remove FileName(), change Trace code to manage its own path.
* Rename id_ member variable to file_.
* Removed the open_ member variable since the same functionality can be gotten from just checking the file pointer.
* Don't call CloseFile inside of Write. Write shouldn't be changing the state of the class beyond just attempting to write.
* Remove concept of looping from FileWrapper and never close inside of Read()
* Changed stream base classes to inherit from a common base class instead of both defining the Rewind method. Ultimately, Id' like to remove these interfaces and just have FileWrapper.
* Remove read_only param from OpenFromFileHandle
* Renamed size_in_bytes_ to position_, since it gets set to 0 when Rewind() is called (and the size actually does not change).
* Switch out rw lock for CriticalSection. The r/w lock was only used for reading when checking the open_ flag.
BUG=
Review-Url: https://codereview.webrtc.org/2054373002
Cr-Commit-Position: refs/heads/master@{#13155}
1. It moves calculation of the needed padding to VideoSendStream instead of ViEEncoder and only does it once per send Stream instead of every time the network estimate changes.
2. The maximum amount of padding sent was prior to this cl calculated and updated based on network estimate changes. However, it can only change based on encoder configuration changes and if send streams are added or removed. This cl change the VideoSendStream/VieEncoder to notify the BitrateAllocator of changes to the needed padding bitrate and for BitrateAllocator to notify Call of these changes.
3. Fixed an issue in the SendPacer where it could send a padding packet before sending a real packet. This caused the test EndToEndTest.RestartingSendStreamPreservesRtpStatesWithRtx to fail with these refactorings since the pacer suddenly could send a padding packet before the encoder had produced its first frame.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1993113003
Cr-Commit-Position: refs/heads/master@{#13149}
Reason for revert:
Reverting after experiment. What seems to happen is that the thread can't be stopped when PostThreadMessage fails with this error code (or lack thereof).
Original issue's description:
> Attempt to figure out what the issue is on the Win10 FYI build bot in content_browsertests.
> Check for the case when PostThreadMessage returns false but GetLastError returns ERROR_SUCCESS.
>
> TBR=olka
> NOTRY=true
>
> Committed: https://crrev.com/e11041159d6e66fb25c2e045ad1558fc99d2d6cd
> Cr-Commit-Position: refs/heads/master@{#13143}
TBR=olka@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2067013003
Cr-Commit-Position: refs/heads/master@{#13147}
Reason for revert:
Reverting while we track down the issue on the Win10 bot.
Original issue's description:
> Split IncomingVideoStream into two implementations, with smoothing and without.
>
> This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
>
> Further work done:
>
> * I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
>
> * I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
>
> * I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
>
> * The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
>
> * The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
>
> * Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
>
> * Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
>
> * Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
>
> * Made the render delay value in VideoRenderFrames, const.
>
> BUG=
>
> Committed: https://crrev.com/1c7eef652b0aa22d8ebb0bfe2b547094a794be22
> Cr-Commit-Position: refs/heads/master@{#13129}
TBR=mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2061363002
Cr-Commit-Position: refs/heads/master@{#13146}
EncodedFrameCallbackAdapter was used VideoSendStream and
VideoReceiveStream, but there is no reason to have it as these classes
can call EncodedFrameObserver directly.
Review-Url: https://codereview.webrtc.org/2068463004
Cr-Commit-Position: refs/heads/master@{#13145}
Check for the case when PostThreadMessage returns false but GetLastError returns ERROR_SUCCESS.
TBR=olka
NOTRY=true
Review-Url: https://codereview.webrtc.org/2063313003
Cr-Commit-Position: refs/heads/master@{#13143}
Current number of threads selection code does not work well
for Android builds - middle and low end devices are having hard time
encoding VGA and QVGA with just one thread.
Increase the amount of vp8 encoder threads for 180p and above resolution.
Also limit maximum number of thread to 3, since for 8 core devices
most of time 4 cores are idle when thermal throttling kicks in.
BUG=b/27946721
R=marpan@webrtc.org
Review URL: https://codereview.webrtc.org/2058753003 .
Cr-Commit-Position: refs/heads/master@{#13142}
The RtpReceiverObserverInterface is created.
The SignalFirstPacketReceived will be forwarded from BaseChannel to WebRtcSession.
WebRtcSession will forward SignalFirstAudioPacketReceived and SignalFirstVideoPacketReceived to the RtpReceiverInterface.
The application can listen to the Signal by implementing and registering a RtpReceiverObserver.
Review-Url: https://codereview.webrtc.org/1999853002
Cr-Commit-Position: refs/heads/master@{#13139}
It was already disabled for browsers by design, and for everyone else
because of a bug.
BUG=webrtc:5922
Review-Url: https://codereview.webrtc.org/2055493003
Cr-Commit-Position: refs/heads/master@{#13138}
It appears there the encode and send operation can happen over multiple
threads. Also, padding data itself may be sent on a different thread.
Remove thread checker and protect all data with crit_sect.
BUG=webrtc:5998
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2066863002
Cr-Commit-Position: refs/heads/master@{#13137}
Added the plumbing necessary to get two different lists of codecs from
WebRtcVoiceEngine up to MediaSessionDescriptionFactory.
This should be the last step in this set of CLs. Once
https://codereview.webrtc.org/1991233004/ has landed, it's possible to
implement the ReceiveCodecs getter with the info from the
AudioDecoderFactory. The factory needs to be updated to actually
produce the correct list, as well.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2013053002
Cr-Commit-Position: refs/heads/master@{#13131}
Camera1 tests are now separated from general CameraVideoCapturer tests.
Main motivation behind these changes is that Camera2 implementation can
be tested using the same tests.
CL also reduces code duplication on tests using textures.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024843002
Cr-Commit-Position: refs/heads/master@{#13130}
This CL fixes an issue with the non-smoothing implementation where frames were delivered on the decoder thread. No-smoothing is now done in a separate class that uses a TaskQueue. The implementation may drop frames if the renderer doesn't keep up and it doesn't block the decoder thread.
Further work done:
* I added TODOs and documentation for VideoReceiveStream::OnFrame, where we today grab 5 locks.
* I removed the Start/Stop methods from the IncomingVideoStream implementations. Now, when an instance is created, it should be considered to be "running" and when it is deleted, it's "not running". This saves on resources and also reduces the amount of locking required and I could remove one critical section altogether.
* I changed the VideoStreamDecoder class to not depend on IncomingVideoStream but rather use the generic rtc::VideoSinkInterface<VideoFrame> interface. This means that any implementation of that interface can be used and the decoder can be made to just use the 'renderer' from the config. Once we do that, we can decouple the IncomingVideoStream implementations from the decoder and VideoReceiveStream implementations and leave it up to the application for how to do smoothing. The app can choose to use the Incoming* classes or roll its own (which may be preferable since applications often have their own scheduling mechanisms).
* The non-smoothing IncomingVideoStream implementation currently allows only 1 outstanding pending frame. If we exceed that, the current frame won't be delivered to the renderer and instead we deliver the next one (since when this happens, the renderer is falling behind).
* The lifetime of the VideoStreamDecoder instance is now bound to Start/Stop in VideoReceiveStream and not all of the lifetime of VideoReceiveStream.
* Fixed VideoStreamDecoder to unregister callbacks in the dtor that were registered in the ctor. (this was open to a use-after-free regression)
* Delay and callback pointers are now passed via the ctors to the IncomingVideoStream classes. The thread primitives in the IncomingVideoStream classes are also constructed/destructed at the same time as the owning object, which allowed me to remove one more lock.
* Removed code in the VideoStreamDecoder that could overwrite the VideoReceiveStream render delay with a fixed value of 10ms on construction. This wasn't a problem with the previous implementation (it would be now though) but seemed to me like the wrong place to be setting that value.
* Made the render delay value in VideoRenderFrames, const.
BUG=
Review-Url: https://codereview.webrtc.org/2035173002
Cr-Commit-Position: refs/heads/master@{#13129}
Added initial support for MediaSessionDescriptionFactory to pick different codecs based on communications direction (sendrecv, sendonly, recvonly, inactive) specifically for audio.
This adds some more degradation options for the answer: depending on answer options, it's now possible to degrade to INACTIVE from any offer, as well as to either RECVONLY or SENDONLY from a SENDRECV offer.
The set of "codecs" used for testing the answer was compiled using this spreadsheet:
https://docs.google.com/a/google.com/spreadsheets/d/1nVIfZLsFo5YK10_e80BCAADZnnRQ1devwwwAGmqJPow/edit?usp=sharing
I should probably condense it into a smaller table and put in the source.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1956343002
Cr-Commit-Position: refs/heads/master@{#13126}
Move all its configuration to all.gyp instead, which is
not processed by Chromium builds (webrtc.gyp is).
BUG=webrtc:5949
NOTRY=True
Review-Url: https://codereview.webrtc.org/2060873002
Cr-Commit-Position: refs/heads/master@{#13124}
Earlier, no statistics were reported if no frames were being delivered
for encoding. This makes statics always be reported regardless of if
there are frames being delivered to the encoder.
Review-Url: https://codereview.webrtc.org/2051403002
Cr-Commit-Position: refs/heads/master@{#13122}
not to be created in apprtc on Android.
The path separator was missing when the path for the aecdump
file was created. This CL adds that path separator.
Note that the change of the formatting of the rest of the
line was caused by "git cl format" (the clang automatic
formatting).
BUG=webrtc:5991
Review-Url: https://codereview.webrtc.org/2053263002
Cr-Commit-Position: refs/heads/master@{#13121}
Right now if an exception is thrown, it doesn't seem to be logged
anywhere. This CL makes it show a pop-up with the error message.
This should save time debugging issues.
Review-Url: https://codereview.webrtc.org/2049933004
Cr-Commit-Position: refs/heads/master@{#13120}
We were passing the pointer to the sockaddr to usrsctp_dumppacket,
instead of the pointer to the data. So we were just logging random
bytes. The dangers of void*...
NOTRY=True
TBR=pthatcher@webrtc.org
BUG=619372
Review-Url: https://codereview.webrtc.org/2061093003
Cr-Commit-Position: refs/heads/master@{#13119}
