Now mark the thread resolved. ;) Please have some real x265 encoding numbers to show us, both with SW and HW decoder. Just curious about performance differences on a newer and faster machine. How much GPU memory do so many threads use? Just keep GPU-Z in background and use appropriate AVSMeter swit...

Rocky wrote: ↑

Tue Dec 28, 2021 1:51 pm

OK, thank you.

As per gentle help on MKVToolnix thread, I have found this repo https://github.com/nu774/mp4fpsmod with sources to extract timestamps from mp4 files.

Rocky wrote: ↑

Tue Dec 28, 2021 1:34 pm

Why would I want to do that?

As first iteration to have an idea of "timestamps" for mp4.

Specifications have been added to previous message.

Link me to a sample timestamps.txt file, or the MKV spec for it. I'm not going on wild goose chases. Ok, let me create one for you. In the mean time, you can use ffprobe to display the presentation time stamp (PTS) of every 'packet' in a MP4. ffprobe -show_entries packet=pts_time,duration_time,stre...

OK. Please provide a timestamps.txt file as needed for the sample you gave. How are you currently creating this file? Well, I am not , at least not from MP4. On MKV, you simply extract the existing one with mkvextract "movie.mkv" timestamps_v2 1:timestamps_track1.txt My request was exactly to creat...

gonca wrote: ↑

Tue Dec 28, 2021 11:46 am

I'll stick to DGIndexNV

And of course I will too... :belly-laugh:

Would you put some effort in making DGIndexNV to support variable frame rate video (usually mp4 but mkv too), creating a timestamps.txt file to be used in Matroska while indexing?

Example: https://send.cm/d/78Yq (valid 7 days)

gonca wrote: ↑

Tue Dec 28, 2021 7:07 am

Using VapourSynth Editor to bench mark script

And FFMS2 as reference?

Could you please disable it when launching the indexing process thru CLI?

On batch jobs it has no sense.

Some results with AVSMeter64 and simple AVS scripts, just the few lines to serve the video: DG: AVSMeter 3.0.8.0 (x64), (c) Groucho2004, 2012-2021 AviSynth+ 3.7.1 (r3577, master, x86_64) (3.7.1.0) Number of frames: 34377 Length (hh:mm:ss.ms): 00:23:53.807 Frame width: 1920 Frame height: 1080 Framera...

renols wrote: ↑

Mon Dec 27, 2021 3:32 pm

Maybe I am missing something with your workflow, but x265 is just much more CPU hungry than x264.

I know. Tomorrow in the morning I will try some tests with avsmeter and x264.

gonca wrote: ↑

Mon Dec 27, 2021 3:49 pm

Are you using 100% of the cpu during the encodes?

When using --preset slow yes, with --preset medium almost always with rare decreases to 96/97%.

gonca wrote: ↑

Mon Dec 27, 2021 3:19 pm

Guest 2, what is the cpu usage during each scenario?

As I wrote in my first message, i7-2600k @ 4.5 GHz

You didn't answer my questions about which version of x265 and how you feed the script to it. avs+ [INFO]: AviSynth+ 3.7.1 (r3577, master, x86_64) x265 [INFO]: HEVC encoder version 3.5+21+12-cb341a7ef [Mod by Patman] The AVS script is generated and launched by StaxRip. I did another test with a m2t...

Some data for MKV, will update later with M2TS results.

Recompression from 1080p mkv x264 to x265 (same command line as before).

DG: encoded 33596 frames in 2256.04s (14.89 fps), 1126.28 kb/s, Avg QP:27.89
FF: encoded 33596 frames in 2320.88s (14.48 fps), 1126.28 kb/s, Avg QP:27.89

Any chance to try with an M2TS? I will. You need a script to invoke DGSource, so you are confusing me. I meant: the scripts are really minimal, just the necessary few lines to invoke DG or FF. Not doing any prefetch games (possibly transparently by staxrip)? As far I can see, the script is plain si...

1. the source details 2. both scripts 3. the target format details 4. the performance details for both cases 1) Plain 1080p anime in mkv container, x264 8000 kbit/s cbr 2) No script at all, i.e. the plain lines to serve video to x265, nothing else 3) HEVC 10 bit mkv, x265.exe --crf 22 --tune animat...

gonca wrote: ↑

Mon Dec 27, 2021 7:51 am

I believe that DGDecodeNV frame serves, not encodes, your cpu is doing the encoding.

Serving, serving. My mistake.

It was ages I didn't try to encode something with the support of a software decoder. I had a bunch of anime to encode during xmas to HEVC and I tried to give the batch process of StaxRip a run. Before configuring StaxRip to properly index using DGIndexNV, it had FFVideoSource as default. Well, with ...

Rocky wrote: ↑

Thu Dec 23, 2021 10:04 am

What's more gooder about it compared to Notepad++?

Constant development and resolved issues on github. Nice authors too.

Rocky wrote: ↑

Thu Dec 23, 2021 8:47 am

Seems we can force any application to use UTF-8 this way.

Very nice indeed.

Rocky wrote: ↑

Thu Dec 23, 2021 8:47 am

Notepad++

Try https://github.com/rizonesoft/Notepad3. I had no turning back

Rocky wrote: ↑

Wed Dec 22, 2021 12:07 pm

Thank you!

You are the most welcome, my friend.

Re-generate the DGNV files with the manifest enabled and you will see the C3 A0 values. Content of my DGIndexNV directory: 13/08/2021 02:12 12.288 chapters2qp.exe 27/11/2021 12:44 211 demux2732.txt 08/12/2021 22:42 3.764.224 DGDecodeNV.dll 05/11/2020 18:28 28.632 DGDecodeNVManual.html 27/11/2021 14...

The FFMS file is not UTF-8. A doubt arose in my brain: why, if DGIndexNV avs and dgi are UTF-8, the "à" vowel is not displayed correctly in all the text editors I have tried, when choosing UTF-8 as text encoding? Notepad3, Windows Notepad and UltraEdit recognize them as ANSI Latin I or Western Euro...

Rocky wrote: ↑

Tue Dec 21, 2021 10:55 am

The FFMS file is not UTF-8. It is extended ASCII. I do not have any plans to generate extended ASCII files in DGDecNV. You have UTF-8 if you ask for it with the manifest, or you have whatever is defined in your system locale.

Ah, ok.

Thanks.