Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#13176 closed Bugs (Fixed)

.mp4 file plays back slowly

Reported by: zewt Owned by:
Priority: 4 - Normal Milestone: 12.0 "Frodo"
Component: Video playback (inc. audio in video and codecs) Version: GIT
Severity: Normal Keywords:
Cc: Anssi, bobo1on1, DDDamian, elupus Blocked By:
Blocking: Platform: All
Revision: 20120707-4d1bbd6


I have some .mp4 files which play back very slowly. While they're playing, the time display jumps back and forth between 0:00 and 0:01. This happens on current nightly on an i5-2500k.

I havn't been able to reduce a file. If I cut it with avidemux the problem goes away (muxing issue?). A complete file is at (283MB).

This isn't isolated; I've hit several files in the wild with this issue. The file plays in MPC and on a WDTV.

Attachments (1)

xbmc.log (25.0 KB) - added by zewt 4 years ago.

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by zewt

comment:1 Changed 4 years ago by vdrfan

  • Cc Anssi bobo1on1 DDDamian elupus added
  • Platform changed from Windows to All

FYI, playback is slow on Linux as well.

comment:3 Changed 4 years ago by sho

So has this been merged?

comment:4 Changed 4 years ago by DDDamian

There was some debate on the PR in which there seemed to be consensus that the stream itself was not well muxed, but for some unknown reason @zewt added a massive merge commit to the PR - definitely a no-go for merge there.

comment:5 Changed 4 years ago by elupus

The file is not necessarily invalid, but it should not require such a drastic fix. If we increase to 12 seconds we will eventually find another sample with larger requirement. I just think we are failing to parse the index for some reason.

Ie it needs to be investigated at ffmpeg level.

comment:6 Changed 4 years ago by zewt

If there's a problem with the push, then mention it in the PR (complaining about it elsewhere without making a note in the PR itself is a bit odd), but it's a net change of two bytes, so this is no reason to leave a bunch of files unplayable.

Currently, as soon as one buffer fills, both streams stop buffering, which is strange. The *correct* fix is probably as I described in the PR: to change the buffering to a minimum, rather than a maximum, so one stream having too much data doesn't cause the whole file to stop being read, guaranteeing the other stream is starved. I implemented this in a simple way locally and it worked very well, without requiring the minimum buffers be artificially large. (I didn't try to figure out what would be needed in CDVDPlayer::CheckStartCaching, though, since there are no comments in that code explaining what it's doing. There should probably still also be a hard maximum, too, just to make sure badly broken files don't cause buffering to cause an OOM.)

Maybe there's another issue in ffmpeg, too, but the buffering seems wrong in and of itself--if the video stream has 8 seconds of data and the audio stream has no data, it just doesn't make sense to stop buffering.

comment:7 Changed 4 years ago by Github Janitor

  • Resolution set to Fixed
  • Status changed from new to closed

ffmpeg: reduce allowed mp4/mov a/v skew to 4 seconds

Our video queue's are not guaranteed to handle exactly 8 seconds it can be a small amount less. For files that are not interleaved this meant we we unable to get proper playback

This closes ticket #13176

Changeset: 95b0749850511cebde3197962766913f306a6ed9 By: Joakim Plate

comment:8 Changed 4 years ago by sho

  • Milestone changed from Future / Pending to 12.0
Note: See TracTickets for help on using tickets.