StaxRip 2.0 Support Thread

[Patman]

Originally Posted by NikosD

Using a Skylake Core i5-6500 under Win 10 x64 (17763) with 6951 drivers (API v1.29) and StaxRip v2.0.4.0 (QSVEncC v3.24), everything seems to work fine regarding HW support of VC-1.
It's supported by the GPU/Driver/QSVenc and it works when tested on a few VC-1 files using QSVEnc Intel (--avqsv) decoder which uses the least CPU usage (~7%) and it's the fastest, as a completely HW based implementation.
But I found a VC-1 clip that started OK and finished with error (incorrect function) crashing StaxRip.
The same clip works fine using Avisynth/QSVEnc Software/ffmpeg Intel as decoders.
So, you could find some incompatibilities using a HW decoder like QSVEnc Intel, but not only for VC-1, the same thing can happen to any other supported codec.
The only solution, is to report this specific clip to the developer of the HW encoders, hoping that he could fix it, here:
https://rigaya34589.blog.fc2.com/

Hi NikosD,

thanks for doing a test. Then it can either be the file or a compatibility issue with the hardware. I reported the problem.

[NikosD]

Originally Posted by Patman

Then it can either be the file or a compatibility issue with the hardware. I reported the problem.

It's never (almost) the hardware!
But you can always check hardware decoding using LAV filters and a suitable player like MPC-HC or internal HW decoder of MPC-BE player.
They use DXVA2 or D3D11 instead of QSV Intel to access the hardware decoder and they are extremely tested and optimized for HW decoding.

So, most of the times it's just rigaya's implementation of QSV Intel decoder.

[proper88]

Hi Patman,
thank you very much for reporting this problem to rigaya !!!

[Zetti]

MediaInfo v19.09 is released.

NVEncC v4.47 is released some days ago.

[stax76]

@Zetti

Thanks for posting, I'm currently working on a new beta build.

[stax76]

What are common file extensions for MKV attachments?

So far I got:

"ttf", "txt", "jpg", "png"

[frenchfries]

Originally Posted by stax76

What are common file extensions for MKV attachments?

So far I got:

"ttf", "txt", "jpg", "png"

That seems pretty right to me. TBH other file/MIME types are probably added for their attack vector potential such as PDFs

[stax76]

2.0.4.1 Beta

• nvenc switch --avhw updated (Patman86), --sub-source added
  
• qsvenc switches added: --data-copy, --adapt-ltr
  
• progress display support added for DGIndexNV, MP4Box and ffmpeg audio encoding
  
• L-Smash Works parameters prefer_hw and format have menu support in the avs/vs code editor
  
• the container/muxer dialog has a new tab for MKV attachments
  
• fix: vpy import did not work when the output variable isn't named 'clip'
  
• fix: a format exception was fixed, it was happening when the cut/trim feature was used
  
• update: nvenc 4.47
  
• update: L-Smash Works 2019-09-10 HolyWu
  
• update: MediaInfo 19.09
  
• update: mpv.net 5.4.1.1
  

https://www.dropbox.com/sh/4ctl2y928...dd3yqcAHa?dl=0

https://1drv.ms/f/s!ArwKS_ZUR01gySQIE1QCL2i9F_uR

[sneaker_ger]

Originally Posted by stax76

What are common file extensions for MKV attachments?

So far I got:

"ttf", "txt", "jpg", "png"

otf (OpenType Font), jpeg

[Havokdan]

Is it possible to have StaxRip import .nfo files into mkv format? In this case, the .nfo would be the format used by Kodi to create mkv tags with history, actors, producers and additional data, xvid4psp 6 onwards did that, and it seems to be the only one that did it, but it stopped be free.

[suarsg]

Can someone clue me in why the ordering of the parameters in the "Encoding settings"-field for x265 (visible with MediaInfo for example) changed all of a sudden? For years and with Stax 2.0.2 (x265 v3.1 RC1+3) it looked like this:

cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / ...

Now I've updated to Stax 2.0.4 (x265 3.1+11) it suddenly has this ordering:

rc=crf / crf=17.0000 / qcomp=0.60 / qpstep=4 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / ...

For as long as I can remember, all x265 encodes everywhere looked like the first one. I don't think it's from x265 itself (version barely changed) and I've seen other "x265 3.1+11" encodes where it still looks like the first one.

Did I accidentally change something in StaxRip for this to happen and didn't even notice? Was it a change in StaxRip itself after 2.0.2? I can't find any info on such a change in the changelogs of StaxRip or x265.

[stax76]

Is it possible to have StaxRip import .nfo files into mkv format? In this case, the .nfo would be the format used by Kodi to create mkv tags with history, actors, producers and additional data, xvid4psp 6 onwards did that, and it seems to be the only one that did it, but it stopped be free.

StaxRip allows adding attachments, I hope that's everything needed.

Did I accidentally change something in StaxRip for this to happen and didn't even notice? Was it a change in StaxRip itself after 2.0.2? I can't find any info on such a change in the changelogs of StaxRip or x265.

All what StaxRip does is running a command line, by default the command line is very simple, all can be seen in the log file (Tools > Log File).

[Patman]

Hey Stax you saw?

https://github.com/staxrip/staxrip/issues/51

[Patman]

Originally Posted by suarsg

Can someone clue me in why the ordering of the parameters in the "Encoding settings"-field for x265 (visible with MediaInfo for example) changed all of a sudden? For years and with Stax 2.0.2 (x265 v3.1 RC1+3) it looked like this:

cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / ...

Some of these settings are default settings, so they are no longer listed separately. These can be found under Performance at the x265 options.

[suarsg]

Originally Posted by Patman

Some of these settings are default settings, so they are no longer listed separately. These can be found under Performance at the x265 options.

That's not what I'm talking about.

Originally Posted by stax76

All what StaxRip does is running a command line, by default the command line is very simple, all can be seen in the log file (Tools > Log File).

I've done some digging in x265's source code. The ordering has never officially changed, like I suspected. So whoever compiled the x265.exe you shipped 2.0.4.0 with, has done so with his own custom function for x265_param2string(). I've confirmed this by replacing the x265.exe in Apps/Encoders/x265 with one from here for the exact same x265 version. I then ran StaxRip with a test clip back to back, first with the old and then with new x265.exe. The replacement-exe writes the correct metadata, the x265.exe StaxRip is shipped with does not. I don't know where you got it from but it's definitely not compiled from the original official source code.

[Patman]

Originally Posted by suarsg

That's not what I'm talking about.

Sorry, my fault. I've build a x265 from official git and the settings info shows "cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / ..."

As far as i know staxrip uses x265 build from Wolfberry. Maybe there is used a custom param.cpp for this build.

[stax76]

Originally Posted by Patman

Hey Stax you saw?

https://github.com/staxrip/staxrip/issues/51

Sorry Patman, I had missed it. I've updated now x265, ffmpeg and MP4Box so it will be available in the next beta.

I've done some digging in x265's source code. The ordering has never officially changed, like I suspected. So whoever compiled the x265.exe you shipped 2.0.4.0 with, has done so with his own custom function for x265_param2string(). I've confirmed this by replacing the x265.exe in Apps/Encoders/x265 with one from here for the exact same x265 version. I then ran StaxRip with a test clip back to back, first with the old and then with new x265.exe. The replacement-exe writes the correct metadata, the x265.exe StaxRip is shipped with does not. I don't know where you got it from but it's definitely not compiled from the original official source code.

Maybe ask in the x265 thread, I don't know if Wolfberry follows the staxrip thread.

[Havokdan]

Originally Posted by stax76

StaxRip allows adding attachments, I hope that's everything needed.

Hopefully in the future we will have this feature, initially at least importing from the format used by Kodi, parsing and placing in mkv tags.

https://kodi.wiki/view/NFO_files/TV_shows
https://kodi.wiki/view/NFO_files/Movies

[stax76]

Originally Posted by Havokdan

Hopefully in the future we will have this feature, initially at least importing from the format used by Kodi, parsing and placing in mkv tags.

https://kodi.wiki/view/NFO_files/TV_shows
https://kodi.wiki/view/NFO_files/Movies

It's tricky, tricky (Tricky) tricky, sorry but I don't understand much about Kodi.

edit:

So I was looking if some of my 'samples' has nfo mediainfo, full text search unfortunately don't work because nfo is part of info, is there a certain mediainfo property I can look for or does mediainfo not support this info?

This is my full text search command:

get-childitem | foreach { (mediainfo $_.fullname) | out-string } | where { $_ -match 'nfo' }

edit2:

The match operator in powershell uses regex, non of my files have an attachment with nfo file extension. As I understand it such nfo files have xml content that can be created and edited with external applications, the nfo file is then added as mkv attachment which staxrip supports, I can add nfo support to the file open dialog extension filter but apart from that I don't see a need for improvement in staxrip.

[Havokdan]

Originally Posted by stax76

It's tricky, tricky (Tricky) tricky, sorry but I don't understand much about Kodi.

edit:

So I was looking if some of my 'samples' has nfo mediainfo, full text search unfortunately don't work because nfo is part of info, is there a certain mediainfo property I can look for or does mediainfo not support this info?

This is my full text search command:

get-childitem | foreach { (mediainfo $_.fullname) | out-string } | where { $_ -match 'nfo' }

I don't know if I understand correctly, but kodi looks for info about the web media file for its media center function, but it has the option to read local nfo files, you can manually create nfo files, or use tools like MediaElch, Media Companion and TinyMediaManager (which is what I use), I wanted to import the information from this nfo which has a schema that looks like xml as tags in mkv, example of how it looked in xvid4psp:

General
Unique ID : 109171765302595762700583546447705430305 (0x5221B7999E7089240A3F1143861C5921)
Complete name : E:\Videos\Filmes\[REC] (2007)\[REC] (2007).mkv
Format : Matroska
Format version : Version 4
File size : 620 MiB
Duration : 1 h 15 min
Overall bit rate : 1 152 kb/s
Movie name : [REC]
Description : Uma equipa de repórteres de TV decide documentar em direto, uma patrulha de bombeiros em serviço durante a noite. O objetivo é registar a vida destes profissionais, incluindo as situações mais arriscadas. A primeira missão da noite, é resgatar uma senhora idosa que se encontra fechada no seu apartamento por razões desconhecidas. Durante esta missão algo corre terrivelmente mal… O que parecia de rotina, torna-se num verdadeiro inferno. Algo maléfico e sinistro está fora de controlo e ameaça a corporação e a equipa de TV. Os papéis invertem-se. A sobrevivência e a fuga terão de se sobrepor ao medo e, custe o que custar, a câmara não é para desligar… até ao último momento.
Writing application : XviD4PSP 7.0.455 DAILY
Writing library : Lavf57.71.100
ErrorDetectionType : Per level 1
Attachments : poster.jpg / backdrop.jpg
ACTORS : Manuela Velasco, Ferran Terraza, Martha Carbonell, David Vert, Carlos Lasarte, Pablo Rosso, Vicente Gil, Carlos Vicente, Jorge Yamam, María Teresa Ortega, Manuel Bronchud, Maria Lanau, Claudia Silva, Javier Botet, Ben Temple, Akemi Goto, Kao Chen-Min, Ana Isabel Velásquez, Javier Coromina, Pep Sais
COUNTRY : Spain
DATE : 2007-04-10
DIRECTOR : Jaume Balagueró, Paco Plaza
ENCODING_INFO : MATROSKA,WEBM > MKV MKV / H264 > COPY Smart / AAC-LC > COPY Smart
GENRE : Terror, Mistério
HD_VIDEO : 1
Language : und
MEDIA_TYPE : 9
PRODUCER : Julio Fernández, Alberto Marini
PUBLISHER : Filmax
RATING : 7.10
WRITER : Jaume Balagueró, Paco Plaza, Luis Berdejo

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 15 min
Nominal bit rate : 1 024 kb/s
Width : 1 280 pixels
Height : 688 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.047
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1024 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : Yes
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Duration : 1 h 15 min
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Title : _audio.aac - Imported with GPAC 0.5.1-DEV-rev4246
Default : Yes
Forced : No

In short, in practice, I wanted to pull the files into mkv with these tags with additional information about the file, in this case getting them from an external nfo file that contained them, in this case in the Kodi standard.