Very short videos won't play
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| vlc (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
A very short video, such as 1 frame long, won't play in VLC. Nothing will show up, even if the video is paused.
A 1-frame video can be useful for things like testing the performance of different encoding settings. While it's possible that VLC (maybe depending on vout display module) causes the appearance of a video to change slightly so it's not directly comparable to display by other software, the display of two VLC instances can generally be compared to each other.
The 1-frame video can be converted to a different format, but sometimes this is lossy.
A bit related, if a video is very slow, like 1 frame per second, it won't show up for a while in VLC. It's possible VLC is trying to buffer several frames before showing anything.
Maybe also related, I noticed in ffmpeg, which VLC uses for decoding, that a filtergraph wasn't receiving frames until at least two frames had a DTS that was after the PTS of the frame entering the filtergraph. So it's possible VLC is not receiving frames from libav (?).
ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: vlc 2.2.0-0ubuntu0.
ProcVersionSign
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelMo
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:45:45 2015
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)
| Misaki (myjunkmail311006) wrote | #1 |
| description: | updated |
| Misaki (myjunkmail311006) wrote | #2 |
| Misaki (myjunkmail311006) wrote | #3 |
| Misaki (myjunkmail311006) wrote | #4 |
This video demonstrates the problem. The video starts at 0, as demonstrated by looking at the frames such as with "ffprobe -select_streams 0 -show_frames timing.mp4 |less".
But vlc starts video playback around 2, showing frame 0 at that time, and ends at the 6th frame (frame 5), not displaying the last four frames at all. As with bug #1443835, pressing 'e' to advance a frame doesn't work.
Changing decoding and output options doesn't change this. Seeking to the middle of the video, though, does cause vlc to...
1) display frame 5
2) very briefly display frame 6
3) display frames 7, 8, and 9 for the normal time duration.
This could be related to frames 8 and 9 having no decoding-time-stamp listed in ffprobe, so vlc or libav could decide to decode them simultaneously (instead of 1 sec apart), and then display the most recent frame in the buffer (since it's already 2 sec late) each time one of those frames is decoded. It isn't clear why this doesn't happen for normal playback though, without seeking.
The video was generated with this command:
ffmpeg -ss 4.5 -i '『-Project DIVA F-』 - Nostalgic [40_XMJzyQPE].webm' -vf "fps=1,
I note that avplay (I don't have ffplay) plays it better; it does display the first frame only briefly, and then turns black, but all the rest of the frames are displayed at the correct times. (Totem also works correctly.)
So it seems like vlc should be getting frames earlier than it is. Since framerate can be variable, this wouldn't be based on a buffer of a certain length of time.