media: Report Renderer Type as Media.BasicPlayback UKM field [chromium/src : main]
Sangbaek Park (Gerrit)
Sangbaek Park added 1 comment![]( "Open in Gerrit")
1. `Media.WebMediaPlayerState` already reports `RendererType` field whereas `Media.BasicPlayback` doesn't.
2. `Media.WebMediaPlayerState` has `KeySystem` and `IsHardwareSecure` fields whereas `Media.BasicPlayback` doesn't.
3. As far as MediaFoundationRenderer is concerned, we have to do a join operation between two UKMs on the same PlayerID to inspect some UKM fields from `Media.BasicPlayback`.
Not sure it would be more proper if we add `KeySystem` and `IsHardwareSecure` to `Media.BasicPlayback` instead (or not sure these values are available for the watch time recorder). By simply reporting `RendererType` field for `Media.BasicPlayback`, it gives us more flexibility without the expensive join operation when inspecting the data. WDYT?
Related details
- Dale Curtis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Vikram Pasupathy (Gerrit)
Vikram Pasupathy added 1 comment![]( "Open in Gerrit")
1. `Media.WebMediaPlayerState` already reports `RendererType` field whereas `Media.BasicPlayback` doesn't.
2. `Media.WebMediaPlayerState` has `KeySystem` and `IsHardwareSecure` fields whereas `Media.BasicPlayback` doesn't.
3. As far as MediaFoundationRenderer is concerned, we have to do a join operation between two UKMs on the same PlayerID to inspect some UKM fields from `Media.BasicPlayback`.Not sure it would be more proper if we add `KeySystem` and `IsHardwareSecure` to `Media.BasicPlayback` instead (or not sure these values are available for the watch time recorder). By simply reporting `RendererType` field for `Media.BasicPlayback`, it gives us more flexibility without the expensive join operation when inspecting the data. WDYT?
+1 to this idea, and two follow up questions for Dale:
1. Are there any docs discussing the differences and intentions with the different Media Playback UKMS? I don't understand what feels like some duplication (which we try solving via ideas like Sangbaek's). Maybe there is something out there, but couldn't find anything after a cursory search.
2. When we add a field like this to the UKM, are we expected to create a new UKM review document? ex: https://docs.google.com/document/d/1cdfAP66Hm4W4hcXmgOm1BqScYIS0KP7cyCgLu91f-kE/edit?tab=t.0#heading=h.k5jx6iluw4yt
I'm asking because I've seen UKMs have a running document where reviewers can give LGTMs to fields, rather than explaining what the UKM does from scratch.
Related details
- Dale Curtis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dale Curtis (Gerrit)
Dale Curtis added 1 comment![]( "Open in Gerrit")
Vikram Pasupathy1. `Media.WebMediaPlayerState` already reports `RendererType` field whereas `Media.BasicPlayback` doesn't.
2. `Media.WebMediaPlayerState` has `KeySystem` and `IsHardwareSecure` fields whereas `Media.BasicPlayback` doesn't.
3. As far as MediaFoundationRenderer is concerned, we have to do a join operation between two UKMs on the same PlayerID to inspect some UKM fields from `Media.BasicPlayback`.Not sure it would be more proper if we add `KeySystem` and `IsHardwareSecure` to `Media.BasicPlayback` instead (or not sure these values are available for the watch time recorder). By simply reporting `RendererType` field for `Media.BasicPlayback`, it gives us more flexibility without the expensive join operation when inspecting the data. WDYT?
+1 to this idea, and two follow up questions for Dale:
1. Are there any docs discussing the differences and intentions with the different Media Playback UKMS? I don't understand what feels like some duplication (which we try solving via ideas like Sangbaek's). Maybe there is something out there, but couldn't find anything after a cursory search.
2. When we add a field like this to the UKM, are we expected to create a new UKM review document? ex: https://docs.google.com/document/d/1cdfAP66Hm4W4hcXmgOm1BqScYIS0KP7cyCgLu91f-kE/edit?tab=t.0#heading=h.k5jx6iluw4yt
I'm asking because I've seen UKMs have a running document where reviewers can give LGTMs to fields, rather than explaining what the UKM does from scratch.
Anything that can change is supposed to be on the BaiscPlayback table, WebMediaPlayerState is supposed to be one time. RendererType is a bit of an exception though since it can actually change (e.g., remoting renderer). So it should actually have been on the basic playback table all along.
I don't understand what's so problematic about the JOIN though? Presumably you're just using an inner join between the two tables (after filtering down to just what you want in basic playback table) based on the id?
Related details
- Sangbaek Park
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sangbaek Park (Gerrit)
Sangbaek Park added 1 comment![]( "Open in Gerrit")
Vikram Pasupathy1. `Media.WebMediaPlayerState` already reports `RendererType` field whereas `Media.BasicPlayback` doesn't.
2. `Media.WebMediaPlayerState` has `KeySystem` and `IsHardwareSecure` fields whereas `Media.BasicPlayback` doesn't.
3. As far as MediaFoundationRenderer is concerned, we have to do a join operation between two UKMs on the same PlayerID to inspect some UKM fields from `Media.BasicPlayback`.Not sure it would be more proper if we add `KeySystem` and `IsHardwareSecure` to `Media.BasicPlayback` instead (or not sure these values are available for the watch time recorder). By simply reporting `RendererType` field for `Media.BasicPlayback`, it gives us more flexibility without the expensive join operation when inspecting the data. WDYT?
Dale Curtis+1 to this idea, and two follow up questions for Dale:
1. Are there any docs discussing the differences and intentions with the different Media Playback UKMS? I don't understand what feels like some duplication (which we try solving via ideas like Sangbaek's). Maybe there is something out there, but couldn't find anything after a cursory search.
2. When we add a field like this to the UKM, are we expected to create a new UKM review document? ex: https://docs.google.com/document/d/1cdfAP66Hm4W4hcXmgOm1BqScYIS0KP7cyCgLu91f-kE/edit?tab=t.0#heading=h.k5jx6iluw4yt
I'm asking because I've seen UKMs have a running document where reviewers can give LGTMs to fields, rather than explaining what the UKM does from scratch.
Anything that can change is supposed to be on the BaiscPlayback table, WebMediaPlayerState is supposed to be one time. RendererType is a bit of an exception though since it can actually change (e.g., remoting renderer). So it should actually have been on the basic playback table all along.
I don't understand what's so problematic about the JOIN though? Presumably you're just using an inner join between the two tables (after filtering down to just what you want in basic playback table) based on the id?
Presumably you're just using an inner join between the two tables (after filtering down to just what you want in basic playback table) based on the id?
Right. Actually, it's not a huge deal for doing that inner join operation but it gives us a good benefit when tackling some playback issues specifically for PlayReady HWDRM + detecting abuse/fraud cases if RendererType is reported in the BasicPlayback. And also I'm not sure if selecting the same PlayerID between BasicPlayback and WebMediaPlayerState per session_id per client_id gives us the correct entries since the PlayerID is an incremental number from 0 (any idea on this?).
Looks like adding `RendererType` into BasicPlayback is good to go, right?
Related details
- Dale Curtis
- Vikram Pasupathy
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dale Curtis (Gerrit)
Dale Curtis added 1 comment![]( "Open in Gerrit")
Vikram Pasupathy1. `Media.WebMediaPlayerState` already reports `RendererType` field whereas `Media.BasicPlayback` doesn't.
2. `Media.WebMediaPlayerState` has `KeySystem` and `IsHardwareSecure` fields whereas `Media.BasicPlayback` doesn't.
3. As far as MediaFoundationRenderer is concerned, we have to do a join operation between two UKMs on the same PlayerID to inspect some UKM fields from `Media.BasicPlayback`.Not sure it would be more proper if we add `KeySystem` and `IsHardwareSecure` to `Media.BasicPlayback` instead (or not sure these values are available for the watch time recorder). By simply reporting `RendererType` field for `Media.BasicPlayback`, it gives us more flexibility without the expensive join operation when inspecting the data. WDYT?
Dale Curtis+1 to this idea, and two follow up questions for Dale:
1. Are there any docs discussing the differences and intentions with the different Media Playback UKMS? I don't understand what feels like some duplication (which we try solving via ideas like Sangbaek's). Maybe there is something out there, but couldn't find anything after a cursory search.
2. When we add a field like this to the UKM, are we expected to create a new UKM review document? ex: https://docs.google.com/document/d/1cdfAP66Hm4W4hcXmgOm1BqScYIS0KP7cyCgLu91f-kE/edit?tab=t.0#heading=h.k5jx6iluw4yt
I'm asking because I've seen UKMs have a running document where reviewers can give LGTMs to fields, rather than explaining what the UKM does from scratch.
Sangbaek ParkAnything that can change is supposed to be on the BaiscPlayback table, WebMediaPlayerState is supposed to be one time. RendererType is a bit of an exception though since it can actually change (e.g., remoting renderer). So it should actually have been on the basic playback table all along.
I don't understand what's so problematic about the JOIN though? Presumably you're just using an inner join between the two tables (after filtering down to just what you want in basic playback table) based on the id?
Presumably you're just using an inner join between the two tables (after filtering down to just what you want in basic playback table) based on the id?
Right. Actually, it's not a huge deal for doing that inner join operation but it gives us a good benefit when tackling some playback issues specifically for PlayReady HWDRM + detecting abuse/fraud cases if RendererType is reported in the BasicPlayback. And also I'm not sure if selecting the same PlayerID between BasicPlayback and WebMediaPlayerState per session_id per client_id gives us the correct entries since the PlayerID is an incremental number from 0 (any idea on this?).
Looks like adding `RendererType` into BasicPlayback is good to go, right?
Right you have to join on client_id+session_id+player_id. I'm not opposed to it, but you'll need UKM review to decide if we need a new doc for copying this key to another table. Probably we should deprecate the one in WMPState since renderer can change, but that would mean updating the code a bit.
Related details
- Sangbaek Park
- Vikram Pasupathy
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |