Reversed video from AviSynth is "blocky".

[jagabo]

Don't worry , it was only for curiosity

What I meant to compare was

FFVideoSource().Reverse()

VS.

FFVideoSource(threads=1, seekmode=0).Reverse()


Because AVCSource and FFVideoSource are using different decoders

03:55 and 06:13 respectively.

I tried it with a ~10 second HD video. The difference was something like 2 fps vs 40 fps.

[sambat]

And vdub shows audio with that script loaded (file=>file information) ?

If it does, add back the resize and reverse to vid , if audio is still ok, then add the 2nd video and stackhorizontal

Thank you, I started adding the lines back and it worked - then I noticed that in the previous script I had Return(vid) in the last line.

This script works as I wanted.
Thanks again for your time and patience.

a=FFVideoSource("GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv", threads=1, seekmode=0).LanczosResize(640,264)
b=FFVideoSource("GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv", threads=1, seekmode=0).LanczosResize(640,264).reverse()
vid=stackhorizontal(a, b)
aud=FFAudioSource("GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv")
audiodub(vid,aud)
info()

[vhelp]

sambat, can you post the original avc video (trailer) that is giving you this problem ?

i'm curious to see if this happens on everyones machine with different codecs. it might be the way the video is being decoded. i had this problem several years ago and posted the same blocky issue but noone was able to resolve. i gave up and moved on. but i'd still like to check it out on my machine. thank you.

[poisondeathray]

Thank you, I started adding the lines back and it worked - then I noticed that in the previous script I had Return(vid) in the last line.

whoops I totally glossed over that.... should have seen it right away

I tried it with a ~10 second HD video. The difference was something like 2 fps vs 40 fps.

Huuuuuugee difference . I think a lot is going to depend on encoding settings and hardware. Some encoding settings will make this difference even larger . Faster / more cores/ hardware will be handicapped more by threads=1



vhelp - This is probably it

http://filessurf.com/File/aee0jl09o09pg

[jagabo]

I tried it with a ~10 second HD video. The difference was something like 2 fps vs 40 fps.

Huuuuuugee difference . I think a lot is going to depend on encoding settings and hardware. Some encoding settings will make this difference even larger . Faster / more cores/ hardware will be handicapped more by threads=1

I was using x264 with the veryfast preset so the encoding load would be minimized. Ie, decoding was the bottleneck. The source was one of those Nikon PSF videos. That may have been harder than normal to decode.

[vhelp]

nupe..link seems to take me to a divxplushd.exe file d/l. tx anyways.

found this link: http://www.divx.com/en/devices/solutions/high-definition/divx-plus-hd/video

[poisondeathray]

I tried it with a ~10 second HD video. The difference was something like 2 fps vs 40 fps.

Huuuuuugee difference . I think a lot is going to depend on encoding settings and hardware. Some encoding settings will make this difference even larger . Faster / more cores/ hardware will be handicapped more by threads=1

I was using x264 with the veryfast preset so the encoding load would be minimized. Ie, decoding was the bottleneck. The source was one of those Nikon PSF videos. That may have been harder than normal to decode.

Another option is to use avsmeter , but with "veryfast" I suspect the difference or ratio will be similar on similar hardware/setup/video sample
http://forum.doom9.org/showthread.php?t=165528

[poisondeathray]

nupe..link seems to take me to a divxplushd.exe file d/l. tx anyways.

huh ?? Did you push "download ?" . It's actually a re-direct

I just tried it right now... definitely works

Here is a direct link if you are having browser issues
http://divxtrailers.divx.com/GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv

[vhelp]

see link below, othewise, i already got it! .. tx 4 tryn
https://forum.videohelp.com/threads/349080-vhelp-Images-II?p=2200339#post2200339

[vhelp]

confirmed. i d/l'ed latest/last version of dgavcdec109.zip and it ran through reverse() script, and it blocked in the same scene, and many others. however, when i feed the original .mkv file into scripplet below, symptom disapeared.

x = "g:\GIJoeTheRiseOfCobraTrailer-DivXPlusHD.mkv"
LoadPlugin( "C:\PLUGINS\ffms2.dll" )
FFVideoSource(x, fpsden=1, fpsnum=24, width=720, height=304, seekmode=0)
reverse()

edit: i see, the op had already resolved. oh well.

[sambat]

seekmode=0

I tried with and without this - no difference in the processing time nor perceived quality;what's it's function?

[Selur]

int seekmode = 1
Controls how seeking is done. Mostly useful for getting uncooperative files to work. Only has an effect on files opened with the libavformat demuxer; on other files the equivalent of mode 1 is always used. Valid modes are:

• -1: Linear access without rewind; i.e. will throw an error if each successive requested frame number isn't bigger than the last one. Only intended for opening images but might work on well with some obscure video format.
• 0: Linear access (i.e. if you request frame n without having requested all frames from 0 to n-1 in order first, all frames from 0 to n will have to be decoded before n can be delivered). The definition of slow, but should make some formats "usable".
• 1: Safe normal. Bases seeking decisions on the keyframe positions reported by libavformat.
• 2: Unsafe normal. Same as mode 1, but no error will be thrown if the exact seek destination has to be guessed.
• 3: Aggressive. Seeks in the forward direction even if no closer keyframe is known to exist. Only useful for testing and containers where libavformat doesn't report keyframes properly.

-> read: https://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html

I tried with and without this - no difference in the processing time nor perceived quality;

you say it works without seekmode=0
for vhelp it works without threads=1
-> so simply using ffmpegvideosource solves the problem?

[poisondeathray]

I couldn't reproduce "blocky" results with ffvideosource eitherway with reverse on that sample , I think threads and/or seekmode are unecessary in this case . The error that he got earlier with FFMpegSource2 was from requestlinear

[sambat]

[QUOTE=Selur;2231641]

-> so simply using ffmpegvideosource solves the problem?

Sorry to be late - yes!