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. |
6th November 2018, 23:14 | #981 | Link | |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
Quote:
|
|
27th March 2019, 10:09 | #982 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
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 |
28th March 2019, 21:19 | #983 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
And also snippet of the script which BD3D2MK3D is using. Thanks |
|
29th March 2019, 09:18 | #984 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
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))
__________________
r0lZ PgcEdit homepage (hosted by VideoHelp) BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV |
29th March 2019, 09:50 | #985 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
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 |
30th March 2019, 18:41 | #986 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
I will issue bugfix next weekend. |
|
31st March 2019, 08:57 | #987 | Link | |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
Quote:
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 |
|
6th April 2019, 17:12 | #988 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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 ) |
|
8th April 2019, 15:23 | #989 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
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 |
8th April 2019, 21:30 | #990 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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. |
|
17th February 2020, 09:34 | #991 | Link |
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 |
18th February 2020, 22:09 | #992 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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? |
|
19th February 2020, 22:18 | #993 | Link |
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 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 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 |
21st February 2020, 20:43 | #994 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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! |
|
21st February 2020, 21:01 | #995 | Link |
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 |
26th February 2020, 02:47 | #996 | Link |
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. |
26th February 2020, 21:44 | #997 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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. |
|
8th March 2020, 12:15 | #998 | Link |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
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 |
9th March 2020, 10:11 | #999 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,483
|
Thanks, videofan3d !
__________________
r0lZ PgcEdit homepage (hosted by VideoHelp) BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV |
1st July 2020, 04:02 | #1000 | Link |
Guest
Posts: n/a
|
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:
EDIT There should be a general problem. Here is an illustration with FRIMEncode Last edited by SpasV; 2nd July 2020 at 01:07. |
Tags |
encoders, mvc |
Thread Tools | Search this Thread |
Display Modes | |
|
|