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 > (HD) DVD, Blu-ray & (S)VCD > (HD) DVD & Blu-ray authoring

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th November 2018, 23:14   #981  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,488
Quote:
Originally Posted by videofan3d View Post
In 1.29 I made changes mainly related to HEVC and also to include VPP unit into FRIMDecode.
To incorporate VPP I had to rework all internal loops there.
Probably - as positive side-effect of this - something has changed/improved what impacted the previous HW decoding - in positive manner.
Thanks for the info, videofan3d. I'll probably have to rebase my code off the latest Intel sample code. Or I may just let it be, as you seem to have things covered very well with FRIMSource().
videoh is offline   Reply With Quote
Old 27th March 2019, 10:09   #982  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here. It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 28th March 2019, 21:19   #983  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by r0lZ View Post
Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here. It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!
Could you please send me examples - which BD3D are affected? I will try it.
And also snippet of the script which BD3D2MK3D is using.

Thanks
videofan3d is offline   Reply With Quote
Old 29th March 2019, 09:18   #984  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
AFAIK, all BDs with the inverted views are affected, notably the Boss Baby, Shrek the Third and Epic. I did my test with the Boss Baby. I will try to cut a sample of the movie...
In the meantime, here is the script:
Code:
LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\FRIMSource.dll")
interleaved = FRIMSource("mvc", "00600.track_4113.264", "00600.track_4114.mvc", layout = "alt", num_frames = 2000, cache = 2, platform = "")
right = SelectEven(interleaved)
left  = SelectOdd(interleaved)
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
I know that it is possible to return directly a Full-SBS or Full-TAB image, with the layout option, but BD3D2MK3D requires two different streams, for technical reasons. I haven't tried the direct method.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 29th March 2019, 09:50   #985  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
And here is the sample: FRIMSource inverted views bug sample.7z
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 30th March 2019, 18:41   #986  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by r0lZ View Post
Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.
videofan3d is offline   Reply With Quote
Old 31st March 2019, 08:57   #987  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
Quote:
Originally Posted by videofan3d View Post
Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.
Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 6th April 2019, 17:12   #988  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by r0lZ View Post
Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.
Here is bugfix for FRIMSourceNN.dll.
Would be good if you could independently test it.

(I will provide full release once I complete integration of latest Intel Media libraries 2018R2.1 )
videofan3d is offline   Reply With Quote
Old 8th April 2019, 15:23   #989  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 8th April 2019, 21:30   #990  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by r0lZ View Post
Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!
Fix is independent on HW or SW platform - defect was purely in my code, after obtaining L+R frame from Intel library. Actually, the particular code section is now even clearer and simpler than before.
I checked also SBS and TAB - and seemed to be fine as well.

Version with new Intel libs uploaded (2019-04-16).

Last edited by videofan3d; 13th June 2019 at 21:26.
videofan3d is offline   Reply With Quote
Old 17th February 2020, 09:34   #991  |  Link
mindsong
Registered User
 
Join Date: Mar 2018
Posts: 4
I don't think this is necro-ing a thread - I hope not, as it seems like the right place to ask/archive this info.

I'm struggling with a latest-version-based FRIMEncode<-AVISynth script effort that could be caused by any number of setup errors on my side, so perhaps it would be best to post my simplest example and see if the problem is more widespread, or just my environment, before I pursue it with the gory details.

Could someone with a stable/working FRIMEncode/AVISynth environment try this simple AVIsynth script that generates a basic/short test 3840x1080 SBS stream for encoding into a base.avc+dep.mvc file pair?

AVISynth Script (MyScript.AVS) - creates a simple 100 frame SBS stream:

L = ColorBars(1920,1080,"YV12")
L = KillAudio(L)
L = Info(L)

R = ColorBars(1920,1080,"YV12")
R = KillAudio(R)
R = Info(R)

V = StackHorizontal(L,R)
V = Trim(V,0,-100)
# redundant, but...
V = ConvertToYV12(V)
return(V)


FRIMEncode command:

FRIMencode32 ^
-avi ^
-i MyScript.avs ^
-sbs 2 ^
-viewoutput ^
-o:mvc 01_base.avc 01_dependent.mvc ^
-u 1

It's intended to be as *minimal* as possible, with the real script/workflow doing something that's actually meaningful... (real mpeg2 interlaced 3D -> MVC-3D)

Does this basic sequence work for anyone else, w any specific FRIM and toolset versions? Should it be able to, or have I missed something simple (some import or ...?) ?

I'm using an up-to-date W10 x64 system with a current x86 FRIM/AVISynth/Intel/codec toolchain and I'm seeing a colorspace mismatch. I've tried with a current x64 workflow to the same effect, so any test that works is welcomed, if it's possible. It seems like something FRIMencode is trivially able to do, so I'm wondering what I'm missing.

I'm fairly competent with these tools and environment, so I've got variations, various tool versions, specs, samples, variations, that I can share to ID my specifics, and maybe we can then pursue the fix to my puzzle, but fixing *my* workflow only makes sense if we know that this *can* work at all in anyone's stable environment - so this seems like a safe/easy place to start.

I'd appreciate if anyone could take this quick test for a spin and share their results - or perhaps correct some basic assumptions I'm making as I go down this path.

I've really done a bunch of research and experiments on getting this to work, so any help is truly appreciated at this point.

Cheers, and thanks in advance,

--ms

Last edited by mindsong; 17th February 2020 at 10:21. Reason: clearer wording, change upper-case -I to lower -i in cmd
mindsong is offline   Reply With Quote
Old 18th February 2020, 22:09   #992  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by mindsong View Post

AVISynth Script (MyScript.AVS) ..

FRIMEncode command: 01_base.avc

I'm seeing a colorspace mismatch.
I opened MyScript.avs (as defined above) using MPC-HC
and then 01_base.avc (created as defined above) also using MPC-HC...

But honestly - I see identical colorbars on screen.
No visual difference.

So what is the problem?
videofan3d is offline   Reply With Quote
Old 19th February 2020, 22:18   #993  |  Link
mindsong
Registered User
 
Join Date: Mar 2018
Posts: 4
hello videofan3d,

Thanks for the reply (and for your great work on this project).

In your short reply, you've confirmed that my system is (still) not configured correctly. Most folks in here are working with a different data-flow (BD-3D to standalone MVC-3D), so I wanted to check to see if my simple test/approach was working for others before hitting up the thread with a "it doesn't work" assertion... Apparently it does work...

For me, the 'parts' all seem to be working on their own, but FRIMEncode isn't seeing my simple (or slightly more complex) AVISynth output as I420 and exits before it creates the avc/mvc pair - the error has been mentioned before and most folks have been able to fix their issues. I've read enough to see that the system setup is as likely (or more likely) to be a source of problems as the final FIRM/Intel step, so I wanted to be sure my ultimate target was viable (simple AVS script to avvc/mvc). Thanks for verifying that.


In gory detail, for those that might 'see' my problem, and future readers who go down this debugging path:

As I assumed (and still do) that the problem *is* my system, so my resolution efforts follow:

1) I've worked to match my x86/x64 toolchains with 'proper' (bitwise) versions of the AVISynth, ffdshow/VFW, FRIM, and Intel MSDK as a foundation. (everything is x86 for now)

2) I've then checked to be sure my simple AVS script is viable (it renders fine using AVIsynth 2.60 and AviSynth+ in 32-bit Vdub2, WMP, MPC-HC, and ffmpeg's avs renderer to both pipes and files)

3) I've done everything I know how to ensure that the AVS script outputs are YV12/I420 AVI streams and files, using Vdub2 and ffmpeg - files and pipes show lossless 4:2:0 YV12 or I420 content at various resolutions and framerates. The files/streams/pipes seem to play well enough on the above players and media-info/ffprobe indicate appropriate content/formats

4) I'm pretty certain that my ffdshow layer is causing the issue in the pipeline, but after hacking at that for a day, thought I'd ask some smarter folks to be sure my approach was/is plausible and that the script/workflow wasn't missing some obvious understanding ("of course that doesn't work!..." kind of thing).

5) with ffdshow(-tryout from sourceforge ffdshow_rev4533_20140929_clsid.exe) , the default install (32bit) with the default settings and the VFW decode "RGB raw video" set to "all-supported", I get the mentioned error from the above FRIMEncode32.exe command and script:

Code:
ERROR: Cannot get I420 frame from input avi-file MyScript.avs
       Frame was written in default format to file MyScript.avs.error.bmp
and the bmp file that is produced *looks correct* (double-wide colorbars), so I assume that the AVISynth framework is operating properly (I have removed/disabled *all* of my avisynth plugins to ensure no side-effects/conflicts)

Also - when run *without* the "-avi" option, my FRIMEncode32.exe is able to run, ingest, process, and output a avc/mvc pair (660K.avc - 654k.mvc - mvc should be 520k-ish?) from an AVI file created from the above AVS script (~600 M avi for the 100 frames) using vdub2 (latest).

For good reason, I think the output is correct but not useful (the input file looks fine in WMP, but the avc file has sliding/blocky content from the FRIM/Intel stage (in WMP), and a tsmuxer m2ts from the pair plays, but also looks 'wrong' in the same way (no errors in the tsmuxer stage).

I assume FRIMEncode is expecting raw video and my AVI has repeating/confusing header/frame info that causes this corruption/sliding image effect. Probably doing the right thing. It only processes 50 frames (of 100).

If I run the command *with* the "-avi" switch, I get the same I420 related error message.



Infile specs (generated from vdub2 with the above AVS script):

Code:
General
Complete name                            : C:\Users\mindsong\Desktop\at\I420_3840x1080.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 593 MiB
Duration                                 : 4 s 167 ms
Overall bit rate                         : 1 194 Mb/s
Writing application                      : Lavf58.29.100

Video
ID                                       : 0
Format                                   : YUV
Codec ID                                 : I420
Codec ID/Info                            : 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.
Duration                                 : 4 s 167 ms
Bit rate                                 : 1 194 Mb/s
Width                                    : 3 840 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 3.556
Frame rate                               : 24.000 FPS
Compression mode                         : Lossless
Bits/(Pixel*Frame)                       : 12.000
Stream size                              : 593 MiB (100%)

FRIM Command that processes this file (with funky output avc/mvc files (size = 660K.avc - 654k.mvc) :

Code:
FrimEncode32 -i I420_3840x1080.avi -sbs 2 -viewoutput -o:mvc b.avc d.mvc -w 3840 -h 1080 -dsth 1080 -dstw 1920 -u 4

FRIM Encoder version 1.30 - Win32 (build: Apr 16 2019)
 - based on Intel(R) Media SDK

Media SDK impl          HARDWARE (3) - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version       1.20
Memory type             System
Async depth             4

Input  format           I420

Encoder                 AVC

Input picture:
  Resolution            3840x1088
  PAR                   0:0
  Structure             Progressive
  Crop X,Y,W,H          0,0,3840,1080
  Frame rate            23.976
Output picture:
  Resolution            1920x1088
  PAR                   0:0
  Structure             Progressive
  Crop X,Y,W,H          0,0,1920,1080
  Frame rate            23.976
Bitrate control         CBR
  bitrate               3572
GOP structure:
  GOP length            24
  I-/P-frame distance   4
  IDR-frame interval    0
  GOP type              Opened
Num of slices           6
Target usage            4 (balanced)

Processing started
Frame number: 50
Processing finished in 3.00 seconds
(and adding the -avi option causes the process to fail with the mentioned I420 colorspace format error.)


So I believe that my FRIM (1.30) tools are not able to ingest my (seemingly) I420 4.2.0 lossless AVI streams, and probably due to my ffdshow/VFW/raw-video conduit setup.

I saw mention earlier in this thread of the ffdshow version being an issue for someone. Is there a preferred version/source (x64 and x32) of ffdshow? (or any of the tools that I'm using?)

Again, I may be missing something *really* basic and have no idea that I'm overlooking something - Are the above steps (toolchain, tests, workflow) rational for what I'm trying to do?

Of course I can provide samples and config screenshots if they would help!

Thanks again for all insights and advice!

cheers,

mindsong

Last edited by mindsong; 19th February 2020 at 23:00. Reason: typos, awkward wording fixes, code tags
mindsong is offline   Reply With Quote
Old 21st February 2020, 20:43   #994  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by mindsong View Post
Code:
ERROR: Cannot get I420 frame from input avi-file MyScript.avs
       Frame was written in default format to file MyScript.avs.error.bmp


If I run the command *with* the "-avi" switch, I get the same I420 related error message.
Hi,

Yes, FRIMEncode assumes flat YUV files (I420 or YV12, i.e. chroma 4:2:0) because this is what underlaying Intel Media SDK can encode. (unfortunately 4:2:2 is not implemented there but this is another story)

I added -avi option long time ago, primarily for output from Adobe Premiere using DebugMode frame server (this was long before I wrote FRIMExport.prm).

Yes, -avi + Avisynth together need somehow ffdshow in the chain. Frankly speaking - configuration of all these Windows filters is magic - you never know what you have in the system and how they impact/influence each other.

Just play with it and try to find working combination.
These two links (mentioned in the past in this thread) may bring some advise
http://forum.doom9.org/showthread.ph...ow#post1655564
http://forum.doom9.org/showthread.ph...ow#post1663488

Good luck!
videofan3d is offline   Reply With Quote
Old 21st February 2020, 21:01   #995  |  Link
mindsong
Registered User
 
Join Date: Mar 2018
Posts: 4
Thanks! I will continue to experiment.

I am more comfortable now, knowing that amidst these 'magical' system dataflow path variables (codecs, etc.), that my goals with FRIM are plausible. If I learn anything specific, I will share the knowledge here.

lurking questions for me (to anyone/everyone):

For AVI files,

- what versions of ffdshow are folks working with? There are a number of versions and forks. Is anyone using clsid's latest to good effect, or is there a agreed-upon favorite older version that 'just works'.

- x86 or x64 - are folks working with avi files with the x86 versions, or does the x64 toolchain work too?

- avisynth+ ... or some previous version (w avi files...)

Any other tidbits that have haunted users in their setups are welcomed.

Thanks again videofan3d!

be well,
--ms
mindsong is offline   Reply With Quote
Old 26th February 2020, 02:47   #996  |  Link
mindsong
Registered User
 
Join Date: Mar 2018
Posts: 4
Still trying:

Cranked up a VM with a raw W7, and both the completely minimal x86/x64 toolchains - frim/intel/ffdshow/avisynth - x86/x64 isolated

No luck - same I420 issue.

The reason I revisit this thread, is when the FRIM tools start and run the many tested avisynth variants and fails to 'see' the output, even though the error process indicates that the avisynth is *working*, because a valid BMP file is created when the error occurs - it seems like AVIsynth is properly starting and working, but not 'sharing' its results with the FRIM tools. How to test this?

I wonder if perhaps there's an environment setting I've missed - perhaps not in the fddshow side, but maybe in a temp-file location, named-pipe setup (I haven't used them), or maybe some 'assumed' avisynth plugin/routine that tries to send the output to FRIMENcode, but fails if that plugin/script isn't available, etc. (I've removed all plugins - my testing AVIsynth is 'naked' - is this OK?)

I've used the frim (1.30) -debug modes, but there is no magic window into how FRIM starts avisynth, and how it gathers and then passes the stream data to the Intel conversion engines. Just the proper BMP on error. It feels so close to working.

Another angle I've experimented with is using ffmpeg's avisynth mode to generate outputs that I think should be readable to my FRIM tools. The files also look reasonable to my eye (media-info/ffprobe), but aren't handled any better (or differently) as uncompressed YUV4:2:0 AVIs, and I don't know how to generate a transport stream (3840x1080 sbs) output that makes FRIMencode happy. I've tried many of the raw outputs and get 600M files from ffmpeg for the MyScript.avs script above, but none of them generate the output I'm hoping for (or expecting).

Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?

(Maybe FRIM is working perfectly and my Intel stuff is partially broken - it *seems* to be working, so I'm not looking there (yet)).

Thanks a bunch for any feedback!

--ms

Last edited by mindsong; 26th February 2020 at 02:50.
mindsong is offline   Reply With Quote
Old 26th February 2020, 21:44   #997  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
Quote:
Originally Posted by mindsong View Post
Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?
Q: is there any way to 'see' the avisynth output as FRIMencode sees it
A: FRIM uses old native Windows API from vfw.h: AVIFileOpen(), AVIFileGetStream(), ... , AVIFileRelease()
Thus all AviSynth magic is hidden to it somewhere in background

Q: is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?
A: indeed, ffmpeg can produce raw video in requested format, check its help for all options

(only principle description, but working)

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an outputfile.yuv

where outputfile.yuv will be in YV12 or I420 (I'm not exactly sure, they differ only by order of UV, VU respectively)

Now, you can connect ffmpeg to FRIM using pipes

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an pipe:1.yuv | FRIMencode32 -i - -o:h264 output.h264 -w 1920 -h 1080 -f 23.976 [and other FRIM encoding options]

Optionally you could use also named pipes, which is a bit more tricky. The abobe stdout-stdin pipe works as well.

Q: lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?
A: This error is coming from FRIM, when it requests video stream in I420 chroma format using AVIStreamGetFrameOpen(). When it fails, you get this bitmap.
videofan3d is offline   Reply With Quote
Old 8th March 2020, 12:15   #998  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 313
FRIM version 1.31

FRIM version 1.31 released

All - build with Intel Media SDK 2019 R1 and MS Visual Studio 2017

FRIMTranscode:
- h265 (HEVC) codec added
- plugin support added with optional parameters:
-iguid decode-GUID-code
-iplugin full-decode-plugin-path-name
-oguid encode-GUID-code
-oplugin full-encode-plugin-path-name

FRIMSource:
- HEVC decoding uses 10-bit processing with AviSynth+

FRIMImport:
FRIMExport:
- HEVC decoding/encoding uses 10-bit processing with Adobe Premiere
videofan3d is offline   Reply With Quote
Old 9th March 2020, 10:11   #999  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,384
Thanks, videofan3d !
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 1st July 2020, 04:02   #1000  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
setting FRIM version 1.31

Thank you videofan3d for your work.

I am on setting FRIM version 1.31 and couldn't resolve the problem I have. It is seen below - FRIMDecode generates colorless stream.



Command line:
"D:\Program Files\FRIM\x64\FRIMDecode64" -i:h265 "Rambo Last Blood 2019.h265" -o frim(1240).yuv -start 1240 -length 653 -sw

FRIM Decoder version 1.31 - Win64 (build: Mar 8 2020)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (D:\Program Files\FRIM\x64\libmfxsw64.dll)
Media SDK version 1.28
Memory type System
Async depth 4

Decoder HEVC

Input picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,0,0
Frame rate 23.976
Output picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,3840,2160
Frame rate 23.976

Output format P010

Processing started
Frame number: 653
Processing finished in 69.70 seconds

Notes:
  • The peculiarities:
    CPU: Ryzen 3900X, Graphics: NVIDIA 1660S
  • FRIMDecode64() works the same way without option sw

EDIT
There should be a general problem.
Here is an illustration with FRIMEncode

Last edited by SpasV; 2nd July 2020 at 01:07.
SpasV is offline   Reply With Quote
Reply

Tags
encoders, mvc

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 09:01.


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