Closed
Bug 1426818
Opened 8 years ago
Closed 8 years ago
video actus
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
RESOLVED
INVALID
People
(Reporter: andrej8anubis, Assigned: bryce)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557
Steps to reproduce:
At our company we use actus in web page for video streaming html5, and video does not work. There is black window instead video, saying "loading..." or "buffering...". More about actus is on link:
http://actusdigital.com/products/actus-view/
http://actusdigital.com/products/
I try in settings for firefox: enable disable DRM, clear cach, older version 56.0.2, curently we are using 57.0.2 64 bit, windows 7 and 10 64 bit. It does not work. It works in google crome.
I do not to install crome for everyone. But I can not show you the page, sorry.
Actual results:
There is black window instead video, saying "loading..." or "buffering...".
Expected results:
Video should be seen.
In fact, the team of engineers that deployed actus recommended that we use crome,
because firefox has issues. I hope that will change.
Updated•8 years ago
|
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Comment 2•8 years ago
|
||
Hi hombre83,
Thanks for filing this bug.
Can you provide a link of actus video or email me the access information? So we can check it.
Of course I can not give you access to company internal server, on the outside
we do not have visible this video. Just links above to company (actus) that provides us
with the solution. They told us that it is html5. Sorry, I do not know how to help more.
Comment 4•8 years ago
|
||
Hi Mike!
Is this something your team can help contact actusdigital[1] to see how we help them make their products work in Firefox?
[1]http://actusdigital.com/products/
Flags: needinfo?(miket)
Priority: -- → P3
Comment 5•8 years ago
|
||
Sure thing, Blake.
Adam, would you be able to try to start a conversation between Actus and Blake's team, so we can try to understand the technical issues behind this bug? Thanks.
Flags: needinfo?(miket) → needinfo?(astevenson)
Comment 6•8 years ago
|
||
Yep, reaching out via LinkedIn. Will update when I hear back.
Flags: needinfo?(astevenson)
Comment 7•8 years ago
|
||
Heard back from Actus. They provided a demo for us to test with.
Mike - I shared the credentials with you by email. Can you take a look please?
Flags: needinfo?(miket)
Comment 8•8 years ago
|
||
Using the credentials from Adam (thanks btw!), I bisected this down to:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91c2b9d5c1354ca79e5b174591dbb03b32b15bbf&tochange=938ce16be25f9c551c19ef8938e8717ed3d41ff5
But... that's still a lot of changes. Blake, is there someone who can look further? We can email them credentials to the test server provided by actus.
Flags: needinfo?(miket) → needinfo?(bwu)
Comment 9•8 years ago
|
||
Please email :alfredo (Alfredo Yang) credentials and we will take over from here.
Thanks for your team's help!
Ni Alfredo to be on the same page.
Flags: needinfo?(bwu) → needinfo?(ayang)
Updated•8 years ago
|
Assignee: nobody → ayang
Flags: needinfo?(ayang)
Comment 10•8 years ago
|
||
Unfortunately Alfredo isn't able to work on this issue. Free for anyone to take on.
Assignee: ayang → nobody
Comment 11•8 years ago
|
||
Ralph, can you help find someone to look at the range in Comment #8 to maybe narrow down the 57 regression? Thanks.
Flags: needinfo?(giles)
Comment 12•8 years ago
|
||
Bryce, do you mind working with Adam to get site access running this through mozregression?
Assignee: nobody → bvandyk
Flags: needinfo?(giles)
| Assignee | ||
Comment 13•8 years ago
|
||
On it.
| Assignee | ||
Comment 14•8 years ago
|
||
I wonder if bug 1300296 is the thing within that range that had an impact. I'm noticing that the code added there is detecting a number of demuxed video frames as incorrectly labelled as not being keyframes when inspection suggests they are. I wouldn't have thought that alone would cause the bustage, so I'll keep looking, but it suggests that there may be issues with the video stream.
Comment 15•8 years ago
|
||
Safari won't play this stream either (same for Quicktime once I extracted the content)
Apple VideoToolbox is too, unable to decode this content (it returns kVTVideoDecoderBadDataErr)
FFmpeg somehow manages to decode this.
On Windows, it works with the software decoder.
I would close this bug as invalid. The encoding is bad.. you should report the problem to actus. I doubt it's them however, more likely the encoder was used or configured (from Mainconcept MP4 Video Media Handler)
We wouldn't have a way to fix this problem anyway, as we have no control on what the system H264 decoder can actually do
Comment 16•8 years ago
|
||
Should be closed as invalid or won't fix
| Reporter | ||
Comment 17•8 years ago
|
||
So our only option is to use google crome ?
| Assignee | ||
Comment 18•8 years ago
|
||
Elaborating on my and :jya's comments above:
- The check I mentioned in comment 14 is the reason this is happening. However, the rejection is valid here as the stream is malformed.
- This previously worked on some systems as certain decoders will be tolerant of the malformed data (as noted in comment 15). However, given that we use decoders present on systems we're running on, we don't want to roll the dice on if they're tolerant or not.
- The stream appears to be storing data in NAL access unit delimiters (AUD), rather than using the AUDs to delimit other NALs which should contain the data. This is the issue with the encoding mentioned above.
As noted above, the content should be re-encoded to avoid this issue.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 19•8 years ago
|
||
Besides crome, it also works on Opera. But it wont work on Firefox. It is really sad.
| Assignee | ||
Comment 20•8 years ago
|
||
(In reply to hombre83 from comment #19)
> Besides crome, it also works on Opera. But it wont work on Firefox.
This is likely due to shared components between Opera and Chrome.
As noted in comment 15 and comment 18, the stream is malformed. Again, some decoders may be able to handle a non-spec stream, but relying on such behaviour is dangerous.
Comment 21•8 years ago
|
||
According to ffmpeg folks, such bad muxing was often seen with data converted from annex b. All the data is put in a single NAL.
Comment 22•8 years ago
|
||
it fails just the same with microsoft edge...
| Reporter | ||
Comment 23•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #22)
> it fails just the same with microsoft edge...
that is probably why most people do not use ti
Comment 24•8 years ago
|
||
Safari won't play it either.
The problem isn't with the actus player (unless it encode things)... It's your video, they are badly encoded, breaking specs and no browsers other than chrome based one will play them...
You can continue blaming the browsers for not playing your corrupted content, or you can fix your encoding.... Remuxing your files so that they work everywhere isn't a hard thing to do....
Or talk to Mainconcept, seeing they are those who encoded that thing.
You need to log in
before you can comment on or make changes to this bug.
Description
•