New encoder options 0.47.05

[AUTOBOT]

Just downloaded the v.047.05 and noticed two new encoder options:
x264 Encoder

FRIM Encoder

What does the FIRM Encoder do differently that the x264?

[Ch3vr0n]

Frim's main purpose is for 3D, as it's the currently the only freeware engine capable of MVC though it can be used for 2D aswell. Jdobbs is actually interested in results for 2D encodes comparing x264 vs FRIM

[jdobbs]

FRIM has the ability to take advantage of Quick-Sync on Intel processors that support it. So theoretically it could do encoding much faster if HW mode is enabled (see HIDDENOPTS.TXT). But from the feedback I've gotten, it seems to be hit-or-miss -- and often results in failures or blocky output in HW mode. So I'm not sure whether you'll see it as a 2D option in future releases.

As Ch2vron mentioned, it was mainly added for 3D support and it works reliably in SW mode... and will remain a part of the package for that purpose.

[AUTOBOT]

Frim's main purpose is for 3D, as it's the currently the only freeware engine capable of MVC though it can be used for 2D aswell. Jdobbs is actually interested in results for 2D encodes comparing x264 vs FRIM

FRIM has the ability to take advantage of Quick-Sync on Intel processors that support it. So theoretically it could do encoding much faster if HW mode is enabled (see HIDDENOPTS.TXT). But from the feedback I've gotten, it seems to be hit-or-miss -- and often results in failures or blocky output in HW mode. So I'm not sure whether you'll see it as a 2D option in future releases.

As Ch2vron mentioned, it was mainly added for 3D support and it works reliably in SW mode... and will remain a part of the package for that purpose.

Thank you both for the answer.

Keep up the good work Jdobbs.

[mparade]

@jdobbs

Since I have tried to do my test encodes with FRIMEncode BD-RB always complains about the same before starting the reencoding process just after demultiplexing the streams, regardless of the type of source, frame server, if making a full backup or a movie-only backup. The result is always as follows:

- Using FRIMEncoder for AVC encoding
- [22:30:30] Reencoding: VID_00001, Pass 1 of 1
[22:30:31] - Failed video encode, aborted

Is it possible that some setting for x264 in my ini file is messing up FRIMEncoder? Now, I am testing FRIMEncode for AVC encoding.

Your help would be really appreciated. With x264 I do not have such problems at all.

[jdobbs]

@jdobbs

Since I have tried to do my test encodes with FRIMEncode BD-RB always complains about the same before starting the reencoding process just after demultiplexing the streams, regardless of the type of source, frame server, if making a full backup or a movie-only backup. The result is always as follows:

- Using FRIMEncoder for AVC encoding
- [22:30:30] Reencoding: VID_00001, Pass 1 of 1
[22:30:31] - Failed video encode, aborted

Is it possible that some setting for x264 in my ini file is messing up FRIMEncoder? Now, I am testing FRIMEncode for AVC encoding.

Your help would be really appreciated. With x264 I do not have such problems at all.It's possible a setting may be off. If you post your INI I can take a look at it.

[mparade]

It's possible a setting may be off. If you post your INI I can take a look at it.

Please find as an attachment.
Your help is really appreciated.

Edit: Sorry, the "wrong" ini is attached to this letter. (I was forgetful because meanwhile I switched back to my x264 settings).

[mparade]

It's possible a setting may be off. If you post your INI I can take a look at it.

Please find attached my "correct" ini for the FRIMEncoding processes.It keeps crashing right after demultiplexing the streams with the error message of:

- Using FRIMEncoder for AVC encoding
- [22:30:30] Reencoding: VID_00001, Pass 1 of 1
[22:30:31] - Failed video encode, aborted

Thank you for the help again.

[jdobbs]

Please find attached my "correct" ini for the FRIMEncoding processes.It keeps crashing right after demultiplexing the streams with the error message of:

- Using FRIMEncoder for AVC encoding
- [22:30:30] Reencoding: VID_00001, Pass 1 of 1
[22:30:31] - Failed video encode, aborted

Thank you for the help again.I just started an encode using your INI -- and it is working fine... not sure what could be the issue on your end.

After the encode fails, try opening a command window running the file ENCODE.BAT (found in your working folder). You will at least be able to see the error message when it fails. Are you positive you are using all the correct versions of FFDSHOW, HAALI, and AVISYNTH?

[mparade]

I just started an encode using your INI -- and it is working fine... not sure what could be the issue on your end.

After the encode fails, try opening a command window running the file ENCODE.BAT(found in your working folder). You will at least be able to see the error message when it fails. Are you positive you are using all the correct versions of FFDSHOW, HAALI, and AVISYNTH?

Internal Inspect is telling:

[05.11.14] Checking System Settings
- BD-Rebuilder v0.47.06 (beta)
- Windows Version: 6.1 [7601]
- Working Path Free Space: 320,77GB
- 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
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[05.11.14] Systems Settings Check complete

I am using the versions of FFDSHOW, HAALI, and AVISYNTH from the first page of "Bug Reports Only" thread.

Interestingly, the ENCODE.BAT is telling (I had to translate to english): "system does not find the access path given". The problem is with character "á" and "Á",(element of the hungarian character set) I think . As if in some of the command lines these characters could not be used correctly due to some reason. Please find attached this file as well.

Thanks you very much for your efforts!

Edit: by removing the WORKING and OUTPUT folders to a location (directly to E:\), where the special characters are not troubling the command line anymore, seems to have been a solution for the issue

[mparade]

I encountered the problem as follows at the very end (:mad:) of a 2D test encode with FRIMEncoder:

----------------------
[05.18.14] BD Rebuilder v0.47.06 (beta)
[10:24:46] Source: CARS2_D1_00800
- Input BD size: 28,95 GB
- Approximate total content: [01:46:16.453]
- Target BD size: 13,67 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Resize: SD to HD 1080 enabled
- Quality: Ultra High Quality (Extremely Slow), ABR
- Output folder: E:\BD-RB\
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[10:24:46] PHASE ONE, Encoding
- [10:24:46] Processing: VID_00800 (1 of 2)
- [10:24:46] Extracting A/V streams [VID_00800]
- [10:29:42] Reencoding video [VID_00800]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 152*242 frames
- Bitrate: 6*630 Kbs
- Using FRIMEncoder for AVC encoding
- [10:29:42] Reencoding: VID_00800, Pass 1 of 1
- [14:09:59] Video Encode complete
- [14:10:00] PredictAndEncode() 00053 2806
[14:13:58] - Aborted by user request

Any proposal would be appreciated.

[jdobbs]

It appears that BD-RB is attempting to rename a file -- and the file doesn't exist. But I don't see how that is possible -- as the renaming only occurs when X264's internal LAVF is used for encoding (and, of course, that shouldn't be possible when FRIM is selected). I'll check and see if there is a contradicting flag.

[Edit]

Yes that was it. I will fix it for the next release. In the meantime, please uncheck "Use x264's internal LAVF for Frame Serving" on the SETUP screen when you are using FRIMEncode.

[mparade]

It appears that BD-RB is attempting to rename a file -- and the file doesn't exist. But I don't see how that is possible -- as the renaming only occurs when X264's internal LAVF is used for encoding (and, of course, that shouldn't be possible when FRIM is selected). I'll check and see if there is a contradicting flag.

[Edit]

Yes that was it. I will fix it for the next release. In the meantime, please uncheck "Use x264's internal LAVF for Frame Serving" on the SETUP screen when you are using FRIMEncode.

Thank you jdobbs, but I haven't been using LAVF for Frame Serving at all for a long time, but DirectShow instead, both for x264 and Frim encoding processes. :confused:

Edit: Maybe I should try the frame serving with FrimSource. I hope the result will be positive.

[jdobbs]

Thank you jdobbs, but I haven't been using LAVF for Frame Serving at all for a long time, but DirectShow instead, both for x264 and Frim encoding processes. :confused:

Edit: Maybe I should try the frame serving with FrimSource. I hope the result will be positive.Well I just ran a disc with and without LAVF selected. I can repeat your issue when it is selected and it goes away when it isn't... so I'm certain that is the problem.

There is only about 4 lines of code between the last message your log shows ("Video Encode complete") and the point at which the 2806 error location tag no longer applies -- and those four lines are only executed if LAVF is selected. So even though you may no longer use LAVF and you think that wasn't it -- I can say positively it was selected at the time you ran the job from which the log was created. No "ifs", "ands", or "buts" are possible (barring a glitch in the Matrix, which is highly improbable outside a movie-theater).

[mparade]

Well I just ran a disc with and without LAVF selected. I can repeat your issue when it is selected and it goes away when it isn't... so I'm certain that is the problem.

There is only about 4 lines of code between the last message your log shows ("Video Encode complete") and the point at which the 2806 error location tag no longer applies -- and those four lines are only executed if LAVF is selected. So even though you may no longer use LAVF and you think that wasn't it -- I can say positively it was selected at the time you ran the job from which the log was created. No "ifs", "ands", or "buts" are possible (barring a glitch in the Matrix, which is highly improbable outside a movie-theater).

Thank you very much for your time and efforts you wasted again on one of my "invisible" problem.
I will triple check my ini file, perhaps something stuck in it again...my setup dialog says no frameserver has been choosen which means, as far as I know, that DirectShow is
used for decoding as my attached dialogue shows above.

Sorry for wasting your time with my "invisible" problem.

[jdobbs]

Thank you very much for your time and efforts you wasted again on one of my "invisible" problem.
I will triple check my ini file, perhaps something stuck in it again...my setup dialog says no frameserver has been choosen which means, as far as I know, that DirectShow is
used for decoding as my attached dialogue shows above.

Sorry for wasting your time with my "invisible" problem.It's not invisible. I can make it happen every time when FRIM is selected -- but only when LAVF is selected as well. The log will say "Directshow" and be wrong -- that's because that's what should be used with FRIM (as internal LAVF can't possible be used)... but the bug was setting the "X264_INTERNAL" flag without regard to FRIM, and that was what was cause of the issue. Here's an example from one of my earlier tests:[05/18/14] BD Rebuilder v0.47.07 (beta)
[08:40:12] Source: ROAD_RUNNER_2D_SHORT_TEST
- Input BD size: 0.20 GB
- Approximate total content: [00:03:04.642]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Quality: High Quality (Default), ABR
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[08:40:15] PHASE ONE, Encoding
- [08:40:15] Processing: VID_00000 (1 of 1)
- [08:40:15] Extracting A/V streams [VID_00000]
- [08:40:20] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 4,427 frames
- Bitrate: 35,000 Kbs
- Using FRIMEncoder for AVC encoding
- [08:40:20] Reencoding: VID_00000, Pass 1 of 1
- [08:44:30] Video Encode complete
- [08:44:30] PredictAndEncode() 00053 2806
[08:44:35] - Aborted by user requestAnd here's that same job after the fix:[05/18/14] BD Rebuilder v0.47.07 (beta)
[08:52:28] Source: ROAD_RUNNER_2D_SHORT_TEST
- Input BD size: 0.20 GB
- Approximate total content: [00:03:04.642]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Quality: High Quality (Default), ABR
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[08:52:32] PHASE ONE, Encoding
- [08:52:32] Processing: VID_00000 (1 of 1)
- [08:52:32] Extracting A/V streams [VID_00000]
- [08:52:39] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 4,427 frames
- Bitrate: 35,000 Kbs
- Using FRIMEncoder for AVC encoding
- [08:52:39] Reencoding: VID_00000, Pass 1 of 1
- [08:56:46] Video Encode complete
- [08:56:46] Processing audio tracks
- Track 4352 (eng): Reencoding audio to AC3...
- [08:56:48] Multiplexing M2TS
[08:56:58]PHASE ONE complete
[08:56:58]PHASE TWO - Rebuild Started
- [08:56:58] Rebuilding BD file Structure
[08:56:58] - Encode and Rebuild complete
[08:56:58] JOB: ROAD_RUNNER_2D_SHORT_TEST finished.It was a legitimate bug, and I'm glad you reported it. It's been fixed for the next release.

[mparade]

Thank you very much!