[Windows] Supports optional frame_rate for progressive playback. [chromium/src : main]
Qiu, Jianlin (Gerrit)
Qiu, Jianlin voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gwsq (Gerrit)
Message from gwsq![]( "Open in Gerrit")
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: ke...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
IPC reviewer(s): ke...@chromium.org
Reviewer source(s):
ke...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
Related details
- Dale Curtis
- Ken Buchanan
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Ken Buchanan (Gerrit)
Ken Buchanan voted and added 1 comment![]( "Open in Gerrit")
Votes added by Ken Buchanan
| Code-Review | +1 |
1 comment
Related details
- Dale Curtis
- Qiu, Jianlin
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| 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")
This is only going to work for src= video which is pretty rare. You would instead need to add this support to MSE if you want this to work on YT and elsewhere.
Related details
- Qiu, Jianlin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| 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")
configured, instead of hard code to 60fps which blocks super resolutionAFAIK we only enable super resolution at composition time not decode time, which is not done in this code (decode time). That instead happens at swap chain presenter?
Qiu, Jianlin (Gerrit)
Qiu, Jianlin added 2 comments![]( "Open in Gerrit")
This is only going to work for src= video which is pretty rare. You would instead need to add this support to MSE if you want this to work on YT and elsewhere.
Yes as indicated the in commit message, supporting populating framerate will be added with another seperate CL.
My plan is to use the information in the 'trex' box for fragmented mp4, and also reference the stts/stsz box -> But that seems to introducing overhead for parsing them.
Any suggestions?
configured, instead of hard code to 60fps which blocks super resolutionAFAIK we only enable super resolution at composition time not decode time, which is not done in this code (decode time). That instead happens at swap chain presenter?
Yes that happens at swapchain presenter. After MSE also delivers framerate information to compositor, I'll add change in VideoResourceUpdater to make sure TextureDrawQuad and VideoHoleDrawQuad includes the framerate information, so they can be featured by the overlay processor.
Related details
- Dale Curtis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dale Curtis (Gerrit)
Dale Curtis added 2 comments![]( "Open in Gerrit")
Qiu, JianlinThis is only going to work for src= video which is pretty rare. You would instead need to add this support to MSE if you want this to work on YT and elsewhere.
Yes as indicated the in commit message, supporting populating framerate will be added with another seperate CL.
My plan is to use the information in the 'trex' box for fragmented mp4, and also reference the stts/stsz box -> But that seems to introducing overhead for parsing them.
Any suggestions?
That sounds right, but I'd have to go check the relevant specs. I'd probably just do what ffmpeg is doing.
configured, instead of hard code to 60fps which blocks super resolutionQiu, JianlinAFAIK we only enable super resolution at composition time not decode time, which is not done in this code (decode time). That instead happens at swap chain presenter?
Yes that happens at swapchain presenter. After MSE also delivers framerate information to compositor, I'll add change in VideoResourceUpdater to make sure TextureDrawQuad and VideoHoleDrawQuad includes the framerate information, so they can be featured by the overlay processor.
But why do we need this code change at all then? Isn't it okay that we use 60fps during the decode stage? The compositor portion should already have access to the actual render interval: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=874;drc=0d56d0143aa2bb6c7bfad81a4e27063ad2a9de8a
which properly accounts for playbackRate.
Related details
- Qiu, Jianlin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Qiu, Jianlin (Gerrit)
Qiu, Jianlin added 1 comment![]( "Open in Gerrit")
configured, instead of hard code to 60fps which blocks super resolutionQiu, JianlinAFAIK we only enable super resolution at composition time not decode time, which is not done in this code (decode time). That instead happens at swap chain presenter?
Dale CurtisYes that happens at swapchain presenter. After MSE also delivers framerate information to compositor, I'll add change in VideoResourceUpdater to make sure TextureDrawQuad and VideoHoleDrawQuad includes the framerate information, so they can be featured by the overlay processor.
But why do we need this code change at all then? Isn't it okay that we use 60fps during the decode stage? The compositor portion should already have access to the actual render interval: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=874;drc=0d56d0143aa2bb6c7bfad81a4e27063ad2a9de8a
which properly accounts for playbackRate.
I intend to replace the hard-code here: https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/dc_layer_tree.cc;l=451;drc=0d56d0143aa2bb6c7bfad81a4e27063ad2a9de8a
Yes using the actual render interval should be a better solution.
Related details
- Dale Curtis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Qiu, Jianlin (Gerrit)
Qiu, Jianlin added 1 comment![]( "Open in Gerrit")
configured, instead of hard code to 60fps which blocks super resolutionQiu, JianlinAFAIK we only enable super resolution at composition time not decode time, which is not done in this code (decode time). That instead happens at swap chain presenter?
Dale CurtisYes that happens at swapchain presenter. After MSE also delivers framerate information to compositor, I'll add change in VideoResourceUpdater to make sure TextureDrawQuad and VideoHoleDrawQuad includes the framerate information, so they can be featured by the overlay processor.
Qiu, JianlinBut why do we need this code change at all then? Isn't it okay that we use 60fps during the decode stage? The compositor portion should already have access to the actual render interval: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/video_frame_submitter.cc;l=874;drc=0d56d0143aa2bb6c7bfad81a4e27063ad2a9de8a
which properly accounts for playbackRate.
I intend to replace the hard-code here: https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/dc_layer_tree.cc;l=451;drc=0d56d0143aa2bb6c7bfad81a4e27063ad2a9de8a
Yes using the actual render interval should be a better solution.
I'm holding this CL, and switch to use rendering interval for FPS calculation. (effectively depending on PTS for the rate).
Related details
- Dale Curtis
- Ken Buchanan
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |