Summary: | media-video/mplayer mencoder -ovc copy -oac mp3lame skipping frames | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Honza <hkmaly> |
Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED REMIND | ||
Severity: | normal | CC: | david.morgan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Honza
2004-07-02 07:42:12 UTC
Someone told me that "-mc 0" can help in this cases. I didn't test it yet ... and I still think this can be only workaround, not repair. *bump* latest mplayer fixes this? Which one ? mplayer-1.0_pre5-r5 still has that problem. what about one of the newer versions? Please try with pre7. Problem is still present with media-video/mplayer-1.0_pre7. Note: I just noticed I made mistake in bug report. First step to reproduce is 1. mencoder something.avi -ovc copy -oac mp3lame -o result.avi (or mencoder something.avi -ovc copy -oac lavc -lavcopts acodec=mp3, but it skip different frame(s) in -pre7. Also it seems it skips less frames.) Sorry to all who didn't get it from sentence "With -oac lavc -lavcopts acodec!=mp3 or -oac pcm, another frames is skipped." Note: just noticed three skipped frames after command 'mencoder *801* -o 8xx-Znelka.avi -ss 1:03 -endpos 0:1:0 -oac copy -ovc copy'. It also was visible in video (skipped frame referenced from later frame problem). -mc 0 workaround worked.<BR>mplayer-1.0_pre7-r1 (1.0pre7try2-3.3.2) No activity on this for ~6 months - does it still happen with 1.0.20060415? Can anyone even reproduce this? It works fine here. Yes, it still happens. On first video I tried one missing frame. Or, more reproducible: download http://movies.apple.com/movies/fox/ice_age_2/ice_age_2-tlrD_h480.mov (it's free trailer), then mencoder ice_age_2-tlrD_h480.mov -ovc copy -oac mp3lame -o ice_age.avi. Two skipped frames. Ok, I can reproduce this now. You can use -noskip -mc 0, to stop this happening - does that get rid of the crashing with certain decoders that you reported? Apart from that, I think this is more of an upstream issue (I'm only a lowly arch tester, though). After almost two years I don't remember what sensitive decoders I was talking about (I suppose it was something on windows). But I reported the crashing and visibility of error only to prove skipping frames with -ovc copy is bug (also, theoretically, if only frames just before I-frames will be skipped, it won't be bug, but I think -ovc copy don't have access to information about what frames are I-frames). There's no reason while decoders should crash if no frames is skipped. While -noskip don't work, I already reported -mc 0 is usable workaround. It probably is upstream issue. But I still don't lost belief that peoples from gentoo bugzilla have contact with developers and even if they don't, we can at least track the bug (and workarounds) here for peoples searching for it. I'm sorry about that, hopefully the problem will be mitigated in the future once the support for this kind of files improves. I'm marking it as REMIND Due to the way -ovc copy works, I don't think there is a way to properly fix this. You should use -mc 0 -noskip (I think using only -mc 0 can lead to A-V desync in some cases). (Yes, of course it would be possible to make -ovc copy imply these options, but that would reduce functionality e.g. for raw streams or all-keyframes streams, thus I think the "workaround" is the right solution). I was thinking there is in fact some bug in A-V sync code, because recoded video should be already synced (of course, there might be bug in A-V sync of program used to create it). Or something as using algorithm which is correct in most cases instead of optimal algorithm, and it doesn't work on begin of stream ... And this bug is only product of this hidden bug. And there is still that posibility with deleting frames just before keyframes or something like that. But yes, with -mc 0 workaround this bug is not so severe. Also, maybee this should be mentioned in documentation ... |