HDMI Capture Problem SOLVED - AviSynth RULES!

Vitaliy Kiselev said:
May be it'll be possible to write small standalone software using ffmpeg or similar library to convert captured footage to proper format?
Click to expand...

yes thats good idea

like batch avs script with wild cards or .bat

Actually "Khaver" on HV20 forums already has a batch utility GUI made with PDF instructions it should be easy enough for most users . Avisynth, ffmpeg are backends

http://www.hv20.com/showthread.php?25044-Batch-Intermediate-Creation-Utilities

(go to end of thread because newer versions there)
 
Vitaliy Kiselev said:
I do not mean scripts.

I mean single exe utility. And using ffmpeg library.
Click to expand...

Yes that's what a GUI is. :) That's what Khaver's utility does

There is even diagrams and a pdf instructions

The only thing that needs to be adapted is the "template script" which can be copy & pasted . (you would need a different script for 30p vs. 24p)
 
Again.
I do not mean GUI with "templete scripts".
I mean normal application that is able to decode each frame, process fields and encode to lossless format.
And using statically linked ffmpeg to decode and encode purposes.
 
Ok, I see what you mean. Sorry, not sure how to do that. Are you able to write it ?

FFMPEG is very weak for processing fields, cadence etc... You would have to take the avisynth code for the various filters and adapt it to a proper program. I think it would have to be GPLed
 
PDR said:
Ok, I see what you mean. Sorry, not sure how to do that. Are you able to write it ?

FFMPEG is very weak for processing fields, cadence etc... You would have to take the avisynth code for the various filters and adapt it to a proper program. I think it would have to be GPLed
Click to expand...

I don't have time.
But I see no big problem here.
And you do need ffmpeg for fields processing, as you'll have access to decoded frame.
I see this as decoding->RGB frame (may be other formats will be better)->fields processing using your own code->Saving to MJPEG encoded stream (or lossless for ones who like it).
 
Yes FFMPEG could be used for decoding +/- encoding, but the logic has to come from elsewhere (ffmpeg isn't good for that). Note that FFMPEG can't decode some formats, for example UT Video Codec, Prores - another popular capture format, in the examples above so you would have to make provisions for other decoders

Khaver's utility isn't that bad. It basically does the same thing.

You just select files or folder, select template script (e.g. "24p IVTC") , select ffmpeg (or other encoder) encode parameters, push encode.

Why the aversion to template scripts?
 
PDR said:
Also there are tradeoffs. The black letters in the red ball might become less legible, there might be more red blurring "bloom" on the red ball top edge etc... than say, using a 0.5 shift. Or the white grille in the speaker will become yellow at the edges. For example, compare this to the 2 shots above (I adjusted for Rec.601) (flip back & forth between the 3 and you will see tradeoffs). There's actually pros/cons tradeoffs to every choice here - because there is no "perfect" way to resize or resample. For example a spline64 chroma resize will produce more chroma aliasing than a bilinear resize
http://www.mediafire.com/?ar0i0ohggs9clbx
Click to expand...

Yup, I noticed that.. was playing around with subpixel shifting as well. Was thinking of trying to shift individual channels as well to see what that'd do.
 
Vitaliy Kiselev said:
I do not mean scripts.

I mean single exe utility. And using ffmpeg library.
Click to expand...

Hrm, sounds like a novel idea for general endusers, although for those already comfortable with AviSynth, I feel it's still a fairly ideal option. Reason I say that is you can frameserve to a large amount of encoders/editors of your choosing. Like right now I can load the script right into TMPGEnc, make fine edits, and utilize whatever encoder it has available to it.
 
GrgurMG said:
Hrm, sounds like a novel idea for general endusers, although for those already comfortable with AviSynth, I feel it's still a fairly ideal option. Reason I say that is you can frameserve to a large amount of encoders/editors of your choosing. Like right now I can load the script right into TMPGEnc, make fine edits, and utilize whatever encoder it has available to it.
Click to expand...

I've had trouble getting avisynth scripts to open in anything other than VirtualDub and Premiere CS5.
Specifically, what other programs work? And can you point to some links on how to do it.
 
Ralph B said:
I've had trouble getting avisynth scripts to open in anything other than VirtualDub and Premiere CS5.
Specifically, what other programs work? And can you point to some links on how to do it.
Click to expand...

Hrm, I've always had pretty decent luck with alot of what I use. Aside from the aforementioned Premiere and VirtualDub, I utilize TMPGEnc extensively whether using AVISynth or not. It's generall pretty good at loading most AVISynth script files just as if they were a regular video file. In particularly if I'm using Neatvideo or some heavy deinterlacer I'll load the script right into TMPGEnc.. which is an improvement from when I used to deal with more intermediary files. I can trim down or add to a clip with TMPGEnc as well as run additional filters.

http://tmpgenc.pegasys-inc.com/en/download/te4xp_rireki.html

Also, unless I'm otherwise scaling with AVISynth, I always use TMPGEnc as oppose to Premiere to do any sort of upscaling or downscaling of a video.. like when I'm scaling a finished product down to DVD, because it utilizes Lanczos (unless you specify otherwise) to scale things, where as Premiere is bilinear or bicubic depending on the settings. Although I think it does do some form of Lanczos now when utilizing CUDA. Which is another thing TMPGEnc has (might of had before Adobe I think) is full CUDA support for hardware accelerated operations.. in particularly you can drop in some basic color adjustments without much if any effect on the render time... if you have a CUDA video card that is.

Those 3 programs (if your including the entire Adobe suite) is pretty much most of what I use for video on the norm.

Back in CS3 you used to be able to frameserve from Premiere with AVISynth utilizing a plugin and an AVI dummy file. so you could essentially edit in Premiere but bypass their encoder and encode with something else. Not sure if that might be an option again with CS5... there are frameserver plugins I've seen but haven't tried... don't know if they work directly into a AVISynth workflow though.

--- edit ----

I'd note that TMPGEnc is still missing some common output options here and there.. at least on the version/install I'm running. There's no standard basic DV AVI output or Blu-Ray H264 profiles... so workarounds are needed if anything.
 
Like everything , there are pros/cons

For highest consistency, I would recommend using a digital intermediate . Frameserving adds extra overhead, and performance is slower. A DI will give more consistent results IMO. The downsides of DI route of course, are large filesizes, extra time required to encode

If you are doing any color corrections, then definitely use a 10-bit per channel intermediate (even from 8bpc derived source). Avisynth works in 8-bit and values are quantized, even in those programs interpolate values and work in 16 or 32-bit float.

CS5 runs on 64-bit OS, so you cannot use the regular premiere avs import plugin (which is 32-bit)

(There are OS x64 versions of avisynth and the premiere avs import plugin, but they are unstable and buggy IMO)

Other options for frameserving: You can use AVFS (avisynth virtual file system), or makeavis (comes with ffdshow), or VFAPI (depreciated, I would avoid). The idea behind all of these is to make a "dummy" AVI wrapper for the .avs script (or signpost) that the other program is able to use. To the other programs, they "see" it as a video.
http://www.turtlewar.org/avfs/
 
Last edited:
Hrm, I can't really comment on in what workflows might it actually be faster to use an intermediate rather then frameserver with potentional overhead, as I don't clock myself too closely, although in certain scenarios it can be more convenient to get a process done all in one shot. For example if making an intermediate for a long clip is going to take an hour or two and then another how many hours to then encode that to something else, it's sometimes beneficial to have it done all in one shot, so that you can leave go to work, go to bed, or otherwise leave it unsupervised without having to worry about manually beginning the second step. Not to mention it can save disk space.

However, I'd agree it all depends on your work flow and there are various situations where you would want to have an intermediate file.. particularly if it's not an established workflow, thus causing you to jump back to square one with the AVISynth processes should you screw up with whatever else your encoding to in stage 2. This of course depends on how intense your initial script is on time... for instance in our current case an intermediary file is definately advisable pre-edit, although if it's a very short clip.. it'd still be feasible to bypass one. But getting back to the original point, giving yourself options for what you want that intermediary file to be and what to encode it with or if to use one at all, is where sticking with AVISynth has a strong point.
 
Last edited:
The "overhead" I was referring to is more about editing fluidity (decoding latency). Something like a cineform intermediate will editing a lot "snappier". Personally I don't care about leaving encodes overnight, but the actual editing experience isn't as fluid

You're right, it will depend on the workflow - for people that do multipass exports (for say blu-ray or you need a set bitrate) and use heavy filters (like neat video, or qtgmc) will definitely benefit from using intermediate . If you're using heavy processing - you only have to endure the slow algorithms once instead of twice. These IVTC algorithms are very "light" compared to neat video or some of the other avisynth filters

IMO, for short edit projects with no major color correction, frameserving is a good option. In my experience, the larger the project, the more files you have to frameserve leads to higher chance of problems with stability
 
Very true... we don't spend all this money on fancy computers and expensive software to all of the sudden feel like we're editing HDV on a low clock Pentium 4 without enough RAM, again.
 
Ralph - what audio stream are you using to check for sync?

Does it fall back, recover, fall back , recover, or is there progressively worsening difference over time?

Are you playing the lossless encode for this? Is your hardware adequate? Are you sure there are no I/O bottlenecks (like HDD) or frame drops from playing? (do you have UT setup correctly with the #cores , frame divide count, and "predict left"?)

AssumeFPS has sync_audio "off" by default (only processes video) , if you want to process the audio as well, you need to use "true".
AssumeFPS(24000,1001,true)

For "normal" telecined streams this shouldn't be necessary, but this HDMI output is far from normal...

My concern is Fdecimate(threshold=2) doesn't work on Barry's clip (even the "normal" one) . It leaves duplicates, and drops frames causing "jumps".
 
Last edited:
For checking audio sync I'm not relying on realtime playback. I put the AVCHD clip on the timeline in Premiere and put the avisynth process clip on a track directly above it. Align the head slate. Change the opacity of the avisynth clip to 50%, then step through the timeline. If a frame goes out of sync, it's immediately visible. (of course, I'm using footage that has continuous movement)

Tdecimate falls back, recovers, falls back, recovers, etc. It's never more than one frame off, but it's one frame off, perhaps 30% of the time.

I've worked with Barry's clips, and the revised script with fdecimate(threshold=2) decodes 24P #1 and the 30P clip perfectly. 24P#2 however, has 6 duplicate frames. The good news is that it recovers almost immediately by skipping a frame. Not so, with tdecimate. If Barry's clip went on for 3 minutes, I guarantee you would not be happy with the result.

But, with more normal footage, fdecimate(threshold=2) only has a few duplicates in the first second or two. After that, it is rock solid.

At present, the revised script is the only one I know of that is frame accurate over the long haul. Sure, I'd like those first two seconds to be clean, and maybe we can achieve it. But, far better to have glitches in the first 2 seconds, then clean, than to have glitches everywhere.
 
Hmmmm that sucks. Is the audio exactly the same in the HDMI recording as the AVCHD clip? Can you line them up and check the waveforms?

What about using "sync audio" and comparing the HDMI embedded audio?

So if there is no progressive desync on the longer clips, this suggests lengths the same then. Ie it truly running at 24000/1001 , and not 24.0 fps ?




I've worked with Barry's clips, and the revised script with fdecimate(threshold=2) decodes 24P #1 and the 30P clip perfectly. 24P#2 however, has 6 duplicate frames. The good news is that it recovers almost immediately by skipping a frame. Not so, with tdecimate. If Barry's clip went on for 3 minutes, I guarantee you would not be happy with the result.
Click to expand...

Was this a typo? The 30p clip doesn't require decimation

Also, I couldn't replicate your results Barry's 1st 24p clip with AssumeTFF().TFM().FDecimate(threshold=2) . It causes frame dupes corrsponding to the exact field location each time white/black rectangle abnormal field occurs (it produces a frame duplicate in the sense the big rectangles are duplicated, but the white/black rectangle is white in one frame, black in the other). I'm still puzzled by his 1st clip. This can't occur if it was a progressive scan, with pulldown applied afterwards.

Audio desync or skipped/jump frames would make it unsable in my book.

There seems to be some inconsistencies in your recordings and Barry's recordings. I'm not sure what to make of it
 
Last edited:
PDR said:
Was this a typo? The 30p clip doesn't require decimation
Click to expand...

Actually it does. Remember, the camera is adding extra fields to the 29.97P signal to make 60.0i. We need to decimate those extra fields.

PDR said:
Also, I couldn't replicate your results Barry's 1st 24p clip with AssumeTFF().TFM().FDecimate(threshold=2) . It causes frame dupes corrsponding to the exact field location each time white/black rectangle abnormal field occurs (it produces a frame duplicate in the sense the big rectangles are duplicated, but the white/black rectangle is white in one frame, black in the other). I'm still puzzled by his 1st clip. This can't occur if it was a progressive scan, with pulldown applied afterwards.
Click to expand...

I think I've replicated your problem. I notice you're writing your script with periods between the arguments. That's not how I run my scripts. Try it this way:

AssumeTFF()
TFM()
FDecimate(threshold=2.0)
AssumeFPS(24000,1001)

This is the exact script I used to successfully decode Barry's 24P #1.

Download the result here:
http://www.sendspace.com/file/rma5bi

It's encoded with UT codec.

I know in theory these scripts should do the same thing, but they don't. When I tried it with the periods, I got the duplicates you describe.

As for the 30P clip, I used the same script, but had to change the target frame rate.
(fdecimate has a default target rate of 23.976)

AssumeTFF()
TFM()
FDecimate(rate=29.97, threshold=2.0)
assumefps(29.97)

You can also download the result:
http://www.sendspace.com/file/t0gdeg


Also, FWIW, here are the versions I am using:

avisynth.dll 2.6 - Modified: Saturday, September 19, 2009, 5:36:58 AM

fdecimate 1.0.1 - Modified: Saturday, June 19, 2004, 4:11:30 AM

TIVTC - version 1.0.5.0 - Modified Thursday, January 17, 2008, 1:01:48 PM

Windows XP SP2
 
You must log in or register to reply here.
Back
Top