Glitchy Pixels?

[mirkosp]

That BD isn't Japanese, but Funi, and open-gop has been seen on American BDs in the past AFAIK, hence why it seems like a possible reason.

[Mister Hatt]

Oh it's a funi BD? Just get the DVD, you get more quality and your problem is solved. IIRC there is no issue with open GOP in lavc/lavf anymore anyway, but I still don't think that looks quite like open GOP issues do. Can't quite explain what the difference is either, heh.

[TheRyuu]

I sense some slightly wrong information in this thread.

To quote TheFluff (a ffms2 devel):

Jesus, people, stop repeating the same thing over and over again just to have it fail every time and then act surprised that it still doesn't work when there has been no changes. Do I really have to post "interlaced h264 in ts will not work with ffms2" once every two pages?

Status of TS support in FFMS2 is as follows:
- progressive mpeg2: should work with Haali's splitter; frame accuracy is doubtful, however. Seeking most likely extremely broken with lavf unless you use seekmode=0 or -1 (that is to say, you never seek).
- interlaced mpeg2: same as above, but you may or may not get funny frame duplication issues; I haven't really tried.
- progressive h264: only 100% safe way to get this to work is demuxer="lavf" and seekmode=0 or -1 (-1 prevents wasting cpu cycles on pointless shit). Then it'll decode properly and be "frame accurate" by virtue of never seeking.
- interlaced h264: bat country. Will most likely not work properly at all no matter what you do. If you're feeling particularly adventurous you can try demuxer="lavf", seekmode=-1, threads=1 and then use the correct fpsnum/fpsden for your source, but you're still likely to get random corruption issues. Remuxing to MKV will rid you of the need to use demuxer="lavf" and seekmode=-1 but will not solve the frame duplication and you're still likely to get random corruption issues, and apparently lavc likes crashing with threads > 1 now too.
- any type of vc1: it is a mystery.

MPEG PS is probably mostly the same, but nobody uses PS these days except on DVD's, and there are better tools for handling those.


The next time you see someone complain about interlaced h264 you can quote what I just posted here. The status has been the same since forever (it has always been broken) and will not change until someone either fixes lavf's ts parser, or rewrites FFMS2 to use something else. Fixing lavc's h264 decoder is also likely to be necessary. I took a look at ffdshow's handling of interlaced h264 but I couldn't really find anything special so I assume clsid just patched ffmpeg as usual. Needless to say, this being open source and the problem being a) nontrivial, b) boring and c) unrelated to very old video games, none of this will probably ever get done. If it does, you will know, because there'll be a hundred people blogging endlessly about it.

tl;dr version: BD decoding is still fucked in more then one way.
Either use special means of sourcing with ffms2 (using hacks as described above) or actually use something which isn't fucking broken (like dss2 (sort of)). There aren't any free ways to get (guaranteed) frame accurate decoding of a BD m2ts (only payware: dgavcdecodedi/dgavcdecodenv). But since you don't seem to need to seek (looking at your script) you should be able to get away with using ffms2 with settings as described above.

Basically when you index it with ffmsindex (which you have to do if you want this to work) set demuxer=lavf. Then with ffvideosource include seekmode=-1. If you're experiencing the double frame(rate) issue (where each field is decoded to a frame - your fps becomes 59.something means you have this problem) you can set fpsnum/fpsden to whatever they need to be.

[Mister Hatt]

tl;dr what I said about seekmode