Closed Bug 1222201 Opened 4 years ago Closed 4 years ago

Video playback distortion, The right end of youtube video is stretched several pixels

Categories

(Core :: Audio/Video: Playback, defect, P1)

44 Branch
Unspecified
Windows 7
defect

Tracking

()

VERIFIED FIXED
mozilla45
Tracking Status
firefox43 --- unaffected
firefox44 + verified
firefox45 + verified
b2g-v2.5 --- fixed

People

(Reporter: alice0775, Assigned: jya)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

[Tracking Requested - why for this release]: regression of Video playback distortion


Video playback distortion, The right end of youtube video is stretched several pixels

See screenshot

Steps To Reproduce:
1. Open video ( e.g. https://www.youtube.com/watch?v=KKTGiNqUKUQ )
2. Select 480P
3. Seek at around 00:10

Actual Results:
The right end of youtube video is stretched several pixels


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=86d1b3a8aecb978a7e656e8c8018e227333d9ae5&tochange=b4401440ad83

Suspect: 8415ac131a72	Jean-Yves Avenard — Bug 1217226: P1. Use VideoInfo display size data rather than attempt to detect value in stream. r=cpearce
Flags: needinfo?(jyavenard)
And https://www.youtube.com/watch?v=Z5jyEphbGo4 480P around 00:05
Priority: -- → P1
Probably something with the the frame crop metadata.
From talking to roc, this is due to our dxva compositor not handling offsets. Which vp9 videos often uses
Flags: needinfo?(jyavenard)
@Ralph Giles:   The regression window is provided in comment 0. Btw, I got the same regression window
Milan - who fixes compositor bugs?
Flags: needinfo?(milan)
I have a suspicion on what's going on with the dimensions returned by WMF. I'll look into it later today. Still need to implement margins support with dxva
Assignee: nobody → jyavenard
Use calculated dimensions found in SPS rather than the values returned by the WMF.
Turned out that the attribute MF_MT_FRAME_SIZE is actually the stride size rather than the usable size and previously we would use the values returned by GetPictureRegion. I got incorrectly stirred by the name of the attribute and the name of the variables.
Attachment #8687833 - Flags: review?(cpearce)
Comment on attachment 8687833 [details] [diff] [review]
Only use container calculated dimensions

kind of forgot to do hg qnew and uploaded the big ffvpx one instead :)
Attachment #8687833 - Attachment is obsolete: true
Attachment #8687833 - Flags: review?(cpearce)
Use calculated dimensions found in SPS rather than the values returned by the WMF.
Turned out that the attribute MF_MT_FRAME_SIZE is actually the stride size rather than the usable size and previously we would use the values returned by GetPictureRegion. I got incorrectly stirred by the name of the attribute and the name of the variables.
Attachment #8687834 - Flags: review?(cpearce)
Comment on attachment 8687834 [details] [diff] [review]
Only use container calculated dimensions

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

Looks like we'll need a similar change to media/gmp-clearkey/0.1/WMFH264Decoder.cpp.
Attachment #8687834 - Flags: review?(cpearce) → review+
(In reply to Chris Pearce (:cpearce) from comment #10)
> Comment on attachment 8687834 [details] [diff] [review]
> Only use container calculated dimensions
> 
> Review of attachment 8687834 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks like we'll need a similar change to
> media/gmp-clearkey/0.1/WMFH264Decoder.cpp.

no it's fine there.
It calls wmf::GetPictureRegion(aMediaType, pictureRegion); which does the proper thing (or at least get the right value).

The alternative approach would be to re-add the use of GetPictureRegion().. I'm in two mind about it, as it guarantees that there's no regression over the earlier code which has worked fine for a long time now
Duplicate of this bug: 1222103
https://hg.mozilla.org/mozilla-central/rev/87b9a8debdad
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Tracking as this is a high end-user impact regression.
Jean-Yves, should we consider uplifting this to Aurora44? Thanks!
Flags: needinfo?(jyavenard)
Alice0775 White, could you please verify that this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(alice0775)
Comment on attachment 8687834 [details] [diff] [review]
Only use container calculated dimensions

Approval Request Comment
[Feature/regressing bug #]: 1222201
[User impact if declined]: Visual corruptions in MP4 data on windows (obvious when using YouTube)
[Describe test coverage new/current, TreeHerder]: In central for 2 weeks.
[Risks and why]: Low, however the fix may not be sufficient and there may be a need to revert the entire set of changes in the WMF which were made to support the intel hardware decoder (now disabled by default)
[String/UUID change made/needed]: None
Flags: needinfo?(jyavenard)
Attachment #8687834 - Flags: approval-mozilla-aurora?
(In reply to Ritu Kothari (:ritu) from comment #17)
> Alice0775 White, could you please verify that this issue is fixed as
> expected on a latest Nightly build? Thanks!

I cannot reproduce the problem on latest Nightly45.0a1 anymore.

https://hg.mozilla.org/mozilla-central/rev/47b49b0d32360fab04b11ff9120970979c426911
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 ID:20151130030228

But, of course, I can still reproduce the problem on Aurora44.0a2.

https://hg.mozilla.org/releases/mozilla-aurora/rev/7ea5152b84175b42bfe7519e450d24e546e014db
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20151129004009
Flags: needinfo?(alice0775)
(In reply to Alice0775 White from comment #19)
> (In reply to Ritu Kothari (:ritu) from comment #17)
> > Alice0775 White, could you please verify that this issue is fixed as
> > expected on a latest Nightly build? Thanks!
> 
> I cannot reproduce the problem on latest Nightly45.0a1 anymore.
> 
> https://hg.mozilla.org/mozilla-central/rev/
> 47b49b0d32360fab04b11ff9120970979c426911
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
> ID:20151130030228
> 
> But, of course, I can still reproduce the problem on Aurora44.0a2.
> 
> https://hg.mozilla.org/releases/mozilla-aurora/rev/
> 7ea5152b84175b42bfe7519e450d24e546e014db
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
> ID:20151129004009

Thank you for doing the verification! We will uplift the fix to Aurora44.
Comment on attachment 8687834 [details] [diff] [review]
Only use container calculated dimensions

This fix has been verified on Nightly, it makes sense to uplift to Aurora44.
Attachment #8687834 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
¡Hola Jean-Yves!

Verified with steps from https://bugzilla.mozilla.org/show_bug.cgi?id=1222103#c1

This works on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 ID:20151201030226 CSet: 66a6d7ec9534b9d7847b665142fef0dd87623768

¡Gracias!
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Reproduced with Nightly from 2015-11-05 under Windows 7 64-bit.
Verified fixed with Firefox 44 beta 4 (Build ID: 20151228134903) and latest Developer Edition 45.0a2 (from 2016-01-03), under Windows 7 64-bit and Mac OS X 10.11.
Depends on: 1244294
Flags: needinfo?(milan)
You need to log in before you can comment on or make changes to this bug.