Closed Bug 1426818 Opened 8 years ago Closed 8 years ago

video actus

Categories

(Core :: Audio/Video: Playback, defect, P3)

57 Branch
defect

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.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
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.
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
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)
Yep, reaching out via LinkedIn. Will update when I hear back.
Flags: needinfo?(astevenson)
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)
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)
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)
Assignee: nobody → ayang
Flags: needinfo?(ayang)
Unfortunately Alfredo isn't able to work on this issue. Free for anyone to take on.
Assignee: ayang → nobody
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)
Bryce, do you mind working with Adam to get site access running this through mozregression?
Assignee: nobody → bvandyk
Flags: needinfo?(giles)
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.
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
Should be closed as invalid or won't fix
So our only option is to use google crome ?
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
Besides crome, it also works on Opera. But it wont work on Firefox. It is really sad.
(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.
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.
it fails just the same with microsoft edge...
(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
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.