Closed
Bug 1113370
Opened 10 years ago
Closed 10 years ago
MP4Demuxer thinks video starts at 0.083333 instead of 0
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
RESOLVED
INVALID
People
(Reporter: bholley, Unassigned)
References
()
Details
Attachments
(1 file)
1006.87 KB,
video/mp4
|
Details |
This affects the AppendVideo and AbortVideo tests in the MSE conformance suite.
The tests do this:
test.prototype.onsourceopen = function() {
var stream = StreamDef[streamName];
var runner = this.runner;
var sb = this.ms.addSourceBuffer(stream.type);
var xhr = runner.XHRManager.createRequest(stream.src, function(e) {
var data = xhr.getResponseData();
function updateEnd(e) {
runner.checkEq(sb.buffered.length, 1, 'Source buffer number');
runner.checkEq(sb.buffered.start(0), 0, 'Range start');
runner.checkApproxEq(sb.buffered.end(0), stream.duration, 'Range end');
...
And the result of sb.buffered.start(0) is 0.083333. This comes from SourceBuffer::GetBuffered, which basically goes straight to MP4Reader, and then straight to the demuxer. I get a bit lost down there, but it looks like the problem is somewhere around Index::ConvertByteRangesToTimeRanges.
Somebody who knows more about libstagefright should probably take over here.
Reporter | ||
Comment 1•10 years ago
|
||
Test video from the suite.
Reporter | ||
Comment 2•10 years ago
|
||
Matt is going to look at this today.
Flags: needinfo?(matt.woodrow)
Comment 3•10 years ago
|
||
The video appears to have a timescale of 24, and all the frames have a composition time offset of 2.
1/24 * 2 = 0.083333.
It doesn't appear to have an edts box, and I can see anything else that would move our first sample to timestamp 0.
Comment 4•10 years ago
|
||
MP4Dump of the file: http://pastebin.mozilla.org/8066716
Flags: needinfo?(matt.woodrow)
Updated•10 years ago
|
Priority: -- → P2
Reporter | ||
Comment 5•10 years ago
|
||
Ok - so then presumably chrome just ignores the composition time offset? Should we raise this with them?
Comment 6•10 years ago
|
||
(In reply to Bobby Holley (Busy with media, don't ask for DOM/JS/XPConnect things) from comment #5)
> Ok - so then presumably chrome just ignores the composition time offset?
> Should we raise this with them?
We can't do that, videos frequently use these offsets to reorder frames.
It would be very interesting to know how chrome parses this file.
Comment 7•10 years ago
|
||
This is an old file and therefore an invalid test. Chrome has a work around that probably pre-dates the edts.elst spec.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•