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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th August 2020, 14:22   #2181  |  Link
Statick
Registered User
 
Join Date: Aug 2016
Posts: 26
I'm having a weird issue with avisynth colourspaces in the preview window in staxrip. I'm not sure if this is intentional behaviour or if I'm just missing something, as I don't fully understand this

if I assign my source clip to a variable, and then return that variable, the preview window stops working as expected, and instead shows "raw" data (I think) which varies depending on the colourspace - so instead of seeing the image as expected, I see multiple squished grey images as well as some glitchy stuff (I think this is each plane of the colourspace side by side, and some other data appearing visually)

so this happens if the bottom of my script looks like this
Code:
clip1 = last
return clip1
and if I just remove those two lines then it's absolutely normal again

however, despite the preview looking weird, the actual output generated when I run the script will be normal and correct - it's only the preview window that's affected this way

I can make the preview window look correct if I convert the clip to RGB - but this then produces a flipped output (apparently RGB space is upside-down) so I also need to flip it vertically - then I can preview the output the way I expect to

Code:
return clip1.ConverttoRGB().FlipVertical()
but because only the preview window is affected this way, I also need to remove this code again before generating my output, otherwise the output comes out flipped...

is there a reason for this to be happening this way, and is there any way I can stop it? other than modifying my script for when I need to preview it, and then correcting it when it's time to generate the output?
Statick is offline   Reply With Quote
Old 4th September 2020, 15:53   #2182  |  Link
hevron
Registered User
 
Join Date: Jun 2020
Posts: 18
StaxRip-x64-2.1.4.3-Beta
There is a very inconvenient moment. When the encoding of files ends and the assembly into the container begins, an obstacle to the program may arise, for example, the free disk space has run out, a file in the temp folder is missing, or something else ... a banner flies out and everything that was done is reset . You can only manually continue the build from what was saved in the temp folder by another software. It would be correct if the program stopped and waited for the user to fix the error.
Thanks.

Last edited by hevron; 4th September 2020 at 16:01.
hevron is offline   Reply With Quote
Old 4th September 2020, 19:04   #2183  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
But unfortunately that would not be compatible with the batch logic. If you do so, the whole batch will wait, and you eventually realize that Staxrip didn't process the jobs due to a single error.... Of course that would make sense for insufficient free space, but not for other reasons...
44vince44 is offline   Reply With Quote
Old 4th September 2020, 19:54   #2184  |  Link
hevron
Registered User
 
Join Date: Jun 2020
Posts: 18
Quote:
Originally Posted by 44vince44 View Post
Of course that would make sense for insufficient free space, but not for other reasons...
It's a pity!
thanks.
hevron is offline   Reply With Quote
Old 5th September 2020, 09:19   #2185  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
But it would'nt change much because mainly the problems occur when muxing. If video is already processed, when you reload the job and re-create it (with NEXT), if no modification has been made in the video settings, you'll be asked if you want to use the already encoded video, so you can finish processing quickly, without encoding again.
44vince44 is offline   Reply With Quote
Old 6th September 2020, 21:12   #2186  |  Link
creeve4
Registered User
 
Join Date: Mar 2013
Posts: 4
I am not able to hardcode subtitles when encoding a 4K HDR source with mostly default settings. I selected the vobsub (.idx) subtitle file that was converted automatically with BDSup2Sub.

Attached is the log file.

What am I doing wrong?

Edit: got it working. I had to use VapourSynth instead of the default AviSynth.

Last edited by creeve4; 6th September 2020 at 22:54.
creeve4 is offline   Reply With Quote
Old 7th September 2020, 01:43   #2187  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Just in case anyone was waiting for it there is a new beta out that includes working hardware accelerated video decoding with DXVA2 so if you have any large 4K or 8K files they would probably greatly benefit from this acceleration, I know mine did.
BobbyBoberton is offline   Reply With Quote
Old 7th September 2020, 08:36   #2188  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
@creeve4 your log file is still pending approval, I can't see it. You could put it on a free external site like pastebin.com and link to it here (instantly and easily) to avoid long waitss like now.
I would guess you're using avisynth.
The Avisynth version of hardcoded subs filter (with ctrl+h) does not work with 10bits+ sources. But VapourSynth version does.
I hope this replies to your problem.
44vince44 is offline   Reply With Quote
Old 7th September 2020, 15:09   #2189  |  Link
creeve4
Registered User
 
Join Date: Mar 2013
Posts: 4
Quote:
Originally Posted by 44vince44 View Post
@creeve4 your log file is still pending approval, I can't see it. You could put it on a free external site like pastebin.com and link to it here (instantly and easily) to avoid long waitss like now.
I would guess you're using avisynth.
The Avisynth version of hardcoded subs filter (with ctrl+h) does not work with 10bits+ sources. But VapourSynth version does.
I hope this replies to your problem.
This does answer my question. Thank you.
creeve4 is offline   Reply With Quote
Old 7th September 2020, 18:10   #2190  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
You're welcome!
44vince44 is offline   Reply With Quote
Old 11th September 2020, 05:10   #2191  |  Link
creeve4
Registered User
 
Join Date: Mar 2013
Posts: 4
I have a question about using the HDR Ingest option. When using this, 2 files are generated one of which has the suffix "_HDR10".

The only difference I notice is that the _HDR10 file has an adjusted value for Mastering display luminance (which is less than the original file) and two additional values: Maximum Content Light Level and Maximum Frame-Average Light Level. Neither of these two additional values are present in video files on my blu-ray disks.

Both video files appear to play back identically on my HDR TV.

What is the purpose of this _HDR10 version of the video?

Last edited by creeve4; 11th September 2020 at 13:46.
creeve4 is offline   Reply With Quote
Old 19th September 2020, 13:40   #2192  |  Link
mcjordan
Registered User
 
Join Date: Nov 2010
Posts: 121
There are some troubles when compiling the source with the updated to 1.9.0.1 DirectN library...
mcjordan is offline   Reply With Quote
Old 19th September 2020, 23:20   #2193  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,389
Quote:
Originally Posted by creeve4 View Post
I have a question about using the HDR Ingest option. When using this, 2 files are generated one of which has the suffix "_HDR10".

The only difference I notice is that the _HDR10 file has an adjusted value for Mastering display luminance (which is less than the original file) and two additional values: Maximum Content Light Level and Maximum Frame-Average Light Level. Neither of these two additional values are present in video files on my blu-ray disks.
I can't speak as to what the other file is about, but it is highly unlikely that there wasn't a MaxCLL or MaxFALL value set in the source. It is possible they were coded to "0" meaning "undefined." But I've never seen any commercial HDR content where the parameter didn't exist at least. MediaInfo should show it.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd September 2020, 22:05   #2194  |  Link
MrBrownCow
Registered User
 
Join Date: Feb 2019
Posts: 22
Has anyone had success with increasing 'chunks' to something more than 1? I've tried changing it to 2 a couple times now but the resulting video is corrupted right around the middle in several spots. Not sure if this is an issue with staxrip or something else.

staxrip 2.1.3.7, Ryzen 3900X CPU.

Example:
https://imgur.com/a/WF1ZtC7

If I leave chunks at 1 the result has no corruption issues but it takes much longer. My understanding is that 'chunks' basically allows the encoding to be split up into 2 parts and both parts can be encoded simultaneously. If I leave chunks at 1 the time is around 6 hours and with chunks at 2 the result is 4 hours but with corruption in the middle of the video.

With chunks at 1 staxrip seems to use about 60% of the CPU. With chunks at 2 staxrip uses about 97% of the CPU. I thought this was a good way to use my CPU and save time but if the result is corrupted obviously this doesn't help.

If anyone has thoughts or suggestions that would be great!
MrBrownCow is offline   Reply With Quote
Old 23rd September 2020, 07:35   #2195  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
MrBrownCow, chunks has been introduced to allow full usage of CPU, especially when using Ryzens with so many logical cores. We made many tests on small files with mkv output, and they worked without corruption. And no one reported such problems until now.

This is very important. We need the log file first (so we can get at least info about staxrip version and what container you are using for output).

Paste your log file (that you can still find in the settings folder of staxrip), in pastebin.com, and link to it here.

Last edited by 44vince44; 23rd September 2020 at 08:07.
44vince44 is offline   Reply With Quote
Old 23rd September 2020, 09:12   #2196  |  Link
MrBrownCow
Registered User
 
Join Date: Feb 2019
Posts: 22
Quote:
Originally Posted by 44vince44 View Post
MrBrownCow, chunks has been introduced to allow full usage of CPU, especially when using Ryzens with so many logical cores. We made many tests on small files with mkv output, and they worked without corruption. And no one reported such problems until now.

This is very important. We need the log file first (so we can get at least info about staxrip version and what container you are using for output).

Paste your log file (that you can still find in the settings folder of staxrip), in pastebin.com, and link to it here.
Hi Vince. I don't want to come off as pointing fingers, its very possible this is something I did wrong. I've tried it three times now with different source files and had the same issues but all the source files were large files. Each one took about 5 hours with chunks at 2 and then another 7 hours with chunks back at 1 because of the corruption.

Maybe its a filter or setting? I'm open to ideas and thankful for any help here.

https://pastebin.com/vhpyLkZH
MrBrownCow is offline   Reply With Quote
Old 23rd September 2020, 09:20   #2197  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
MrBrownCow, thanks for the log file, I will do some testing later today, using filters. Our previous tests did not include filters, and were made with an older version of Staxrip. So maybe it's a matter of filters, or a regression with newer versions. So this this important!. I'll get back tomorrow to confirm.

Edit: the problem is not due to merging the chunks: the garbled frame is at 52:38 while the cutting point is at something like 55:55, so it's gonna hard to find the reason....

Mr BrownCow, can you please check if the output video has corruption around 55m56s

Last edited by 44vince44; 23rd September 2020 at 14:02.
44vince44 is offline   Reply With Quote
Old 24th September 2020, 14:13   #2198  |  Link
44vince44
Registered User
 
Join Date: May 2020
Posts: 82
MrBrownCow, I did several tests and couldn't reproduce that. I am still wondering why the corruption doesn't happen at the merge point, as it appears in your screenshot.
44vince44 is offline   Reply With Quote
Old 24th September 2020, 22:55   #2199  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,454
Quote:
Originally Posted by MrBrownCow View Post
Hi Vince. I don't want to come off as pointing fingers, its very possible this is something I did wrong. I've tried it three times now with different source files and had the same issues but all the source files were large files. Each one took about 5 hours with chunks at 2 and then another 7 hours with chunks back at 1 because of the corruption.

Maybe its a filter or setting? I'm open to ideas and thankful for any help here.

https://pastebin.com/vhpyLkZH
Remove knlmeanscl and other filters and try again.
Atak_Snajpera is online now   Reply With Quote
Old 2nd October 2020, 16:45   #2200  |  Link
hevron
Registered User
 
Join Date: Jun 2020
Posts: 18
Friends, thank you very much for updating the program, you are the best ➕➕➕
Small note, Versions.txt is missing in the Apps folder.

Last edited by hevron; 2nd October 2020 at 16:56.
hevron is offline   Reply With Quote
Reply

Tags
aac, hdr, hevc, nvenc, staxrip, x264, x265

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.