View Issue Details

IDProjectCategoryView StatusLast Update
0000001eac3tobugpublic2015-03-10 22:04
ReporterStasX4 Assigned Tomadshi  
Status closedResolutionfixed 
OSWindows All 
Summary0000001: Different number of frames for the left and right view after demux
DescriptionAfter demux some 3D video we have video streams with different number of frames.
eac3to v3.27
command line: .\eac3to\eac3to.exe I:\BDMV\PLAYLIST\00000.mpls 1) -demux
M2TS, 2 video tracks, 2 audio tracks, 1:36:53, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: AC3, Russian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: DTS, English, 5.1 channels, 1510kbps, 48kHz
Creating file "00000 - Chapters.txt"...
[a04] Extracting audio track number 4...
[v02] Extracting video track number 2...
[a05] Extracting audio track number 5...
[v03] Extracting video track number 3...
[v03] Creating file "00000 - 3 - h264 (right eye), 1080p24.h264"...
[a04] Removing AC3 dialog normalization...
[v02] Creating file "00000 - 2 - h264 (left eye), 1080p24.h264"...
[a05] Creating file "00000 - 5 - DTS, English, 5.1 channels, 1510kbps, 48kHz.dts"...
[a04] Creating file "00000 - 4 - AC3, Russian, 5.1 channels, 448kbps, 48kHz.ac3"...
[a04] Audio overlaps for 30ms at playtime 0:50:18. <WARNING>
[a05] Audio overlaps for 9ms at playtime 0:50:18. <WARNING>
[a04] Starting 2nd pass...
[a04] Realizing (E-)AC3 gaps...
[a04] Creating file "00000 - 4 - AC3, Russian, 5.1 channels, 448kbps, 48kHz.ac3"...
[a05] Starting 2nd pass...
[a05] Realizing DTS gaps...
[a05] Creating file "00000 - 5 - DTS, English, 5.1 channels, 1510kbps, 48kHz.dts"...
Video track 2 contains 139367 frames.
Video track 3 contains 139368 frames.
eac3to processing took 9 minutes, 54 seconds.
TagsNo tags attached.
eac3to Version3.24 3.27



2013-01-21 17:44

administrator   ~0000001

I'll need a sample to fix this.


2013-01-21 18:33

administrator   ~0000002

P.S: This is complicated. If you just cut some SSIF file, you might end up producing a sample which *really* has one frame less in one eye stream than in the other. I think it's unlikely that the original full SSIF files have a different number of frames. So ideally I'd need an SSIF file with which I can reproduce the issue and which was *not* cut in any way. I guess the best solution might be to try the small SSIF files from a seamless branching disc. Is there such a thing as a seamless branching 3D Blu-Ray? If not, maybe some 3D extra material (trailer)? If that fails, too, things become complicated. In that case I'd need a list of 3D Blu-Rays with which the problem occurs. Maybe, with a *lot* of luck, I own one of them...


2013-01-21 18:57

reporter   ~0000003

Last edited: 2013-01-21 19:16

The name of this video is "Resident Evil: Afterlife 3D".
It's a very big file.
cmd for this torrent:
eac3to.exe H:\BDMV\PLAYLIST\00043.mpls -demux
1. Incorrect number of frames. Blu-Ray Demuxer Pro 3D 2.4 works correct and we have the same number of frames.
2. Chapters bad. "CHAPTER02=00:00:40.207". It's not correct. "CHAPTER02=00:00:40.206" is correct.


2013-01-21 19:18

administrator   ~0000004

I don't have that specific Blu-Ray. Do you have any USA or EU 3D Blu-Rays with which the problem occurs? Please no links to pirated content. Just give me the name and country of the Blu-Ray release.

In your experience, how often does this problem occur? 50% of all 3D Blu-Rays? 10%? 70%? xxx%?


2013-01-21 19:34

reporter   ~0000005

Sorry for the link.
Name: Resident Evil: Afterlife 3D (CEE - Central Eastern Europe).
I can't say how often. Approximately twenty-five percent.


2013-01-21 19:38

administrator   ~0000006

Unfortunately I don't have that Blu-Ray. Are there any others you can remember where this problem occurred? Thanks.


2013-01-22 10:07

reporter   ~0000007

Last edited: 2013-01-22 10:10

You can download this video (ISO file). Duration of seven seconds.

eac3to v3.27
command line: .\eac3to\eac3to.exe I:\BDMV\STREAM\SSIF\00000.ssif -demux
M2TS, 2 video tracks, 0:00:07, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/AVC (right eye), 1080p24 /1.001 (16:9)
[v01] Extracting video track number 1...
[v02] Extracting video track number 2...
[v02] Creating file "00000 - 2 - h264 (right eye), 1080p24.h264"...
[v01] Creating file "00000 - 1 - h264 (left eye), 1080p24.h264"...
Video track 1 contains 167 frames.
Video track 2 contains 168 frames.
eac3to processing took 1 second.
2. Chapters sometimes are bad:
timestamp - IN TIME=95735640
Your metod use milliseconds_round, but the program needs to use milliseconds_int.


2013-01-22 10:24

administrator   ~0000008

Thanks. Is that ISO/m2ts file a complete file or did you cut it to make it small?

And why should I truncate chapter times? Are you sure that is the correct way to do it? I mean that would be quite unusual. Usually rounding is better than truncating...


2013-01-22 10:49

reporter   ~0000009

1. I cut. I used BDDemuxer Pro 2.4 for demux and Scenarist 5.7.2 for "mux and cut".
2. I agree, but a lot of programs use truncating. BDInfo, BDDemuxer Pro 2.4, tsMuxeR_1.10.6 etc.
Sorry for my English.


2013-01-22 11:19

reporter   ~0000010

BDDemuxer Pro 2.4 makes these files:
They are the same number of frames.
You can download them:


2013-01-22 11:29

administrator   ~0000011

If you're sure that the number of frames is identical in the final ssif/m2ts files then everything's fine and that file you uploaded should allow me to fix the issue.

I don't care what BDInfo, BDDemuxer and tsMuxeR do, unless there is real evidence that truncating is correct and rounding is wrong. I would rather guess that those 3 mentioned programs do it wrong.


2013-01-22 12:50

reporter   ~0000012

1. I'm sure.

2. I'm looking...


2013-01-22 14:46

reporter   ~0000013

I didn't find real evidence. But MediaInfo and Media Player Classic display as milliseconds_int.


2013-01-22 15:02

administrator   ~0000014

I've checked the Blu-Ray spec and can't find any hint whether to use truncation or rounding. I suppose Blu-Ray players jump to exact chapter times, not to rounded or truncated times. The only reason why this matters for chapter extraction is that the chapter extraction format has a different clock than the Blu-Ray chapter information. So I guess it's everybody's own interpretation whether to use truncation or rounding. Personally, I believe rounding is better because it results in a smaller error compared to the chapter marks Blu-Ray hardware players are jumping to.


2013-01-23 09:01

reporter   ~0000015

I understood you. Thanks.


2015-03-10 22:04

administrator   ~0000722

I've implemented a workaround for this problem, but I have some fear that it might introduce follow up bugs. Anyway, let's try...

Issue History

Date Modified Username Field Change
2013-01-21 15:23 StasX4 New Issue
2013-01-21 17:44 madshi Note Added: 0000001
2013-01-21 17:44 madshi Assigned To => madshi
2013-01-21 17:44 madshi Status new => feedback
2013-01-21 18:33 madshi Note Added: 0000002
2013-01-21 18:57 StasX4 Note Added: 0000003
2013-01-21 18:57 StasX4 Status feedback => assigned
2013-01-21 19:16 madshi Note Edited: 0000003
2013-01-21 19:18 madshi Note Added: 0000004
2013-01-21 19:18 madshi Status assigned => feedback
2013-01-21 19:34 StasX4 Note Added: 0000005
2013-01-21 19:34 StasX4 Status feedback => assigned
2013-01-21 19:38 madshi Note Added: 0000006
2013-01-21 19:38 madshi Status assigned => feedback
2013-01-22 10:07 StasX4 Note Added: 0000007
2013-01-22 10:07 StasX4 Status feedback => assigned
2013-01-22 10:10 StasX4 Note Edited: 0000007
2013-01-22 10:24 madshi Note Added: 0000008
2013-01-22 10:25 madshi Status assigned => feedback
2013-01-22 10:49 StasX4 Note Added: 0000009
2013-01-22 10:49 StasX4 Status feedback => assigned
2013-01-22 11:19 StasX4 Note Added: 0000010
2013-01-22 11:29 madshi Note Added: 0000011
2013-01-22 11:30 madshi Priority immediate => high
2013-01-22 12:50 StasX4 Note Added: 0000012
2013-01-22 14:46 StasX4 Note Added: 0000013
2013-01-22 15:02 madshi Note Added: 0000014
2013-01-23 09:01 StasX4 Note Added: 0000015
2015-03-10 22:04 madshi Note Added: 0000722
2015-03-10 22:04 madshi Status assigned => closed
2015-03-10 22:04 madshi Resolution open => fixed