1131467 - Can't seek in MSE demo player

Status: RESOLVED DUPLICATE of bug 1123669

(Core :: Audio/Video, defect)

Description

[Alfredo Yang (:alfredo)]

http://dash-mse-test.appspot.com/dash-player.html

I tried to rollback to 226601, the result is the same.
After performing seeking, Input() is called twice and then stopping to be called.
The OMX decode won't output any frame for just 2 inputs.

Comment 1

[Alfredo Yang (:alfredo)]

Another clue is: http://developer.android.com/reference/android/media/MediaCodec.html

My my understanding, QCT OMX needs to be configure as adaptive, or it needs to call MediaCodec->flush() after seeking.

Comment 2

[Blake Wu [:bwu][:blakewu]]

(In reply to Alfredo Yang from comment #0)
> http://dash-mse-test.appspot.com/dash-player.html
> 
> I tried to rollback to 226601, the result is the same.
> After performing seeking, Input() is called twice and then stopping to be
> called.
> The OMX decode won't output any frame for just 2 inputs.
Then we should make input() to be called more... :)
It seems MP4Reader should not expect any output for just 2 inputs. 
Let me check it.

Comment 3

[Alfredo Yang (:alfredo)]

From MediaCodec document:

"Once the client reaches the end of the input data it signals the end of the input stream by specifying a flag of BUFFER_FLAG_END_OF_STREAM in the call to queueInputBuffer(int, int, int, long, int). The codec will continue to return output buffers until it eventually signals the end of the output stream by specifying the same flag (BUFFER_FLAG_END_OF_STREAM) on the BufferInfo returned in dequeueOutputBuffer(MediaCodec.BufferInfo, long). Do not submit additional input buffers after signaling the end of the input stream, unless the codec has been flushed, or stopped and restarted. "

Since current code uses BUFFER_FLAG_END_OF_STREAM without flush(), it could be one reason.

BTW, this problem can be reproduced by normal video. It can't seek to other place after playing to end.

Comment 4

[Blake Wu [:bwu][:blakewu]]

(In reply to Alfredo Yang from comment #3)
> From MediaCodec document:
> 
> "Once the client reaches the end of the input data it signals the end of the
> input stream by specifying a flag of BUFFER_FLAG_END_OF_STREAM in the call
> to queueInputBuffer(int, int, int, long, int). The codec will continue to
> return output buffers until it eventually signals the end of the output
> stream by specifying the same flag (BUFFER_FLAG_END_OF_STREAM) on the
> BufferInfo returned in dequeueOutputBuffer(MediaCodec.BufferInfo, long). Do
> not submit additional input buffers after signaling the end of the input
> stream, unless the codec has been flushed, or stopped and restarted. "
> 
> Since current code uses BUFFER_FLAG_END_OF_STREAM without flush(), it could
> be one reason.
> 
> BTW, this problem can be reproduced by normal video. It can't seek to other
> place after playing to end.
Thanks for the info!
It looks this bug could be similar to Bug 1123669.

Comment 5

[Blake Wu [:bwu][:blakewu]]

The rootcause are 
1. mDrainComplete is not reset when flushing, so ProcessOutput[1] will not enter the loop to retrieve the decoded data.
2. mInputEOS is not reset when flushing, so no input data will be processed. 


[1]https://dxr.mozilla.org/mozilla-central/source/dom/media/fmp4/gonk/GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#174
[2]https://dxr.mozilla.org/mozilla-central/source/dom/media/fmp4/gonk/GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#54

Comment 6

[Blake Wu [:bwu][:blakewu]]

(In reply to Blake Wu [:bwu][:blakewu] from comment #5)
> The rootcause are 
> 1. mDrainComplete is not reset when flushing, so ProcessOutput[1] will not
> enter the loop to retrieve the decoded data.
> 2. mInputEOS is not reset when flushing, so no input data will be processed. 
> 
> 
> [1]https://dxr.mozilla.org/mozilla-central/source/dom/media/fmp4/gonk/
> GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#174
> [2]https://dxr.mozilla.org/mozilla-central/source/dom/media/fmp4/gonk/
> GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#54
I should put this comment in bug 1123669 since currently I only tested on local playback instead of MSE case. The rootcause might be different. Will MSE afterwards.

Comment 7

[Blake Wu [:bwu][:blakewu]]

After verifying the patch in bug 1123669 in MSE case, the problem in this bug is gone.