View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000001 | eac3to | bug | public | 2013-01-21 15:23 | 2015-03-10 22:04 |
| Reporter | StasX4 | Assigned To | madshi | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| OS | Windows All | ||||
| Summary | 0000001: Different number of frames for the left and right view after demux | ||||
| Description | After demux some 3D video we have video streams with different number of frames. Log: 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. Done. | ||||
| Tags | No tags attached. | ||||
| eac3to Version | 3.24 3.27 | ||||
|
|
I'll need a sample to fix this. |
|
|
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... |
|
|
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. |
|
|
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%? |
|
|
Sorry for the link. Name: Resident Evil: Afterlife 3D (CEE - Central Eastern Europe). I can't say how often. Approximately twenty-five percent. |
|
|
Unfortunately I don't have that Blu-Ray. Are there any others you can remember where this problem occurred? Thanks. |
|
|
1. You can download this video (ISO file). Duration of seven seconds. https://docs.google.com/file/d/0B5o0xOUXFs2nTzJKTVdpRDZBbjQ/edit ---- 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. Done. ---- 2. Chapters sometimes are bad: timestamp - IN TIME=95735640 milliseconds_float=(modulo(95735640/45000))/45=458,6666667 milliseconds_int=int(milliseconds_float)=458 milliseconds_round=round(milliseconds_float)=459 Your metod use milliseconds_round, but the program needs to use milliseconds_int. |
|
|
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... |
|
|
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. |
|
|
BDDemuxer Pro 2.4 makes these files: 00000_1_01.avc 00000_1_01.mvc They are the same number of frames. You can download them: https://docs.google.com/file/d/0B5o0xOUXFs2nLXlMTzNoVjRWdlU/edit |
|
|
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. |
|
|
1. I'm sure. 2. I'm looking... |
|
|
I didn't find real evidence. But MediaInfo and Media Player Classic display as milliseconds_int. Thanks. |
|
|
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. |
|
|
I understood you. Thanks. |
|
|
I've implemented a workaround for this problem, but I have some fear that it might introduce follow up bugs. Anyway, let's try... |
| 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 |
