nestegg_read_packet returns EOS if reading the block_duration or discard_padding hits EOS

RESOLVED FIXED in mozilla35

Status

()

Core
Audio/Video
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: kinetik, Assigned: kinetik)

Tracking

(Blocks: 1 bug)

Trunk
mozilla35
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
nestegg_read_packet successfully reads the final block, but if it hits an EOS on a call to ne_read_block_duration, ne_read_discard_padding, or ne_read_block_additions it will return EOS and WebMReader will not be able to use the final packet.

This is a regression from any/all of the following three nestegg commits:
https://github.com/kinetiknz/nestegg/commit/d46a8605
https://github.com/kinetiknz/nestegg/commit/1aae70ca
https://github.com/kinetiknz/nestegg/commit/dcd18d1f
(Assignee)

Comment 1

3 years ago
Should be fixed by https://github.com/kinetiknz/nestegg/commit/fe78d485aabf8339c9d2e033a0d37436c33370d9, but need to test Opus playback for regressions.
(Assignee)

Comment 2

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=68e746d26902
(Assignee)

Comment 3

3 years ago
Created attachment 8486805 [details] [diff] [review]
Don't treat EOS as fatal when reading optional block subelements in nestegg_read_packet
(Assignee)

Comment 4

3 years ago
Comment on attachment 8486805 [details] [diff] [review]
Don't treat EOS as fatal when reading optional block subelements in nestegg_read_packet

Green on try.
Attachment #8486805 - Flags: review?(cajbir.bugzilla)

Updated

3 years ago
Attachment #8486805 - Flags: review?(cajbir.bugzilla) → review+
(Assignee)

Comment 5

3 years ago
(In reply to Matthew Gregan [:kinetik] from comment #4)
> Green on try.

But this + bug 1064699 is orange because the tests check v.duration == 4.0 but with both patches applied we end up with a duration of 4.001 (root cause is bug 1065207).  seek.webm's frame rate is 30 FPS and the timecode durations alternate between 33ms and 34ms.  The last frame has a start time of 3.967 ans should be 33ms long, but we calculate it as 34ms because the preceding timecode was 3.933 (= 34ms duration).
(Assignee)

Comment 6

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/170ce237e4a0
(Assignee)

Comment 7

3 years ago
(In reply to Matthew Gregan [:kinetik] from comment #6)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/170ce237e4a0

I tweaked the tests for now, since this fix is more important.  The tweak references bug 1065207.
(Assignee)

Updated

3 years ago
Depends on: 1067762
https://hg.mozilla.org/mozilla-central/rev/170ce237e4a0
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
sorry had to back this out for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=48178648&tree=Mozilla-Inbound
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 10

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/bbeb7caa2cda
https://hg.mozilla.org/mozilla-central/rev/bbeb7caa2cda
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.