1 Reply by _Shorty

(18 replies, posted in Using SVP)

AlvinB wrote:

You're right, NVEncC supports passthrough of HDR10 metadata, which ffmpeg currently lacks when using Nvidia HEVC encoding. Switching to NVEncC in SVP transcoder would indeed be beneficial for preserving HDR metadata during the encoding process.

As I just mentioned, you just need to tell ffmpeg what to use.  Doesn't look like SVP currently passes along all commands properly, though.

Go to forum: Using SVP

2 Reply by _Shorty

(18 replies, posted in Using SVP)

I have written a python script to take files that probably have bitrate overkill and make them smaller by targeting a specific VMAF score to suit my needs.  In it I use ffprobe to check for HDR metadata, and when it exists I extract it and ensure the encoding job uses the same metadata in the x265 command so the output file is still an HDR file when the input file is an HDR file.  I don't see why SPV couldn't do the same thing.  I think we can probably manually accomplish this by editing the x265 parameters, but SPV should be able to automate that.

edit:  Well, maybe not.  An example file I have would need these parameters:

X265 Parameters:
hdr10=1
hdr10-opt=1
repeat-headers=1
colorprim=bt2020
range=limited
transfer=smpte2084
colormatrix=bt2020nc
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)
max-cll=1655,117

But when you try to add those manually to the x265 parameters the dialog box doesn't let you enter the last two lines properly.  It interprets the commas as new-line characters and you get a bunch of new lines added that are nonsensical as a result, like this:

master-display=G(13250
34500)B(7500
3000)R(34000
16000)WP(15635
16450)L(40000000
50)
max-cll=1655
117

edit2: Unfortunately the parameters didn't work for me anyway.  But hopefully the devs can get this working.  Doesn't seem like too hard of a job to extract the necessary metadata and use that going forward from there.

Go to forum: Using SVP

3 Reply by _Shorty

(3 replies, posted in Using SVP)

Yeah, it doesn't seem like this was written by someone whose native language is English.  It seems to me as though Small will use the least CPU for this portion of the job, and Average will use a medium amount of CPU, and Large will use the most amount of CPU.  And I believe it is talking about how much CPU to use in the area where it matters the least, at the coarse end of the hierarchy.  Once it gets to the fine end of the hierarchy that is where spending more CPU will make more of a difference, or show better results.  I think what it means is that at this point of the job the amount of CPU that you spend will not be as important so you might not want to bother spending more CPU since it should affect the final result the least.  You can set it to Average or Large if you still want it to spend more CPU here, but the effect on the final result may be what is called diminishing returns.  You won't likely see a difference compared to the amount of CPU spent.

I could be wrong.

Go to forum: Using SVP

4 Reply by _Shorty

(4 replies, posted in Using SVP)

Today I only see 360p mp4 videos available to download with some videos.  All the other formats, including 360p V+A, have the line through them and won't download/play.  This is not true of all videos, however.  Some are giving me access to 720p and 1080p formats just fine.  Here is an example of one that is only letting me access the 360p mp4 format.

https://www.youtube.com/watch?v=k7dEvOvAV5I

Go to forum: Using SVP

5 Topic by _Shorty

(0 replies, posted in Using SVP)

More or less just a cosmetic bug, but it seems like the fps counter continues running while you have it paused.  Obviously this doesn't really affect much other than the estimated time for completion gains error at the same time, and the longer it has been paused the less accurate the estimation becomes.  Once you unpause it the estimation quickly runs down as the work completes much quicker than the incorrect average fps would indicate.

Go to forum: Using SVP

6 Reply by _Shorty

(17 replies, posted in Using SVP)

That appears to be working just fine for me.  I disallowed 10-bit output and put ";deband" in the lavfi line, and I got an 8-bit file and it appears much better than the previous version.  Thank you very much for taking the time to look into this, and coming up with a fix.  Much appreciated.

00:37:43.507: ===== Starting mpv ======
00:37:43.507: Command line: C:\Program Files (x86)\SVP 4\mpv64\mpv.exe C:/temp5/test1-short.mkv -o C:/temp5/test1-short.SVP.temporary.mkv --no-audio --no-sub --no-sub-auto --input-ipc-server=mpvencodepipe --input-media-keys=no --no-msg-color --vf=vapoursynth:[C:\Users\Clay\AppData\Roaming\SVP4\scripts\ffff.py]:4:12,lavfi=[deband] --of=matroska --ovc=libx264 --ovcopts=preset=superfast,crf=18,threads=12
00:37:43.546: (+) Video --vid=1 (*) (hevc 3840x2160 25.000fps)
00:37:43.546: Audio --aid=1 (*) (ac3 6ch 48000Hz)
00:37:43.546: Audio --aid=2 (*) (eac3 6ch 48000Hz)
00:37:45.443: VO: [lavc] 3840x2160 yuv420p
00:37:45.444: [vo/lavc] Opening encoder: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [libx264]
00:37:45.444: [ffmpeg] libx264: MB rate (777600000) > level limit (16711680)
00:37:45.462: [encode] Opening output file: C:/temp5/test1-short.SVP.temporary.mkv
00:37:45.463: [encode] Opening muxer: Matroska [matroska]
00:37:45.495: V: 00:00:00 / 00:00:04 (1%) {0.0min 0.0MB}
00:37:54.503: [encode] video: encoded 28153705 bytes
00:37:54.503: [encode] audio: encoded 0 bytes
00:37:54.503: [encode] muxing overhead 2976 bytes
00:37:54.508: Exiting... (End of file)
00:37:54.581: ===== Starting mkvmerge ======
00:37:54.581: Command line: C:\Program Files (x86)\SVP 4\extensions\code\mkvmerge.exe -o C:/temp5/test1-short.SVP.mkv C:/temp5/test1-short.SVP.temporary.mkv -D C:/temp5/test1-short.mkv
00:37:54.635: mkvmerge v35.0.0 ('All The Love In The World') 32-bit
00:37:54.652: 'C:/temp5/test1-short.SVP.temporary.mkv': Using the demultiplexer for the format 'Matroska'.
00:37:54.668: 'C:/temp5/test1-short.mkv': Using the demultiplexer for the format 'Matroska'.
00:37:54.668: 'C:/temp5/test1-short.SVP.temporary.mkv' track 0: Using the output module for the format 'AVC/h.264'.
00:37:54.669: 'C:/temp5/test1-short.mkv' track 1: Using the output module for the format 'AC-3'.
00:37:54.669: 'C:/temp5/test1-short.mkv' track 2: Using the output module for the format 'AC-3'.
00:37:54.669: The file 'C:/temp5/test1-short.SVP.mkv' has been opened for writing.
00:37:54.682: Progress: 27%
00:37:54.741: Progress: 100%
00:37:54.741: The cue entries (the index) are being written...
00:37:54.751: Multiplexing took 0 seconds.

Go to forum: Using SVP

7 Reply by _Shorty

(17 replies, posted in Using SVP)

Chainik wrote:

in this log you just re-encoded 10-bit source as 10-bit, w/o any conversion at all

---
update to the latest SVP rev.182 (it includes dithering in the Vaporsynth script) and put deband filter into lavfi field

Yes, I was confirming the behaviour you were saying I should see since the option did not actually exist, and how a mistake I made had me thinking it was successfully converted when in fact it was not.

Thanks!  I will try the update now.

Go to forum: Using SVP

8 Reply by _Shorty

(17 replies, posted in Using SVP)

Oh, for crying out loud.  I see what I did now.  Ok, at some point during various file edit/copy operations I ended up saving some x264 lossless source files that were edited to just some short test segments.  And for some of them I had let Handbrake do the 10-bit to 8-bit conversion, which I was using just for testing various CRF values.  And when I got back to testing the SVP stuff again really late that night it appears I may have been selecting those pre-converted files as my source.  And that's apparently how I ended up with 8-bit conversions that looked ok with the non-existent ovcopts pix_fmt option.  Argh.  Sorry for that waste of a bit of time.

Go to forum: Using SVP

9 Reply by _Shorty

(17 replies, posted in Using SVP)

My mistake!  I am seeing the same thing you're seeing now.

16:46:36.162: ===== Starting mpv ======
16:46:36.162: Command line: C:\Program Files (x86)\SVP 4\mpv64\mpv.exe C:/temp5/test2.mkv -o C:/temp5/test2.SVP.temporary.mkv --no-audio --no-sub --no-sub-auto --input-ipc-server=mpvencodepipe --input-media-keys=no --no-msg-color --vf=vapoursynth:[C:\Users\Clay\AppData\Roaming\SVP4\scripts\ffff.py]:4:12 --of=matroska --ovc=libx264 --ovcopts=preset=superfast,crf=18,pix_fmt=yuv420p,threads=12
16:46:36.198: (+) Video --vid=1 (*) (hevc 3840x2160 25.000fps)
16:46:36.198: Audio --aid=1 (*) (ac3 6ch 48000Hz)
16:46:36.198: Audio --aid=2 (*) (eac3 6ch 48000Hz)
16:46:37.175: VO: [lavc] 3840x2160 yuv420p10
16:46:37.185: [vo/lavc] AVOption 'pix_fmt' not found.
16:46:37.189: [vo/lavc] Opening encoder: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [libx264]
16:46:37.190: [ffmpeg] libx264: MB rate (777600000) > level limit (16711680)
16:46:37.225: [encode] Opening output file: C:/temp5/test2.SVP.temporary.mkv
16:46:37.225: [encode] Opening muxer: Matroska [matroska]
16:46:37.250: V: 00:00:00 / 00:00:20 (0%) {0.0min 0.0MB}
16:46:40.972: Script exceeded memory limit. Consider raising cache size.
16:47:17.760: [encode] video: encoded 69755088 bytes
16:47:17.760: [encode] audio: encoded 0 bytes
16:47:17.760: [encode] muxing overhead 10694 bytes
16:47:17.764: Exiting... (End of file)
16:47:17.840: ===== Starting mkvmerge ======
16:47:17.840: Command line: C:\Program Files (x86)\SVP 4\extensions\code\mkvmerge.exe -o C:/temp5/test2.SVP.mkv C:/temp5/test2.SVP.temporary.mkv -D C:/temp5/test2.mkv
16:47:17.894: mkvmerge v35.0.0 ('All The Love In The World') 32-bit
16:47:17.906: 'C:/temp5/test2.SVP.temporary.mkv': Using the demultiplexer for the format 'Matroska'.
16:47:17.931: 'C:/temp5/test2.mkv': Using the demultiplexer for the format 'Matroska'.
16:47:17.931: 'C:/temp5/test2.SVP.temporary.mkv' track 0: Using the output module for the format 'AVC/h.264'.
16:47:17.931: 'C:/temp5/test2.mkv' track 1: Using the output module for the format 'AC-3'.
16:47:17.931: 'C:/temp5/test2.mkv' track 2: Using the output module for the format 'AC-3'.
16:47:17.932: The file 'C:/temp5/test2.SVP.mkv' has been opened for writing.
16:47:17.944: Progress: 9%
16:47:18.112: Progress: 100%
16:47:18.112: The cue entries (the index) are being written...
16:47:18.121: Multiplexing took 0 seconds.

So now I'm confused as to what I ended up doing to end up with the 8-bit file that turned out with a better conversion.  Going to have to see if I can remember what steps I ended up taking to get here from there.  I could've sworn that's all I did, pix_fmt=yuv420p, but apparently that can't be correct.  Hmm...

Go to forum: Using SVP

10 Reply by _Shorty

(17 replies, posted in Using SVP)

As I said, lavfi: ";format..." does not work.  It produced the same incorrect output as "allow 10-bit" off did.  Putting "pix_fmt=yuv420p" in ovcopts works.  I've got output files that I am not imagining that show this to be the case.  They actually exist on my machine, hehe. wink  In case it wasn't clear, I am talking about transcoding, which means ffmpeg, no?  Doesn't vo/lavc have to do with the player and not the encoder?  Do you not use ffmpeg to encode?  Because I see ffmpeg.exe in SVP's utils directory.  Encoding with ffmpeg means --pix_fmt is a valid option, which also happens to provide correct output files.  And I thought that's what the ovcopts were when you were using libx264/libx265, ffmpeg command line options.  Sure seems to be the case, since it worked.

Go to forum: Using SVP

11 Reply by _Shorty

(17 replies, posted in Using SVP)

This doesn't appear to work.  It looks the same as when disallowing 10-bit output.

lavfi: ;format=pix_fmts=yuv420p

I think there might be something wrong with that, or the lavfi documentation is incorrect.

https://ffmpeg.org/ffmpeg.html

The section on pixel format states:

"-pix_fmt[:stream_specifier] format (input/output,per-stream)
Set pixel format. Use -pix_fmts to show all the supported pixel formats."

So it appears -pix_fmt is for setting the format, and -pix_fmts is for getting a list of available formats.  I get an error if I remove the s from it, though.
Anyway, back on topic...

This worked, though!

ovcopts: pix_fmt=yuv420p

The output from that, with 10-bit output allowed, gives an 8-bit output file that looks very similar to the Handbrake output.  So that will work just great!  Here's the test sample if you're still curious.  Thanks again for the help.

https://www.dropbox.com/s/idedyznh71do0 … t.mkv?dl=0

Go to forum: Using SVP

12 Reply by _Shorty

(17 replies, posted in Using SVP)

I turned "Allow 10-bit output" in SVP off, as I thought that was the way to get it to convert the 10-bit source to 8-bit.

Go to forum: Using SVP

13 Reply by _Shorty

(17 replies, posted in Using SVP)

Gave it a try on a small sample that I had noticed the issue on, and it doesn't really appear to be doing much.  Tried looking at the difference between the two SVP images in Photoshop with a difference blend, and the difference image was almost completely black, as in there was very little change, so perhaps the issue is not in the workflow position that --deband would affect things.  Here is a small portion of the sky in a particular frame that illustrates the banding issue.  If you mouse-over on the four different labels or press the corresponding number on your keyboard it will switch between those four samples.  One is the 10-bit original, one is the 8-bit conversion done by Handbrake, one is SVP 8-bit, and finally one is SVP 8-bit with --deband.  This is from the very first frame of the test sample, so the frame shouldn't be any different between each sample, other than colour conversion.

http://www.framecompare.com/image-compa … n/JMBMFNNU

edit:  Both Handbrake and SVP were using x264 medium CRF 18.

Go to forum: Using SVP

14 Reply by _Shorty

(17 replies, posted in Using SVP)

Thank you very much!  I'll give it a try, as well as read through that whole list as I find some time.  Appreciate it.

Go to forum: Using SVP

15 Topic by _Shorty

(17 replies, posted in Using SVP)

I've got some 10-bit stuff that I'm converting to 8-bit.  Mainly I'm just doing this because my HTPC is still on Win7, which doesn't properly support 10-bit playback.  I've noticed that the 8-bit colour conversion that SVP does during transcoding when 10-bit output is disabled is noticeably worse than what Handbrake manages to do when it converts to 8-bit colour.  There is a lot more banding and blockiness noticeable in the SVP conversion.  Might this be something simple to fix on SVP's side, or would it be complicated to fix?  Thanks.

Go to forum: Using SVP