Closed Bug 846122 Opened 7 years ago Closed 7 years ago

[A/V] Seek doesn't work in WEBM video contents

Categories

(Firefox OS Graveyard :: Gaia::Video, defect, P2)

x86
Windows 7
defect

Tracking

(blocking-b2g:leo+, b2g18 fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- fixed

People

(Reporter: leo.bugzilla.gecko, Assigned: kinetik)

References

Details

(Keywords: regression)

Attachments

(4 files, 2 obsolete files)

When I try to seek while playing webm video clip, the player suddenly stopped and changed its screen to video list.
The problem is occured in all webm video clip that I have.
Attached video test video clip
Duplicate of this bug: 846121
I think that audio data is not decoded normally, so StateMachine generate event of EOS of audio stream.
Flags: needinfo?(leo.bugzilla.gecko)
blocking-b2g: --- → leo?
This works for me on my unagi with a v1.0.1 build (gaia d40dcdd1).  It looks like it's been fixed in the time between the initial report and now.  Please re-open if it continues to happen with a more recent build.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I tested V1.1 build and the problem still occurred.
This problem occur in every webm video clip that I have.
Status: RESOLVED → REOPENED
Flags: needinfo?(leo.bugzilla.gecko)
Resolution: WORKSFORME → ---
blocking-b2g: leo? → leo+
Keywords: regression
Chris^2, who can take a look at this?
Not sure what's going on there. In Nightly on Windows seeking into the middle of the test video work (in the range of about 17-21s), but seeking to other parts of the media fail. Maybe the Cues are corrupt?

+CC Matthew Gregan and Paul Adenot, who have more expertise in this area than I.
The Cues have entries for both the video and audio tracks.  What's happening is that we're selecting the CuePoint closest to the desired seek time, then rejecting it when the track does not match the requested seek track.

For example, with video as track 1 and audio as track 2, seeking to 1.004s on track 1:

    [...]
    | + Cue point at 2609021
    |  + Cue time: 1.000s at 2609023
    |  + Cue track positions at 2609027
    |   + Cue track: 1 at 2609029
    |   + Cue cluster position: 9014 at 2609032
    | + Cue point at 2609036
    |  + Cue time: 1.004s at 2609038
    |  + Cue track positions at 2609042
    |   + Cue track: 2 at 2609044
    |   + Cue cluster position: 9014 at 2609047
    [...]

nestegg selects the second CuePoint (which matches the target time exactly), then rejects the CuePoint because it is for the audio track (2).  This could be fixed by modifying ne_find_cue_point_for_tstamp to consider the target track.

The WebM spec says:

    Muxer Guidelines

    Muxers should treat all guidelines marked SHOULD in this section as MUST. This will foster consistency across WebM files in the real world.

    [...]
        WebM files SHOULD include a keyframe-only Cues element.
            The Cues element SHOULD contain only video key frames, to decrease the size of the file header.

So the question is whether a demuxer that encounters Cues for multiple tracks is permitted to reject them.  We only do so by accident.  Seeking in Chromium is also broken with similar observable behaviour.
Shelly,
Please co-work with Cervantes on fixing this issue.
Assignee: nobody → slin
I don't see the problem with other webm video clips, however, I do see the issue with your test sample(not everytime, but mostly 9 out of 10), could you provide more test files or more information?
Flags: needinfo?(leo.bugzilla.gecko)
Attached video another test file
Flags: needinfo?(leo.bugzilla.gecko)
I added another one. I have one more webm file that has same problem but it cannot be uploaded because it's over 4MB.
Attached patch possible fix (obsolete) — Splinter Review
This seems to work.
Attachment #735571 - Flags: review?(paul)
Assignee: slin → kinetik
Attachment #735571 - Flags: review?(paul) → review+
Failed test: https://tbpl.mozilla.org/php/getParsedLog.php?id=21842603&tree=Mozilla-Inbound#error0

The test image shows frame 0 and the reference image shows frame 249.
Attached patch patch v1 (obsolete) — Splinter Review
Handle search for cues correctly when it should terminate at the end of the range.  Refactor some code in to ne_find_cue_position_for_track, remove extraneous test of segment.cues.cue_point.head after calling ne_init_cue_points (which does the same check).

Videos linked from this bug and the video used in the failing reftest all work correctly with this version.  Mochitests pass locally.

Try push (just the failing test suite): https://tbpl.mozilla.org/?tree=Try&rev=79c45bad3078
Attachment #735571 - Attachment is obsolete: true
Attachment #738301 - Flags: review?(paul)
Attachment #738301 - Flags: review?(paul) → review+
Attached patch patch v1.1Splinter Review
Oops, patch v1 applied on top of patch v0.  This is the rollup that applies against m-c, carrying forward r+.
Attachment #738301 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/52169bf1e074
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
(In reply to leo.bugzilla.gecko from comment #5)
> This problem occur in every webm video clip that I have.

What tool are you using to produce the WebM files? It's probably worth filing a bug against that, as the way it produces Cues is of dubious value anyway.
(In reply to Matthew Gregan [:kinetik] from comment #21)
> (In reply to leo.bugzilla.gecko from comment #5)
> > This problem occur in every webm video clip that I have.
> 
> What tool are you using to produce the WebM files? It's probably worth
> filing a bug against that, as the way it produces Cues is of dubious value
> anyway.

Internal QE team created test contents of the project.
They said that they use AVS and Kirara to encode test contents.
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
Added B2G Video Suite Test Case #8582 [Video] Ability to use Seek feature on WEBM video clips in the Video App
You need to log in before you can comment on or make changes to this bug.