View Bug Details

IDProjectCategoryView StatusLast Update
0001463DCP-o-matic[All Projects] Bugspublic2019-02-13 00:22
ReportercarlAssigned Tocarl 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version 
Target Version2.14.0Fixed in Version 
Summary0001463: 3D separate L/R not working properly
Description

https://dcpomatic.com/forum/viewtopic.php?f=2&t=1236
~/cr2/scozz76

TagsNo tags attached.
Estimated work requiredUnknown

Activities

carl

2019-02-11 08:03

administrator   ~0003066

Certainly looks like the 3D drops out at some point early on and returns around frame 247 (when I make a DCP using those input files).

carl

2019-02-11 20:07

administrator   ~0003074

Last edited: 2019-02-11 20:09

View 2 revisions

Content from right stops arriving after frame 131 and starts again after 16 left frames have gone through. Then they're very out of sync til they come back in around 247.

carl

2019-02-11 20:42

administrator   ~0003075

Last edited: 2019-02-11 20:45

View 2 revisions

The muxing of video/audio is odd in the left.mp4. At the start, for example, over 1s of audio appears before any video. Throughout the file, the video/audio are often a second apart (either way).

carl

2019-02-11 23:54

administrator   ~0003077

Both sources miss out frame 2. This is supposed to be handled by Player::video but the shuffler is inserted between decoder and player. Hence the missing frame causes data to back up in the shuffler, until it is full, at which point things (sort-of) recover.

Perhaps Shuffler should cope with gaps.

It could emit gaps, if that would help. e.g.

receives

1L
1R

3L
3R

Once it gets 3R (i.e. it has everything for frame 3) it can carry on; Player will cope with the gap.

carl

2019-02-11 23:55

administrator   ~0003078

Shuffler should have the check

if (_store.size() > _max_size) {
    LOG_WARNING ("Shuffler is full after receiving frame %1; 3D sync may be incorrect.", video.frame);
}

carl

2019-02-13 00:22

administrator   ~0003081

Hopefully fixed by 27fbe80bccafe744ca3f96129c9e582f39921891

Bug History

Date Modified Username Field Change
2019-02-10 20:05 carl New Bug
2019-02-11 08:03 carl Note Added: 0003066
2019-02-11 20:07 carl Note Added: 0003074
2019-02-11 20:09 carl Note Edited: 0003074 View Revisions
2019-02-11 20:42 carl Note Added: 0003075
2019-02-11 20:45 carl Note Edited: 0003075 View Revisions
2019-02-11 23:54 carl Note Added: 0003077
2019-02-11 23:55 carl Note Added: 0003078
2019-02-13 00:22 carl Assigned To => carl
2019-02-13 00:22 carl Status new => resolved
2019-02-13 00:22 carl Resolution open => fixed
2019-02-13 00:22 carl Note Added: 0003081