8b476173d897c8e88330de683f9f9e9c81e76589
12 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| ba050a6d6d |
Reland of Add a flags field to video timing extension. (patchset #1 id:1 of https://codereview.webrtc.org/2995953002/ )
Reason for revert: Create reland CL to add fix to. Original issue's description: > Revert of Add a flags field to video timing extension. (patchset #15 id:280001 of https://codereview.webrtc.org/3000753002/ ) > > Reason for revert: > Speculative revet for breaking remoting_unittests in fyi bots. > https://build.chromium.org/p/chromium.webrtc.fyi/waterfall?builder=Win7%20Tester > > Original issue's description: > > Add a flags field to video timing extension. > > > > The rtp header extension for video timing shuold have an additional > > field for signaling metadata, such as what triggered the extension for > > this particular frame. This will allow separating frames select because > > of outlier sizes from regular frames, for more accurate stats. > > > > This implementation is backwards compatible in that it can read video > > timing extensions without the new flag field, but it always sends with > > it included. > > > > BUG=webrtc:7594 > > > > Review-Url: https://codereview.webrtc.org/3000753002 > > Cr-Commit-Position: refs/heads/master@{#19353} > > Committed: |
|||
| f0f7378b05 |
Revert of Add a flags field to video timing extension. (patchset #15 id:280001 of https://codereview.webrtc.org/3000753002/ )
Reason for revert:
Speculative revet for breaking remoting_unittests in fyi bots.
https://build.chromium.org/p/chromium.webrtc.fyi/waterfall?builder=Win7%20Tester
Original issue's description:
> Add a flags field to video timing extension.
>
> The rtp header extension for video timing shuold have an additional
> field for signaling metadata, such as what triggered the extension for
> this particular frame. This will allow separating frames select because
> of outlier sizes from regular frames, for more accurate stats.
>
> This implementation is backwards compatible in that it can read video
> timing extensions without the new flag field, but it always sends with
> it included.
>
> BUG=webrtc:7594
>
> Review-Url: https://codereview.webrtc.org/3000753002
> Cr-Commit-Position: refs/heads/master@{#19353}
> Committed:
|
|||
| cf5d485e14 |
Add a flags field to video timing extension.
The rtp header extension for video timing shuold have an additional field for signaling metadata, such as what triggered the extension for this particular frame. This will allow separating frames select because of outlier sizes from regular frames, for more accurate stats. This implementation is backwards compatible in that it can read video timing extensions without the new flag field, but it always sends with it included. BUG=webrtc:7594 Review-Url: https://codereview.webrtc.org/3000753002 Cr-Commit-Position: refs/heads/master@{#19353} |
|||
| 73c0eb5014 |
ObjC: Implement HW codecs in ObjC instead of C++
The current ObjC HW encoder is implemented as a C++ webrtc::VideoEncoder. We then wrap it two times in the following way: webrtc::VideoEncoder -> RTCVideoEncoder -> webrtc::VideoEncoder. This was originally done to minimize the code diff when landing the injectable encoder. This CL removes the first wrapping and implements the ObjC HW encoder as a RTCVideoEncoder directly. Similarly, the decoder is implemented as a RTCVideoDecoder directly. Based on andersc@ CL: https://codereview.webrtc.org/2978623002/. BUG=webrtc:7924 Review-Url: https://codereview.webrtc.org/2987413002 Cr-Commit-Position: refs/heads/master@{#19255} |
|||
| 8eab09c77b |
ObjC style fix for injectable video codecs
This CL fixes some ObjC style issues from CL https://codereview.webrtc.org/2977213002/. BUG=webrtc:7924 Review-Url: https://codereview.webrtc.org/2989803002 Cr-Commit-Position: refs/heads/master@{#19186} |
|||
| fb143127d7 |
Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2980173002/ )
Reason for revert: Relanding after fixing issues with no video. Original issue's description: > Revert of Injectable Obj-C video codecs (patchset #2 id:370001 of https://codereview.webrtc.org/2979983002/ ) > > Reason for revert: > Still having problems with no video. Reverting. > Once no video is visible, no video is available from then on even if the callee app is in the foreground. > > > Original issue's description: > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ ) > > > > Reason for revert: > > Fix the broken build file > > > > Original issue's description: > > > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ ) > > > > > > Reason for revert: > > > Breaks bots. Build file incorrect. > > > > > > Original issue's description: > > > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ ) > > > > > > > > Reason for revert: > > > > New CL for fixing the issues > > > > > > > > Original issue's description: > > > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ ) > > > > > > > > > > Reason for revert: > > > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future. > > > > > > > > > > Original issue's description: > > > > > > Injectable Obj-C video codecs > > > > > > > > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264 > > > > > > (wrapping the VideoToolbox codec). > > > > > > > > > > > > Some notes / things left to do: > > > > > > - There are some hard-coded references to codec types that are supported by > > > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc > > > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder. > > > > > > These types would need to be more codec agnostic to avoid this. > > > > > > - Most interfaces are borrowed from the design document for injectable > > > > > > codecs in Android. Some data in the corresponding C++ classes is discarded > > > > > > when converting to the Obj-C version, since it has fewer fields. I have not > > > > > > verified whether all data that we do keep is needed, or whether we might be > > > > > > losing anything useful in these conversions. > > > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264 > > > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder. > > > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/ > > > > > > Decoder wrapper classes. > > > > > > - List the injected codec factory's supported codecs in the list of codecs in > > > > > > AppRTCMobile. > > > > > > > > > > > > BUG=webrtc:7924 > > > > > > R=magjed@webrtc.org > > > > > > > > > > > > Review-Url: https://codereview.webrtc.org/2966023002 . > > > > > > Cr-Commit-Position: refs/heads/master@{#18928} > > > > > > Committed: |
|||
| 860f729816 |
Revert of Injectable Obj-C video codecs (patchset #2 id:370001 of https://codereview.webrtc.org/2979983002/ )
Reason for revert: Still having problems with no video. Reverting. Once no video is visible, no video is available from then on even if the callee app is in the foreground. Original issue's description: > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ ) > > Reason for revert: > Fix the broken build file > > Original issue's description: > > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ ) > > > > Reason for revert: > > Breaks bots. Build file incorrect. > > > > Original issue's description: > > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ ) > > > > > > Reason for revert: > > > New CL for fixing the issues > > > > > > Original issue's description: > > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ ) > > > > > > > > Reason for revert: > > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future. > > > > > > > > Original issue's description: > > > > > Injectable Obj-C video codecs > > > > > > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264 > > > > > (wrapping the VideoToolbox codec). > > > > > > > > > > Some notes / things left to do: > > > > > - There are some hard-coded references to codec types that are supported by > > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc > > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder. > > > > > These types would need to be more codec agnostic to avoid this. > > > > > - Most interfaces are borrowed from the design document for injectable > > > > > codecs in Android. Some data in the corresponding C++ classes is discarded > > > > > when converting to the Obj-C version, since it has fewer fields. I have not > > > > > verified whether all data that we do keep is needed, or whether we might be > > > > > losing anything useful in these conversions. > > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264 > > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder. > > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/ > > > > > Decoder wrapper classes. > > > > > - List the injected codec factory's supported codecs in the list of codecs in > > > > > AppRTCMobile. > > > > > > > > > > BUG=webrtc:7924 > > > > > R=magjed@webrtc.org > > > > > > > > > > Review-Url: https://codereview.webrtc.org/2966023002 . > > > > > Cr-Commit-Position: refs/heads/master@{#18928} > > > > > Committed: |
|||
| 732a3437da |
Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ )
Reason for revert: Fix the broken build file Original issue's description: > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ ) > > Reason for revert: > Breaks bots. Build file incorrect. > > Original issue's description: > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ ) > > > > Reason for revert: > > New CL for fixing the issues > > > > Original issue's description: > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ ) > > > > > > Reason for revert: > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future. > > > > > > Original issue's description: > > > > Injectable Obj-C video codecs > > > > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264 > > > > (wrapping the VideoToolbox codec). > > > > > > > > Some notes / things left to do: > > > > - There are some hard-coded references to codec types that are supported by > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder. > > > > These types would need to be more codec agnostic to avoid this. > > > > - Most interfaces are borrowed from the design document for injectable > > > > codecs in Android. Some data in the corresponding C++ classes is discarded > > > > when converting to the Obj-C version, since it has fewer fields. I have not > > > > verified whether all data that we do keep is needed, or whether we might be > > > > losing anything useful in these conversions. > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264 > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder. > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/ > > > > Decoder wrapper classes. > > > > - List the injected codec factory's supported codecs in the list of codecs in > > > > AppRTCMobile. > > > > > > > > BUG=webrtc:7924 > > > > R=magjed@webrtc.org > > > > > > > > Review-Url: https://codereview.webrtc.org/2966023002 . > > > > Cr-Commit-Position: refs/heads/master@{#18928} > > > > Committed: |
|||
| 81d40ee149 |
Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
Reason for revert: Breaks bots. Build file incorrect. Original issue's description: > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ ) > > Reason for revert: > New CL for fixing the issues > > Original issue's description: > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ ) > > > > Reason for revert: > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future. > > > > Original issue's description: > > > Injectable Obj-C video codecs > > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264 > > > (wrapping the VideoToolbox codec). > > > > > > Some notes / things left to do: > > > - There are some hard-coded references to codec types that are supported by > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder. > > > These types would need to be more codec agnostic to avoid this. > > > - Most interfaces are borrowed from the design document for injectable > > > codecs in Android. Some data in the corresponding C++ classes is discarded > > > when converting to the Obj-C version, since it has fewer fields. I have not > > > verified whether all data that we do keep is needed, or whether we might be > > > losing anything useful in these conversions. > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264 > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder. > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/ > > > Decoder wrapper classes. > > > - List the injected codec factory's supported codecs in the list of codecs in > > > AppRTCMobile. > > > > > > BUG=webrtc:7924 > > > R=magjed@webrtc.org > > > > > > Review-Url: https://codereview.webrtc.org/2966023002 . > > > Cr-Commit-Position: refs/heads/master@{#18928} > > > Committed: |
|||
| a5f1de1e65 |
Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
Reason for revert: New CL for fixing the issues Original issue's description: > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ ) > > Reason for revert: > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future. > > Original issue's description: > > Injectable Obj-C video codecs > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264 > > (wrapping the VideoToolbox codec). > > > > Some notes / things left to do: > > - There are some hard-coded references to codec types that are supported by > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder. > > These types would need to be more codec agnostic to avoid this. > > - Most interfaces are borrowed from the design document for injectable > > codecs in Android. Some data in the corresponding C++ classes is discarded > > when converting to the Obj-C version, since it has fewer fields. I have not > > verified whether all data that we do keep is needed, or whether we might be > > losing anything useful in these conversions. > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264 > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder. > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/ > > Decoder wrapper classes. > > - List the injected codec factory's supported codecs in the list of codecs in > > AppRTCMobile. > > > > BUG=webrtc:7924 > > R=magjed@webrtc.org > > > > Review-Url: https://codereview.webrtc.org/2966023002 . > > Cr-Commit-Position: refs/heads/master@{#18928} > > Committed: |
|||
| 1095ada7ad |
Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
Reason for revert:
Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
Original issue's description:
> Injectable Obj-C video codecs
>
> Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> (wrapping the VideoToolbox codec).
>
> Some notes / things left to do:
> - There are some hard-coded references to codec types that are supported by
> webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> These types would need to be more codec agnostic to avoid this.
> - Most interfaces are borrowed from the design document for injectable
> codecs in Android. Some data in the corresponding C++ classes is discarded
> when converting to the Obj-C version, since it has fewer fields. I have not
> verified whether all data that we do keep is needed, or whether we might be
> losing anything useful in these conversions.
> - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> Decoder wrapper classes.
> - List the injected codec factory's supported codecs in the list of codecs in
> AppRTCMobile.
>
> BUG=webrtc:7924
> R=magjed@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2966023002 .
> Cr-Commit-Position: refs/heads/master@{#18928}
> Committed:
|
|||
| a0349c138d |
Injectable Obj-C video codecs
Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
(wrapping the VideoToolbox codec).
Some notes / things left to do:
- There are some hard-coded references to codec types that are supported by
webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
These types would need to be more codec agnostic to avoid this.
- Most interfaces are borrowed from the design document for injectable
codecs in Android. Some data in the corresponding C++ classes is discarded
when converting to the Obj-C version, since it has fewer fields. I have not
verified whether all data that we do keep is needed, or whether we might be
losing anything useful in these conversions.
- Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
Decoder wrapper classes.
- List the injected codec factory's supported codecs in the list of codecs in
AppRTCMobile.
BUG=webrtc:7924
R=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2966023002 .
Cr-Commit-Position: refs/heads/master@{#18928}
|
