Closed Bug 919252 Opened 7 years ago Closed 7 years ago

[B2G][Helix][camera][dingyu]There is a strange line in the left of the video viewfinder when I play the video in horizontal

Categories

(Firefox OS Graveyard :: Gaia::Camera, defect, P2)

defect

Tracking

(blocking-b2g:-)

RESOLVED INVALID
blocking-b2g -

People

(Reporter: lecky.wanglei, Unassigned)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1

Steps to reproduce:

1.open the camera and take a video recording
2.touch to the thumbnail to check the video
3. make the phone in horizontal direction 
4. click the video file to play it 


Actual results:

4. there is a strange line in the left of the video viewfinder, when the video start playing

By the way the video file is played normally in Gellery app and Vide app


Expected results:

4. the video play normally
Severity: normal → blocker
blocking-b2g: --- → hd?
Priority: -- → P1
Attached file WP_20130306_005.mp4
Flags: needinfo?(wchang)
Vincent, not sure if this is something you can check or know who can?
Flags: needinfo?(wchang) → needinfo?(vlin)
Af first, I feel this may be related to rounding bug. We met it in gaia before. But when I investigate more about this bug, I find that the css calculation about width, height and transform are different between img and video element.

I cut exactly the same image and css to create this testing app(this attachment). After opened, you can see a line at the screen which is 1px shift between img element and video element. The css I use is:

      .VideoPoster, .VideoPlayer {
        position: absolute;
        left: 0; /* we position it with a transform */
        top:0;
        transform-origin: 0 0;

        transform: translate(352.4090909090909px,0px) rotate(90deg) scale(0.9090909090909091);
        width: 320px;
        height: 261.8181818181818px;

      }
      .VideoPlayer {
        background-color: black;
      }

The image element is under the video element. Image element's src is "VID_0014.jpg" and video element doesn't have any src setting.

Just open it, see the extra line.

This device is using partner's latest gecko build, the git commit hash is cd5c76e23dc73924b13bb26ae60954b64a9ae357. But I can't find the hg revision.
Hi  John:
   I cann't find the modify the git commit hash cd5c76e23dc73924b13bb26ae60954b64a9ae357, can you help to comfirm the change in 1.1hd version and uoload the change to the attachment?
Hi Lecky, 

I can't find it, too. I just dump the message from the /system/source.xml.
Hi John:
  Can you help to confirm the problem in hd version and give us the modify?
No, I can't. It is related to the implementation of img and video element. If I can provide you a patch, I will do it instead of write a testing app to show the bug.

BTW, Would you mind to test this test app in your device?? It is 100% reproducible in my helix device and very easy to catch that.
We may still need to wait for Vincent's investigation.
Hi John:
   I have test the test app and find the extra line in my helix device. Thank you!

Vincent:
   Can you give some addvice about this case?
Flags: sec-review?
In this testing app, I didn't write any JavaScript but few lines of "css". And those css are applied to both img and video element at the same time.
(In reply to lecky from comment #9)
> Hi John:
>    I have test the test app and find the extra line in my helix device.
> Thank you!
> 
> Vincent:
>    Can you give some addvice about this case?

Something I have to check for more details

1. Which version of Helix you found for this case? I need to reproduce this on the correct version.

(In reply to John Hu [:johnhu] from comment #3)
> Created attachment 810495 [details]
> simple app to reproduce it
> 
> Af first, I feel this may be related to rounding bug. We met it in gaia
> before. But when I investigate more about this bug, I find that the css
> calculation about width, height and transform are different between img and
> video element.
> 

Hi John,
Can you please tell me source location the camera app did for the css calculation about width, height and transform? I want to check more detail about you sad for the difference between img and video element. Thanks.
Flags: needinfo?(lecky.wanglei)
Flags: needinfo?(johu)
Hi Vincent,

The calculation is at setPlayerSize in video_player.js[1]. The poster is the img element and player is the video element. The visibility is at play function[2] which hides poster and shows player.


[1] https://github.com/mozilla-b2g/gaia/blob/3286df632d9a1c47b667e888be2a98838d972c17/shared/js/media/video_player.js#L316-L376
[2] https://github.com/mozilla-b2g/gaia/blob/3286df632d9a1c47b667e888be2a98838d972c17/shared/js/media/video_player.js#L162-L166
Flags: needinfo?(johu)
Hi Vincent:

   Our version of Helix is 1.1hd, the probability is 100%.
   wchang have our device, you can check with him, thanks!
Flags: needinfo?(lecky.wanglei)
Just for a memo.

We may provide a work around in gaia side which is to round all digitals under decimal point. But the outcome may have one pixel black at one of the edges.
(In reply to lecky from comment #13)
> Hi Vincent:
> 
>    Our version of Helix is 1.1hd, the probability is 100%.
>    wchang have our device, you can check with him, thanks!

I tried update the 20130924 image but can't reproduce this issue. This version of image is also the 1.1hd. Can you really point out what date of image release to Mozilla can reproduce it? Thanks.
(In reply to John Hu [:johnhu] from comment #14)
> Just for a memo.
> 
> We may provide a work around in gaia side which is to round all digitals
> under decimal point. But the outcome may have one pixel black at one of the
> edges.

Yes, From the information from :wachang, I realized how to reproduce it. Looked into the code and found setPlayerSize() got different containerWidth/containerHeight when opening the same recorded file in camera and gallery apps separately. I will keep looking into it.
Priority: P1 → P2
Hi Vincent:
   Have you find the reason why setPlayerSize() got different containerWidth/containerHeight when opening the same recorded file in camera and gallery apps separately?

Thans?
Flags: needinfo?(vliu)
Severity: blocker → normal
The line shows for a split second before the video is played. Not blocking here as minimal user impact but Vincent if your time permits, please look into it.

Please feel free to nominate it to koi? or 1.3? if you see any reason.
blocking-b2g: hd? → ---
Hi Wayne:

   Do you mean this bug will not fixed in 1.1hd? If it not plan to fix this bug in 1.1hd, can you give the plan for this bug?
   By the way, Though the line shows for a split second, but It's very easily to be seen by the users. I am very appreciate that it can be solved in 1.1hd

Thanks!
Sorry for late response.
I guess Vincent Liu is looking into this bug.

The position of image layer(before playing video) and video layer(after playubg video) should be the same. It seems the position of video layer was 1 line lower than image layer.
Flags: needinfo?(vlin)
Flags: needinfo?(wchang)
Flags: needinfo?(wchang)
Attached patch WIPSplinter Review
(In reply to lecky from comment #17)
> Hi Vincent:
>    Have you find the reason why setPlayerSize() got different
> containerWidth/containerHeight when opening the same recorded file in camera
> and gallery apps separately?
> 
> Thans?

Sorry to late response because I busy for other issues. A WIP might be a work around. Currently we have the flow in the below link when playing video file in camera app.

https://github.com/mozilla-b2g/gaia/blob/60bb46e0082284d46d74d6c043003b3ef89d4351/shared/js/media/video_player.js#L160

In player(), run |hidePoster()| at first to hide posted image element and then run |showPlayer();| to show video element. The issue happens at the time the hide action is not done but the video element pops up. Adding a window.setTimeout() for showPlayer to prevent two things overlapping. Can you tried this WIP if it is also works for you? Thanks.
Flags: needinfo?(vliu)
Hi Vincent:
   I have tried this WIP and it works. By the way, and I have tested that if I set the delay to 50ms, it still work. 
   
   According to the human eye's persistence of visionthe, the the video's fps >= 24, Human eye will feel the video is continuous. So I think if the time delay > 1/24s, It can work fine. 
   
   By the way Does this change will merge to 1.1hd?
blocking-b2g: --- → hd?
Flags: needinfo?(vliu)
(In reply to Wayne Chang [:wchang] from comment #18)
> The line shows for a split second before the video is played. Not blocking
> here as minimal user impact but Vincent if your time permits, please look
> into it.
> 
> Please feel free to nominate it to koi? or 1.3? if you see any reason.
blocking-b2g: hd? → -
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Flags: needinfo?(vliu)
You need to log in before you can comment on or make changes to this bug.