Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
![]() |
#21 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,566
|
Argh,... I give up all the following calls:
Code:
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/ED-360-png/%05d.png" -frames:v 15691 -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\elephantsDream_360.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/ED-1080-png/%05d.png" -frames:v 15691 -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\elephantsDream_1080.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/tearsofsteel-4k.y4m" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\tearsofsteel-4k.xvc Using another encoder like x264 or x265 instead of xvcenc didn't crash. Cu Selur Ps.: I also reencoded a 8bit console lagaringth capture using: Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 24 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_24.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_30.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 34 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_34.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 40 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_40.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 50 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_50.xvc Code:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 60 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_60.xvc Last edited by Selur; 9th February 2018 at 23:34. |
![]() |
![]() |
![]() |
#22 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
Thanks Selur for sharing.
I tried to replicate your ED-360 encoding using both master (730987c) and dev (452170c) and both of my encodings completed successfully. Did you use the same compiled encoder for all your runs? (I.e. version 1 of xvc - from the master branch) Did you change anything compared to the other run that you reported in your earlier post (which from my understanding, was completed successfully) other than using -qp 18 -explicit-encoder-settings "aqp_strength 16"? Please share any information you have about the crash (potential error message or printout, verbose output etc.) Did you compile for 32-bit or 64-bit architecture? |
![]() |
![]() |
![]() |
#23 | Link | ||||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,566
|
Quote:
Quote:
Quote:
Quote:
Cu Selur |
||||
![]() |
![]() |
![]() |
#24 | Link |
Registered User
Join Date: Mar 2002
Posts: 864
|
I ran a few tests with Selur's build (thanks btw). I did not test a wide variety of bitrate ranges and just tried a few test videos, but this encoder consistently beats av1 in all cases. Very promising, good job jonatans!
|
![]() |
![]() |
![]() |
#27 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Not sure if I'm doing something wrong here. It took my 12-core Xeon roughly 53 seconds per frame to encode a 10-frame test, using a 1080p60 source. I used Selur's (hi!) build of xvcenc and one of his encoding scripts from post #21.
update: There's apparently some sort of a set-up cost at the beginning of the process. A 300-frame long encode just finished in 3179 seconds, i.e. an average of 11 seconds per frame. CPU load held steady at 5.5% during the encode. Last edited by colinhunt; 8th March 2018 at 21:08. |
![]() |
![]() |
![]() |
#28 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
I uploaded two source files and two encoding tests here: https://drive.google.com/open?id=1Hv...UnL-VbQybO6Zfd
The 1080p59.94 source footage was shot by me. Feel free to use the provided source files for your encoding testing (altho the footage is not for re-sale). The 15-second source clips are encoded in 1) 8-bit 4:2:0 AVC at 42 Mbps (.mp4, 76MB) and 2) 8-bit 4:2:2 DNxHR SQ at 291 Mbps (.mov, 525MB). |
![]() |
![]() |
![]() |
#29 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
Thanks colinhunt! Nice to see that it's working ok.
Quality seems fine on your encodings, given that it's a compression ratio of around 50:1 compared to the mp4 file and around 350:1 compared to the mov file. It's true that the encoding is slow, and there is no multi-threading. However, a nice property of the .xvc files is that you can concatenate any two of them to create a new valid .xvc file. So if you want to encode a longer sequence and use more than a single core, you can split up the work and then merge the output files at the end. It will however result in closed-GOP intra pictures so it will have a negative visual impact (especially at low rates and at short clips). I created a simple python script for doing this. It expects a y4m input file but it should be possible to extend it to support any input format by adding a call to ffmpeg and using a seek operation to fetch the right part. https://drive.google.com/open?id=1hR...ijjl72SpSGMYYV I have also uploaded new binaries built from the latest commit of the dev branch. The default speed mode is now even slower than in version 1 (but also produces better quality) but there is also a speed-mode 2 which should give faster encoding times than xvc version 1.0 (and hopefully also better visual quality). It should be noted that these are experimental binaries for evaluation purposes only. It has not yet been decided what the final set of coding tools in xvc 2.0 will be. https://drive.google.com/open?id=1kW...uQTZP-Rqqdy9Jx |
![]() |
![]() |
![]() |
#30 | Link | |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Quote:
Thanks for the python script and new binaries! |
|
![]() |
![]() |
![]() |
#31 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Got an error from the new encoding binary (I named it xvcenc_dev.exe). First here's the script I ran:
ffmpeg -y -loglevel fatal -threads 8 -i "10bit-dnxhd.mov" -frames:v 100 -an -sn -vsync 0 -pix_fmt yuv422p -f yuv4mpegpipe - | xvcenc_dev.exe -input-file - -verbose 1 -input-chroma-format 2 -input-bitdepth 10 -speed-mode 2 -qp 25 -explicit-encoder-settings "aqp_strength 16" -output-file d:\output.xvc Note: source is 10bit 4:2:2 DNxHD 1080p59.94. ffplay has no problem playing it, and ffmpeg transcodes it just fine. Error msg: Assertion failed: 0, file C:\Users\jonat\proj\xvc\app\xvc_enc_app\y4m_reader.cc, line 93 Currently encoding the same source using Selur's build, same parameters except without "-speed-mode 2". Hasn't crashed so far. update - uploaded the DNxHD source to shared folder: "fruit--dnxhd-10bit-422-440mbps--1080p5994.mov" (1.16 GB) Last edited by colinhunt; 9th March 2018 at 16:45. |
![]() |
![]() |
![]() |
#32 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
Thanks for pointing this out!
The reason for the assert is that the y4m read function did not have support for 422. We have just checked in a fix to that. (There was no such support in version 1 either, but that binary might have been compiled without the asserts) Here is a new binary: https://drive.google.com/open?id=1iJ...yQmWu6EwPwOQ10 Now it should be able to understand both 422 and 444 directly from the y4m file so there is no need to indicate "-input-chroma-format 2 -input-bitdepth 10". I hope it works fine now! |
![]() |
![]() |
![]() |
#33 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Thanks!
Hmm.. I'm seeing this upon running the new binary, regardless of whether parameters include "-input-chroma-format 2 -input-bitdepth 10" or not (tried both ways): Input: - Output: d:\output.xvc Size: 1920x1080 Bitdepth: 8 Framerate: 59.9401 QP: 25 Selur's build reported a bitdepth of 10 with same source file. |
![]() |
![]() |
![]() |
#34 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
Hi again,
I think the problem relates to the settings for the ffmpeg pipe. In order to support 10 bit you need to add "-strict -1" and change from "-pix_fmt yuv422p" to "-pix_fmt yuv422p10le". Or remove the "-pix_fmt" parameter altogether if you want ffmpeg to pipe the same format as the original file. That seems to be working fine for me. |
![]() |
![]() |
![]() |
#35 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
^ Thank you!
I let that previous "Bitdepth: 8" encode finish. When I played it, decoder reported both output and internal bitstream had a bitdepth of 10. Well, no matter, I removed "-pix_fmt" and added "-strict -1" , and encoder is now reporting 10bit. Last edited by colinhunt; 9th March 2018 at 18:52. |
![]() |
![]() |
![]() |
#36 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Added a new source file to the share. It's a 10-bit 4:2:2 1080p24.00 DNxHD .mov of motocross bikes rushing off from the starting line. Also added a qp32 xvc encode of that source with a bitrate of approx. 1 Mbps.
Source files in share: Fruits ![]() Moss ![]() Moto ![]() Last edited by colinhunt; 11th March 2018 at 12:25. |
![]() |
![]() |
![]() |
#37 | Link |
Angel of Night
![]() Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,562
|
So is this an automatic 2-pass? The length of time before real encoding starts seems to indicate that it's doing some serious analysis beforehand. Is there a plan for developing a streaming encoder, or is the format generally designed only for archival?
|
![]() |
![]() |
![]() |
#38 | Link | ||
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
Quote:
The encoding is quite slow so it will take some time before the first picture has been encoded (and the statistics of that picture is output if -verbose 1 is used), so maybe that is the reason why it appears to take long time before encoding is started. |
||
![]() |
![]() |
![]() |
#39 | Link | |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Quote:
![]() x265 (green) catches up with xvc (red) briefly at frame 250, also somewhere around frames 332-335, and from frame 385 onwards it fares slightly better than xvc on average. It's perhaps worth noting that I used speed-mode 2 for the xvc encode. (Argh. Noticed now that I had misnamed the files; instead of 1080p5994 both should have read 1080p24.) Last edited by colinhunt; 14th March 2018 at 15:03. |
|
![]() |
![]() |
![]() |
Tags |
codec, compression, video codec, video encoding, xvc |
Thread Tools | Search this Thread |
Display Modes | |
|
|