CyberLink Community Forum
where the experts meet
| Advanced Search >
SVRT inter-compatibility test with maker/camera file outputs, new topic
Reply to this topic
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4541 Offline
[Post New]
Quote: Hi jeff,
Thank you for your comments. You will recall (with PD9) providing some 23 mts video files from your Canon camera. I have been playing with these files in both PD9 and 10. I note that in PD9 these files have full use of SVRT now when previously they did not. The Canon camera you have produced a variable bitrate file that was beyond PD9's SVRT range. I see that has been corrected in a patch, so all the 23 files now benefit from SVRT. Other than a degree of "hosepiping" in the sample files (not a problem but I've watched the videos a lot), the SVRT functioned the same in both PD10 and PD9 with and without a transition being added to the project. I then attempted to replicate the mts set up with video files from an mp4 camera. Whereas your Canon recorded 60i the mp4 were 60p. The SVRT functioned the same in both with slight header delays during the SVRT operation at the start of each clip in the track. The inclusion of a transition did not have any affect on the rest of the clips in the simple test I carried out. I was unable to repeat the test in PD9 for the mp4 files as these files could not use SVRT or in previous builds of PD, prior to 10. During testing I note the hanging display when attempting to view the video after production in Produce. Because it was not the finished file but the data in the tracks and was limited by the graphics card's capability. The final finished file when viewed from the media library in full screen display played without a problem in all cases on my system.

My testing/this thread is about the inter compatibility of SVRT with other cameras with make and models being tested. A fair degree of boredom is involved.

NOT all camera files have the SVRT capability available to them and the tests I'm carrying out will show that as well.

Please Jeff, if you have issues with using SVRT then raise them on another thread as a new topic.

Too bad the thread was locked http://forum.cyberlink.com/forum/posts/list/21678.page , my comments were not pertaining to my exact clips provided to try and aid some of the many SVRT issues in PD, but rather how SVRT has functioned as a whole. But since you bring up my clips Dafydd, a detailed discussion of an SVRT audio issues in PD10 with the same Canon clips that you indicate are corrected in PD9 and PD10 is presented here, http://forum.cyberlink.com/forum/posts/list/20483.page I guess when one says "corrected in a patch" can have different relative meanings, to me what SVRT does with the sample clips I had provided is still not correct. Yes, it will be a eye-opener when corrected and I totally look forward to the patch.

Jeff
Reply
Dafydd B [Avatar]
Senior Contributor Private Message Joined: Aug 26, 2006 08:20 Messages: 11973 Offline
[Post New]
Jeff,
The tests I'm carrying out are to do with video files from different cameras. I'm not testing SVRT for the faults you're indicating. SVRT inter-compatibility test with maker/camera file outputs
I'm of a mind to not continue with or provide the results of what I have found out.

You are correct, I did not test your 23 video files for any audio issues in SVRT. Your girl's volley ball game (clip recordings) audio was not appealing to me at all. I dealt only with the visual and render quality. There may have been issues in the audio but please forgive me for not wanting to listen to chanting, shouting and high whistle tones.
Thanks
Dafydd



This message was edited 3 times. Last update was at Apr 19. 2012 12:54

Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4541 Offline
[Post New]
Quote: Jeff,
The tests I'm carrying out are to do with video files from different cameras. I'm not testing SVRT for the faults you're indicating. SVRT inter-compatibility test with maker/camera file outputs
I'm of a mind to not continue with or provide the results of what I have found out.

You are correct, I did not test your 23 video files for any audio issues in SVRT. Your girl's volley ball game (clip recordings) audio was not appealing to me at all. I dealt only with the visual and render quality. There may have been issues in the audio but please forgive me for not wanting to listen to chanting, shouting and high whistle tones.
Thanks
Dafydd
It would appear to me that could be what SVRT inter-compatibility is. Just so I understand, if audio and/or video would go dead or a black screen or video jerks or skipped frames during a transition applied from one maker/camera video to another that's okay because your testing is only considering the SVRT feature that no rendering was done to either clip other than the transition region?

I never ask nor implied you should listen to the audio of those clips, keep in mind, they were supplied for CL to investigate a video bitrate difference clip to clip that caused SVRT to be applied and not applied and the SVRT green status bar to be totally incorrect with no transition or edits of any kind to the footage. I see no real reason to belittle the clips that were provided for a specific purpose. The link and pdf file that was referenced was video from the same camera with a pure tone audio so one could easily inspect the waveform for proper characteristics with SVRT compatibility.

It's your testing with the members at large footage, you can share or not share as you wish. However the sharing is basically what the forum is all about. "This is a forum for CyberLink members to discuss and share their users' experience."

Jeff
Reply
Dafydd B [Avatar]
Senior Contributor Private Message Joined: Aug 26, 2006 08:20 Messages: 11973 Offline
[Post New]
Quote: It would appear to me that could be what SVRT inter-compatibility is. Just so I understand, if audio and/or video would go dead or a black screen or video jerks or skipped frames during a transition applied from one maker/camera video to another that's okay because your testing is only considering the SVRT feature that no rendering was done to either clip other than the transition region?

I never ask nor implied you should listen to the audio of those clips, keep in mind, they were supplied for CL to investigate a video bitrate difference clip to clip that caused SVRT to be applied and not applied and the SVRT green status bar to be totally incorrect with no transition or edits of any kind to the footage. I see no real reason to belittle the clips that were provided for a specific purpose. The link and pdf file that was referenced was video from the same camera with a pure tone audio so one could easily inspect the waveform for proper characteristics with SVRT compatibility.

It's your testing with the members at large footage, you can share or not share as you wish. However the sharing is basically what the forum is all about. "This is a forum for CyberLink members to discuss and share their users' experience."

Jeff


Just for you to be clear. The video I have is 5 seconds long in many cases. The audio is or isn't relevant on them and the only test that was being carried out is to see if SVRT is accepted between video clips from different models and makes. You may want it to be a test for other things but that isn't happening. Re: Adding transitions between each tested clip and then testing them between every other clip, no I wont be doing that. It would be great to do but that isn't what I'm currently testing for - good point though. The task as it is is very time consuming and adding a transition between each and switching the clips around would add a huge amount to the workload.

As for the 23 video clips from the canon files. Yes, I used them to test SVRT for the very thing that you complained about in PD9. The variable bitrated clips not registering in an earlier build of PD9/SVRT. The last PATCH in PD9 which was applied after your complaint, appears to have fixed the SVRT acceptance issue for the few clips. As for "belittling" your clips, I think I pointed out the audio on them was such, it was "unpleasant" to listen to and not suitable to use for any testing of audio sync. I believe I also mentioned "hosepiping" earlier, whiich does make for a difficult visual check on some clips. I was being observational and remarking on how difficult it is when using random clips from others in tests, your canon files being louder and different. I asked for the sample files etc.

Should I determined to stop testing the inter-compatibility of the clips between cameras, it will be my choice. Your attitude to what is being attempted with limited samples and such is disappointing.

I have been testing the inter-compatibility of clips between cameras makes and models. Basically would a video file from a Canon when added to a Sony file have SVRT for both files and which cameras offer this. Now this might not be information you want Jeff or you don't want to purchase a second or third camera but many editors would like to know which camera is ok to have and see that SVRT does function in the tracks/render. Anything greater than that starts getting far to heavy and would need significant resources and time to carry out. Neither of which is available.

The option to test further once the initial information has been done may offer a chance to test out transitions etc. For the moment the part being carried out is to see which cameras and which files work with SVRT. Only after this work/test has been carried out could additional testing be done. Identifying which makes and models video files are inter-compatible will enable additional testing, narrowing the field.

Sharing: In a test of a 720p 29.97fps mp4 file, SVRT did not display nor offer a custom profile. Recently I confirmed a finding by an editor that allowed a custom profile to be made. this new profile failed to display in the SVRT Track view but was available when selected in Produce. however the resulting produced video was not SVRT compatible.
1. How should the mp4 file be reported in the inter-compatibility test? Should it show as SVRT or not. I say No, but I did add a notation in the report.
2. The observation was passed onto CyberLink to correct, my thanks to the editors involved.

Comment. One thing at a time and when time is short one can only do what one can.

Dafydd

This message was edited 6 times. Last update was at Apr 20. 2012 05:22

Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4541 Offline
[Post New]
Dafydd, I read through my posts and don’t really see anything in my attitude that one should find disappointing. SVRT has not functioned correctly for many years and many users have contributed in an attempt to make it better. Yes it has improved, but very marginal improvements. I really think CL has let their users down by advertising a capability with very few limitations if you read the documentation but yet the experience in the forum is very few can actually use it with satisfaction. Many have issues with SVRT of one nature or another, quality, freezes…. and so on. Your inter-compatibility testing would be one more contribution and if CL would make significant corrections based on your findings, absolutely great.

Yes, all testing can be boring and time consuming, that’s an understatement. If the only intent of your testing is to see if SVRT is used from one clip to the next this thought below might work. It’s very similar how I did some evaluation during the PD9 beta test cycle. During beta I wanted to build a bunch of random timelines from a bank of sample video clips, add random transitions between all clips, and see if they consistently produced or if some random permutations would fail. The concept may work for you and could take a little boredom from your task.

I used a scriptable desktop automation program with looping and a little extra scripting to automate the task. Say you have 100 clips, if one would like to test all permutations of just two clips in the timeline that’s 9900 tests if one treats “Video A” followed by “Video B” as being different than “Video B” followed by “Video A”. So yes, lots of boring testing for this scope of SVRT evaluation, obviously rather tough to do manually. I would automate the whole process so it tests all 9900 permutations and I really do nothing while it is testing. The computer might run for a day or more but I don’t. To do this I create a sample timeline and then simply have my scripting modify the video filenames inside the pds file and use the scriptable automation utility to automate and loop the whole process through PD with each loop being one configuration of the 9900 permutations. I’d think for this SVRT functionality test it should be enough to monitor the process time to get at least a reasonable first pass effect if SVRT works or not between various video clips. On my system, two 5 second clips with SVRT working takes about 3 seconds total process time, if both clips are cpu rendered, 15 seconds. So by looping through the 9900 permutations anything taking longer than 5 seconds on my sytem is probably questionable and could be flagged and then one could evaluate further manually if so desired. So if SVRT works for half of the 9900 tests and fails for the other half that’s about 24hrs of PD testing on my box plus one needs to add a little time for scripting overhead. Yes it takes sometime to setup but that’s not all that boring.

Since you have direct access to CL R&D I’d surely think they would have an xml based batch process test method or something like that to do regression testing on multiple video clips every night or weekly as code is checked in. Maybe under contract you could use and/or modify their approach to suite your SVRT compatibility testing.

I think any testing that highlights SVRT incompatibilities is worthy if CL takes action to correct. I think if the bugs in SVRT could be fixed so users could adopt with confidence, SVRT could be a very strong selling point and a great feature for users. It totally beats any GPU or CPU encoding speed and if done right the quality of your produced video is what you shot. Really can’t beat that.

Jeff
Reply
Reply to this topic
Powered by JForum 2.1.8 © JForum Team