Closed Bug 994889 Opened 10 years ago Closed 10 years ago

[B2G][Tarako][Browser] Youtube vidoes are being stretched while playing

Categories

(Core :: Audio/Video, defect)

28 Branch
ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- verified
b2g-v1.4 --- wontfix

People

(Reporter: jschmitt, Assigned: sotaro)

References

()

Details

Attachments

(5 files, 3 obsolete files)

Description:
The bottom of Youtube vidoes are being stretched

Repro Steps:
1) Update a Tarako to BuildID: 20140410004001
2) Open the Browser app
3) Proceed to youtube.com
4) Select any video
5) Play 

Actual:
Youtube vidoes are stretched and distorted

Expected:
Youtube vidoes play fine and not stretched

1.3 Environmental Variables:
Device: Tarako 1.3 MOZ
BuildID: 20140410004001
Gaia: 022b03a57e4b8c697a6066961e7581d07eb99305
Gecko: b9dba13d50a9
Version: 28.1
Firmware Version: Sp6821a

Notes:
Repro frequency: 100%
See attached: video clip
I was unable to repro this issue on 1.3 Buri build

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140408004002
Gaia: 0a7a50129995f080c1df4d807a2334701701e8ed
Gecko: e3fca8c23e1d
Version: 28.0
Firmware Version: V1.2-device.cfg
Hi Josh, I don't see a video clip and I was unable to reproduce what you were seeing.  Could you attach the video clip please?
Flags: needinfo?(jschmitt)
The video clip is in the URL, but I don't see clearly how the video shows that there's a bug here.
Component: Gaia::Browser → Video/Audio
Product: Firefox OS → Core
Version: unspecified → 28 Branch
Attached image Stretching.png
Flags: needinfo?(jschmitt)
(In reply to Jason Smith [:jsmith] from comment #3)
> The video clip is in the URL, but I don't see clearly how the video shows
> that there's a bug here.

I have attached an image of the same Youtube vidoes being played on the Tarako device, I highlighted the area where the stretching is occurring at for more visibility.
Still can't see the bug here.

Can you provide a direct link to a youtube URL that reproduces this bug?
Flags: needinfo?(jschmitt)
(In reply to Jason Smith [:jsmith] from comment #6)
> Still can't see the bug here.
> 
> Can you provide a direct link to a youtube URL that reproduces this bug?

Here is the link to the youtube video

https://www.youtube.com/watch?v=7WNdMwM_oFQ
Flags: needinfo?(jschmitt)
Attached image screenshot_1
the bug can be seen with any videos, look at the bottom of the screen - this screenshot shows it very clear
Ok - the screenshot in comment 8 makes this bug look clear.

This is potentially bad because the bottom part of the video is rendering incorrectly. If we intend to support h264 video content on Tarako, then we need to fix this (especially if we want YouTube support).
blocking-b2g: --- → 1.3T?
ni? peter
Flags: needinfo?(pchang)
It looks very similar to Bug 850566.
Flags: needinfo?(pchang) → needinfo?(chung)
I highly suspect it is a texture coordinate things. Let me try to repro first.
Flags: needinfo?(chung)
blocking-b2g: 1.3T? → 1.3T+
(In reply to Chiajung Hung [:chiajung] from comment #12)
> I highly suspect it is a texture coordinate things. Let me try to repro
> first.

The texture coordinate seems correct...
Chiajung, take it bravely!
Assignee: nobody → chung
Attached video Converted raw image
This seems a codec related bug, the attachment is a frame dumped by gdb before composition. I convert it from NV12 format to RGBA8 format by 7-yuv. To view the image, you may need a raw image viewer.
Assignee: chung → nobody
I dumped both content buffer and compositor buffer, the content is both corrupted, please help to check.
Flags: needinfo?(mchen)
Eric, please help to comment
Flags: needinfo?(mchen) → needinfo?(echou)
Sotaro, this looks like very similar to Bug 850566, could you assist with taking a quick look? Feel free to tell me if you don't have enough bandwidth. Thank you.
Flags: needinfo?(echou) → needinfo?(sotaro.ikeda.g)
Okey, I will take a look.
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
Temporary patch to add logout around video size info.
Flags: needinfo?(sotaro.ikeda.g)
Actual video size is (w=320,h=180). But from the log, it is rendered as (w=320,h=180).

> 04-17 02:02:42.608  2864  2887 I GonkOmx : ImageHost::Composite() 2 textureSize.width 320 textureSize.height 192
The followins are log of OmxDecoder::SetVideoFormat(). This calculation seems incorrect. It get video size by using pre ICS ways and get wrong value. "192" is decoded video buffer height since ICS. It is not valid decoded video height.

> 04-17 02:02:40.058  3024  3085 I GonkOmx : OmxDecoder::SetVideoFormat()_E
> 04-17 02:02:40.058  3024  3085 I GonkOmx : OmxDecoder::SetVideoFormat() 1 width 320 height 180
> 04-17 02:02:40.058  3024  3085 I GonkOmx : OmxDecoder::SetVideoFormat() 2 crop_left 0 crop_top 0 crop_right 319 crop_bottom 179
> 04-17 02:02:40.058  3024  3085 I GonkOmx : OmxDecoder::SetVideoFormat() 3 width: 320 height: 192 component: OMX.sprd.mpeg4.decoder format: 21 stride: 320 sliceHeight: 192 rotation: 0
> 04-17 02:02:40.058  3024  3085 I GonkOmx : OmxDecoder::SetVideoFormat()_X
Confirmed the fix on v1.3t tarako.
Attachment #8408308 - Attachment description: patch - Fix how to get video size from OMXCodec → patch for v1.3t - Fix how to get video size from OMXCodec
Fix nits and add some comments.
Attachment #8408308 - Attachment is obsolete: true
Fix blank.
Attachment #8408319 - Attachment is obsolete: true
Update comments.
Attachment #8408321 - Attachment is obsolete: true
Assignee: nobody → sotaro.ikeda.g
Attachment #8408323 - Flags: review?(cajbir.bugzilla)
Comment on attachment 8408323 [details] [diff] [review]
patch v3 - Fix how to get video size from OMXCodec

Review of attachment 8408323 [details] [diff] [review]:
-----------------------------------------------------------------

Does something similar need to be done with the Android code?

::: content/media/omx/OmxDecoder.cpp
@@ +637,5 @@
> +                                          &crop_top,
> +                                          &crop_right,
> +                                          &crop_bottom)) {
> +    mVideoWidth = crop_right - crop_left + 1;
> +    mVideoHeight = crop_bottom - crop_top + 1; 

Remove trailing whitespace.
Attachment #8408323 - Flags: review?(cajbir.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/52a236cf50bd
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Fixed on todays 1.3T build.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140428014001
Gaia: 8895b180ed636069473703d0e7b73086989601ce
Gecko: 7caf4b5abfce
Version: 28.1
Firmware Version: sp6821
Blocks: 1077235
[Blocking Requested - why for this release]: Bug 1077235 is nominating to b2g-v1.4.
blocking-b2g: 1.3T+ → 1.4?
v1.4 is EOL
blocking-b2g: 1.4? → ---
You need to log in before you can comment on or make changes to this bug.