Bugzilla

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #6)
> - Troubleshooting information: Go to `about:support`, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

(Not sure this is relevant/useful in this case; no harm in doing this, but not a priority.)

(In reply to Raul Bucata from comment #5)
> Here is the performance profile [...] And I have attached the memory report.

Thanks. The profile shows the hulu.com process growing to use ~300MB of RAM, which seems pretty reasonable for playing large high-quality video. 

The memory report shows the Hulu process having 404.56 MB in "explicit allocations" and another 200MB or so of other allocations (mostly in js-main-runtime / js-main-runtime-gc-heap-committed).  So that process is responsible for ~600MB of memory usage, it looks like.

And then it shows the GPU process occupying 262MB of "explicit allocations" and 518MB under "gfx" (for webrender | textures).  So that process is responsible for 780MB of usage.

So: combined, those make up nearly 1400MB, which doesn't quite reach the 2.1GB shown in task manager, but makes up the bulk of it (and it's believable that the parent process & other misc. memory usage make up the rest. There might also be some shenenigans where Task Manager over-reports certain memory that's reserved but not used, etc.)

(Again, it's not obvious to me that this is an unusual amount of memory usage for this use-case.)

RE the comparison to Chrome here (which maxes out at around 450MB as shown in your screencast): Chrome never actually shows any video in that screencast.  I wonder if that was due to some sort of anti-piracy measure where they're detecting the screen-recording and turning off the video?  I don't know if the video was nerfed entirely vs. was only-displayed-on-the-physical-monitor vs. something else.

Raul, could you try Chrome on this site again, without any screen-recorder software running (to avoid any possible video-playback-interference), and report back about what their reported memory usage is in that scenario, just to rule out the possibility of anti-piracy video-playback-blocking stuff being involved there?

(It's also conceivable that Chrome's DRM-video-playback pipeline has some of the decoding happening in another process or bit of hardware that's simply not showing up in the task manager.  That feels sorta-likely, if they're still really only reporting 450MB of memory usage.)

In any case, it seems like this belongs in the Audio/Video component --> Reclassifying.

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #6)
> - Troubleshooting information: Go to `about:support`, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

(Not sure this is relevant/useful in this case; no harm in doing this, but not a priority.)

(In reply to Raul Bucata from comment #5)
> Here is the performance profile [...] And I have attached the memory report.

Thanks. The profile shows the hulu.com process growing to use ~300MB of RAM, which seems pretty reasonable for playing large high-quality video (and whatever fancy JS overhead Hulu is doing as part of that).

The attached memory report shows the Hulu process having 404.56 MB in "explicit allocations", and another 200MB or so of other allocations (mostly in js-main-runtime / js-main-runtime-gc-heap-committed).  So, assuming that those numbers are additive, that process is really responsible for ~600MB of memory usage, it looks like.

And then it shows the GPU process occupying 262MB of "explicit allocations" and 518MB under "gfx" (for webrender | textures).  So that process is responsible for 780MB of usage.

So: combined, those make up nearly 1400MB, which doesn't quite reach the 2.1GB shown in task manager, but makes up the bulk of it (and it's believable that the parent process & other misc. memory usage make up the rest. There might also be some shenenigans where Task Manager over-reports certain memory that's reserved but not used, etc.)

(Again, it's not obvious to me that this is an unusual amount of memory usage for this use-case.)

RE the comparison to Chrome here (which maxes out at around 450MB as shown in your screencast): Chrome never actually shows any video in that screencast.  I wonder if that was due to some sort of anti-piracy measure where they're detecting the screen-recording and turning off the video?  I don't know if the video was nerfed entirely vs. was only-displayed-on-the-physical-monitor vs. something else.

Raul, could you try Chrome on this site again, without any screen-recorder software running (to avoid any possible video-playback-interference), and report back about what their reported memory usage is in that scenario, just to rule out the possibility of anti-piracy video-playback-blocking stuff being involved there?

(It's also conceivable that Chrome's DRM-video-playback pipeline has some of the decoding happening in another process or bit of hardware that's simply not showing up in the task manager.  That feels sorta-likely, if they're still really only reporting 450MB of memory usage.)

In any case, it seems like this belongs in the Audio/Video component --> Reclassifying.

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #6)
> - Troubleshooting information: Go to `about:support`, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

(Not sure this is relevant/useful in this case; no harm in doing this, but not a priority.)

(In reply to Raul Bucata from comment #5)
> Here is the performance profile [...] And I have attached the memory report.

Thanks. The profile shows the hulu.com process growing to use ~300MB of RAM, which seems pretty reasonable for playing large high-quality video (and whatever fancy JS overhead Hulu is doing as part of that).

The attached memory report shows the Hulu process having 404.56 MB in "explicit allocations", and another 200MB or so of other allocations (mostly in js-main-runtime / js-main-runtime-gc-heap-committed).  So, assuming that those numbers are additive, that process is really responsible for ~600MB of memory usage, it looks like.

And then it shows the GPU process occupying 262MB of "explicit allocations" and 518MB under "gfx" (for webrender | textures).  So that process is responsible for 780MB of usage.

So: combined, those make up nearly 1400MB, which doesn't quite reach the 2.1GB shown in task manager, but makes up the bulk of it (and it's believable that the parent process & other misc. memory usage make up the rest. There might also be some shenenigans where Task Manager over-reports certain memory that's reserved but not used, etc.)

(Again, it's not obvious to me that this is an unusual amount of memory usage for this use-case.)

RE the comparison to Chrome here (which maxes out at around 450MB as shown in your screencast): Chrome never actually shows any video in that screencast.  I wonder if that was due to some sort of anti-piracy measure where they're detecting the screen-recording and turning off the video?  I can't tell if the video was blocked entirely from playing back in Chrome, vs. was only-displayed-on-the-physical-monitor-but-not-captured-in-the-screencast, vs. something else.

Raul, could you try Chrome on this site again, without any screen-recorder software running (to avoid any possible video-playback-interference), and report back about what their reported memory usage is in that scenario, just to rule out the possibility of anti-piracy video-playback-blocking stuff being involved there?

(It's also conceivable that Chrome's DRM-video-playback pipeline has some of the decoding happening in another process or bit of hardware that's simply not showing up in the task manager.  That feels sorta-likely, if they're still really only reporting 450MB of memory usage.)

In any case, it seems like this belongs in the Audio/Video component --> Reclassifying.

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #6)
> - Troubleshooting information: Go to `about:support`, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

(Not sure this is relevant/useful in this case; no harm in doing this, but not a priority.)

(In reply to Raul Bucata from comment #5)
> Here is the performance profile [...] And I have attached the memory report.

Thanks. The profile shows the hulu.com process growing to use ~300MB of RAM, which seems pretty reasonable for playing large high-quality video (and whatever fancy JS overhead Hulu is doing as part of that).

The attached memory report shows the Hulu process having 404.56 MB in "explicit allocations", and another 200MB or so of other allocations (mostly in js-main-runtime / js-main-runtime-gc-heap-committed).  So, assuming that those numbers are additive, that process is really responsible for ~600MB of memory usage, it looks like.

And then it shows the GPU process occupying 262MB of "explicit allocations" and 518MB under "gfx" (for webrender | textures).  So that process is responsible for 780MB of usage.

So: combined, those make up nearly 1400MB, which doesn't quite reach the 2.1GB shown in task manager, but makes up the bulk of it (and it's believable that the parent process & other misc. memory usage make up the rest. There might also be some shenenigans where Task Manager over-reports certain memory that's reserved but not used, etc.)

(Again, it's not obvious to me that this is an unusual amount of memory usage for this use-case.)

RE the comparison to Chrome here (which maxes out at around 450MB as shown in your screencast): Chrome never actually shows any video in that screencast.  I wonder if that was due to some sort of anti-piracy measure where they're detecting the screen-recording and turning off the video?  I can't tell if the video was blocked entirely from playing back in Chrome, vs. was only-displayed-on-the-physical-monitor-but-not-captured-in-the-screencast, vs. something else.

Raul, could you try Chrome on this site again, without any screen-recorder software running (to avoid any possible video-playback-interference), and report back about what their reported memory usage is in that scenario, just to rule out the possibility of anti-piracy video-playback-blocking stuff inadvertently reducing Chrome's memory usage there? 

(It's also conceivable that Chrome's DRM-video-playback pipeline has some of the decoding happening in another process or bit of hardware that's simply not showing up in the task manager.  That feels sorta-likely, if they're still really only reporting 450MB of memory usage.)

In any case, it seems like this belongs in the Audio/Video component --> Reclassifying.