Enlarge OMX buffer size when the default size it too small

RESOLVED INVALID

Status

()

Core
Audio/Video: Playback
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: alfredo, Assigned: alfredo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
The input source could be larger than a single omx input buffer size.
So it needs to get enough omx buffers to handle this case.
(Assignee)

Comment 1

2 years ago
Created attachment 8697289 [details] [diff] [review]
handle_buffer_size_too_small
Attachment #8697289 - Flags: review?(sotaro.ikeda.g)
:alfredo, when does the situation happen? I checked ACodec and OMXCodec, but both seems not handle the situation.
Flags: needinfo?(ayang)
(Assignee)

Comment 3

2 years ago
During fixing bug 1224889, I found it happens while playing a high bitrate video; for some reasons, it is easier to reproduce it while seeking.
Flags: needinfo?(ayang)
(In reply to Alfredo Yang (:alfredo) from comment #3)
> During fixing bug 1224889, I found it happens while playing a high bitrate
> video; for some reasons, it is easier to reproduce it while seeking.

It sound wired, is it clear that one input data does not include multiple video frames?
Flags: needinfo?(ayang)
sync frame data could be larger than another frame's data, that might be a reason of it.
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> (In reply to Alfredo Yang (:alfredo) from comment #3)
> > During fixing bug 1224889, I found it happens while playing a high bitrate
> > video; for some reasons, it is easier to reproduce it while seeking.

:alfredo, Can we have the video file and valid information(STR device name) to reproduce it?
(Assignee)

Comment 7

2 years ago
I use flame-kk to test it. I'll email the test video link to you.
Flags: needinfo?(ayang)

Updated

2 years ago
Depends on: 1231257

Updated

2 years ago
No longer depends on: 1231257

Updated

2 years ago
Blocks: 1224889
(In reply to Alfredo Yang (:alfredo) from comment #7)
> I use flame-kk to test it. I'll email the test video link to you.

I tried to reproduce the symptom by applying bug 1231257, bug 1231690 Bug 1231939 with enabling OmxDecoderModule and latest master flame-kk. But I could not reproduce the symptom in comment 0 with the video you mentioned in the mail.

Following the STR
[1] Down load the video locally
[2] Open Video app
[3] Start playback the video
[4] Does a lot of seek during playback.
:alfredo, how often did you see the problem? Can you provide more detailed STR?
Flags: needinfo?(ayang)
(Assignee)

Comment 10

2 years ago
I found it when I'm testing patch in bug 1224889. Audio decoding doesn't have this problem, it happens on video decoding. Since video decoding in bug 1224889 is not solved yet, I think it can't reproduce with current m-c codes.

Maybe we should hold on this bug for a while. After bug 1224889 is solved, we can check this bug again.
What do you think?
Flags: needinfo?(ayang)
(Assignee)

Updated

2 years ago
Attachment #8697289 - Flags: review?(sotaro.ikeda.g)
Yea, it is a good idea. Since android does not handle this case, hit this situation could be a defect of another part or might cause another defect.
It seems ACodec force input port buffers of video decoder to be at least 64K bytes [1]. This could be why Android doesn't have this problem.

[1] http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/ACodec.cpp#2366
(In reply to John Lin [:jolin][:jhlin] from comment #12)
> It seems ACodec force input port buffers of video decoder to be at least 64K
> bytes [1]. This could be why Android doesn't have this problem.
> 
> [1]
> http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/
> ACodec.cpp#2366

Nice!
(Assignee)

Comment 14

2 years ago
(In reply to John Lin [:jolin][:jhlin] from comment #12)
> It seems ACodec force input port buffers of video decoder to be at least 64K
> bytes [1]. This could be why Android doesn't have this problem.
> 
> [1]
> http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/
> ACodec.cpp#2366

Thanks John!

Should we use large buffer as ACodec or multiple omx input buffers? I'm ok for both ways.
Any suggestion?
Flags: needinfo?(sotaro.ikeda.g)
It seems better to align to ACodec to prevent unexpected errors.
OMXCode also does similar things. OMXCodec::configureCodec() calls OMXCodec::setMinBufferSize() to extend input buffer size. kKeyMaxInputSize metadata is set by MediaExtractors.

>   if (meta->findInt32(kKeyMaxInputSize, &maxInputSize)) {
>        setMinBufferSize(kPortIndexInput, (OMX_U32)maxInputSize);
>    }

http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/OMXCodec.cpp#564
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Sotaro Ikeda [:sotaro] from comment #15)
> It seems better to align to ACodec to prevent unexpected errors.

It is for to prevent unexpected errors. Doing different things could cause another defect.
(Assignee)

Updated

2 years ago
Summary: Use multiple omx input buffers for large input source → Enlarge OMX buffer size when the default size it too small
(Assignee)

Comment 17

2 years ago
(In reply to Sotaro Ikeda [:sotaro] from comment #15)
> It seems better to align to ACodec to prevent unexpected errors.
> OMXCode also does similar things. OMXCodec::configureCodec() calls
> OMXCodec::setMinBufferSize() to extend input buffer size. kKeyMaxInputSize
> metadata is set by MediaExtractors.
> 
> >   if (meta->findInt32(kKeyMaxInputSize, &maxInputSize)) {
> >        setMinBufferSize(kPortIndexInput, (OMX_U32)maxInputSize);
> >    }
> 
> http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/
> OMXCodec.cpp#564

Thank you.
I'll rewrite the patch.
(Assignee)

Updated

2 years ago
See Also: → bug 1229363
(Assignee)

Comment 18

2 years ago
Merge patch to bug 1229363. So close this bug.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.