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. |
22nd November 2013, 08:22 | #281 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
I am asking because I had for the first time success with DirectShowMVCSource without crashing FRIMEncode or "loosing" one of the views after some time. Thanks to FRIMEncode Version 1.16 or just a lucky punch? I don't know. Added: Hmmm......seems to work stably now with FRIMEncode 1.16. If it truly works, DirectShowMVCSource would be very convenient as one can start from the .ssif directly and add video processing to the .avs script as needed..... Last edited by Sharc; 22nd November 2013 at 11:26. |
|
22nd November 2013, 09:47 | #282 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
A 77-minute long 3D movie has now been transcoding for 8 hours, with quality set to 3, decoding in software and encoding in hardware. CPU usage hovers around 75-80%.
Videofan3d, would it be possible to implement some sort of percentage display so the user could see how much of the movie has been processed? An "Estimated time remaining" would be even nicer, actually, but not sure if such a thing is possible here. |
22nd November 2013, 11:00 | #283 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
Displying progress for each session would be confusing. Remember: FRIM are command-line tools (I like unix-style ) which have certain presentation limitations - and on the other hand sigificant advantage in scripting integration. Transcoder displays dot '.' after each 100 decoded frames. |
|
22nd November 2013, 11:05 | #284 | Link | ||
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Quote:
Quote:
The transcode finished a moment ago. It took almost exactly 9 hours to process 110237 frames... and it looks like I miscalculated the bitrate, as the output file is larger than the source avc + mvc combined. It should have been smaller to fit on a BD25. Welp, at least I have an excuse to run the same encode again, this time in software only and with slightly lower bitrate Last edited by colinhunt; 22nd November 2013 at 11:24. |
||
22nd November 2013, 11:10 | #285 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
You can write par file like e.g. this: -i::h264 input.avc -o::sink -i::source -o::h264 output12.h264 -vbr 12000 24000 -i::source -o::h264 output17.h264 -vbr 17000 24000 -i::source -o::h264 output21.h264 -vbr 21000 24000 and create several output within one pass. Of course, it consume more CPU for several parallel encodings, but only one decoding ! |
|
22nd November 2013, 11:14 | #287 | Link | |
Registered User
Join Date: Jan 2007
Posts: 43
|
Quote:
|
|
22nd November 2013, 11:48 | #291 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
|
|
22nd November 2013, 11:50 | #292 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
So I tested running several sessions in parallel. Here's the par file contents:
Code:
-sw -i::mvc left.264 right.mvc -o::sink -length 3500 -hw -i::source -o::mvc clip_hw_33mbps_labrc.264 -labrc 33000 0 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O -hw -i::source -o::mvc clip_hw_33mbps_vbr.264 -vbr 33000 48000 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O -sw -i::source -o::mvc clip_sw_33mbps.264 -vbr 33000 48000 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O Code:
Transcoding started ...................... Return on error: error code -16, .\src\pipeline_transcode.cpp 858 Return on error: error code -16, .\src\pipeline_transcode.cpp 693 Transcoding finished MFX session 0 transcoding FAILED Processing time: 491.41 sec Number of processed frames: 2154 MFX session 1 transcoding FAILED Processing time: 303.34 sec Number of processed frames: 1060 MFX session 2 transcoding FAILED Processing time: 491.61 sec Number of processed frames: 1077 MFX session 3 transcoding FAILED Processing time: 491.59 sec Number of processed frames: 1077 Return on error: error code 1, .\src\sample_multi_transcode.cpp 629 update: ran the exact same params, but with one addition to line 1: "-async 2". Transcoding finished without errors this time. This is a bit odd: Code:
Session 3: Media SDK impl SOFTWARE (C:\Users\xxx\encoders\libmfxhw32.dll) Media SDK version 1.7 Memory type system Last edited by colinhunt; 22nd November 2013 at 12:36. |
22nd November 2013, 12:36 | #293 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
This all is likely related to -hw option, maybe some constraints of GPU. (I cannot test HW acceleration yet - hopefully in next few weeks I'll have access to Haswell to check and tune it ) |
|
22nd November 2013, 13:43 | #296 | Link | |
French Love
Join Date: Oct 2008
Location: France
Posts: 456
|
Quote:
Thank's videofan3d
__________________
2013-11-29 MVC Player Free v0.0.2.6 BD & 3D BD's Player, Demuxer v0.0.0.8b, Recoder. Tutorial Demo for MVC Player Free: Trailer 3D 3DBD's Free - v0.0.0.0005.exe Old Programing free for all. |
|
22nd November 2013, 13:59 | #297 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
What the... For poops and giggles, I tried to run FRIMTranscode in Hardware mode on i7-3930K. I was under the impression 3930K lacks the required hardware entirely, but nope, Transcode proceeded to run with -hw option just fine.
1000 frames on 3930K (u4) hw decode 61.33 sec hw encode (LA BRC) 62.01 sec (garbled output) sw decode 58.66 sec hw encode (LA BRC) 59.31 sec sw decode 56.77 sec hw encode (vbr) 57.42 sec sw decode 52.04 sec sw encode (vbr) 52.75 sec sw decode 51.92 sec sw encode (LA BRC [shouldn't work with -sw]) 52.66 sec // Compared -sw vbr and -sw labrc encoded outputs. Both are the same size, 84 523KB, but MediaInfo reports something interesting: VBR: Maximum bit rate - 21.8 Mbps (-vbr 34000 40000) LA BRC: Maximum bit rate - 62.5 Mbps (-labrc 34000 0) Last edited by colinhunt; 22nd November 2013 at 14:32. |
22nd November 2013, 14:06 | #298 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
- the base and dependent views of the transcoded combinedMVC.h264 seem to be ok. Both views playback without problems. - the glitch (garbled picture) comes only after remuxing the combinedMVC.h264 to .m2ts or ISO with tsMuxeR => the dependent view gets garbled and playback stops. I noticed that tsMuxeR had to modify the h264 bitstream by inserting nal unit delimiters for some reason. Anyway, I did it again using pipes instead of transcode and everything seems to be ok now. I guess I put this problem aside for now. I may try transcoding later again with version 1.16. |
|
22nd November 2013, 14:44 | #299 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
I will check and tune -hw option once being able to use I7 for development... |
|
Tags |
encoders, mvc |
|
|