New issue
Advanced search Search tips

Issue 663826 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Playing AVC video in AVI container generated by ffmpeg results in jittery playback

Reported by casey.g....@intel.com, Nov 9 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36
Platform: 8907.0.0 (Official Build) dev-channel lars test

Example URL:

Steps to reproduce the problem:
1. Download any video from: http://download.blender.org/peach/bigbuckbunny_movies/
2. Convert video to .avi format with H264 codec using ffmpeg:
ffmpeg -i <input file name> -vcodec libx264 <output name>.avi
3. Transfer to DUT and play video
4. Observe jittery playback where video is jumping back and forth between frames.

What is the expected behavior?
Video plays smoothly for "H264 - MPEG-4 AVC (part 10) (avc1)" video codec with AVI container.

What went wrong?
Video playback is jittery on a Chromebook.

Did this work before? N/A 

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? N/A

Chrome version: 56.0.2890.0  Channel: stable
OS Version: 8907.0.0
Flash Version: Shockwave Flash 23.0.0.205-r1

Reproduced on an ARM nyan_big device:
Chrome version: Google Chrome 56.0.2910.0 Channel: canary
OS Version: 8967.0.0 (Official Build) canary-channel nyan_big
Flash Version: 23.0.0.205-r1

Reproduced with R54 stable build for lars:
Chrome version: Google Chrome 54.0.2840.93 Channel: stable
OS Version: 8743.83.0 (Official Build) dev-channel lars test
Flash Version: 23.0.0.205-r1

Video Information for BigBuckBunny_320x180.mp4 (obtained from http://download.blender.org/peach/bigbuckbunny_movies/)
=============
Video Codec: H264 - MPEG-4 AVC (part 10) (avc1)
Resolution: 320x180
Frame rate: 48
Audio Codec MPEG AAC Audio (mp4a))
Channels: Stereo
Sample rate: 48000 Hz

Host OS that the video was encoded from: Ubuntu 14.04.1, Windows 8.1

Ubuntu ffmpeg version used (downloaded 3.2 release binary from https://www.johnvansickle.com/ffmpeg/):
ffmpeg version 3.2-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers

Windows ffmpeg version used (downloaded 3.2 release binary from https://ffmpeg.zeranoe.com/builds/):
ffmpeg version 3.2 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.4.0 (GCC)

Note: 
The same video plays smoothly on all other players I tested on Ubuntu: VLC, MPlayer, gstreamer, ffplay and Windows: Media Player Classic, VLC.
 
One additional piece of information that may be of note:

When looking at the information for frames using ffmpeg, the byte offset postions (pos) are out of order for the AVC video in an AVI container, but the byte offset positions for the same video with FMP4 codec in an AVI container are all in ascending order.

Using the following ffmpeg command, I obtained the byte offset positions:
ffmpeg -i <video_name> -t 10 -filter:v "fps=fps=25, showinfo" -f null -


AVC video in AVI container
====================
pts_time:0.08    pos:    10108
pts_time:0.12    pos:    11852
pts_time:0.16    pos:    11084
pts_time:0.2     pos:    12520
pts_time:0.24    pos:    10882
pts_time:0.28    pos:    13144

FMP4 video in AVI container
====================
pts_time:0.08    pos:     1693
pts_time:0.12    pos:     2354
pts_time:0.16    pos:     3011
pts_time:0.2     pos:     4173
pts_time:0.24    pos:     5352
pts_time:0.28    pos:     6543

I'd guess the frames are coming out of ffmpeg out of order too, and if they come too far apart we've already rendered a later frame and thus drop the earlier one.
Thx Dale.

> and if they come too far apart we've already rendered a later frame

Interesting. So the reason why all other players work fine would be just because they read more frames in advance? Just making sure I understand this correctly.
For testing, do you know any player where this "look ahead" number can be changed? I mean (re)configured without recompiling.

BTW could you help tag/triage this bug?
Cc: posciak@chromium.org
Yes, that's probably it; the other option is a bug in decoder reordering due to some missing metadata in mp4 vs avi container (or some other reason). There's no way to reconfigure it without recompiling, you'd need to change media/base/limits.h and update kMaxVideoFrames to a higher value.

I'd guess the stream has some issues, but +posciak@ since this is CrOS only (the only platform we support AVI demuxing on).
Cc: -posciak@chromium.org
Owner: posciak@chromium.org
Status: Assigned (was: Unconfirmed)
as per #4, give to posciak@ to start, please re-assign appropriately.

Sign in to add a comment