PD17 SVRT truncation issue

optodata

Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8395 Offline

Solved by

Apr 25, 2019 14:21

I had just finished editing a lacrosse game and had used the dominoes transition whenever my daughter's team scored. I had placed a custom clip on track 1 to show up behind the dominoes, but due to the vagaries of the Move All Clips feature (which in my experience means move almost all clips but randomly leave others untouched), I ended up with some track 1 clips misaligned to their intended transitions.

So I brought the produced clip to the timeline and cut out 4 seconds centered on the problem areas and placed them on the track below, then used SVRT. The SVRT track showed green everywhere except for the sections I wanted to repair, and it produced in a few minutes.

However, the SVRT produced clip was 5 minutes shorter than the source, and I found that PD had completely mangled a middle section of the clip.

When it reached the second image to be produced, instead of using the CPU and then resuming what should have been another 5 min section using SVRT, PD skipped right to the third image and then proceeded normally, completely missing the section in between the 2nd and 3rd repair clips. This is what shortened the clip duration.

Here is a content comparison just after the problem occured:

I have created a test project that uses an images as the new item in 6 places. The packed project, along with my SVRT-produced clip are available in this OneDrive folder. The total with the big clips is 16GB, but you could probably use any 48 minute (or longer) HD 60p clip already on your computer and simply replace my clip with it if you'd like to try this out.

I believe this is another facet of the SVRT "fix" that came out in 2314, which was due to the problems created in the earlier release, and so on. The core issue often doesn't ever get addressed, instead, bandaid patches get applied for specific situations which only increases the complexity of maintaining the code and significantly reduces its reliability

Reply

tomasc

Senior Contributor Private Message Joined: Aug 25, 2011 12:33 Messages: 6364 Online

Apr 26, 2019 20:56

I tried to download the project last night and it timed out after a few hours at 14.2 GB received and will not resume this morning. Windows won’t extract the file as it is partial, incomplete, and has a crc error. Went ahead and renamed the file and extracted everything. Luckily the Woodside main cam is 35:20:14 of 44:55:03 complete. I filled it in with some overlap to 44:55:02 with my B-Boy footage.

Both mp4 1080/60p (40 Mbps) and m2ts 1080/60p (28 Mbps) is available for SVRT. Profile Analyzer also indicated both selections were available. I did not use any selection from the Profile Analyzer. The SVRT indications are all correct this time for this project. There were no release notes in the update patch to indicate this was fixed.

The timeline of 44:55:02 produced to a file of exactly the same length when checked on the timeline. Windows properties and MediaInfo indicate a disreprency of up to 1 second. This is great.

Played the produced file on WMP and VLC and no issues were seen when checked several seconds every few minutes. Here is where I need help. Where in the produced file are the times I need to specifically check to ensure that it is produced and not missing a piece or a section. See the screenshot for Produced file properties, times, etc.

Thank you for posting this project. I am waiting to find the problem here. My preferences had both Hardware Acceleration checkboxes enabled that I normally don’t enable on my pc. Changed 5.1 to stereo for this test. Sure that a user may be able to duplicate the issues. It is working well here. Will post the file to YT if needed.


Filename	Trunc2a.jpg	Download
Description	Produced file placed on the Timeline is exact length.
Filesize	506 Kbytes
Downloaded:	16 time(s)


Filename	Trunc1a.jpg	Download
Description	Produced file with svrt in 14 minutes.
Filesize	449 Kbytes
Downloaded:	16 time(s)

This message was edited 1 time. Last update was at Apr 26. 2019 22:18

Reply

tomasc

Senior Contributor Private Message Joined: Aug 25, 2011 12:33 Messages: 6364 Online

Apr 26, 2019 21:51

Spoke too soon. I reread this post to look for clues and downloaded the embedded picture. Here at 21:31:06 the frame in the produced file is 8 seconds behind the original. See the attached screenshot. It looks like both of our computers are speaking the same mind by displaying the same exact frames. This is something that needs an explanation as why is it 8 seconds off in 21 minutes on a produced m2ts file.

The produced length is the same as the original on the timeline however. Will send PM in 5 minutes.


Filename	Trunk3.jpg	Download
Description	Duplicated the problem.
Filesize	560 Kbytes
Downloaded:	19 time(s)

This message was edited 1 time. Last update was at Apr 26. 2019 22:22

Reply

optodata

Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8395 Offline

Apr 26, 2019 22:33

tomasc, thanks very much for taking the time to test this out on your system!

A quick look at your SVRT-produced video confirms that it has the exact same skip as mine, even though you used different content to fill in the clip you couldn't download.

The YouTube video matches the original project right up until this point, when the scoreboard clock reads 23:04.

If you play from that point, you'll see the image overlay and then you'll see part of the dominoes transition, which shouldn't be there since that happens at the next overlaid image.

When the live action returns here (10 seconds later), the scoreboard clock shows 17:32. However, if you look on the project timeline, the next scene shows the scoreboard clock reading 23:04, so the next 4 minutes and 2 seconds of timeline content is MIA.

This is bad

This message was edited 1 time. Last update was at Apr 26. 2019 22:36

Reply

JL_JL

Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 5786 Offline

Apr 26, 2019 23:16

Quote The core issue often doesn't ever get addressed, instead, bandaid patches get applied for specific situations which only increases the complexity of maintaining the code and significantly reduces its reliability

Been true for way too long.

optodata, in this case if you Ctrl A in the timeline and then just slide all to tracks 2,3, &4 vs 1,2 &3 you may resolve the SVRT produce issue. I know, shouldn't have to, but....

Jeff

Reply

optodata

Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8395 Offline

Apr 27, 2019 00:20

Quote Been true for way too long.

optodata, in this case if you Ctrl A in the timeline and then just slide all to tracks 2,3, &4 vs 1,2 &3 you may resolve the SVRT produce issue. I know, shouldn't have to, but....

Jeff

OK, so how long has Track 1 been deeply tied to SVRT issues? I seem to vaguely remember something about this from years ago.

You are correct - if I select all clips and drag everything down by one track, SVRT works exactly as expected. However, if I keep the existing content on tracks 2 and 3 and delete all clips on track 1, SVRT produces the broken output.

In both cases, there is no content on track 1, but in this simple test, SVRT only works if I move exisiting content down. Do you have any ideas why that might be the case?

In the attached image, the SVRT produced clip on track 5 exactly matches the length of the source clip, and was made by moving all content down by one track. The SVRT produced clip on track 6 is more than 4 minutes shorter, and was made by deleting all track 1 content.


Filename	SVRT results.jpg	Download
Description	timeline view of 2 SVRT clips
Filesize	300 Kbytes
Downloaded:	18 time(s)

This message was edited 1 time. Last update was at Apr 27. 2019 02:01

Reply

tomasc

Senior Contributor Private Message Joined: Aug 25, 2011 12:33 Messages: 6364 Online

Apr 27, 2019 01:23

Something doesn’t seem right. Does that mean that one should not use track 1? Moved everything down one track. Produced the video using SVRT and the 44 minute timeline only took 7 min. instead of 14 min. to complete this time and the produced file is now 300 KB larger in size.

Placed the Produced file on track 5 as a PiP on the lower left. Sync of the original and produced video is perfect. See the screenshots.

Remember the B-Boy portion of the YT video. You can hear the Lacrosse cheering at the beginning. Lip sync is nonexistent until later. In this new produced video the B-Boy audio is perfect at the beginning without the mixing of the Lacrosse audio and is in lip sync.

The 21:31:06 frame is different now compared to the earlier test. Need to find out why when time permits.


Filename	Trunc4.jpg	Download
Description	SVRT time is cut in half to 7 minutes.
Filesize	456 Kbytes
Downloaded:	17 time(s)


Filename	Trunc5.jpg	Download
Description	Perfect frame by frame sync of original and produced.
Filesize	506 Kbytes
Downloaded:	18 time(s)

Reply

optodata

Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8395 Offline

Apr 27, 2019 01:59

Quote Something doesn’t seem right. Does that mean that one should not use track 1? Moved everything down one track. Produced the video using SVRT and the 44 minute timeline only took 7 min. instead of 14 min. to complete this time and the produced file is now 300 KB larger in size.

I only have an 18 second difference in SVRT producing times on my 16 thread CPU (the damaged SVRT clip takes 14% longer, but nowhere near double), and the file size difference is 900MB:

Reply