#12460 closed bug (fixed)
HTML5 audio/video support
Reported by: | ttcoder | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Following up from my offshoot comment in #12423:
When using Web+ on youtube (any channel I tried, including -- what else -- the TTSystems channel 8-), I have...
- video problems (reproducible only for me?)
- garbled audio
It remains to be seen if the regression is general or not
Change History (12)
comment:1 by , 9 years ago
follow-up: 6 comment:2 by , 9 years ago
Do you have a good reproducible testcase (e.g. a website URL) for the memory leak? Had no luck trying to reproduce it here so far with e.g. playing HTML5 video on youtube...
comment:3 by , 9 years ago
Summary: | HTML5 support → HTML5 audio/video support |
---|
- Renaming the ticket because HTML5 is so much more than just the audio and video elements
- As for the audio problem, mismatched formats is also my best guess so far. It may be that I missed one change in the API when adjusting the ffmpeg media plugin to work with ffmpeg 2.8. I don't think it is specific to WebPositive (which only sends the bytes to the media kit). Compiling others audio/video apps with gcc4 and ffmpeg 2.8 would allow to test that.
comment:4 by , 9 years ago
A test case that (apparently) exhibits a 32 vs 16 bit sampling mismatch:
Black screen/view, garbled audio. Oddly, memory usage is fairly stable across the board in that case
comment:5 by , 9 years ago
A test case that is more general (on this computer at least), where memory usage grows super fast and I have a few seconds to react and close the tab, or kill W+, and even after that the memory is not reclaimed (until I reboot):
- http://www.youtube.com/embed/nLtmEjqzg7M (no man's sky trailer)
This is the behavior I see on all (other) videos I tried so far. Good idea about compiling other apps against gcc4 for testing purposes, could be a learning experience :-)
comment:6 by , 9 years ago
Replying to jua:
Do you have a good reproducible testcase (e.g. a website URL) for the memory leak? Had no luck trying to reproduce it here so far with e.g. playing HTML5 video on youtube...
Try the video link in the description for ticket #11384. It won't play and pegs memory usage every time using x86_gcc2. 64 bit appears to work ok, using the older Web+ and ffmpeg.
comment:7 by , 9 years ago
About the memory leak: Fixed in hrev49843, which plugs the memory leak and also brings further performance improvements. Please note that due to the new alpha mask caching, you can see app_srver grow by up to 8 MiB which are not free'd when Web+ is quit, that is because a regular time-based cache cleanup is not yet implemented.
Not closing this ticket, the remaining problem is the garbled audio... that's most probably due to the new ffmpeg version, maybe PulkoMandy can take a look at it.
comment:9 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Reopening as it's still not working. What I did in hrev49844 fixes "playfile" built for gcc4, that was an easy one to build for the other arch on my system. However, there are still issues with youtube videos.
comment:10 by , 9 years ago
Confirming; video is (unexpectedly?) fixed by that changeset, it seems to work 100% here now.
Sound, however, is still corrupt.. But in a 'different' way now: it now goes "klik klik klik". Oddly, the loudness of the "kliks" is constant, even if I change the master volume (in the deskbar). If I run Cortex to look at the Web+ connection to the mixer (not sure how useful that is..) I see it's a 32 bit float connection, 44100 Hz, little endian.
Edit: a newer hrev fixed sound a few days ago by invoking the swr_xxx() ffmpeg function, but as pulkomandy posted in another ticket there are still issues with video playing at 2x (pts/dts issue).
comment:12 by , 9 years ago
I just tested the difference on my Asus EEE901.
Sound is perfect in youtube now. Audio didn't even drop out once, even though the video was choppy due to hardware / accelerant constraints.
Replying to pulkomandy:
With a few more hours usage, I can be more specific now: 1) when attempting HTML5 playback, the memory usage shoots up explosively (the deskbar replicant goes from blue to red in 3 or 4 seconds) and most of that memory usage 'explosion' is indeed not freed, even after quitting W+ the app_server still consumes 600 MB instead of 15 MB 2) I've never seen that before: whatever the HTML5 memory usage was before (hrev of a couple weeks ago) it was always freed (even in app_server) when quitting Web+ 3) That memory usage problem might be just a consequence of the second problem (garbled audio) so I'll wait for that first ; and HTML5 is not all that high a priority for me, so if it's the only one that leaks memory I'll wait some more to file a ticket on that, let's take these problems one at a time =)
Actually we might have a shot at finding a 'shortcut' for fixing this. Explaining:
From my past experiences with mis-matching sample formats (yea I do that a lot *g*), the audio I get on e.g. the TTSystems channel sounds like 32 bit samples are being read as 16 bit samples. It could be something else (endianness mismatch, signedness mismatch..) but I from what I hear, Dane's voice is faintly audible if you listen carefully, though it's drowned into a lot of white noise. That clearly sound to me like 32 vs 16 bit mismatch. Maybe that hints at the problem ?