Opened 13 years ago
Closed 13 years ago
#1872 closed defect (fixed)
Mencoder unable to maintain correct playback speed from VFR mp4 source
| Reported by: | Owned by: | reimar | |
|---|---|---|---|
| Priority: | normal | Component: | core |
| Version: | 1.0rc4 | Severity: | normal |
| Keywords: | Cc: | cehoyos | |
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
When feeding in a video to mencoder from an mp4 source with a variable frame rate, 1.0-rc2 was the last version of mencoder that maintained the right playback rate. The latest version of mencoder continually passes on the message of "Skipping frame" and drops them. The resultant video plays back much faster than it's supposed to.
The source mp4 is reported as
VIDEO: [avc1] 1920x1080 24bpp 95.904 fps 0.0 kbps ( 0.0 kbyte/s)
Although it's mostly 24000/1001 with a few extra frames.
This command:
mencoder_old -nosound -mc 0 -ovc lavc -lavcopts vcodec=ffv1:keyint=24 -ofps 24000/1001 -vf scale=1280:720,harddup -o output.avi input.mp4
works fine on RC2, skipping only 1 frame.
Whereas RC4 gives:
Pos: 0.0s 2f ( 0%) 0.00fps Trem: 0min 163mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 4f ( 0%) 0.00fps Trem: 0min 326mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 5f ( 0%) 0.00fps Trem: 1min 326mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 6f ( 0%) 0.00fps Trem: 1min 326mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 8f ( 0%) 0.00fps Trem: 1min 492mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 9f ( 0%) 0.00fps Trem: 1min 492mb A-V:0.000 [0:0]
Skipping frame!
Pos: 0.1s 10f ( 0%) 0.00fps Trem: 1min 492mb A-V:0.000 [0:0]
and so on.
Change History (6)
comment:1 by , 13 years ago
| Cc: | added |
|---|
comment:2 by , 13 years ago
(In reply to comment #1)
Did you provide a sample?
Sure, here's one. Please tell me once you've grabbed it so I may delete it off this server. It's rather large (336077653) but an excellent example of the problem:
http://ittaku-subs.net/ka_20.mp4
comment:4 by , 13 years ago
Yes this indeed works, thanks! However at RC2 the default demuxer chosen did not have this problem, so perhaps defaulting to a suitable demuxer would be better? Thanks.
comment:5 by , 13 years ago
Did you consider that using a more "suitable" demuxer was the reason for changing the default since rc2?
comment:6 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I'm not sure what you're trying to say. I never even thought about the demuxer since I was assuming the most suitable one would be chosen automatically which I guess was just my wrong assumption. Either way I have a workaround for now which avoids me keeping a copy of rc2 around, thanks. I'll mark this resolved.
Did you provide a sample?