artefacts when viewing avs script

[bamsebo]

I posted this in the MeGui forum but it was suggested I may get more help here....

I have an h264 1920x1080i25 broadcast ts that I am trying to re-encode using MeGui and x264.

however I am seeing some odd artefacts when playing back the avs script even before encoding. I have tried various deinterlacing options without any luck. the original ts file plays back fine in both wmp and vlc.

the script:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("D:\TVRecording\Unedited\Dexter 1\test2\dextertest.dga")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\TDeint.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\EEDI2.dll")
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,edeint=edeintted)
#crop
#resize
#denoise

the artefacts:
http://img221.imageshack.us/img221/4919/vlcsnap00006r.png (http://imageshack.us/photo/my-images/221/vlcsnap00006r.png/)

Uploaded with ImageShack.us (http://imageshack.us)

thanks
Barry



plays

[CruNcher]

does it show with only the decoding part ?

[Didée]

Don't use AVCSource with interlaced AVC. It's based on outdated ffmpeg libraries.

Try recent builds of ffmpegsource (ffms2) instead.

[dragon_warrior]

And also try to remux it to mkv before loading by ffmpeg
Just don't use those ffmpeg mt versions, or you will be more likely to have a crash with vfr source

[bamsebo]

OK thanks for the advice all! remuxing it to mkv produces a very jerky file when played which it retains after re-encoding....

the original ts file plays fine though, and a quick re-encode in Videoredo as mkv plays fine too.

[TheRyuu]

Don't use AVCSource with interlaced AVC. It's based on outdated ffmpeg libraries.

Try recent builds of ffmpegsource (ffms2) instead.

That actually might be a not so great idea (but could be better than dgavcdecode):
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.

If used properly with the right settings ffms2 will work just be careful.

[Guest]

Try DGDecNV. The author does not consider proper implementation of random access to be "boring".

[Didée]

Oh, the situation with TS and ffmpegsource still is that disastreous? Seems I've missed that, since - see above - DGDecodeNV works pretty flawlessly with interlaced-or-not-AVC-in-TS ...
I'm using ffmpegsource only for WMV files - which in turn isn't possible with DGDecodeNV without demuxing WMV to raw VC1, which in turn isn't exactly trivial.

Summed up: It is the year 2011 AD, and opening "today's standards" video streams in Avisynth still is martial arts. What a misery.

[bamsebo]

Try DGDecNV. The author does not consider proper implementation of random access to be "boring".

as I understand it I cant try it to see if it works without purchasing a licence?

[TheRyuu]

as I understand it I cant try it to see if it works without purchasing a licence?

ffms2 will work if you don't seek and use the proper settings as defined in my previous post.

Furthermore dss2 is also an option that probably works.

[dragon_warrior]

As far as I'm aware of, dss2 won't work properly in most cases.

[Guest]

as I understand it I cant try it to see if it works without purchasing a licence? If it doesn't work for you I'm sure the author will be happy to refund your $. But with Didée's endorsement, how can you go wrong? :)

Just make sure you have a compatible nVidia graphics card.

BTW:

Trimming -> seeks in the source filter
Decimating -> seeks in the source filter
etc.

So a source filter that won't seek properly is severely limiting in the Avisynth environment.

DSS2() requires perfectly monotonic timestamps. Good luck finding that in the real world, and if you have a raw stream, well, you're hosed.

[Mini-Me]

I apologize if this is slightly off topic, but do these decoding problems exist only for H.264 in .ts containers, or do they apply to H.264 in any container (e.g. .mkv and .mp4)? (Or am I confused about the meaning of TS as used here? :p)

[nixo]

I'm using ffmpegsource only for WMV files - which in turn isn't possible with DGDecodeNV without demuxing WMV to raw VC1, which in turn isn't exactly trivial.


Stegre's ASF2VC1 works well for me.

--
Nikolaj

[CruNcher]

Oh, the situation with TS and ffmpegsource still is that disastreous? Seems I've missed that, since - see above - DGDecodeNV works pretty flawlessly with interlaced-or-not-AVC-in-TS ...
I'm using ffmpegsource only for WMV files - which in turn isn't possible with DGDecodeNV without demuxing WMV to raw VC1, which in turn isn't exactly trivial.

Summed up: It is the year 2011 AD, and opening "today's standards" video streams in Avisynth still is martial arts. What a misery.

Frame accuracy in FFmpeg based stuff good joke :D

[Didée]

Stegre's ASF2VC1 works well for me.

THAT's the tool I tried to remember but couldn't. Thanks for the reminder!