Encoding 1080i clips with x264 incredibly slow

[abyss616]

For years I've been capturing video from my DirecTV box using a Hauppauge box at 720p60. I recently decided that I would try to capture at 1080i30 since I recently upgraded my computer which should be able to handle such material.

This is the script I normally use for 720p60:
v=LWLibavVideoSource("J:\Clip.TS")
a=LWLibavAudioSource("J:\Clip.TS").Normalize()
AudioDub(v,a)
ColorMatrix()
UnDot()
ConvertToYV12()
Trim(373,108160)


When I encode using x264 @ 2500 in MeGUI, I get ~120 fps on the first pass and ~60 on the second. The CPU runs at 99% the entire time.

When I used the 1080i clips in that same script, the result was a very jumpy video, which I somewhat expected. After some research, I decided upon this script:

v=LWLibavVideoSource("J:\Clip.TS",fpsnum=30000, fpsden=1001)
a=LWLibavAudioSource("J:Clip.TS").Normalize()
AudioDub(v,a)
ColorMatrix()
UnDot()
ConvertToYV12()
Trim(700,218080)
AssumeTFF()
AssumeFrameBased()
SeparateFields()
Spline36Resize(1920,1080)
SelectEven()


That gave me a nice picture and smooth output. The only glitch I would see would be when editing in VirtualDub, when going frame-by-frame, I would see a random frame pop up every now and again, usually after jumping ahead several thousand frames at once.

However, when encoding in MeGUI using the same x264 settings, I was getting ~10 fps on the first pass! This a major dropoff and a dealbreaker (the CPU is running at 99% here too). Is this to be expected? I realize I'm asking Avisynth to do more, but didn't think it would slow down this much. Is there anything I can do to speed this up?

[videoh]

Run AVSMeter on your script and you'll see if the script is your bottleneck. You've got some silly stuff in there BTW, but others will surely elaborate on that.

[abyss616]

https://i.imgur.com/loP8IRY.jpg

AVSMeter screencap attached.

The ColorMatrix, UnDot and ConvertToYV12 are holdovers that I picked up awhile back. I haven't revisited them to see if they are still valid.

[FranceBB]

You're saying you record in 1080i which basically means that you're already on 1920x1080 29.970 interlaced, so why are you doing this:


AssumeTFF()
AssumeFrameBased()
SeparateFields()
Spline36Resize(1920,1080)
SelectEven()


I mean, why are you separating fields, resizing the fields and selecting the even ones after resizing?


When I used the 1080i clips in that same script, the result was a very jumpy video, which I somewhat expected.


You can't use filters unless they're field-based...


This is what you can do to encode in 1080i NTSC using/refactoring your own script:


#Indexing
v=LWLibavVideoSource("J:\Clip.TS",fpsnum=30000, fpsden=1001)
a=LWLibavAudioSource("J:Clip.TS").Normalize()
AudioDub(v,a)

#trim
Trim(700,218080)

#Let's go to 4:2:0 planar 8bit
Converttoyv12(matrix="Rec.601", interlaced=true)

#From BT601 to BT709
ColorMatrix(mode="Rec.601->Rec.709", interlaced=true, threads=0, thrdmthd=0)

#Bobbing to 60p to remove dots
Bob()
UnDot()

#Re-interlace to 30i
assumeTFF()
separatefields()
selectevery(4,0,3)
weave()


At this point, you can encode with x264 using the --tff flag which will trigger MBAFF mode.
If the final result is choppy, it means that the fields were somehow not read properly.
Sometimes you need to specify AssumeTFF or AssumeBFF to get them correctly. Anyway, let me know...

[abyss616]

First: thank you for responding. I appreciate the help.
Second: why did I do what I did? Because I don't know what I'm doing! This is my first time working with 1080i material - I looked up a few threads on deinterlacing and that's what was recommended. ::shrug::

Using your edits gives me this in AVSMeter:
https://i.imgur.com/IDvPtnb.jpg?1

... and the resulting video is chaos - tries to give me a seizure, with or without the --tff switch.

MediaInfo says my source media is:
Scan type: Interlaced
Scan type, store method: Separated fields
Scan order: Top Field First

[FranceBB]

... and the resulting video is chaos - tries to give me a seizure, with or without the --tff switch.


Well, there's only one way to find out: upload few seconds of the source file so that I can take a look at it.
If it's really interlaced and the field parity is correct, then I guess there's something wrong in the metadata of the source file and the way they're passed to Avisynth by LWLibav.
For instance, if the source file says progressive but it's actually interlaced you would need an AssumeTFF() or AssumeBFF() before everything in Avisynth, otherwise bad things are gonna happen. But in the meantime, try with this:



#Indexing
FFMpegSource2("J:\Clip.TS", atrack=-1)
AssumeTFF()

#Loudness Correction to -24LUFS
Normalize(0.24)

#trim
Trim(700,218080)

#Let's go to 4:2:0 planar 8bit
Converttoyv12(matrix="Rec.601", interlaced=true)

#From BT601 to BT709
ColorMatrix(mode="Rec.601->Rec.709", interlaced=true, threads=0, thrdmthd=0)

#Bobbing to 60p to remove dots
Bob()
UnDot()

#Re-interlace to 30i
assumeTFF()
separatefields()
selectevery(4,0,3)
weave()


and encode with --tff

if it's still a mess, then try with:


#Indexing
FFMpegSource2("J:\Clip.TS", atrack=-1)
AssumeBFF()

#Loudness Correction to -24LUFS
Normalize(0.24)

#trim
Trim(700,218080)

#Let's go to 4:2:0 planar 8bit
Converttoyv12(matrix="Rec.601", interlaced=true)

#From BT601 to BT709
ColorMatrix(mode="Rec.601->Rec.709", interlaced=true, threads=0, thrdmthd=0)

#Bobbing to 60p to remove dots
Bob()
UnDot()

#Re-interlace to 30i
assumeTFF()
separatefields()
selectevery(4,0,3)
weave()


and encode with --tff.

If once again is a mess, then I gotta take a look at the the sample...
There are many things that can go wrong with interlaced stuff, but there's no way for us to find out without a sample, unfortunately...


MediaInfo says my source media is:
Scan type: Interlaced
Scan type, store method: Separated fields
Scan order: Top Field First

Well, that looks like a normal TFF, so it would be weird for the indexer not to have passed the field parity correctly unless, of course, the metadata are lying.

why did I do what I did? Because I don't know what I'm doing! This is my first time working with 1080i material

Don't worry. The question for you then is: do you want to preserve interlacing or would you rather like to have the final encode as progressive?
What I tried to do with the script is to deliver an interlaced result, but you could as well go for a progressive output.
Honestly it's up to you.
In my case, working in broadcast (although in a PAL country) I have to go to interlaced, but if you're a home user, you can go to progressive as well.

A few things to keep in mind:

- if you keep the encode as interlaced, you're gonna need less space as interlaced encodes take less space

- it's gonna be up to the decoder to deinterlace or bob-deinterlace for display according to the metadata. Pretty much any decent decoder can easily do that, like any players on Windows (MPV, MPC-HC, PotPlayer etc) or TVs etc.



Anyway, I'm gonna be here waiting for a sample.
Oh and in case you wanna go to progressive, we're gonna use something better than bob() of course xD


Side note about the "Loudness Correction": you have put a "Normalize()" there in your script without anything, so I assumed you wanted to use it to perform some kind of correction, so I put the values there, but if it's not what you wanted to do, then feel free to remove it.

[abyss616]

1) I've changed so many things around it's hard for me to keep track what I've tried, what I haven't, what worked, what didn't, and what the results look like.

2) It seems that demuxing the original TS file into separate audio/video streams with LWLibavVideoSource makes all the difference in the world in terms of encoding speed. The original script you posted encodes at ~8 fps using TS file as video input and ~76 fps using a demuxed h.264 video stream in an MKV container for video input.

3) What does it tell you that I took out everything from the script after ColorMatrix (so, Bob, UnDot, AssumeTFF, etc...) and just used the --tff switch in x264, and the result doesn't look all that bad? No combing effects, no jumping or anything. It's hard to get a great comparison when you're having to go back and forth between the original and output, but I don't think I can tell much of a difference.

[videoh]

Take FranceBB's advice and post a link to an unprocessed source clip with good motion. 50MB should be enough. You can use DGSplit on the source to cut it. Otherwise we are all just guessing.

[FranceBB]

Take FranceBB's advice and post a link to an unprocessed source clip with good motion. 50MB should be enough. You can use DGSplit on the source to cut it. Otherwise we are all just guessing.

Yep. @abyss616 post a sample.
I can't speculate over what could have gone wrong...


3) What does it tell you that I took out everything from the script after ColorMatrix and just used the --tff switch in x264, and the result doesn't look all that bad?

That you didn't mess up the fields 'cause Colormatrix is interlacing-aware?

But honestly, man, post a sample...
If you think that it's private and you wanna keep it confidential, can't you trim a part where there's only a landscape or nature or a part in which there's nobody and just objects? Anything will do...

[abyss616]

@FranceBB - sent you a PM.

Sorry - I somehow missed the part where you said you were waiting on me to post a sample.

[videoh]

Make it available for everyone!

[abyss616]

Make it available for everyone!
What's a free host service I can use? I'm not putting my Google account out for the public.

[StainlessS]

Mediafire is popular.

[real.finder]

also https://www.solidfiles.com/

[abyss616]

https://www.mediafire.com/file/fn81z4dygxuq7yi/2021_One_Shining_Moment.TS/file

[FranceBB]

@FranceBB - sent you a PM.


Gotcha!

Oh! But this is the NCAA! We air this! hahaha
When I first came to Sky Sports in 2017 they were like "and then there's the NCAA" and I was like "what the heck is that?" and they were like "Oh, college stuff" xD

Anyway, I can totally say that it's not your fault: the file is a recording from a CBS live feed, so it's truly interlaced and can be easily bobbed to 59.940fps progressive.
Now the problem is that both FFMpegSource2 and LWLibavVideoSource are broken due to the container which confuses them (they've never been working great with .ts as container) which is why you saw improvements once you remuxed.
Anyway, this is a simple H.264 truly interlaced top field first 29.970i and guess what indexed it correctly? The latest and greatest ffms2? Nope! LSMASH.dll? Nope... The 12 years old indexer DGAVCDecode made by Donald Graft (by the way, he's here, it's "videoh" and he's not a noob, the "noob" thing in his description is a joke, he knows more than you and me combined xD). :)

https://i.imgur.com/5eieTXB.png


So, once again, with kudos to Donald Graft for getting it right when others got it wrong, here is your script, using the 12 years old DGAVCDecode for video and the 15 years old NicAudio for audio (boys, we're getting old):


#Indexing
video=DGAVCDecode_AVCSource(dga="Z:\2021 One Shining Moment.dga", i420=yes, deblock=yes)
audio=NicAC3Source("Z:\2021 One Shining Moment PID 1100 2_0ch 48KHz 384Kbps DELAY -68ms.ac3")
AudioDub(video, audio)

#Trimming ads
trim(161, 5578)

#Bob-deinterlacing
AssumeTFF()
QTGMC(Preset="Medium")

#Clipping
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

#Loudness Correction
Normalize(0.22, show=false)


https://i.imgur.com/SIwvgaN.png

Note: the last two parts (Clipping + Loudness) are optional as you don't have to air anything and you can skip those if you want. Then encode with x264 like you've always done for progressive materials with no flags. ;)

Oh well since we're here, here is the x264 crf 18 encode with the script: https://we.tl/t-rUxYcxDEys

Cheers,
Frank

[videoh]

Thank you, FranceBB, for your kindness. Of course DGDecNV (DGIndexNV + DGDecodeNV) is preferred when an nVidia adapter is available, because one can use the PureVideo double-rate deinterlacer, which is quite effective and fast. The OP was concerned about the speed of his script so perhaps QTGMC may be an issue for him.

Always wondered why the alternative source filters cannot handle a relatively simple transport format. The specs are readily available and the authors are very smart people. Kinda baffling. A pathology of open-source development; multiple developers but no-one in particular wants to step up and fix things?

[StainlessS]

A pathology of open-source development; multiple developers but no-one in particular wants to step up and fix things?
Perhaps it requires someone who knows how to do it [subtle hint] :)

[FranceBB]

Of course DGDecNV (DGIndexNV + DGDecodeNV) is preferred when an nVidia adapter is available, because one can use the PureVideo double-rate deinterlacer, which is quite effective and fast. The OP was concerned about the speed of his script so perhaps QTGMC may be an issue for him.


Oh right, he came here for speed in the first place...
Well, if he has an NVIDIA GPU, then yes, DGDecNV is great.


@abyss616... If you have a modern NVIDIA GPU and your concern is speed, you can definitely use it. I've been using it with my NVIDIA Quadro P4000 for some years now and it works like a charm. It ain't free, though, but you get lots of activation in a licence for a very small fee.
Anyway, if you wanna stick with the free stuff and the script I posted above is too slow, you can replace QTGMC with:


tdeint(mode=1, order=-1, field=-1, mthreshL=6, mthreshC=6, map=0, type=2, debug=false, mtnmode=1, sharp=true, cthresh=6, blockx=16, blocky=16, chroma=true, MI=64, tryWeave=true, link=1, denoise=true)


which is gonna be faster.



Perhaps it requires someone who knows how to do it [subtle hint] :)

+1

[abyss616]

Thanks everyone -- especially FranceBB -- for the help. My main concern, in regards to the speed, was why it was so slow (exponentially so) when compared to the 720p60 source material I had been using. Plus, the only interlacing/deinterlacing I had done before was on VHS captures that needed to have QTGMC applied to it to get rid of combing. But from what I'm seeing, this doesn't need QTGMC - just AssumeTFF in the script and the -tff flag in x264 and I'm good to go. Sometimes, simpler is better (and faster).

While I appreciate Donald's efforts in the way of his indexer (I am a capitalist, after all), I'll stick with SMASH since its free and demuxing into an MKV container isn't hard to do. My encodes are getting ~113 fps on the first pass, which isn't close to the ~300 fps for 720p60, but it's much better than the ~10 I was getting before. I do have an NVIDIA GeForce GTX 1650 SUPER, so maybe it's something to look into.

[videoh]

I'll stick with SMASH since its free and demuxing into an MKV container isn't hard to do.

Then why is your source file a transport stream? :p It may not be hard but remuxing is totally unnecessary and amounts to a lame workaround.

For your use case, DGAVCDec is adequate and free.

Assuming a usage period of 5 years, the cost for DGDecNV is $3 per year. That's close enough to free for practical purposes.

You can use your GPU for encoding and get a large speed increase. Given the low quality of your capture and your use of fast presets for x264, there would be no significant downside to GPU encoding.

[abyss616]

For your use case, DGAVCDec is adequate and free.

Assuming a usage period of 5 years, the cost for DGDecNV is $3 per year. That's close enough to free for practical purposes.


I said I'd think about it ;)

[wonkey_monkey]

Well, if he has an NVIDIA GPU, then yes, DGDecNV is great.


Not quite all NVIDIA GPUs are supported, though (or, rather, not all NVIDIA GPUs have the functionality DGDecNV needs). I was a little miffed to find that my new laptop didn't, and might have considered a different model if I'd known at the time (the NVIDIA datasheets weren't clear enough; they've since been updated). Now I do an ffmpeg remux to .mkv and then use ffmpegsource2. It's about as fast as DGDecNV was on my previous 10-year-old laptop.

[abyss616]

I decided to do a comparison between DGAVC and LWLibavVideoSource on the same source - the UCLA vs Gonzaga Final Four game. It's the complete game; source clip is almost 3 hours long. A few of observations:

1) When using DGAVC to load my clip into VirtualDub so I can edit out the commercials, it is incredibly slow. It took me at least twice as long to do my edits that it would have with LWLibavVideoSource because scanning through the timeline was very sluggish. This is probably a deal-breaker for me - would DGDecNV be any better? If it was a movie where I just had to trim the beginning and end, it would be fine, but if I have to make a bunch of edits, it takes too long.

2) Using the same settings in MeGUI (bitrate @ 3500, two-pass), with DGAVC I got ~50 fps on pass 1 and ~47 fps on pass 2. With LWLibavVideoSource it was ~102 fps on pass 1 and ~56 on pass 2. Not the end of the world, just noting it.

Only difference between the two scripts was in the 'video' loading:

v=AVCSource(dga="D:\Video\UCLA-Gonzaga.dga", i420=yes, deblock=yes)
a=NicAC3Source("D:\Video\UCLA-Gonzaga PID 1100 2_0ch 48KHz 384Kbps DELAY -68ms.ac3").Normalize()

v=LWLibavVideoSource("D:\Video\UCLA-Gonzaga.mkv",fpsnum=30000, fpsden=1001)
a=NicAC3Source("D:\Video\UCLA-Gonzaga.ac3").Normalize()

I did not deinterlace as I didn't think it needed it. I think I've read that you shouldn't deinterlace unless you absolutely need to - is that right?

I should also note that the clip I shared earlier is not the best quality, but mostly because my CBS affiliate isn't that great. I've noticed that on other captures before. Other channels are much clearer. It was captured using the highest settings allowed on my device.

[FranceBB]

There's no need to load it in virtual dub, you can get the frame from the DGAVCDecode GUI which is faster.
About the fact that you shouldn't deinterlace unless you really need to, that's true, you can just keep it as it is, put the --tff flag there and call it a day. The resulting file in x264 will also be smaller 'cause it's interlaced

[manolito]

Tried the usual source filters for this uploaded source, and like FranceBB I found that neither FFVideoSource nor LWLibavVideoSource can handle this source.

Even after repacking the source to MKV these source filters had problems. Atak's SeekTester showed tons of corrupted frames, not useable at all.

Then I tried my pet source filter DSS2Mod with LAV Filters, and this was a big surprise. Using "preroll=50" (instead of my usual "preroll=15") I got a clean output without any errors at a very nice speed. :D

But generally I agree that TS files (especially if they are HD interlaced) should be repacked to MKV or MP4 before applying any processing. The TS format is aimed at preventing Audio / Video sync problems for broadcasts over SAT or terrestrial links. But once these files are captured to your HDD in a TS container, this TS format does no longer make any sense. Even Myrsloik urged users in an earlier post to repack TS files to a "real" container before applying any further processing.

[abyss616]

Tried the usual source filters for this uploaded source, and like FranceBB I found that neither FFVideoSource nor LWLibavVideoSource can handle this source.

Even after repacking the source to MKV these source filters had problems. Atak's SeekTester showed tons of corrupted frames, not useable at all.

Then I tried my pet source filter DSS2Mod with LAV Filters, and this was a big surprise. Using "preroll=50" (instead of my usual "preroll=15") I got a clean output without any errors at a very nice speed. :D

I hadn't heard of that program before, but ran it on a few files using LWLibavVideoSource.

All 1080i TS files that I tested came back with errors. Everything else -- 720p60 TS and remuxed 1080i MKVs from those same 1080i TS files -- came back OK. Even the MKV of the One Shining Moment TS file that I posted earlier didn't return any errors.

[kedautinh12]

Here: http://avisynth.nl/index.php/DSS2mod

[videoh]

1) When using DGAVC to load my clip into VirtualDub so I can edit out the commercials, it is incredibly slow. It took me at least twice as long to do my edits that it would have with LWLibavVideoSource because scanning through the timeline was very sluggish. This is probably a deal-breaker for me - would DGDecNV be any better? If it was a movie where I just had to trim the beginning and end, it would be fine, but if I have to make a bunch of edits, it takes too long. DGAVCDec has been deprecated for a decade or more. It was suggested only because it handles TS correctly and you were reluctant to try DGDecNV. DGDecNV will of course perform much faster. For example here is your stream with PureVideo double-rate deinterlacing enabled:

D:\Downloads>avsmeter64 "2021 One Shining Moment.avs"

AVSMeter 2.7.5 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Number of frames: 12130
Length (hh:mm:ss.ms): 00:03:22.369
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 12130 (0 - 12129)
FPS (min | max | average): 331.9 | 849.1 | 783.6
Memory usage (phys | virt): 307 | 659 MiB
Thread count: 19
CPU usage (average): 12%

Time (elapsed): 00:00:15.479

Deinterlacing is effectively free.

2) Using the same settings in MeGUI (bitrate @ 3500, two-pass), with DGAVC I got ~50 fps on pass 1 and ~47 fps on pass 2. With LWLibavVideoSource it was ~102 fps on pass 1 and ~56 on pass 2. Not the end of the world, just noting it.

Only difference between the two scripts was in the 'video' loading:

v=AVCSource(dga="D:\Video\UCLA-Gonzaga.dga", i420=yes, deblock=yes)
a=NicAC3Source("D:\Video\UCLA-Gonzaga PID 1100 2_0ch 48KHz 384Kbps DELAY -68ms.ac3").Normalize()

v=LWLibavVideoSource("D:\Video\UCLA-Gonzaga.mkv",fpsnum=30000, fpsden=1001)
a=NicAC3Source("D:\Video\UCLA-Gonzaga.ac3").Normalize() Here you conveniently neglect to consider the time spent re-muxing to MKV.

It's not a coincidence that the guys pushing re-muxing to MKV are the same ones who have source filters that fail on transport streams. :sly:

[videoh]

it's "videoh" and he's not a noob, the "noob" thing in his description is a joke Yes. "Useful n00b" is a play on Doom9's description "Clueless n00b".

[videoh]

Then I tried my pet source filter DSS2Mod To be clear it was authored by forclip. Also, AFAIK it has not been updated for high bit depth.

[videoh]

The TS format is aimed at preventing Audio / Video sync problems for broadcasts over SAT or terrestrial links. This guy is apparently unaware that bluray disks (both HD and UHD) use transport streams. The rationalization is off the charts.

[StvG]

Tried the usual source filters for this uploaded source, and like FranceBB I found that neither FFVideoSource nor LWLibavVideoSource can handle this source.

Even after repacking the source to MKV these source filters had problems. Atak's SeekTester showed tons of corrupted frames, not useable at all.

I guess you used ffmpeg for remuxing to mkv. Try mkvmerge/mkvtoolnix for remuxing to mkv - that way SeekTester shows no error (both ffms2 and lsmash tested).

Edit: For this sample the bitstream framerate doesn't match the container one. In that case ffmpeg takes the bitstream framerate into account while mkvmerge/mkvtoolnix takes the conatainer one.

[manolito]

To be clear it was authored by forclip. Also, AFAIK it has not been updated for high bit depth.
Of course forclip has written this filter. The "my" is directed to "pet", not to "filter".

And why in hell it was decided to use transport streams for BluRay is beyond me. Bad design decision IMO... :p

https://forum.doom9.org/showthread.php?p=1921871#post1921871

[manolito]

I guess you used ffmpeg for remuxing to mkv. Try mkvmerge/mkvtoolnix for remuxing to mkv - that way SeekTester shows no error (both ffms2 and lsmash tested).

Edit: For this sample the bitstream framerate doesn't match the container one. In that case ffmpeg takes the bitstream framerate into account while mkvmerge/mkvtoolnix takes the conatainer one.

Yes, you are right...

Using MKVToolNix to repack the TS source to MKV solves it. But out of curiosity I did some more tests, and the results were a little surprising:

When using ffmeg to convert the TS file to either MKV or MP4 the conversion finishes, but I get this error:
[mpegts @ 04e18240] PES packet size mismatch
[mpegts @ 04e18240] Packet corrupt (stream = 1, dts = 18247954)
And sure enough the resulting MKV or MP4 files had seek problems.

I also tried MP4Box to repack the TS to an MP4 file, but no luck either.

What did fix it to my surprise was treating the source TS with TS-Doctor. TS-Doctor did not find any issues with the source, it did not try to repair anything. But creating a "fixed" TS file (which just removed padding which is always present in captured transport streams) solved all previous issues. The fixed TS file did no longer have any seek problems in Atak's SeekTester, and a test conversion using the latest LWLibavVideoSource by HolyWU was quite fast and the result was perfect.

[kalehrl]

I always run a ts file through MeGUI's or staxrip's eac3to. If there are inconsistencies in the file, they are "corrected" meaning the audio will stay in sync with the video. You can read in the log file if any corrections are applied.