Free H.264 MVC 3D Encoder

[videofan3d]

Originally Posted by tymoxa

Exactly.
I want do something like this:

I will thing about it

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?

[videofan3d]

Originally Posted by Sharc

v1.11 named pipe still does not work here. Now I get the error:
Error: Unknown codec

Unknown codec - you have likely wrong command line, some hyphen "-" is missing, or you have there extra space.

[tymoxa]

Originally Posted by HWK

Good news we already have decoder which can do it for you and yes you can use X.264 encoder with it.

You are referencing to DirectShow MVC Source.dll? It's not an option to me.

[tymoxa]

Originally Posted by videofan3d

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?

We already have pure_L.h264. I want pure_R.h264.

[HWK]

Originally Posted by tymoxa

You are referencing to DirectShow MVC Source.dll? It's not an option to me.

May I know why, if that is ok with you?

[Eseninzhiv]

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

is it possible to add the conversion directly from the file SSIF?

[Sharc]

@videofan3d
I confirm that separate input files and named pipe now work perfectly with v1.11:

FRIMDecode.exe mvc -i base.264 -i dependent.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O

[tymoxa]

Originally Posted by Eseninzhiv

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

That's odd. In my tests both methods give me the same size of .yuv's.

[Sharc]

Originally Posted by colinhunt

Does this mean I can feed it demuxed h264 files directly from a 3DBD?

Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools, like:

FRIMDecode.exe mvc -i 00049.track_4113.264 -i 00050.track_4114.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 8000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O

(I included resizing to 1280x720 in the example)
=> You will get re-encoded base *.avc and dependent *.mvc streams.
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[videofan3d]

Originally Posted by Eseninzhiv

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

This is strange - for investigation I need to simulate it.
How did get the original combined file and related separated files? Please describe me process in order to reproduce it.

[Eseninzhiv]

demux SSIF via tsMuxeR 2.1.6
1. MVC combined, use the utility http://forum.doom9.org/showthread.ph...58#post1628058 files are the same
2. MVC separate, demux SSIF via tsMuxeR 2.1.6 http://i.imgur.com/haAbf6b.png

if demux with eac3to playlist, all right, files are the same
eac3to probably adds at the end of an empty frame

eac3to v3.24
command line: "F:\3D\H.264 MVC 3D Decoder\eac3to v3.24\eac3to.exe" "J:\BDMV\PLAYLIST\00250.mpls" 01: l.h264 02: r.h264
------------------------------------------------------------------------------
M2TS, 2 video tracks, 3 audio tracks, 3 subtitle tracks, 0:01:41, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/AVC (right eye), 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: AC3, Russian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), French
7: Subtitle (PGS), Dutch
8: Subtitle (PGS), Russian
[v02] Extracting video track number 2...
[v01] Extracting video track number 1...
[v02] Creating file "r.h264"...
[v01] Creating file "l.h264"...
Video track 1 contains 2419 frames.
Video track 2 contains 2420 frames.
eac3to processing took 4 seconds.
Done.

[videofan3d]

Originally Posted by HWK

Post was geared towards videofan3d

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

[HWK]

Originally Posted by videofan3d

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

Ok I will try again and see what happens.

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.

[Cedvano]

Works fine for me.
Thank you very much videofan3D.

[Sharc]

Originally Posted by HWK

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.

Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

Edit:
Oooops! It runs for some time (few thousand frames), then FRIMencode crashes with the error
M_Alloc; error allocing 4552128
Doing more tests .....

Edit2:
Encoding a 2 hours movie with named pipes worked flawlessly and was reasonably fast.
Interesting that the original had a file size ratio dependent/base = 0.304 (which is exceptionally low, more typical ratios seem to be around 0.5), while after encoding with FRIMenocde this ratio became 0.83.

[HWK]

Originally Posted by Sharc

Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

That would be helpful, Although I own mainconcept mvc encoder but I want to help improve this as well.

In the mean time I would also try using ssif file decoder as well which doesn't rely on directshowmvcsource to decode file.

[colinhunt]

Originally Posted by Sharc

Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

Awesome answer, thank you Sharc!

[Cedvano]

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.

Originally Posted by Sharc

Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with eac3to
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[frencher]

Originally Posted by videofan3d

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

@videofan3d

1 minute is too short for view from AVS problem
I have upload full video demo and log report with 266804 total frames (AVC/MVC from "MVCcombined.264")
Download:
FRIMDecode YUV FRIMEncode - VS - From AVS Script.rar
Watch FRIMDecode YUV FRIMEncode - VS - From AVS Script.mkv (include into package) before explore folder and report

Low CPU Usage for recode, it's possible to add CPU optimisation ? x264x64 use 100% of my CPU (i7 3930k)


Thanks for your bigest works

[Sharc]

Originally Posted by Cedvano

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.

Strange; should perhaps be reported to physic.
What is the consequence of the 1 frame difference? Does the encoding fail?