Hi,
This looks like interlaced video. I think 3 pass encoding does not work with these. If that's the problem you are facing, just rm frameno.avi and do -oac mp3lame during all passes and it should be ok. the video is not interlaced! (transcode can detect that) the better word is 'field-coded', not nececssary interlaced, although thsi coding method has no much sence for progressive (non-interlaced) video. anyway i doubt that any app (be it transcode or other) can reliable detect interlacing, sometimes even teh human eye+mind combination fails... hm, if an app can render MPEG2 video, it must also know it is interlaced or not!? am i wrong here?
yes you're wrong the format/codecs itself doesnt know about the original video being interlaced. there are flags noting if its' field-coded (a sin your case) or telcined (3:2 pulldown) which both suggests interlacing but doenst force it. you can encode progressive video as interlaced and vice versa. (by losing quality)
any idea how i can draw the developers attention to that problem? the
if you mean mplayer developers, they do read this list. this is why we really hate beginner questions and incomplete bugreports here. well i made a complete bugreport in my initial post (well with a macosx backtrace instead of a gdb one, but i can of course supply an gdb one too)
about beginner question....i searched both the whole documentation, FAQ and mailing list archives and could not find anything useful about this issue
dunno if it's well documented, i'm not docs author. but it was discussed more than enough at all teh mailing lists.
sample .VOB and problem description are still in the incoming dir on the ftp server...?
probably. but it's a known limitation, and not possible to fix in mencoder exactly what is the limitation here? i have 14 DVDs here that work fine
without decoding the video stream (ie. 1st pass of 3pass encode) mencoder don't know if it's field-coded, so it have to read 2 packet to get 1 output frame, while in normal (frame-coded) case it's one packet for one frame. we could either hack a partial header decoder into demuxer/mencoder to detect it without decoding, or redesign teh whole demuxer-decoder-encoder pipeline API to pass such info back somehow. it just doesnt worth it.
with 3-pass-mencoder and one that does not (crashes mencoder just like
it means that 14 dvd are frame-coded and this one is field-coded (field-coded mpeg is rare enough)
reported)...the issue doesn't seem to be the interlaced video (because transcode says it isn't interlaced)... is there any way i can know (prior to encoding) if a DVD will work or mencoder will just crash?
no then mencoder could know too...
, without major hacks or architecture changes. i mean this isn't a bug. if this isn't a bug, mencoder should print out a message that it can't encode this DVD (or .VOB) instead of silently mysteriously failing, or crashing!
it shouldnt crash (it doesnt crash for me, just drop everty 2nd field resulting bad quality jumpy output file) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu