1508501 - After seeking to start position, demuxer can't get the first sample

Status: RESOLVED DUPLICATE of bug 1505250

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

Description

[Alastor Wu [:alwu]]

https://treeherder.mozilla.org/logviewer.html#?job_id=212739779&repo=try&lineNumber=379625
https://treeherder.mozilla.org/logviewer.html#?job_id=212739767&repo=try&lineNumber=387198
https://treeherder.mozilla.org/logviewer.html#?job_id=212739755&repo=try&lineNumber=378621
https://treeherder.mozilla.org/logviewer.html#?job_id=212739723&repo=try&lineNumber=389654

We request to do seek to the start position [1], and then request audio data [2]. However, even if MFR's seek was success, demuxer still can't get the first data and returns EOS to us.

[1] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/dom/media/MediaDecoderStateMachine.cpp#903

[2] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/dom/media/MediaDecoderStateMachine.cpp#911

Comment 1

[Alastor Wu [:alwu]]

Hi, Jya,

I found that FLAC demuxer would incorrectly return EOS when resource is fetching data too slowly [1].

In the log, you can see the previous sample it returned is [185759,197368]
> MediaDecoderStateMachine[0xdf4e1800] Decoder=e7f91190 OnAudioDecoded [185759,197368]

However, for `flac-s24.flac`, that sample is apparently not the last frame. The last frame should be [3993832,4040271]. In addition, this sample is also weird, because when I used `ffprobe` to check the sample inside [2], the sample should be look like [185759,278638]. I don't know why the sample we demuxed was so short.

I looked our code and saw that we would return EOS if we can't read enough size from resource [3]. If resource is still fetching data, that would cause unexpected EOS.

Do you have any idea about that?

Thank you.

[1] https://pastebin.com/raw/b2Ak7b9A
[2] 
{
  "codec_type": "audio",
  "stream_index": 0,
  "pts": 16384,
  "pts_time": "0.185760",
  "dts": 16384,
  "dts_time": "0.185760",
  "duration": 8192,
  "duration_time": "0.092880",
  "size": "21324",
  "pos": "51330",
  "flags": "K_"
}
[3] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/dom/media/flac/FlacDemuxer.cpp#273

Comment 2

[Jean-Yves Avenard [:jya]]

(In reply to Alastor Wu [:alwu] from comment #1)
> Hi, Jya,
> 
> I found that FLAC demuxer would incorrectly return EOS when resource is
> fetching data too slowly [1].
> 
> In the log, you can see the previous sample it returned is [185759,197368]
> > MediaDecoderStateMachine[0xdf4e1800] Decoder=e7f91190 OnAudioDecoded [185759,197368]
> 
> However, for `flac-s24.flac`, that sample is apparently not the last frame.
> The last frame should be [3993832,4040271]. In addition, this sample is also
> weird, because when I used `ffprobe` to check the sample inside [2], the
> sample should be look like [185759,278638]. I don't know why the sample we
> demuxed was so short.
> 
> I looked our code and saw that we would return EOS if we can't read enough
> size from resource [3]. If resource is still fetching data, that would cause
> unexpected EOS.

the scenario you describe can't occur.

Reading the MediaResource is blocking. The only time the MediaResource will return less data than requested is when the MediaResource have reached EOS and there's no more data to fetch.

So you can't have an unexpected EOS because it's too slow or we're still fetching data. If you get EOS, there's nothing more to read and there's no point trying again.

Comment 3

[Alastor Wu [:alwu]]

Will fix this issue in bug 1505250.