Encoding 1080i clips with x264 incredibly slow

[videoh]

Originally Posted by abyss616

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? 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]

Originally Posted by videoh

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]

Originally Posted by FranceBB

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.

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]

Originally Posted by 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.

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]

Originally Posted by abyss616

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.

[videoh]

Originally Posted by FranceBB

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]

Originally Posted by manolito

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]

Originally Posted by manolito

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]

Originally Posted by 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.

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]

Originally Posted by videoh

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...

https://forum.doom9.org/showthread.p...71#post1921871

[manolito]

Originally Posted by StvG

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.