View Full Version : MVCenc v3.0.0 - MVC 3D Encoder (Intel Quick Sync)
pistacho
4th March 2014, 00:23
As part of BDtoAVCHD (http://forum.doom9.org/showthread.php?t=154957) software I developed this tool to optimize Blu-Ray 3D to BD-25/BD-9 MVC 3D transcoding. Is based on Intel Media SDK 2021 R1 with Intel Quick Sync HW acceleration capabilities on supported Intel Graphics systems, or SW acceleration on all systems.
Since not use pipes or other tricks and has been developed for just this purpose in mind, can be expect better performance that other existent tools. Conversely offers less flexibility and more simplified command line options.
http://images.imagebam.com/da/17/c9/4d94b0564581603.png
Other features are "x264 compatible" status and progress indicator (eta) and advanced caching strategy for better I/O disk throughput.
Can expect 80 - 90 fps for high quality 3D MVC transcoding BD50 to BD25 on modern i7-4770K based system and no less of 60 fps on i7-3770K.
UPDATE: On Skylake 6700k from version 2.6.3 improved performance to 120 - 140 fps.
DOWNLOAD
BDtoAVCHD_v3.1.9.msi (https://www.connecta2000.com/download/BDtoAVCHD_v3.1.9.msi) (44.61 MB)
COMMAND LINE USAGE
http://images.imagebam.com/e1/22/c2/19c30f564581733.png
Example:
MVCenc.exe "path_to_source_avc.h264" "path_to_source_mvc.h264" 130873 "path_to_output.h264" 32699 2
CHANGELOG
Version 3.0.3 (06/03/2022)
- Updated compiler to Visual Studio 2022.
Version 3.0.0 (06/11/2021)
- Updated to Intel Media SDK 2021 R1.
Version 2.9.8 (01/02/2021)
- Updated to Intel Media SDK 2020 R1.
Version 2.9.2 (01/24/2020)
- Updated to Intel Media SDK 2019 R1 (API 1.28).
- Updated compiler to Visual Studio 2019.
Version 2.8.6 (03/19/2018)
- Updated to Intel Media SDK 2018 R2.1 (API 1.27).
- Updated compiler to Visual Studio 2017 with Update 9.
Version 2.8.0 (05/12/2018)
- Updated to Intel Media SDK 2018 R1 (API 1.26).
- Updated compiler to Visual Studio 2017 with Update 6.
Version 2.7.2 (07/19/2017)
- Updated to Intel Media SDK 2017 R1 (API 1.23).
- Updated compiler to Visual Studio 2017
Version 2.6.4 (10/26/2016)
- New 64-bit version.
- Shared memory surfaces for decode-encode parts: this improves performance by 40% on both 32-bit and 64-bit versions.
- Workaround to avoid memory leak present on Skylake systems using recent Intel HD Graphics Drivers 4501, 4530 and 4539.
- Updated compiler to Visual Studio 2015 Update 3
Version 2.5.8 (07/27/2016)
- Fixed: with some sources hangs using HW mode and recent Intel Graphics Drivers.
Version 2.5.7 (06/28/2016)
- Updated to Intel Media SDK 2016 R2 (API 1.19).
Version 2.5.6 (05/09/2016)
- Simplified memory allocation scheme.
Version 2.5.1 (11/27/2015)
- Updated to Intel Media SDK 2016 (API 1.17).
Version 2.5.0 (11/12/2015)
- Updated to Intel Media SDK 2015 Update 2.1 (API 1.16).
Version 2.4.6 (09/21/2015)
- Upgraded to Visual Studio 2015 (no functional changes).
Version 2.4.5 (08/17/2015)
- Updated to Intel Media SDK 2015 Update 2 (API 1.15).
Version 2.4.1 (04/02/2015)
- Fixed error "No free frame surfaces" triggered on SW encode + target usage 1, 2 + slow system (encode speed < 1 fps).
Version 2.4.0 (03/20/2015)
- PGS subtitles 3D depth information are preserved on transcoded stream (MVC scalable nesting SEI message).
- Updated to Intel Media SDK 2015 Update 1.
Version 2.2.4 (11/20/2014)
- Upgraded to Visual Studio 2013 (no functional changes).
Version 2.2.3 (11/07/2014)
- Fixed all Pacific Rim 3D decoding issues (SW mode and HW mode).
- Full compatible with latest Intel HD Graphics driver's series.
- Slightly reduced CPU usage and memory usage.
Version 2.2.2 (10/25/2014)
- Fixed: Possible image corruption (artifacts on MVC view) using Quick Sync acceleration and latest Intel
Graphics drivers 15.33.xx.39xx
Version 2.2.1 (10/04/2014)
- Updated to Intel Media SDK 2014 R2.
- Added Kb/s written to disk on progress/eta status message.
- Fixed: in some cases, last four or six frames of input stream are not encoded.
Version 2.1.3 (03/16/2014)
- Final version included with BDtoAVCHD v2.1.3
Version 1.3.0 (03/09/2014)
- If num_frames specified is lower that source frame count, encoded output are trimmed.
- Fixed a typo in target usage range (valid range is 1-7).
Version 1.2.0 (03/05/2014)
- Fixes artifacts/pixelation reported in some systems (HW encoding).
Version 1.1.0 (03/04/2014)
- Added command line help and current system capabilities info.
- Better strategy for detection HW API LEVEL supported by system and chose SW on not supported systems.
- Improved I/O caching strategy for better disk throughput.
- Fixed random fail on SW encoding.
Version 1.0.0 (02/26/2014)
- Initial release included with BDtoAVCHD 2.1.2
Eseninzhiv
5th March 2014, 14:10
Thank you for the work done!
There is support for 2 passes?
pistacho
5th March 2014, 23:41
There is support for 2 passes?
Not because Intel Media SDK no admits it. However, it is likely that in future Intel implements it. :)
Specifying the number of frames is only related to showing the correct status and not the amoung of frames it will decode/encode ?
I have specified 5000 frames and its showing this and still counting:
MVCenc [100.0%] 16754/5000 frames, 93.88 fps, eta 0:00:00
Also - target_usage: Intel's 'speed_vs_quality' (1-9; 1=max quality, 9=max speed)
If I specify level 8 or 9 its says: Cant init encoder, works fine with level 1-7, maybe a typo ?
pistacho
9th March 2014, 11:52
Specifying the number of frames is only related to showing the correct status and not the amoung of frames it will decode/encode ?
I have specified 5000 frames and its showing this and still counting:
MVCenc [100.0%] 16754/5000 frames, 93.88 fps, eta 0:00:00
Effectively only used to calculate the progress status, but in next version can will be used also to trim to specified number of frames. :)
Also - target_usage: Intel's 'speed_vs_quality' (1-9; 1=max quality, 9=max speed)
If I specify level 8 or 9 its says: Cant init encoder, works fine with level 1-7, maybe a typo ?
Yes it’s a typo, fortunately BDtoAVCHD never calls MVCenc with level higher than 7. Fixed in next version.
I have a problem with: MVCenc_v1.3.0, _v1.2.0, _v1.1.0..(works only _v1.0.0)
Not all frames encoded..
http://i33.fastpic.ru/big/2014/0309/6b/7b5acde5413ed7cadbd13d0f742ce56b.jpg
Right view is broken..
http://i59.fastpic.ru/big/2014/0309/c7/a26b942945a0154214b5275650dd1ac7.jpg
pistacho
9th March 2014, 18:06
@sef:
Please, upload exactly l & r files you used somewhere to check in my side.
Unfortunately, I can't upload - weak internet channel..(mobile) :(
P.S. my gpu have latest drivers..(maybe i am wrong, but, HD 3000 not implement support of API 1.7 in HW mode)
P.S.S Intel Developer forum: "The Intel(R) 2nd Generation Core processors (with Intel(R) HD Graphics 3000 adapters) only support hardware features of (up to) API 1.4. Newer hardware supports new features."
What to do.. :(
pistacho
9th March 2014, 19:55
I think:
a) Your source has not 600 frames (bad cut, etc.) really has 593 frames
b) A broken right view is produced by bad settings in tsMuxeR (please uncheck "continually insert PPS/SPS" and CHECK "do not change SEI and VUI data" for AVC and MVC tracks)
c) If you use a SW mode "old" GPU are NOT used at all.
Wishbringer
16th March 2014, 20:14
I don't know MVCenc in deep nor Intel SDK,
but I think it can't reach quality of x264 in AVC part (left eye for normal).
So my question: Is it possible to alter MVCenc that kind that x264 is used for encoding AVC-Part and Intel SDK for MVC-(Diff)-Tracks (right eye).
pistacho
18th March 2014, 23:27
I don't know MVCenc in deep nor Intel SDK,
but I think it can't reach quality of x264 in AVC part (left eye for normal).
So my question: Is it possible to alter MVCenc that kind that x264 is used for encoding AVC-Part and Intel SDK for MVC-(Diff)-Tracks (right eye).
Unfortunately it's not possible because AVC - MVC streams are not independent and must be generated by same encoder. But perhaps Intel improves the quality introducing 2-pass encoding or x264 implementing 3D MVC encoding (in a future probably both things).
colinhunt
21st March 2014, 16:19
First test run ended in an error before encoding started. Found this in error_log.txt: EXIT CODE => -1 (0xFFFFFFFF)
Encoding rig is Windows 7 64-bit, i7-3770K (with HD4000 GPU) and 16GB of RAM. I'm controlling the rig over Remote Desktop, in case that makes any difference.
pistacho
22nd March 2014, 17:34
And what is the command line? or paste entire error_log.txt also MVCenc_log.txt can help
colinhunt
22nd March 2014, 20:29
And what is the command line? or paste entire error_log.txt also MVCenc_log.txt can help
MVCenc_log.txt is empty.
error_log.txt:
-[18/03/2014 - 20:51:36]--------------------------------------------------------------------------------
LAST CMD LINE => "C:\Program Files (x86)\BDtoAVCHD\MVCenc.exe" "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.avc.h264" "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.mvc.h264" 118090 "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.264" 34529 3 60000 30000
EXIT CODE => -1 (0xFFFFFFFF)
--------------------------------------------------------------------------------------------------------
I ran a second test on another PC last night. It's also Win7 64-bit, but with a i7-3820. That job began encoding video, but had stopped/crashed at some point during the night. Unfortunately I managed to delete the workfiles (d'oh!) but I remember looking at the error_log and thinking, "oh, it's the same exit code".
pistacho
22nd March 2014, 20:46
Copy "LAST CMD LINE" to a text file and
add "pause" command.
Rename to .bat
e.g.
test.bat
"C:\Program Files (x86)\BDtoAVCHD\MVCenc.exe" "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.avc.h264" "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.mvc.h264" 118090 "F:\_TEMP\UNIVERSAL SOLDIER [2D+3D].job_0.264" 34529 3 60000 30000
pause
Execute bat and take a screenshot
EDIT:
I ran a second test on another PC last night. It's also Win7 64-bit, but with a i7-3820. That job began encoding video, but had stopped/crashed at some point during the night. Unfortunately I managed to delete the workfiles (d'oh!) but I remember looking at the error_log and thinking, "oh, it's the same exit code".
In this case (because it has been running a while) for sure the log is not empty.
Please, repeat and paste last lines of MVCenc_log.
colinhunt
23rd March 2014, 00:15
Copy "LAST CMD LINE" to a text file and add "pause" command. Rename to .bat
This is what I got from the i7-3770K rig:
F:\_TEMP>"C:\Program Files (x86)\BDtoAVCHD\MVCenc.exe" "F:\_TEMP\base.avc" "F:\_TEMP\dependent.mvc"
18090 "F:\_TEMP\OUTPUT.job_0.264" 34529 3 60000 30000
MVCenc v1.3.0. This tool is part of BDtoAVCHD software. Coded by Joel Gali.
Intel Media SDK Decoder Info: API LEVEL 1.8 -
Source Information:
- Resolution: 1920x1080
- Frame Rate: 48000/2002 (23.976 fps)
MVCenc: ERROR -> QueryIOSurf
F:\_TEMP>pause
Press any key to continue . . .
I had renamed the source files for a test I was running on another software, in case you're wondering. My guess is MVCenc can't access resources because I'm accessing the rig over Remote Desktop.
Setting up another run on the i7-3820 (it's the one I'm typing on now) to see what it writes to MVCenc_log.
pistacho
23rd March 2014, 10:53
Seems that your system has multiple graphics adapters and Intel Graphics has driver installed but is inactive (is not primary display and/or not has a monitor connected).
Try, if you can, disable others graphics adapters and attach a monitor to Intel Graphics.
Also you can create a "fake display" using this method:
http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html
And use Intel Media SDK System Analyzer tool (included with BDtoAVCHD) to check configuration => BDtoAVCHD Help Menu.
colinhunt
23rd March 2014, 11:23
Intel Media SDK System Analyzer (32 bit)
The following versions of Media SDK API are supported by platform/driver:
Version Target Supported Dec Enc
1.0 HW No
1.0 SW Yes X X
1.1 HW No
1.1 SW Yes X X
1.3 HW No
1.3 SW Yes X X
1.4 HW No
1.4 SW Yes X X
1.5 HW No
1.5 SW Yes X X
1.6 HW No
1.6 SW Yes X X
1.7 HW No
1.7 SW Yes X X
1.8 HW No
1.8 SW Yes X X
Graphics Devices:
Name Version State
Intel(R) HD Graphics 4000 10.18.10.3496 Active
NVIDIA GeForce GTX 660 Ti 9.18.13.3489 08
System info:
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
OS: Microsoft Windows 7 Ultimate
Arch: 64-bit
The rig is physically located in such a way that attaching a monitor is currently not possible, but I'll try the "fake display" method.
update: Remote Desktop won't allow changing displays so I switched to TeamViewer. Faking a display and forcing Intel HD4000 did not work quite like the tutorial explains, but I managed it by sheer trial-and-error. The result:
The following versions of Media SDK API are supported by platform/driver:
Version Target Supported Dec Enc
1.0 HW Yes X X
1.0 SW Yes X X
1.1 HW Yes X X
1.1 SW Yes X X
1.3 HW Yes X X
1.3 SW Yes X X
1.4 HW Yes X X
1.4 SW Yes X X
1.5 HW Yes X X
1.5 SW Yes X X
1.6 HW Yes X X
1.6 SW Yes X X
1.7 HW Yes X X
1.7 SW Yes X X
1.8 HW Yes X X
1.8 SW Yes X X
Graphics Devices:
Name Version State
Intel(R) HD Graphics 4000 10.18.10.3496 08
NVIDIA GeForce GTX 660 Ti 9.18.13.3489 Active
Holy moley... I started another encoding run, and according to BDtoAVCHD the rig is encoding MVC at 65 fps!
pistacho
23rd March 2014, 12:18
Right! At this point should work OK.
colinhunt
23rd March 2014, 13:04
Right! At this point should work OK.
Yup, it appears to working great! By the way, how can I set the quality of encoding? I'm assuming MVCenc defaults to 3; what if I wanted to use 2 or 1?
pistacho
23rd March 2014, 13:13
Yup, it appears to working great! By the way, how can I set the quality of encoding? I'm assuming MVCenc defaults to 3; what if I wanted to use 2 or 1?
Inside BDtoAVCHD environment target usage is linked to speed vs quality preset:
(default is 4)
int target_usage = 4;
if (!strcmp (preset, "placebo")) target_usage = 1;
if (!strcmp (preset, "veryslow")) target_usage = 2;
if (!strcmp (preset, "slower")) target_usage = 2;
if (!strcmp (preset, "slow")) target_usage = 3;
if (!strcmp (preset, "fast")) target_usage = 5;
if (!strcmp (preset, "faster")) target_usage = 6;
if (!strcmp (preset, "veryfast")) target_usage = 6;
if (!strcmp (preset, "superfast")) target_usage = 7;
if (!strcmp (preset, "ultrafast")) target_usage = 7;
colinhunt
23rd March 2014, 13:17
Inside BDtoAVCHD environment target usage is linked to speed vs quality preset
You mean I can change the quality to 2 by selecting "slower" or "veryslow" in the Speed vs. Quality pulldown menu?
pistacho
23rd March 2014, 13:22
Yes! :)
colinhunt
23rd March 2014, 13:23
Yes! :)
Excellent. Thank you very much for a very nice software!
colinhunt
23rd March 2014, 14:42
Hmm... This has now happened twice: I've tried to re-encode a Blu-ray 3D title into full 3D MVC .ISO, but for some reason BDtoAVCHD attempts to output 2D. I double-checked that "3D MVC" was selected in 3D Mode Selection, but the encode failed. Here's the error log and other data:
-[23/03/2014 - 11:49:28]--------------------------------------------------------------------------------
LAST CMD LINE => "C:\Program Files (x86)\BDtoAVCHD\x264\x264.exe" --preset "veryslow" --tune "film" --bluray-compat --level "4.1" --vbv-bufsize
30000 --vbv-maxrate 40000 --bitrate 30537 --stats "F:\_TEMP\SPIDERS [2D+3D].ISO.job_0.stats" --keyint 24 --open-gop --slices 4 --frame-packing 14
--qpfile "F:\_TEMP\SPIDERS [2D+3D].ISO.job_0.qpfile" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o NUL ""
EXIT CODE => -1 (0xFFFFFFFF)
--------------------------------------------------------------------------------------------------------
There's no MVCenc_log in the temp directory, but there's a pass1_log.txt:
ffms [error]: could not create index
lavf [error]: could not open input file
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `' via any method!
So even though I made sure the software was set up for 3D MVC output, it tried to run the encode on x264.
update: After some testing, it looks like I need to close and restart BDtoAVCHD after every encode to avoid this problem.
colinhunt
23rd March 2014, 17:44
While testing 3D output from BDtoAVCHD I came up with a couple of feature requests:
1) the program should keep a database of source bitrates, so I wouldn't have to scan them every time when running several backups of the same title
2) also, for several backup runs, demuxed source files should not be deleted automatically like they are now; the program should be able to use previously demuxed files to speed things up
colinhunt
23rd March 2014, 19:07
Ran a quality=3 backup of Gravity, and it looked fine. Ran another backup, this time with "placebo" (quality=1) and it came out garbled. Base view is fine, but dependent view is messed up. Did another run with quality set for 2, and that came out garbled as well.
colinhunt
23rd March 2014, 23:18
Heh. I tried to make a 3D MVC backup of "3 A.M.", a Thai horror movie, and the process seems to have stopped at 100%, just before remuxing. Status line has read "MVCenc [100.00%] 136060/136079 frames, 65.54 fps, eta 0:00:00" for a couple of hours now, and nothing happens.
The very last line of MVCenc_log.txt is:
"fps, eta 0:00:46 MVCenc [97.8%] 133089/136079 frames, 65.59 fps, eta 0:00:45 MVCenc [97.9%] 133155/136079 frames, 65.59 fp"
pistacho
24th March 2014, 11:35
I made a conversion, GRAVITY with target_usage = 1, i7-3770k same grahic drivers and result are perfect, so seems that cause of "garbled" is other than target usage = 1.
For everything you mention seems that your system is unstable and fail randomly.
I cannot reproduce anything you mention.
I have also checked the source code and for example the x264 command line --frame-packing 14 cannot generated by my program and no sense :confused:
-[23/03/2014 - 11:49:28]--------------------------------------------------------------------------------
LAST CMD LINE => "C:\Program Files (x86)\BDtoAVCHD\x264\x264.exe" --preset "veryslow" --tune "film" --bluray-compat --level "4.1" --vbv-bufsize
30000 --vbv-maxrate 40000 --bitrate 30537 --stats "F:\_TEMP\SPIDERS [2D+3D].ISO.job_0.stats" --keyint 24 --open-gop --slices 4 --frame-packing 14
--qpfile "F:\_TEMP\SPIDERS [2D+3D].ISO.job_0.qpfile" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o NUL ""
EXIT CODE => -1 (0xFFFFFFFF)
--------------------------------------------------------------------------------------------------------
colinhunt
24th March 2014, 11:56
I made a conversion, GRAVITY with target_usage = 1, i7-3770k same grahic drivers and result are perfect, so seems that cause of "garbled" is other than target usage = 1.
It's peculiar, I know. I even rebooted the rig remotely and re-tried with target_usage = 1, and the output was garbled again :/
For everything you mention seems that your system is unstable and fail randomly.
Everything is possible. And yet it works like a charm with BD-Rebuilder and several other software programs. BD-RB had no problem with 3 A.M., for example, while BDtoAVCHD got stuck at the end of the file every time (three attempts).
I have also checked the source code and for example the x264 command line --frame-packing 14 cannot generated by my program and no sense :confused:
Did you try what happens when you do one MVC encode, then load another source and try to make another MVC encode right away, without restarting BDtoAVCHD? It looks like I can't do two MVC encodes in a row without the second one getting messed up (x264 runs instead of MVCenc). The problem disappears if I shut down and restart BDtoAVCHD after every MVC encode.
pistacho
24th March 2014, 12:14
It's peculiar, I know. I even rebooted the rig remotely and re-tried with target_usage = 1, and the output was garbled again :/
More quality = more hardware demand = more heat = more unstable
Everything is possible. And yet it works like a charm with BD-Rebuilder and several other software programs. BD-RB had no problem with 3 A.M., for example, while BDtoAVCHD got stuck at the end of the file every time (three attempts).
BDRebuilder not reach 65 fps (imagine this, because I have not tried). Then not demand much to hardware.
Did you try what happens when you do one MVC encode, then load another source and try to make another MVC encode right away, without restarting BDtoAVCHD? It looks like I can't do two MVC encodes in a row without the second one getting messed up (x264 runs instead of MVCenc). The problem disappears if I shut down and restart BDtoAVCHD after every MVC encode.
I have put up to 4 MVC jobs in the queue and have completed all OK.
colinhunt
24th March 2014, 12:27
More quality = more hardware demand = more heat = more unstable
Absolutely. When doing 2D backups on BD-RB, all CPU cores run at 100% for 8-12 hours straight. That's pretty taxing, and yet BD-RB has not crashed this rig once. Going by CPU Usage info alone, running an MVC encoding job with QuickSync is much less taxing than that. However, it's possible the desktop CPU Usage gadget I use does not tell the whole truth during MVC/QS encodes.
About the garbled output: I've only tried playing the output on Stereoscopic Player so far. I haven't burned the data on a BD-R to test on a stand-alone, because target_usage=3 output plays perfectly on Stereoscopic Player, but u:1 and u:2 do not. I'll have to find a BD-RE disc to try the output on a standalone player.
BDRebuilder not reach 65 fps (imagine this, because I have not tried). Then not demand much to hardware.
It reached something like 62 fps when I did "3 A.M. 3D" on it last night.
I have put up to 4 MVC jobs in the queue and have completed all OK.
I haven't used the queue, simply started another job manually once the previous one finished. That's when the program tries to make a 3D title using x264. It's like some corrupted data gets left in memory after a job, and is then read/used for the next one. This reminds me of multiAVCHD which has to be restarted for every job, even according to its creator.
pistacho
25th March 2014, 09:42
I haven't used the queue, simply started another job manually once the previous one finished. That's when the program tries to make a 3D title using x264. It's like some corrupted data gets left in memory after a job, and is then read/used for the next one. This reminds me of multiAVCHD which has to be restarted for every job, even according to its creator.
I tested again: start MVC conversion, wait to finish, no close, start other MVC conversion and all is OK. I’m sorry but I cannot reproduce this bug.
About the garbled output: I've only tried playing the output on Stereoscopic Player so far. I haven't burned the data on a BD-R to test on a stand-alone, because target_usage=3 output plays perfectly on Stereoscopic Player, but u:1 and u:2 do not. I'll have to find a BD-RE disc to try the output on a standalone player.
I also tried on Stereoscopic Player and image is perfect here with target_usage=1
colinhunt
25th March 2014, 10:47
I tested again: start MVC conversion, wait to finish, no close, start other MVC conversion and all is OK. I’m sorry but I cannot reproduce this bug.
OK :/ There's really nothing special in my rig, it's not overclocked or anything. This is very odd.
I also tried on Stereoscopic Player and image is perfect here with target_usage=1
I did four backups in a row with BDRB yesterday, all with target_usage=2 and they all play perfectly on Stereoscopic Player. All were done using QS, too, with encoding speed varying between 55 and 70 fps. BDRB has a tendency of creating undersized discs which is why I preferred your solution.
Hmm. Can I force BDtoAVCHD into using software decoding and hardware encoding, or vice-versa? I remember a while back, when testing FRIMEncoder, I got garbled output when decoding was done in hardware. Image corruption went away when I switched to software decode + hardware encode.
pistacho
25th March 2014, 11:50
I remember a while back, when testing FRIMEncoder, I got garbled output when decoding was done in hardware. Image corruption went away when I switched to software decode + hardware encode.
Interesting: this explains that garbled output is not related exclusively to MVCenc but Quick Sync HW on your system.
MVCenc uses HW decoding + HW encoding (if available) and since uses only one loop (common for encoding + decoding) is not easy to do one process in SW and other in HW.
But, for testing proposes, you can force SW decoding + SW encoding renaming Intel Media SDK path to something:
C:\Program Files\Intel\Media SDK => C:\Program Files\Intel\Media SDK__
Also I think that root cause of your Quick Sync HW problems may be in BIOS video memory settings. For example select a greater value of video memory size 128MB or 256MB or more.
http://img43.imageshack.us/img43/7499/screenshot20120803at120.png
(this is just an example image that I found on google. Another time I will look like I have it on my system)
colinhunt
25th March 2014, 14:04
Interesting: this explains that garbled output is not related exclusively to MVCenc but Quick Sync HW on your system.
Yes-ss... but with the latest FRIMEncoder I can run both decode and encode in HW without image corruption.
But, for testing proposes, you can force SW decoding + SW encoding renaming Intel Media SDK path to something:
I'll give it a shot, thanks!
Also I think that root cause of your Quick Sync HW problems may be in BIOS video memory settings.
Ah-ha, now we might be on to something. The rig also moonlights as a Hackintosh which requires a very small video memory setting. I can't remember what I set the memory amount to before carrying the rig to its current location. I suppose I need to carry it back to get a good look at BIOS, and maybe update it to the latest version while I'm at it :)
pistacho
4th October 2014, 16:49
New version 2.2.1
Version 2.2.1 (10/04/2014)
- Updated to Intel Media SDK 2014 R2.
- Added Kb/s written to disk on progress/eta status message.
- Fixed: in some cases, last four or six frames of input stream are not encoded.
First post is updated also.
pistacho
26th October 2014, 11:33
Version 2.2.2 (10/25/2014)
Fixed: Possible image corruption (artifacts on MVC view) using Quick Sync acceleration and latest Intel Graphics drivers 15.33.xx.39xx
nunub
28th October 2014, 13:54
And what about SBS/TAB to 3D mvc encoding.
pistacho
1st November 2014, 13:37
And what about SBS/TAB to 3D mvc encoding.
This tool is for very specific task (recode BluRay 3D to BD25/ BD9 MVC) and SBS/TAB source is not needed.
dorati
2nd November 2014, 09:56
Works great. Thank yor for this Tool !
pistacho
7th November 2014, 16:23
Version 2.2.3 (11/07/2014)
Fixed all Pacific Rim 3D decoding issues (SW mode and HW mode).
Full compatible with latest Intel HD Graphics driver's series.
Slightly reduced CPU usage and memory usage.
dorati
9th November 2014, 14:50
I have some problems.
I demux the original file with eac3to and then i use this tool.
On My i7-3517 Ivy Bridge, the mfc-video is ok.
On Haswell i get a lot of artifacts. What i make wrong ?
This commandline i use:
C:\Program Files (x86)\BDtoAVCHD>mvcenc "u:\eac3to\video.avc" "u:\eac3to\video.mvc" 999999 c:\eac3to\convert.h264 32699 1
MVCenc v2.2.3. This tool is part of BDtoAVCHD software. Coded by Joel Gali.
Intel Media SDK Decoder Info: API LEVEL 1.11 - HW
Source Information:
- Resolution: 1920x1080
- Frame Rate: 24000/1001 (23.976 fps)
Intel Media SDK Encoder Info: API LEVEL 1.11 - HW
Target Information:
- Resolution: 1920x1080
- Frame Rate: 24000/1001 (23.976 fps)
- Codec: AVC, Level: 4.1, Profile: AVC Stereo High
- Num Slice: 6
- Num Ref: 4
- GOP: 24-4-0 Open
- Buffer Size: 30000 Kbits
- Max Bitrate: 60000 Kbps
- Bitrate: 32699 Kbps
- Tar. Usage: 1
MVCenc [12.2%] 122384/999999 frames, 29.64 fps, 377.45 Kb/s, eta 8:13:27
dorati
9th November 2014, 15:01
Update..
On Stereoscopic Player, all look fine. The Problem i have only with my SamsungTV and m2ts.
Somebody the same problem ?
pistacho
9th November 2014, 23:01
Update..
On Stereoscopic Player, all look fine. The Problem i have only with my SamsungTV and m2ts.
Somebody the same problem ?
What method do you use to create the m2ts?
Maybe if you create the ISO structure using BDtoAVCHD and then use the SSIF file works OK with Samsung TV...
dorati
10th November 2014, 18:18
I make some tests:
I use tsmuxer 2.6.12 to create m2ts.
I found, when select "Always rebuild SEI and VUI data"; the picture seems ok.
Is this setting ok? I read, when use this option, the file normaly is not 100% ok.
pistacho
10th November 2014, 20:42
I don't know. The only scenario tested by me is generating ISO structure to play thought standalone Blu-Ray player or compatible SW (Stereoscopic Player, TMT6, etc.) and in this case is NOT used "rebuild SEI and VUI data" option.
But probably muxer requirements are different for Samsung TV. Anyway it seems clear that this is a muxing issue (unrelated to the encoder itself).
Though not understand how the TV can correctly play 3D content with only .m2ts as there is important information in other files of the ISO structure (such as the assignation of left/right views to AVC/MVC streams).
pistacho
20th November 2014, 11:30
Version 2.2.4 (11/20/2014)
- Upgraded to Visual Studio 2013 (no functional changes).
Tounet
24th November 2014, 11:07
Hello there :)
Thx for you're great tool. Very useful for re-encoding 3D blurays.
There is some problems with some bluray 3D muxed in m2ts on Samsung TVs. I guess that's a bitrate problem. (officially, in the samsung doc, max bitrate is 30Mb/s) This require more testing.
With this tool, we can simply re-encode the bluray with lower bitrate, and that's works well.
I suggest some more functionnality for BDtoAVCHD, i 'll post in the good thread.
pistacho
30th November 2014, 12:18
I guess that's a bitrate problem. (officially, in the samsung doc, max bitrate is 30Mb/s) This require more testing.
This is interesting: bitrate really could be the cause of some problems reported:
Target Information:
- Resolution: 1920x1080
- Frame Rate: 24000/1001 (23.976 fps)
- Codec: AVC, Level: 4.1, Profile: AVC Stereo High
- Num Slice: 6
- Num Ref: 4
- GOP: 24-4-0 Open
- Buffer Size: 30000 Kbits
- Max Bitrate: 60000 Kbps
- Bitrate: 32699 Kbps
- Tar. Usage: 1
Then I put a sample command lines that can be used for testing:
max_bitrate = 30000
buffer_size = 30000
bitrate = 25000
encode:
"C:\Program Files (x86)\BDtoAVCHD\MVCenc.exe" "T:\TEMP\source.avc.h264" "T:\TEMP\source.mvc.h264" 187608 "T:\TEMP\encode.h264" 25000 4 30000 30000
187608 is the frame count of source, change accordingly or put a smaller number (10000) for short test.
remux:
1. Create a text file called "tsmuxer.meta":
MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr --vbv-len=500
V_MPEG4/ISO/MVC, "T:\TEMP\encode.h264", subTrack=1
V_MPEG4/ISO/AVC, "T:\TEMP\encode.h264", subTrack=2
2. command line:
"C:\Program Files (x86)\BDtoAVCHD\tsMuxeR\2.x\tsMuxeR.exe" "T:\TEMP\tsmuxer.meta" "T:\TEMP\encode.m2ts"
If dorati, Tounet or someone with a Samsung TV proves it and comment the result will be very useful :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.