Announcement: Our new CyberLink Feedback Forum has arrived! Please transfer to our new forum to provide your feedback or to start a new discussion. The content on this CyberLink Community forum is now read only, but will continue to be available as a user resource. Thanks!
CyberLink Community Forum
where the experts meet
| Advanced Search >
Quote: Arise,

Try selecting Dolby 5.1 when you produce your file. That seemed to help me.


Oh yes, certainly helps here too
Thanks dude!
I can also confirm PD8 playing nice now with my HG20 material
"Checkbox" enabled....

took 3 clips, added 2 transitions, total video time 4min 24sec
svrt encoded it in 1min 29sec.

tested with 1920x1080/60i, 17mbps profile

However i can also confirm the audio "pop/click" at transition entry/exit points when using SVRT.

Thanks Cyberlink, you're on the right track.
Quote: Your right it does not work with 2220c.

I should have said that I retested my encoding test using build 2508 and checking the H.264 box in preferences. I thought that was implied from the title of the thread. Sorry for the confusion.

Contact Cyberlink for 2508 and you should be good to go.


ah ok, that's why
i'm running the demo version, i guess i'll wait for GA of 2508.
If it works, i'll buy the thing...finally....
Quote: I retested my encoding test with Canon 24 Mb/s AVCHD data. After checking the H.264 box in preferences SVRT now works when a long fade transition is inserted between two clips.


doesn't work for me in 2220c
tried both FXP and MXP (17 and 24mbps)
what format are your files?
OH! the option is available on 2220c as well!
testing it right now....
thanks guys, interesting finds!
did you have HW acceleration on or off?

i think you can't have both SVRT and CUDA on at the same time, right?
i also have a Canon HG20 by the way.

the key is in the coding parameters of AVCHD, Canon's way.
Tried with 2220c last night and simply adding 2 clips with no transitions or anything, just straight "merge" and output to H264 1920x1080, SVRT reported "all blue" > need to re-encode 100% video.

Checked the SVRT info (select the blue SVRT bar above the material in the timeline then open File/view/svrt info), the only thing showing a "V" was this coding parameters variable.
Quote:
During testing yesterday, I authored two projects. The one I mentioned in my earlier post was completly re-encoded and took about 2 hour 45 minutes. An SVRT check prior to production indicated that the vast majority of the video did not need re-encoding, yet it all was. Excellent video quality at the end though.

The second project was of similar length with no transitions or any enhancements of any kind. This burnt to folders in 35minutes - indicating obviously that SVRT worked perfectly.

Was not the whole point of James's initial post a properly working SVRT??
I can happily report that SVRT finally works with my Canon HG20 camera at its maximum recording settings. I'm using build 2508.

Yes PD8 2508 didn't crash for you and produced a video but I think the WHOLE point of the initial post was SVRT is now working on Canon. In my opinion, it is not working the way CL documents SVRT to function.

Jeff


If SVRT is now fixed, your second project should have been rendered also with transitions (fade, etc). If it's smart, then it should render only the transitions, leaving everything else 1:1 "streamcopied".

Can you please do 2 tests to verify this?
1. take 3-4 clips, no transitions or effects, output to AVCHD
2. take same 3-4 clips, put transitions between them and output to AVCHD

What is the render time difference?
Thanks!
fred, must be early in the morning for you
grab a coffee and try out the new search function, you will maybe find other posts that i asked for a changelog (hint: 1930a).

but guess what, i figured out some of the changelog already!
well, here's my changelog for build 2013 and AVCHD (Canon HG20 FXP mode, 1920x1080@17mbps)

- SVRT -> still broken
- Magic Fix (stabilization) -> still flickering on slightest camera move
- Transition hiccups -> still there ~ 1sec before/after particular transitions

What a surprise....
G'night.
since you're going to delete the post anyway, here's my 2 cents:
you're doing a (too) good of a job to stick to the rules, risking ending up patrolling these forums on your own.

Cyberlink PD8 has lots of issues raised by quite a high number of users. They better answer some questions, and do so fast. Might as well start with a changelog of things they supposedly fixed in (already) 2 builds since PD8 1930 release.

So to answer Marc's question: no they're not thieves, they just don't care about you. Go find peace using another (better supported) product.

good night.
i just noticed the trial version is build 2013, is this for real?
what happened also to 1930a as a separate update?

does Cyberlink have a changelog on this please?
thanks!
bumping thread, can anyone comment on update 1930a changelog and availability?
as an interesing edit: SVRT works for a m2ts material produced by PD8.
- imported 3 17mbps 1920x1080 clips
- inserted 2 transitions
- SVRT needed to re-encode 98% of the material (audio/video)
- removed the initial 3 clips from the timeline
- imported the PD8 output to the timeline
- splitted it into 3 parts and added 2 transitions
- SVRT works -> it re-encodes only the transition (audio/video), meaning 2% only. The rest of 98% is untouched.

This is how it should work from the beginning on the original clips!
if 17mbps (FXP mode) for 1920x1080 is considered a "high bitrate", then i guess you're right..........

By the way, PD8 (trial) detects the 17mbps material as 15.something. By looking at the max video bitrate limits (17mbps), this is well within the "range" that PD8 allegedly supports.

There is word already of a PD8 1930a update, which weighs around 700MB. Can anyone confirm its availability?

Or can Cyberlink at least provide the updated binaries as the trial version?
sorry but i don't agree with the view that SVRT is becoming obsolete.
Why the #$%% should i re-render (in worse quality) 98% of a 3h movie, when i actually need only 2% re-rendered (transitions, text scroll, etc...) ??? We're talking about same resolution/bitrate clips here!!!!!

Don't worry about my spare CPU cycles, i have better use for them if needed.
even though i'm not quite sure what's up with that flick, i hope your signature won't be representative for PD8

"We learn from history that we learn nothing from history (G.B. Shaw)"
Cld, many thanks for the heads-up on PD8!
I have however some doubts about the SVRT feature.

17mbps as well as 24mbps (topmost limit of AVCHD standard) are currently not usable with PD7 and SVRT. For some reason, everything is encoded @ 14.8 mbps, meaning SVRT won't work at all. I own also a HG20 and wasn't able to use SVRT with any bitrate (even 5mbps).

Question is: should i start saving for PD8 knowing that a functional SVRT/CUDA rendering path exists for 17mbps? I can live with the GM October update which supports 24mbps...

What we expect from PD8 is to be able to smart render AVCHD using CUDA/GPGPU. In other words: output exact input bitrate when no modifications are detected, while smart rendering transitioned/edited parts/joint clips/effects/text.

Thanks in advance!
Just wondering,

a possible explanation of poor backward support could be having a small set of devs which are already dedicated mostly to new release of the product.

Therefore, any infos on ETA for a point or major new release of PD from Cyberlink? Maybe some fixes/enhancement/new features list (changelog)?

Thanks
i also confirm no time difference with HG20 material
yes, but this raises another question: do camcorder manufacturers implement AVCHD coding differently, or does the software (PD7) have problems with recognizing certain levels?

considering all the posts in this forum from different users with different camcorders (Sony, Panasonic, Canon) have something in common (SVRT doesn't work) it proves the problem is on Cyberlink's side correct?

maybe someone with a camera other than Canon can do the same test above and check if we can repro?
Go to:   
Powered by JForum 2.1.8 © JForum Team