Free H.264 MVC 3D Encoder

[jdobbs]

Jdobbs, does "MULTIPROCESS" need to be in hidden option for this method to work? I tired with instructions and it run in only one instance.

I am doing again by adding multiprocess to options.No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

[HWK]

No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

Hmm, then why didn't it run with two instance even though I set this before opening main program and of course I replace exe file.

I use option import and choose side by side 3D which is 4th option in import caterogy.

Source: Pacific Rim and it is half SBS.

[Options]
VERSION=0.46.0.12
MODE=3
ENCODE_QUALITY=0
ONEPASS_ENCODING=2
AUTO_QUALITY=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
IGNORE_3D=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=1
AVCHD=1
REMOVE_WORKFILES=0
MOVIE_ONLY_LOOP=1
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=1
USE_LAVF=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
UNMASK_CHAPTER=1
COMPLETION_BEEP=1
DGDECNV=1
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=23500
FRIM_SW_PROCESSES=2
SHOW_ENCODER=1
MINIMIZE_TO_TRAY=1
TARGET_SIZE=23500
[Paths]
DGIndexNV=D:\Blu-ray Remaster\dgdecnv2046\DGIndexNV.exe
DGDecNV=D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll
WORKING_PATH=E:\BD_RB\WORKFILES\
SOURCE_PATH=E:\BD_RB\WORKFILES\IMPORTS\PACIFIC_RIM\


Maybe something you can see or which I have missed.

[Hajnal]

No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

http://thumbnails109.imagebam.com/30730/e0343b307290167.jpg (http://www.imagebam.com/image/e0343b307290167)

source
avc ~14.8gb
mvc ~8.8gb

bdrb software
avc ~11gb
mvc ~9.1gb ??

Frimtranscode gui
avc ~10gb
mvc ~10gb

dvdfab
avc ~12.5gb
mvc ~8gb

upd.

bdrb hardware
avc ~10gb
mvc ~10gb - Why become larger than the original?

and no 3D subtitles

http://thumbnails110.imagebam.com/30733/1ce105307328210.jpg (http://www.imagebam.com/image/1ce105307328210)

[jdobbs]

Hmm, then why didn't it run with two instance even though I set this before opening main program and of course I replace exe file.

I use option import and choose side by side 3D which is 4th option in import caterogy.

Source: Pacific Rim and it is half SBS.



Maybe something you can see or which I have missed. I apologize, my fault. I typed it wrong in my post. You have FRIM_SW_PROCESSES=2 and it should be FRIM_SBS_PROCESSES=2.

[HWK]

You have FRIM_SW_PROCESSES=2 and it should be FRIM_SBS_PROCESSES=2

hmm, thanks I will test again.

[jdobbs]

hmm, thanks I will test again.Sorry about that. I wasted a lot of your time with bad instructions.

[HWK]

Sorry about that. I wasted a lot of your time with bad instructions.

nah, don't be that is fun part of beta testing :D

[HWK]

http://thumbnails109.imagebam.com/30730/e0343b307290167.jpg (http://www.imagebam.com/image/e0343b307290167)

source
avc ~14.8gb
mvc ~8.8gb

bdrb software
avc ~11gb
mvc ~9.1gb ??

Frimtranscode gui
avc ~10gb
mvc ~10gb

dvdfab
avc ~12.5gb
mvc ~8gb

upd.

bdrb hardware
avc ~10gb
mvc ~10gb - Why become larger than the original?

and no 3D subtitles

http://thumbnails110.imagebam.com/30733/1ce105307328210.jpg (http://www.imagebam.com/image/1ce105307328210)
You are trying two address two issues in one post, lets discuss one thing at a time.

BD-Rb is software, there is no hardware part to it.
Muxer used by BD-RB has broken 3D subtitle support in latest version.

[update]
After having closer look I realized you were referring to hardware support provided by Intel not BD-RB.

[jdobbs]

@Hajnal

As you probably know (since you posted in this thread), BD-RB uses FRIMEncode for encoding MVC. In the version you are using there is a bug that doesn't allow BD-RB to keep original 3D sources intact -- in the next release you should never see a target that is larger than the source. It is the bitrate that sets the output size -- and I would guess that your target size that drives the size. The ratio of the base to dependent stream is pretty much out of BD-RB's control, as it is driven by the Intel SDK. I can't really speak to the HW results, as I have no system that uses it. As for comparison to other packages -- I'd rather not comment and I'd appreciate it if those discussions were avoided. For one thing it isn't even close to apples-to-apples, second it violates the "what's best" forum rule -- but more importantly we really shouldn't care how other packages do. I personally only care about my software and the apps it uses (like FRIMEncode) perform.

[Hajnal]

sorry, it's just a compare only

BDRB & Intel Hardware ~40 minutes (i5)

- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 130873 frames
- Bitrate: 31047 Kbs
- Using FRIMEncoder for MVC encoding
- [17:58:55] Reencoding: VID_00098, Pass 1 of 1
- [18:36:06] Video Encode complete

[jdobbs]

sorry, it's just a compare only

BDRB & Intel Hardware ~50 minutes (i5)

- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 130*873 frames
- Bitrate: 31*047 Kbs
- Using FRIMEncoder for MVC encoding The HW setting is pretty fast in comparison. On my AMD system with 8 processors (FX-8350) that would likely take about 3 1/2 hours in SW mode.

[Hajnal]

The HW setting is pretty fast in comparison. On my AMD system with 8 processors (FX-8350) that would likely take about 3 1/2 hours in SW mode.


the settings wrong, moving plaid
http://thumbnails101.imagebam.com/30738/147cb5307375980.jpg (http://www.imagebam.com/image/147cb5307375980)

BDRB make MVCENCODE.BAT (workfiles)
-gop 24 4 0 S

edit

-gop 50 1 2 o

[HWK]

What is playback device for which you are seeing this error?

[omegaman7]

What is playback device for which you are seeing this error?

Indeed. If I wanna confirm results like that, I use a standalone player, or VirtualDub to snatch the frame.

[Hajnal]

What is playback device for which you are seeing this error?

pdvd
windvd
but only when playing 3d

Frimtranscode Gui

[jdobbs]

the settings wrong, moving plaid
http://thumbnails101.imagebam.com/30738/147cb5307375980.jpg (http://www.imagebam.com/image/147cb5307375980)

BDRB make MVCENCODE.BAT (workfiles)
-gop 24 4 0 S

edit

-gop 50 1 2 oI'm not sure what you're trying to say. But BD-RB's settings are meant for blu-ray output. The edited setting you've shown completely violates the blu-ray standard. Maximum GOP length is 24 for 1080p 3D unless the maxbitrate is under 15Mbs (which is likely too low) -- and even then the maximum GOP length is limited to 48.

I've done lots of encoding with FRIMEncode, likely more than most, since my system has been encoding 24/7 testing it -- and I have never once seen anything like that. You haven't given enough information to make heads-or-tails of it... without logs and settings it is pretty much useless.

[Hajnal]

I'm not sure what you're trying to say. But BD-RB's settings are meant for blu-ray output. The edited setting you've shown completely violates the blu-ray standard. Maximum GOP length is 24 for 1080p 3D unless the maxbitrate is under 15Mbs (which is likely too low) -- and even then the maximum GOP length is limited to 48.

I've done lots of encoding with FRIMEncode, likely more than most, since my system has been encoding 24/7 testing it -- and I have never once seen anything like that. You haven't given enough information to make heads-or-tails of it... without logs and settings it is pretty much useless.


BDRB - movie-only backup

FRIM_SW_DECODE=0
FRIM_SW_ENCODE=0
FRIM_SW_PROCESSES=2

MVCENCODE.BAT (fix cli?)

"C:\Programok\BD_Rebuilder\tools\FRIMDecode.exe" -ts -i::mvc "K:\BDMV\STREAM\00098.m2ts" "K:\BDMV\STREAM\00104.m2ts" -o \\.\pipe\bdrb.yuv | "C:\Programok\BD_Rebuilder\tools\FRIMEncode.exe" mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\TEMP4\WORKFILES\VID_00098.AVS.264" -o "D:\TEMP4\WORKFILES\VID_00098.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 2 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 31046 45000 -gop 50 4 0 S -maxdpb 4

job done, play bad as the picture, (only 3D) 2D good

Frimtrancode gui
-gop 50 4 0 S change 48 4 0 o

encod,mux 3d.iso, good play

[HWK]

BDRB - movie-only backup

FRIM_SW_DECODE=0
FRIM_SW_ENCODE=0
FRIM_SW_PROCESSES=2

MVCENCODE.BAT (fix cli?)

"C:\Programok\BD_Rebuilder\tools\FRIMDecode.exe" -ts -i::mvc "K:\BDMV\STREAM\00098.m2ts" "K:\BDMV\STREAM\00104.m2ts" -o \\.\pipe\bdrb.yuv | "C:\Programok\BD_Rebuilder\tools\FRIMEncode.exe" mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\TEMP4\WORKFILES\VID_00098.AVS.264" -o "D:\TEMP4\WORKFILES\VID_00098.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 2 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 31046 45000 -gop 50 4 0 S -maxdpb 4

job done, play bad as the picture, (only 3D) 2D good

Frimtrancode gui
-gop 50 4 0 S change 48 4 0 o

encod,mux 3d.iso, good play

See the things I have highlight in red, they are responsible for your problem. BD specs clearly state GOP length must be one sec if max bitrate is higher than 15000 which it is. Example if fps 23.976024 then GOP must be 24 frames.

As for second question you can't compare, transcoder only deal with quantization to lower output requirement. Where encoder rebuild picture from scratch.

Either way, bottom line is you need follow specs or let BD-RB handle it. Else do not complain if things don't work.

[HWK]

pdvd
windvd
but only when playing 3d

Frimtranscode Gui

Given the setting you are using, I wouldn't be surprised if it doesn't play on hardware player.

Also consider yourself lucky if it plays at all on software. Also software usually don't follow specs that closely as hardware do and once again it is best to stick BD-RB default setting.

[Hajnal]

See the things I have highlight in red, they are responsible for your problem. BD specs clearly state GOP length must be one sec if max bitrate is higher than 15000 which it is. Example if fps 23.976024 then GOP must be 24 frames.

As for second question you can't compare, transcoder only deal with quantization to lower output requirement. Where encoder rebuild picture from scratch.

Either way, bottom line is you need follow specs or let BD-RB handle it. Else do not complain if things don't work.

http://thumbnails110.imagebam.com/30743/52e930307421207.jpg (http://www.imagebam.com/image/52e930307421207)

I did so
and play bad as the picture

[HWK]

http://thumbnails110.imagebam.com/30743/52e930307421207.jpg (http://www.imagebam.com/image/52e930307421207)

I did so
and play bad as the picture

Try with software, instead of hardware. Accroding this picture media SDK is hardware. At very least decoding is done on software.

[Hajnal]

Try with software, instead of hardware. Accroding this picture media SDK is hardware. At very least decoding is done on software.

the fault is with me
GOP type
- strict = bad
- open = good

tested

[HWK]

Jdobbs, which version of DgdecNV were you using?

[HWK]

@videofan3d

Just want update or progress on ability to insert I frame on demand

http://forum.doom9.org/showpost.php?p=1656939&postcount=390 (http://forum.doom9.org/showpost.php?p=1656939&postcount=390)

[jdobbs]

Jdobbs, which version of DgdecNV were you using?I'm using 2046 (32 bit).

[HWK]

Jdobbs, how many movies you want me to try?

I am finished Pacific Rim and currently doing Avatar with balanced setting in FRIMEncoder, next one I am gone try World War Z (3-way in Dgdecnv) with target usage in frim set to value of 2 or 1 and then something else.

Also if you want I can try with directshowsource as well. Anyways here is the result of first one and no I didn't experience any error during encoding, also just a reminder I am using software mode in FRIMEncoder.

[09:47:13] Importing M2TS: PACIFIC_RIM
- Preparing M2TS for processing...
- Collecting audio/video streams from source...
- Building pseudo-BD source structure...
[11:55:59] Video import completed successfully.
----------------------
[02/11/14] BD Rebuilder v0.46.12t (beta)
[12:00:00] Source: PACIFIC_RIM_00000
- Input BD size: 163.20 GB
- Approximate total content: [02:11:16.952]
- Target BD size: 46.26 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Converting SBS source to BD-3D format
- Quality: Good (Very Fast), ABR
- MVC BD-3D Output Mode enabled
- Decoding/Frame serving: DGDecNV [2-way]
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[12:00:00] PHASE ONE, Encoding
- [12:00:00] Processing: VID_00000 (1 of 1)
- [12:00:00] Extracting A/V streams [VID_00000]
- [12:59:52] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 188,858 frames
- Bitrate: 35,000 Kbs
- Using FRIMEncoder for MVC encoding
- [12:59:52] Reencoding: VID_00000, Pass 1 of 1
- [16:52:55] Video Encode complete
- [16:52:55] Processing audio tracks
- Track 4352 (eng): Keeping original audio
[16:52:55]PHASE ONE complete
[16:52:55]PHASE TWO - Rebuild Started
- [16:52:56] Rebuilding BD file Structure
[17:05:28] - Encode and Rebuild complete
[17:05:28] JOB: PACIFIC_RIM finished.


http://i58.tinypic.com/9hrn7b.jpghttp://i59.tinypic.com/ir5ouc.jpg

In first screenshot I want to show encoding completely successfully and for second one I want to show tsmuxer had no problem in joining files and building structure.

[02/11/14] Checking System Settings
- BD-Rebuilder v0.46.12t (beta)
- Windows Version: 6.1 [7601]
- AVISYNTH Version: 2.5.8.0, Ok
- HAALI Splitter: 1.9.42.1, Ok
- FFDSHOW: 4504, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- AnyDVD settings check: Ok.
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[02/11/14] Systems Settings Check complete


First VID_00000.AVS.1 file contents

"D:\Blu-ray Remaster\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.264" "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.mvc" -sw -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 S -maxdpb 4


Second VID_00000.AVS.2 file contents

"D:\Blu-ray Remaster\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.264" "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.mvc" -sw -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 S -maxdpb 4


First avisynth script

#Created by BD Rebuilder - v0.46.12t (beta)
LoadPlugin("D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll")
DGSource("E:\BD_RB\WORKFILES\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-94429)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)


Second avisynth script

#Created by BD Rebuilder - v0.46.12t (beta)
LoadPlugin("D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll")
DGSource("E:\BD_RB\WORKFILES\WORKFILES\VID_00000.DGI", fieldop=0).Trim(94429,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Pacific Rim Status
[Status]
LABEL=PACIFIC_RIM
VERSION=v0.46.12t (beta)
SOURCE_SIZE=175236993024
SOURCE_VIDEO_SIZE=175236993024
TARGET_SIZE=49666850816
REDUCTION=.283426746595667
RESIZE_1080=0
RESIZE_1440=0
AUDIO_TO_KEEP=eng;
KEEP_HD_AUDIO=-1
SUBS_TO_KEEP=all
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=0
INSTANCES=4
DGDECNV=-1
SSIF_MODE=0
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00000]
AUDIO=1
PGS=1
APULLDOWN=0
S1440=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=49666850816
RATE=35000
SPLITS=2
NSIZE=0
FLINK=0
MLINK=0


tsmuxer meta file contents

MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --label=PACIFIC_RIM --vbr --custom-chapters=00:00:00.000;00:05:00.000;00:10:00.000;00:15:00.000;00:20:00.000;00:25:00.000;00:30:00.000;00:35:00.000;00:40:00.000;00:45:00.000;00:50:00.000;00:55:00.000;01:00:00.000;01:05:00.000;01:10:00.000;01:15:00.000;01:20:00.000;01:25:00.000;01:30:00.000;01:35:00.000;01:40:00.000;01:45:00.000;01:50:00.000;01:55:00.000;02:00:00.000;02:05:00.000;02:10:00.000 --vbv-len=500 --start-time=27000000
V_MPEG4/ISO/AVC, "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.264"+"E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.264", fps=23.976, insertSEI, contSPS
V_MPEG4/ISO/MVC, "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.mvc"+"E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.mvc", fps=23.976, insertSEI, contSPS
A_DTS, "E:\BD_RB\WORKFILES\WORKFILES\00000.track_4352.DTS", lang=eng
S_HDMV/PGS, "E:\BD_RB\WORKFILES\WORKFILES\00000.track_4608.SUP",fps=23.976,3d-plane=0,lang=eng


If you are wondering about size, it is because I am feeding almost lossless file to BD-RB created by x264. Also just want to say quality looks quite good even with half SBS source.

[Cedvano]

BD-Rebuilder v0.46.12t (beta) ?
I can't find this version for test. Or it's a reserved beta ?

[jdobbs]

BD-Rebuilder v0.46.12t (beta) ?
I can't find this version for test. Or it's a reserved beta ?It's a page or so (http://forum.doom9.org/showthread.php?p=1667297#post1667297) back in this thread. It's meant just for testing multiple processes in SBS encoding.

[videofan3d]

@videofan3d

Just want update or progress on ability to insert I frame on demand

http://forum.doom9.org/showpost.php?p=1656939&postcount=390 (http://forum.doom9.org/showpost.php?p=1656939&postcount=390)

Unfortunately, it seems it doesn't work properly in the Intel Media core libraries :(

There is already a hidden feature in FRIMEncode (you can try it)

-gopfile gopfilename.txt

where gopfilename.txt is text file in structure:

<frame_no> I
e.g.


40 I
256 I
1025 I


etc. (frame_no starting 0)


BUT:
It seems there is a bug in Intel Media core libraries.
I observed the following:

1. when using -sw library, no extra key I-frame is inserted - never !!! Bad! :(
2. when using -hw library, and -gop 24 1 0 O (i.e. no B-frames), then Key I-Frame is inserted in expected position
3. when using -hw library, and -gop 24 4 0 O , the Key I-Frame is inserted but on wrong position (usually shifted few frames earlier) - Bad! :(

This is practically useless for HD video processing because B-frames are essential for efficient video encoding...

(I also contacted Intel regarding this issue, but it seems this is not their top priority (I guess they are concentrating to upcoming HEVC))

[HWK]

It's a page or so (http://forum.doom9.org/showthread.php?p=1667297#post1667297) back in this thread. It's meant just for testing multiple processes in SBS encoding.

Jdobbs, do you need more info from me about multiprocess of pacific rim. Also would you be interested in result of others.

[HWK]

Unfortunately, it seems it doesn't work properly in the Intel Media core libraries :(

There is already a hidden feature in FRIMEncode (you can try it)

-gopfile gopfilename.txt

where gopfilename.txt is text file in structure:

<frame_no> I
e.g.


40 I
256 I
1025 I


etc. (frame_no starting 0)


BUT:
It seems there is a bug in Intel Media core libraries.
I observed the following:

1. when using -sw library, no extra key I-frame is inserted - never !!! Bad! :(
2. when using -hw library, and -gop 24 1 0 O (i.e. no B-frames), then Key I-Frame is inserted in expected position
3. when using -hw library, and -gop 24 4 0 O , the Key I-Frame is inserted but on wrong position (usually shifted few frames earlier) - Bad! :(

This is practically useless for HD video processing because B-frames are essential for efficient video encoding...

(I also contacted Intel regarding this issue, but it seems this is not their top priority (I guess they are concentrating to upcoming HEVC))

Thank you, I guess I will live without I frame support.

[HWK]

Jdobbs, for SBS 3D. How did you prepare source files? I am wondering if it has to do something.

[jdobbs]

Jdobbs, do you need more info from me about multiprocess of pacific rim. Also would you be interested in result of others.Are you seeing any significant speed increase when using two instances with sw encoding? I'm just wondering if it is worth the effort. It would also be nice if someone tested with various settings to see if the -hw setting increases encoding speeds. I know your system is like mine, though, and doesn't support the -hw option.

If it looks worthwhile I could extend the splitting/encoding to normal (non SBS) 3D backups as well.

[jdobbs]

Thank you, I guess I will live without I frame support.It's not too much of a problem anyway. It just makes chapter seeking landings an average of 1/2 second off when strict GOPs are used. If open GOPS are used it might get a little worse, I haven't tried it.

[HWK]

Are you seeing any significant speed increase when using two instances with sw encoding? I'm just wondering if it is worth the effort. It would also be nice if someone tested with various settings to see if the -hw setting increases encoding speeds. I know your system is like mine, though, and doesn't support the -hw option.

If it looks worthwhile I could extend the splitting/encoding to normal (non SBS) 3D backups as well.

Yeah, my speed did increase but bottleneck was massive data rate coming into encoder.

BTW: I manage to reproduce your crash with another movie and I will try the setting which I used before to see if there is some sort of pattern which cause crash.

At this stage it is too early to say, but as soon as I have something useful I will let you know.

When I did pacific rim I only used I Frame in original video, no P and B. However I just did avatar with P and b frames included and it crashed as well. I am encoding it in such a way that it has only I frame and then I will run through FRIMEncoder and see what happens. Also few days back I posted about using frimdecode to serve frame and it caused crash as well if splitting is not done properly.

[jdobbs]

Yeah, my speed did increase but bottleneck was massive data rate coming into encoder.

BTW: I manage to reproduce your crash with another movie and I will try the setting which I used before to see if there is some sort of pattern which cause crash.

At this stage it is too early to say, but as soon as I have something useful I will let you know.

When I did pacific rim I only used I Frame in original video, no P and B. However I just did avatar with P and b frames included and it crashed as well. I am encoding it in such a way that it has only I frame and then I will run through FRIMEncoder and see what happens. Also few days back I posted about using frimdecode to serve frame and it caused crash as well if splitting is not done properly.You didn't have any issues when the split was done by BD-RB, did you? BD-RB scans the CLPI's EP_Map table to ensure the split is done at the right points.Yeah, my speed did increase but bottleneck was massive data rate coming into encoder. My best case was about 32% speed increase, and it averaged somewhere in the 20-30% range. I would expect to see a lot more on a HW based encode (assuming no bottleneck in the GPU). Of course that didn't do me much good since it crashes almost every time for me. The real pain is that it takes so long to happen. My last test went 78,000 frames before it crashed.

[HWK]

You didn't have any issues when the split was done by BD-RB, did you? BD-RB scans the CLPI's EP_Map table to ensure the split is done at an IDR frame.

That test was not conducted by using BD-RB, I was just writing this to warn about issues I saw if you decide to go ahead with splitting/encoding to normal (non SBS) 3D backups option. If time and resource permit and you are willing to write code I can test it for you.

[HWK]

My best case was about 32% speed increase, and it averaged somewhere in the 20-30% range. I would expect to see a lot more on a HW based encode (assuming no bottleneck in the GPU). Of course that didn't do me much good since it crashes almost every time for me. The real pain is that it takes so long to happen. My last test went 78,000 frames before it crashed.

My time was roughly cut in half with that and if source was say around 23 gb in size instead of 163 GB. It was going at 0.98X speed. Also all read and write was done on same drive.

[jdobbs]

My time was roughly cut in half with that and if source was say around 23 gb in size instead of 163 GB. It was going at 0.98X speed. Also all read and write was done on same drive.Interesting. All of mine were done with the source being on a different drive than the working folder. I think I'll test and see if that makes a difference. FYI, I already did some tests in which I placed a redundant executable and DLL in different folders -- and it still failed. I was thinking there might be an issue with multiprocessing calls.

Your system is definitely going faster than mine. I peak at around 14fps with two processes and most of the time it is 12-13fps.

One other thing I noticed... that lowering the output bitrate seems to speed up encoding. That makes me think it may be I/O bound.

[HWK]

One other thing I noticed... that lowering the output bitrate seems to speed up encoding. That makes me think it may be I/O bound.

Can you fire up resource monitor and see how much read and write is happening during encode session. Also how much RAM you machine have?

[HWK]

Your system is definitely going faster than mine. I peak at around 14fps with two processes and most of the time it is 12-13fps.



That was with target quality in Frim set to value of 4.

[jdobbs]

Can you fire up resource monitor and see how much read and write is happening during encode session. Also how much RAM you machine have?I have 8GB RAM. There's lot's of available/unused RAM during encode.

[Hajnal]

hello

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie

but the command
-gop 24 4 0 O , good movie

[jdobbs]

hello

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie

but the command
-gop 24 4 0 O , good moviePlease don't post any more of these. You've made your point -- but the reported issue doesn't happen to anybody else, and repeating it over-and-over doesn't change anything. I've personally done hundreds of encodes in testing and have never had a single issue with the strict parameter. I've tested on software players and standalone players. That leads me to believe it is your configuration (either setup or playback) that is at fault. Changing from strict to open GOPs is highly unlikely to cause any kind of detectable difference on a good playback device (other than slightly more efficiency).

Also, this isn't a BD-RB thread -- and we don't need to hijack it. This thread is meant for comments on the topic of "Free H.264 MVC 3D Encoder". If you want to report issues specific with BD-RB please post in the BD-RB Bug Reporting thread.

If anyone else out there is seeing issues when using the "S" (strict) parameter of FRIMEncode. Please post what you are seeing.

[jdobbs]

@HWK

I took note of this post (http://forum.doom9.org/showthread.php?p=1667884#post1667884) by r0lZ today. I'm going to run some tests to see if I still get the multiple instance issue with one of the v4.x.x.x libraries.

[update] No joy. Same issue.

[colinhunt]

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie
I did Gravity last night, latest BD-RB and MVC encoder running on software, using "-gop 24 4 0 S"... and it came out perfect. No problems at all.

[jdobbs]

Has anyone here successfully used AVS2YUV to feed AVS files to FRIMEncode via stdin? I can't seem to get it to work. If I use AVS2YUV to output to a .YUV file and then use that as input and it works fine -- but no luck piping via stdin.

I know I can use the -avi option and read the AVS directly -- but I'm trying to find a workaround for an issue.

[HWK]

Has anyone here successfully used AVS2YUV to feed AVS files to FRIMEncode via stdin? I can't seem to get it to work. If I use AVS2YUV to output to a .YUV file and then use that as input and it works fine -- but no luck piping via stdin.

I know I can use the -avi option and read the AVS directly -- but I'm trying to find a workaround for an issue.

It is interesting I tried yesterday and I couldn't get avs2yuv to work. It says can't write multiple times or similar as error message. I also gave try avs2pipe which is modification of avs2yuv to allow audio as well but it doesn't serve raw yuv frames.

Oh well back on drawing board. Just an update I didn't have time to run avatar yesterday, I am hoping today I can make some time.

[HWK]

Jdobbs, just update on multiprocess of FRIMEncode, it seems failure. Oh well at least attempt was taken.

[jdobbs]

Jdobbs, just update on multiprocess of FRIMEncode, it seems failure. Oh well at least attempt was taken.Yeah, same for me. I'm giving up for a while.