Reason for revert:
Breaks downstream build.
Original issue's description:
> Add QP sum stats for received streams.
>
> This is not implemented yet in any of the decoders.
>
> BUG=webrtc:6541
>
> Review-Url: https://codereview.webrtc.org/2649133005
> Cr-Commit-Position: refs/heads/master@{#16475}
> Committed: ff0e72fd16TBR=hta@webrtc.org,hbos@webrtc.org,sprang@webrtc.org,magjed@webrtc.org,stefan@webrtc.org,sakal@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2680893002 .
Cr-Commit-Position: refs/heads/master@{#16480}
This is not implemented yet in any of the decoders.
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2649133005
Cr-Commit-Position: refs/heads/master@{#16475}
Reason for revert:
Perf test broke as it made assumptions that quality scaling was turned off. This turns out not to be the case. Fixed by turning quality scaling off for the tests.
Original issue's description:
> Revert of Drop frames until specified bitrate is achieved. (patchset #12 id:240001 of https://codereview.webrtc.org/2630333002/ )
>
> Reason for revert:
> due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
>
> Original issue's description:
> > Drop frames until specified bitrate is achieved.
> >
> > This CL fixes a regression introduced with the new quality scaler
> > where the video would no longer start in a scaled mode. This CL adds
> > code that compares incoming captured frames to the target bitrate,
> > and if they are found to be too large, they are dropped and sinkWants
> > set to a lower resolution. The number of dropped frames should be low
> > (0-4 in most cases) and should not introduce a noticeable delay, or
> > at least should be preferrable to having the first 2-4 seconds of video
> > have very low quality.
> >
> > BUG=webrtc:6953
> >
> > Review-Url: https://codereview.webrtc.org/2630333002
> > Cr-Commit-Position: refs/heads/master@{#16391}
> > Committed: 83399caec5
>
> TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2666303002
> Cr-Commit-Position: refs/heads/master@{#16395}
> Committed: 35fc2aa82fTBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,minyue@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2675223002
Cr-Commit-Position: refs/heads/master@{#16473}
We can then drop the CongestionController and RemoteBitrateEstimator
completely from the receive streams.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2669463006
Cr-Commit-Position: refs/heads/master@{#16459}
Reason for revert:
Will try to reland FlexFEC tests, since these do not seem to be flaky on the buildbots.
Original issue's description:
> Revert of Improve and re-enable FEC end-to-end tests. (patchset #3 id:40001 of https://codereview.webrtc.org/2675573004/ )
>
> Reason for revert:
> Ulpfec tests are still flaky on buildbots.
>
> Original issue's description:
> > Improve and re-enable FEC end-to-end tests.
> >
> > These tests got flaky under the new jitter buffer.
> >
> > Enhancements:
> > - Use send-side BWE.
> > - Let BWE ramp up before applying packet loss.
> > - Improve packet loss simulation for ULPFEC.
> > - Add delay to fake network pipe for FlexFEC.
> > (Not added for ULPFEC, since this makes those flaky...?)
> > - Add FlexFEC+NACK test, using RTX instead of "raw retransmits".
> > - Tighter checks of received packets' payload types and SSRCs.
> >
> > TESTED=
> > $ ninja -C out/Debug video_engine_tests && third_party/gtest-parallel/gtest-parallel -r 1000 out/Debug/video_engine_tests --gtest_filter="*EndToEnd*Ulpfec*:*EndToEnd*Flexfec*"
> > ninja: Entering directory `out/Debug'
> > ninja: no work to do.
> > [12000/12000] TestWithNewVideoJitterBuffer/EndToEndTest.RecoversWithFlexfecAndNack/1 (14935 ms)
> >
> > BUG=webrtc:7047
> >
> > Review-Url: https://codereview.webrtc.org/2675573004
> > Cr-Commit-Position: refs/heads/master@{#16449}
> > Committed: d40b0f39e0
>
> TBR=stefan@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:7047
>
> Review-Url: https://codereview.webrtc.org/2672373002
> Cr-Commit-Position: refs/heads/master@{#16450}
> Committed: fd8d2654d7TBR=stefan@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:7047
Review-Url: https://codereview.webrtc.org/2675283003
Cr-Commit-Position: refs/heads/master@{#16452}
Also fixes a bug where RTCP transport feedback was sent even though RTCP was disabled.
May affect perf numbers since the behavior of the send-side BWE differs a lot from the recv-side BWE.
BUG=webrtc:7111
Review-Url: https://codereview.webrtc.org/2669413003
Cr-Commit-Position: refs/heads/master@{#16451}
Reason for revert:
Ulpfec tests are still flaky on buildbots.
Original issue's description:
> Improve and re-enable FEC end-to-end tests.
>
> These tests got flaky under the new jitter buffer.
>
> Enhancements:
> - Use send-side BWE.
> - Let BWE ramp up before applying packet loss.
> - Improve packet loss simulation for ULPFEC.
> - Add delay to fake network pipe for FlexFEC.
> (Not added for ULPFEC, since this makes those flaky...?)
> - Add FlexFEC+NACK test, using RTX instead of "raw retransmits".
> - Tighter checks of received packets' payload types and SSRCs.
>
> TESTED=
> $ ninja -C out/Debug video_engine_tests && third_party/gtest-parallel/gtest-parallel -r 1000 out/Debug/video_engine_tests --gtest_filter="*EndToEnd*Ulpfec*:*EndToEnd*Flexfec*"
> ninja: Entering directory `out/Debug'
> ninja: no work to do.
> [12000/12000] TestWithNewVideoJitterBuffer/EndToEndTest.RecoversWithFlexfecAndNack/1 (14935 ms)
>
> BUG=webrtc:7047
>
> Review-Url: https://codereview.webrtc.org/2675573004
> Cr-Commit-Position: refs/heads/master@{#16449}
> Committed: d40b0f39e0TBR=stefan@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:7047
Review-Url: https://codereview.webrtc.org/2672373002
Cr-Commit-Position: refs/heads/master@{#16450}
These tests got flaky under the new jitter buffer.
Enhancements:
- Use send-side BWE.
- Let BWE ramp up before applying packet loss.
- Improve packet loss simulation for ULPFEC.
- Add delay to fake network pipe for FlexFEC.
(Not added for ULPFEC, since this makes those flaky...?)
- Add FlexFEC+NACK test, using RTX instead of "raw retransmits".
- Tighter checks of received packets' payload types and SSRCs.
TESTED=
$ ninja -C out/Debug video_engine_tests && third_party/gtest-parallel/gtest-parallel -r 1000 out/Debug/video_engine_tests --gtest_filter="*EndToEnd*Ulpfec*:*EndToEnd*Flexfec*"
ninja: Entering directory `out/Debug'
ninja: no work to do.
[12000/12000] TestWithNewVideoJitterBuffer/EndToEndTest.RecoversWithFlexfecAndNack/1 (14935 ms)
BUG=webrtc:7047
Review-Url: https://codereview.webrtc.org/2675573004
Cr-Commit-Position: refs/heads/master@{#16449}
Intervals when video is paused is no longer included in the stats:
"WebRTC.Video.BitrateSentInKbps"
"WebRTC.Video.MediaBitrateSentInKbps"
"WebRTC.Video.PaddingBitrateSentInKbps"
"WebRTC.Video.RetransmittedBitrateSentInKbps"
"WebRTC.Video.RtxBitrateSentInKbps"
"WebRTC.Video.FecBitrateSentInKbps"
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/2536613002
Cr-Commit-Position: refs/heads/master@{#16447}
Use AdaptDown/AdaptUp instead of ScaleDown/ScaleUp, since we may want to
adapt using other means than resolution.
Also, extend vie_encoder with unit test that actually uses frames scaled
to resolution as determined by VideoAdapter, since that seems to be the
default implementation.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2652893015
Cr-Commit-Position: refs/heads/master@{#16402}
Reason for revert:
due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
Original issue's description:
> Drop frames until specified bitrate is achieved.
>
> This CL fixes a regression introduced with the new quality scaler
> where the video would no longer start in a scaled mode. This CL adds
> code that compares incoming captured frames to the target bitrate,
> and if they are found to be too large, they are dropped and sinkWants
> set to a lower resolution. The number of dropped frames should be low
> (0-4 in most cases) and should not introduce a noticeable delay, or
> at least should be preferrable to having the first 2-4 seconds of video
> have very low quality.
>
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2630333002
> Cr-Commit-Position: refs/heads/master@{#16391}
> Committed: 83399caec5TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2666303002
Cr-Commit-Position: refs/heads/master@{#16395}
Delete the calls from RtpStreamReceiver (for video) and
AudioReceiveStream.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2659563002
Cr-Commit-Position: refs/heads/master@{#16393}
This CL fixes a regression introduced with the new quality scaler
where the video would no longer start in a scaled mode. This CL adds
code that compares incoming captured frames to the target bitrate,
and if they are found to be too large, they are dropped and sinkWants
set to a lower resolution. The number of dropped frames should be low
(0-4 in most cases) and should not introduce a noticeable delay, or
at least should be preferrable to having the first 2-4 seconds of video
have very low quality.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2630333002
Cr-Commit-Position: refs/heads/master@{#16391}
Also mark the render_time_ms getter function and the ntp timestamp
as deprecated.
BUG=webrtc:6977
Review-Url: https://codereview.webrtc.org/2633493002
Cr-Commit-Position: refs/heads/master@{#16354}
Video modules are added in reverse order to ensure that the padding order is the same as before, prioritizing high resolution streams.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2655033002
Cr-Commit-Position: refs/heads/master@{#16329}
This CL introduces a way for the VideoReceiveStreams to check whether
they are protected by any FlexfecReceiveStreams. This is done in the
VideoReceiveStream::Start() method, which then propagates this information
down to the jitter buffer adaptation logic.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2649973005
Cr-Commit-Position: refs/heads/master@{#16328}
Reason for revert:
Downstream project relied on changed struct.
Transition made possible by https://codereview.webrtc.org/2655243006/.
Original issue's description:
> Revert of Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters. (patchset #7 id:160001 of https://codereview.webrtc.org/2646073004/ )
>
> Reason for revert:
> Breaks internal downstream project.
>
> Original issue's description:
> > Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
> >
> > Prior to this CL, received RTX (associated) payload types were only configured
> > when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> > SSRC was set up.
> >
> > After this CL, the RTX (associated) payload types are set in
> > WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> > them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> > that is the code path that sets other SSRCs.
> >
> > As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> > We remove the possibility for each video payload type to have an associated
> > specific RTX SSRC. Although the config previously allowed for this, all payload
> > types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> > did not support multiple SSRCs. This change to the config struct should thus not
> > have any functional impact. The change does however affect the RtcEventLog, since
> > that is used for storing the VideoReceiveStream::Configs. For simplicity,
> > this CL does not change the event log proto definitions, instead duplicating
> > the serialized RTX SSRCs such that they fit in the existing proto definition.
> >
> > BUG=webrtc:7011
> >
> > Review-Url: https://codereview.webrtc.org/2646073004
> > Cr-Commit-Position: refs/heads/master@{#16302}
> > Committed: fe2bef39cd
>
> TBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2649323010
> Cr-Commit-Position: refs/heads/master@{#16307}
> Committed: e4974953ceTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
# NOTREECHECKS=true
# NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2654163006
Cr-Commit-Position: refs/heads/master@{#16322}
Test disabled on Windows due to failures on Win Msan, Win64 Debug, Win
SyzyAsan, Win32 Debug and others.
TBR=sprang@webrtc.org
BUG=webrtc:6886
NOTRY=True
Review-Url: https://codereview.webrtc.org/2657233002
Cr-Commit-Position: refs/heads/master@{#16320}
Reason for revert:
Breaks internal downstream project.
Original issue's description:
> Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
>
> Prior to this CL, received RTX (associated) payload types were only configured
> when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> SSRC was set up.
>
> After this CL, the RTX (associated) payload types are set in
> WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> that is the code path that sets other SSRCs.
>
> As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> We remove the possibility for each video payload type to have an associated
> specific RTX SSRC. Although the config previously allowed for this, all payload
> types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> did not support multiple SSRCs. This change to the config struct should thus not
> have any functional impact. The change does however affect the RtcEventLog, since
> that is used for storing the VideoReceiveStream::Configs. For simplicity,
> this CL does not change the event log proto definitions, instead duplicating
> the serialized RTX SSRCs such that they fit in the existing proto definition.
>
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2646073004
> Cr-Commit-Position: refs/heads/master@{#16302}
> Committed: fe2bef39cdTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2649323010
Cr-Commit-Position: refs/heads/master@{#16307}
Prior to this CL, received RTX (associated) payload types were only configured
when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
SSRC was set up.
After this CL, the RTX (associated) payload types are set in
WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
that is the code path that sets other SSRCs.
As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
We remove the possibility for each video payload type to have an associated
specific RTX SSRC. Although the config previously allowed for this, all payload
types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
did not support multiple SSRCs. This change to the config struct should thus not
have any functional impact. The change does however affect the RtcEventLog, since
that is used for storing the VideoReceiveStream::Configs. For simplicity,
this CL does not change the event log proto definitions, instead duplicating
the serialized RTX SSRCs such that they fit in the existing proto definition.
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2646073004
Cr-Commit-Position: refs/heads/master@{#16302}
outputs various elements of the RTP header when there is a delivery error.
output example:
Packet len=984 pt=100 seq=47914 ts=1532364329 ssrc=0xdeadbef0
BUG=webrtc:6991
Review-Url: https://codereview.webrtc.org/2621163006
Cr-Commit-Position: refs/heads/master@{#16294}
Reason for revert:
Bugfixes related to the new jitter buffer has landed.
Original issue's description:
> Revert of Make the new jitter buffer the default jitter buffer. (patchset #2 id:230001 of https://codereview.webrtc.org/2642753002/ )
>
> Reason for revert:
> Breaks tests downstream.
>
> Original issue's description:
> > Reland of Make the new jitter buffer the default jitter buffer. (patchset #1 id:1 of https://codereview.chromium.org/2632123005/ )
> >
> > Reason for revert:
> > Fix in this CL: https://codereview.chromium.org/2640793003/
> >
> > Original issue's description:
> > > Revert of Make the new jitter buffer the default jitter buffer. (patchset #7 id:120001 of https://codereview.chromium.org/2627463004/ )
> > >
> > > Reason for revert:
> > > Breaks android bots.
> > >
> > > Original issue's description:
> > > > Make the new jitter buffer the default jitter buffer.
> > > >
> > > > This CL contains only the changes necessary to make the switch to the new jitter
> > > > buffer, clean up will be done in follow up CLs.
> > > >
> > > > In this CL:
> > > > - Removed the WebRTC-NewVideoJitterBuffer experiment and made the
> > > > new video jitter buffer the default one.
> > > > - Moved WebRTC.Video.KeyFramesReceivedInPermille and
> > > > WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
> > > >
> > > > BUG=webrtc:5514
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2627463004
> > > > Cr-Commit-Position: refs/heads/master@{#16114}
> > > > Committed: 0f0763d86d
> > >
> > > TBR=stefan@webrtc.org,terelius@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:5514
> > >
> > > Review-Url: https://codereview.webrtc.org/2632123005
> > > Cr-Commit-Position: refs/heads/master@{#16117}
> > > Committed: c08c191f7d
> >
> > TBR=stefan@webrtc.org,terelius@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:5514
> >
> > Review-Url: https://codereview.webrtc.org/2642753002
> > Cr-Commit-Position: refs/heads/master@{#16149}
> > Committed: f20dd0014d
>
> TBR=stefan@webrtc.org,terelius@webrtc.org,philipel@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5514
>
> Review-Url: https://codereview.webrtc.org/2638423003
> Cr-Commit-Position: refs/heads/master@{#16159}
> Committed: 04926b8264TBR=stefan@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2652043005
Cr-Commit-Position: refs/heads/master@{#16293}
Removed conditional disabling of
ReceivesFlexfecAndSendsCorrespondingRtcp on Asan, since failure occurs
at other platforms as well.
BUG=webrtc:7050
TBR=holmer@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2651673011
Cr-Commit-Position: refs/heads/master@{#16288}
Order as given by inheritance in class definition.
No functional changes are intended with this CL.
BUG=None
Review-Url: https://codereview.webrtc.org/2646343005
Cr-Commit-Position: refs/heads/master@{#16272}
due to timeout-caused build failure (see bugs.webrtc.org/7047). The
timeout is governed by CallTest::kDefaultTimeoutMs, which is set to 30
seconds. This can be too low for Asan.
TBR=brandtr@webrtc.org
BUG=webrtc:7047
Review-Url: https://codereview.webrtc.org/2657823003
Cr-Commit-Position: refs/heads/master@{#16267}
This CL introduces a dedicated unit test for webrtc::RtpStreamReceiver.
Focus of this CL is testing RtpStreamReciver::OnReceivedPayloadData().
Dependencies with virtual interfaces are (g)mocked, non-virtual
dependencies are instantiated.
This CL is chained to https://codereview.webrtc.org/2638933002/ .
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2641463002
Cr-Commit-Position: refs/heads/master@{#16240}
They were passed on via RtpRtcp::Configuration, but unused for a
receive only RtpRtcp module.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2639423007
Cr-Commit-Position: refs/heads/master@{#16234}
Reason for revert:
Triggers leak on Linux memcheck (non-default trybot):
### BEGIN MEMORY TOOL REPORT (error hash=#0112A395AF2326BC#)
Command: ../Release/./modules_unittests --isolated-script-test-output=/b/s/w/ioUlJCnu/output.json --isolated-script-test-chartjson-output=/b/s/w/ioUlJCnu/chartjson-output.json --gtest_filter=-CommonFormats/AudioProcessingTest*
Leak_DefinitelyLost
45 bytes in 1 blocks are definitely lost in loss record 118 of 277
operator new[](unsigned long) (m_replacemalloc/vg_replace_malloc.c:363)
webrtc::video_coding::H264SpsPpsTracker::CopyAndFixBitstream(webrtc::VCMPacket*) (/b/s/w/irJgAGsR/out/Release/modules_unittests)
webrtc::video_coding::TestH264SpsPpsTracker_SpsPpsOutOfBand_Test::TestBody() (/b/s/w/irJgAGsR/out/Release/modules_unittests)
Suppression (error hash=#0112A395AF2326BC#):
For more info on using suppressions see http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/memory-sheriff#TOC-Suppressing-memory-reports
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:_Zna*
fun:_ZN6webrtc12video_coding17H264SpsPpsTracker19CopyAndFixBitstreamEPNS_9VCMPacketE
fun:_ZN6webrtc12video_coding42TestH264SpsPpsTracker_SpsPpsOutOfBand_Test8TestBodyEv
}
### END MEMORY TOOL REPORT (error hash=#0112A395AF2326BC#)
Original issue's description:
> H264SpsPpsTracker.InsertSpsPpsNalus() should accept Nalus with header.
>
> - Changed method name to clarify that entire Nalus are expected.
> - Added unit test code.
> - Adjusted InsetSpsPpsNalus() implementation to above requirement.
>
> BUG=webrtc:5948
>
> Review-Url: https://codereview.webrtc.org/2638933002
> Cr-Commit-Position: refs/heads/master@{#16221}
> Committed: f53d7374cfTBR=philipel@webrtc.org,sprang@webrtc.org,johan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2649113003
Cr-Commit-Position: refs/heads/master@{#16225}
- Changed method name to clarify that entire Nalus are expected.
- Added unit test code.
- Adjusted InsetSpsPpsNalus() implementation to above requirement.
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2638933002
Cr-Commit-Position: refs/heads/master@{#16221}
