videoWidth & videoHeight should always reflect the display width/height specified in the container. |
||||||||||||||||||||||||||||||||
Issue description
Chrome Version : Version 50.0.2661.37 beta (64-bit)
URLs (if applicable) :
OS version :
Audio/Video format (if applicable): WebM for sure. Should probably check for consistency with MP4.
Behavior in Firefox (if known): Firefox appears to always reflect the display width/height.
Video issue, Audio issue, both, neither? Video.
Flash or HTML5? HTML5. Behavior also seems to differ between src= and MSE.
What steps will reproduce the problem?
Play each of the attached files using src= and MSE and notice that videoWidth & videoHeight do not always match the values of the DisplayWidth and DisplayHeight fields specified in the container.
What is the expected result?
mono-src size is 640x480
mono-downsized size is 640x240
stereo-no-scaling size is 640x240
stereo-with-scaling is 640x480
What is the actual result?
For src= playback:
mono-src size is 640x480
mono-downsized size is 1280x480
stereo-no-scaling size is 640x480
stereo-with-scaling is 320x480
I haven't had time to test this with MSE content, but I'm pretty sure the behavior is different because MSE uses a different container parser.
Any additional information (anything else which may help us debug the
issue)?
I generated the test content with ToT ffmpeg modified with the attached patch and the following command-lines.
./ffmpeg -y -f lavfi -i "color=size=640x480,drawtext=text=TOP %{n}:fontsize=50:fontfile=FreeSerif.ttf:fontcolor_expr=ff0000:x=0:y=(h-text_h)/4:x=(w-text_w)/2,drawtext=text=BOTTOM:fontsize=50:fontfile=FreeSerif.ttf:fontcolor_expr=00ff00:x=0:y=(h-text_h)*3/4:x=(w-text_w)/2,drawbox=h=ih/2:color=ffff00,drawbox=y=ih/2:h=ih/2:color=ff00ff" -t 5 mono-src.webm
./ffmpeg -y -i mono-src.webm -metadata:s:v:0 stereo_mode=top_bottom -vcodec copy stereo-no-scaling.webm
./ffmpeg -y -i stereo-no-scaling.webm -metadata:s:v:0 stereo_mode=0 -vcodec copy mono-downsized.webm
./ffmpeg -y -i stereo-no-scaling.webm -vcodec copy -metadata:s:v:0 no_stereo_div=1 stereo-with-scaling.webm
,
Apr 12 2016
I am able to repro this bug. I think it's more like a blink bug instead of video bug. can somebody in blink team take a look?
,
Apr 12 2016
download attached repro videoSize.htm file and the 4 media files in original bug. load videoSize.htm in Chrome, for each video, the container width and height are expected to be the same as videoWidth and videoHeight, but actually they are not the same except the 1st one.
,
May 18 2016
acolwell@ - Friendly ping! Any update on this bug? Is this issue still seen on latest chrome beta M51-51.0.2704.47 ? Could you please respond for the comment #4 and kindly update this bug with latest behavior. Thanks!
,
Jun 27 2016
acolwell@ : Could you please update the thread according to the above comment #4, and expected output to triage it further.
,
Jun 27 2016
Based on #4, this looks confirmed.
,
Jul 22 2016
,
Jul 23 2016
videoWidth and videoHeight come from WebMediaPlayer::naturalSize(), so if there's a bug (not respecting DisplayWidth and DisplayHeight?) here I think it must be somewhere in or below WMPI?
,
Aug 9 2016
,
Aug 9 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 9 2017
Still a good p2. I'm just overloaded.
,
Aug 9 2017
chcunningham@, can you assign it to appropriately? This bug still repro in Chrome 62
,
Aug 15 2017
change status to available. please feel free to assign appropriately.
,
Aug 16
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 11
,
Oct 11
Seems fixed? |
||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Mar 25 2016Components: -Internals>Media Internals>Media>Source
Labels: OS-All