Ticket #13176 (closed Bugs: Fixed)

Opened 22 months ago

Last modified 18 months ago

.mp4 file plays back slowly

Reported by: zewt Owned by:
Priority: 4 - Normal Milestone: 12.0
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

Description

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  https://services.zewt.org/test.mp4 (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

xbmc.log Download (25.0 KB) - added by zewt 22 months ago.

Change History

Changed 22 months ago by zewt

comment:1 Changed 22 months 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 19 months ago by sho

So has this been merged?

comment:4 Changed 19 months 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 19 months 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 18 months 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 18 months ago by Github Janitor

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

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 18 months ago by sho

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