Hi, thank you very much for your suggestions. I was able to prepare new
recording videos and debug logs, and opened a but report here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1619600
Kind regards,
--
Juan Navarro
Kurento maintainer & developer
j1elo @ Twitter <https://twitter.com/j1elo> / GitHub
<https://github.com/j1elo>
On 2/3/20 11:09, Alexandros Chronopoulos wrote:
Hi Juan,
One thing you could try out is to remove the audio sandbox and retest. In
order to do that, please go in *about:config* page, find the pref *media.*
*cubeb.**sandbox* and flip it to false. Then restart Firefox and retry.
This will give us an indication of where the problem might be. In order to
investigate further, a good idea is to capture Firefox logs. For doing
that, first please restore the audio sandbox (by flipping the pref to true
and restarting) and then follow the instructions here
<https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging>
but replace the MOZ_LOG env with the following:
*set MOZ_LOG=timestamp,cubeb:5,MediaTrackGraph:5*
Please note that this level of logging will affect the performance of the
audio playback so it might affect your scenario too. If it makes impossible
for you to test or the error does not reproduce try to decrease the log
level to something:
*set MOZ_LOG=timestamp,cubeb:4,MediaTrackGraph:4*
It is also a good idea to open a bug in Bugzilla and continue the
discussion there.
Thank you in advance!
On Fri, Feb 28, 2020 at 7:17 PM Juan Navarro <[email protected]> wrote:
After writing that email I realized that the stuff about FFmpeg could be a
bit confusing, so here is some clarification:
In principle, FFmpeg runs optionally to capture and record both video and
audio from inside the container, to let us "see" what happened inside. When
the recording is ENABLED, the described problem does NOT happen. This led
me to test what would happen if the recording is *disabled* but the
container started up with a dummy FFmpeg instance that would just capture
from PulseAudio and just discard the data, and that one is the "ffmpeg -f
null null.out" command that I showed. BTW, this test confirmed that indeed,
as long as audio is being captured from PulseAudio, the playback issue
doesn't occur in Firefox.
Now I've done a different test: removed the dummy FFmpeg capture, and
instead modified the normal recording command. Now we compare what happens
if recording either video only, or video+audio. This has the effect we can
imagine: video-only recording shows the playback issue in Firefox, and
video+audio recording somehow makes the issue disappear.
You can see here a video+audio recording, showing correct behavior:
https://www.dropbox.com/s/cf1370cta1zd5k6/firefox-pulseaudio-short-ok.mp4?dl=0
And here a video-only recording, showing the playback issue:
https://www.dropbox.com/s/je9wqlw5b76u2xe/firefox-pulseaudio-short-err.mp4?dl=0
Later I tested with a longer video and this helped to explain the problem!
Seems that, when the issue happens, *playback works fine in the long term
but it struggles during the first 5 seconds*. We couldn't see that with the
shorter test videos, because they happened to be 5 seconds long!!
Here we see a video+audio recording with a longer test video, correct
behavior:
https://www.dropbox.com/s/j79p6lu37qsvc78/firefox-pulseaudio-long-ok.mp4?dl=0
And here a video-only recording with the larger file, playback issue
happens:
https://www.dropbox.com/s/p9bv11jlvx3mybu/firefox-pulseaudio-long-err.mp4?dl=0
So, how come having another process grabbing audio from PulseAudio can
have such effect on the media playback in Firefox? What can be done to
further troubleshoot this issue?
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
