you're both are correct. Media info says the file is Variable Bit rate 5586Kbps Max 23.9Mbps

This issue caused by how HA is used with the Radeon?

If I choose 1080p 24fps at 16Mbps (MP4), it took 1:47 and bit rate was correct. Still Variable bit rate but Min/Max bitrate is the same.

Not too concerned as I only use PD13 to convert WTV to MP4. Intel i7 4770k, 16GB, GTX1060 3GB, Two 240GB SSD, 4TB HD, Sony HDR-TD20V 3D camcorder, Sony SLT-A65VK for still images, Windows 10 Pro, 64bit
Gary Russell -- TN USA

Jeff

When I D/loaded your 3x3 PD said it was 30 Fps so I wasn't sure if I should change my settings to 60 Fps to render 60i. I left it at 30Fps NTSC and rendered to H.264 1920x1080/60i 24Mbps NTSC. (I'm a PAL user).

My render took a pathetic 21 min - (vs 1:50 for the 20XBoats - which looked OK compared to other posted results). I didn't see in your post if your Produce setting for H.264 were M2TS, Mp4, or MKV so I assumed M2TS. Any ideas why my render time was 10x longer than others? My CPU ran at 60-70% and my GPU 90% (attached). When I Produce or Create Disc I must choose between x.v.Color or Quick Sync - why, and what is the difference?

I'm amazed that a 1 min vid can take 21 min to render. GGRussell got 2:59 - but Jeff got GTX970 HA encode time: 11:34 GTX970 HA encode time: 3:37 GTX970 with OpenCL for video effects activated. Is it because OpenCL is not supported on my GPU. I was happy with my PC until this test!

I'm not sure what you mean by a 3x3 Wall. My timeline shows 5xBoats.m2ts on 9 tracks with effects. Power Director 13&14 Ultimate, Photo Director 6, Audio Dir, Pwr2Go 10
Win 10 64, Intel MB DH87MC, Intel i5-4670 CPU @ 3.40GHz, 16Gb DDR3 1600, 128Gb SSD, 2x1Tb WDBlue 7200rpmSATA6, Intel 4600 GPU, Gigabyte G1 GTX960 4GB, LG BluRay Writer

AlS 3x3 wall - is the output - a video "wall" of 3 by 3 video displays (9 videos in one video display).

I am also somehow using different settings to Jeff. My produced file is +-130MB and not the 185mb he is getting.

My settings are:

see attached files. Note the Remaining size.

This is the produced result:

Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Quote: Jeff

When I D/loaded your 3x3 PD said it was 30 Fps so I wasn't sure if I should change my settings to 60 Fps to render 60i. I left it at 30Fps NTSC and rendered to H.264 1920x1080/60i 24Mbps NTSC. (I'm a PAL user).

My render took a pathetic 21 min - (vs 1:50 for the 20XBoats - which looked OK compared to other posted results). I didn't see in your post if your Produce setting for H.264 were M2TS, Mp4, or MKV so I assumed M2TS. Any ideas why my render time was 10x longer than others? My CPU ran at 60-70% and my GPU 90% (attached). When I Produce or Create Disc I must choose between x.v.Color or Quick Sync - why, and what is the difference?

I'm amazed that a 1 min vid can take 21 min to render. GGRussell got 2:59 - but Jeff got GTX970 HA encode time: 11:34 GTX970 HA encode time: 3:37 GTX970 with OpenCL for video effects activated. Is it because OpenCL is not supported on my GPU. I was happy with my PC until this test!

I'm not sure what you mean by a 3x3 Wall. My timeline shows 5xBoats.m2ts on 9 tracks with effects.

Timeline setting not significant, Produce setting was NTSC

Yes, H.264 1920x1080/60i 24Mbps NTSC

21min sounds about right for your PC configuration, namely a i5-4670, the only component of relevance. The time duration hog in this test is the effect that was applied. I picked a very computationally intensive effect for this test case so one can easily see the benefits of OpenCL for video effect encoding which was the video discussion with CL speaker that you attached. If you get rid of the video effect applied to all 45 video clips and just have a 3x3 video wall of the boats.wmv for the ~1:05 duration, your i5-4670 will produce that in under 2min and maybe you'll feel good again.

GGRussell results maybe a little deceptive, he did get 2:59 time for the proper produce setting but the resulting file was really not as expected. He verified that the bitrate was not what it should be and the best he could do was produce to a different setting, a setting with much less load and a time of 1:47 so not really directly comparable to the other results. You can produce to his setting and compare to his 1:47 if you want to feel unhappy again.

The 5 boats.wmv in the timeline is simply to extend timeline duration to ~1:05 to make testing more valid. If I would only have one boats.wmv in the 9 tracks for the 3x3 video wall my total timeline duration would be ~20 seconds. On faster systems having a encode test case that finishes encoding in like 40 seconds as mine would is not a valid test case. Too many other windows services can affect things and result in a time of say 35 seconds which is a 12+% improvement which may sound better but really it's not, it's simply variability. By having encode times in the several minutes range for a test case you minimize this variability and test real average performance a little better.

Concerning x.v.Color and QS, two totally different items just the same location in the window. To my knowledge PD only lets one use x.v.Color when CPU encoding.

Jeff

Quote: I am also somehow using different settings to Jeff. My produced file is +-130MB and not the 185mb he is getting.

My settings are:

see attached files. Note the Remaining size.

Proper profile settings, slightly improper output from your HD 5450 and PD13 most likely. If you use an instantaneous bitrate viewer on your produced file you will probably see it didn't maintain the ~24Mbps throughout the entire duration, some regions or even across the duration substantially lower yielding the lower file size.

Do a CPU encode (both pref HA tabs and Produce HA disabled) and my guess is you will get closer to the "Renaming size" which is also consistent with what I posted as my produced file size.

Jeff

All HA is disabled - (HA video processing, OpenCL and hardware decoding), this should be CPU only result.
I also realized PD is producing the file at 15.94 MBps (not the selected bit rate).
I also tried one at 16Mbps profile and the file is about 10MB smaller than this one.
PD bug (maybe an issue in the default profile for 24Mbps)?
Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Quote:
All HA is disabled - (HA video processing, OpenCL and hardware decoding), this should be CPU only result.
I also realized PD is producing the file at 15.94 MBps (not the selected bit rate).
I also tried one at 16Mbps profile and the file is about 10MB smaller than this one.
PD bug (maybe an issue in the default profile for 24Mbps)?

Yes, a little bit of a surprise but not really sure its a bug. PD uses a variable bitrate encoder which can drop the bitrate as it see's fit, typically one only observes this bitrate reduction if the video creation has lots of nearly static video or significant number of pictures. Your file size appears consistent for the reduced bitrate and right inline with mine when scaled to the proper average bitrate, 128.6/15.94*22.4=~181MB

I just booted up a old box with an Intel HD4000 and tried QS in support of AIS's observations. Resulting file has a avg video bitrate of 22.4Mbps over the duration and file size consistent with previously quoted Nvidia HA file size and typical of what it should be for near constant bitrate encoding.

Jeff

Jeff -- did the 3x3 wall.pds test again. First time, I just unchecked 'Fast Video Rendering.' Took 3:02, files size was 128MB. Media Info reports the file as 16.6Mbps avg with max 23.8Mbps. GPUz also showed that the video card was being utilized during render.

Second render, I went into PD settings and uncheck Both for Hardware acceleration. This time it took 14:13. Media reports same info as the first render.

Question: So why does checking 'Fast Video Rendering' using .m2ts not work correctly with my Radeon HD7870? Just curious since unchecking that seems to still use the video card anyway. Intel i7 4770k, 16GB, GTX1060 3GB, Two 240GB SSD, 4TB HD, Sony HDR-TD20V 3D camcorder, Sony SLT-A65VK for still images, Windows 10 Pro, 64bit
Gary Russell -- TN USA

Quote:

Quote:
All HA is disabled - (HA video processing, OpenCL and hardware decoding), this should be CPU only result.
I also realized PD is producing the file at 15.94 MBps (not the selected bit rate).
I also tried one at 16Mbps profile and the file is about 10MB smaller than this one.
PD bug (maybe an issue in the default profile for 24Mbps)?

Yes, a little bit of a surprise but not really sure its a bug. PD uses a variable bitrate encoder which can drop the bitrate as it see's fit, typically one only observes this bitrate reduction if the video creation has lots of nearly static video or significant number of pictures. Your file size appears consistent for the reduced bitrate and right inline with mine when scaled to the proper average bitrate, 128.6/15.94*22.4=~181MB

I just booted up a old box with an Intel HD4000 and tried QS in support of AIS's observations. Resulting file has a avg video bitrate of 22.4Mbps over the duration and file size consistent with previously quoted Nvidia HA file size and typical of what it should be for near constant bitrate encoding.

Jeff

So any idea why PD uses a variable bitrate encoder for some (like mine and it looks like GGRussell CPU version also) and not for the one you produced with the Intel HD4000 (larger file size)? Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Quote: Question: So why does checking 'Fast Video Rendering' using .m2ts not work correctly with my Radeon HD7870? Just curious since unchecking that seems to still use the video card anyway.

I'm not sure on your HD7870 question, I don't have any to test, monitor and gain experience so I'd only be guessing with no verification. As I indicated in previous post, my guess is it maybe just PD variable bitrate encoding at play.

I'm not sure I totaly understand your "First time" and "Second render" exact settings. Specifically, what was the HA options in pref (particularly OpenCL setting just leave decode setting unchecked for ease) set to and what was "Fast video rendering" set to on Produce page. Since you have a 4770k and HD7870 it also depends signficantly on what was done there, we have had the GPGPU discsions many times. Was the Intel HD4600 disabled in BIOS? If your HD4600 was disabled one really has 4 options:
1) Pref OpenCL checked, Produce Fast video rendering checked
2) Pref OpenCL checked, Produce Fast video rendering unchecked (was this "First time"?)
3) Pref OpenCL unchecked, Produce Fast video rendering checked (was this "Second render"?)
4) Pref OpenCL unchecked, Produce Fast video rendering unchecked

All items above do something slightly different as far as transfering load between CPU and GPU for this video effects sample test. The difference was explained here http://forum.cyberlink.com/forum/posts/list/40407.page in post 28/09/2014 09:30:58

Items 1-3 will all use the GPU to some degree, attached are two pics that show my GTX970 can be totaly unloaded during this encode process (item 4 above) and on a second box that has a HD4000, it to can be totally unloaded (item 4 above).

Jeff

Quote: So any idea why PD uses a variable bitrate encoder for some (like mine and it looks like GGRussell CPU version also) and not for the one you produced with the Intel HD4000 (larger file size)?

Variable bitrate is used for both Nvidia and HD4000, it's just that a tight spread in bitrate is maintained when viewed with a instantaneous bitrate monitor or MediaInfo stats shown below.

For HD4000:
Format : MPEG-TS
File size : 180 MiB
Duration : 1mn 5s
Overall bit rate mode : Variable
Overall bit rate : 23.2 Mbps
Maximum Overall bit rate : 23.8 Mbps

And for GTX970:
Format : MPEG-TS
File size : 186 MiB
Duration : 1mn 5s
Overall bit rate mode : Variable
Overall bit rate : 23.8 Mbps
Maximum Overall bit rate : 24.0 Mbps

As I guessed earlier, my thought is for whatever reason PD takes some liberties with "variable" and drops your bitrate substantially. This effect is easy to see, drop the ballons.jpg in the timeline and stretch to 1:05 duration (same as 3_3_wall.pds) and produce to same 24Mbps format, you should see a very small file and very low bitrate. Obviously good and bad to this. For the ballons.jpg example probably good as one saved significant produced file size as using a high average bitrate on a static pic really serves no function. For the 3_3_wall.pds example with boats.wmv, my guess is you lost some quality at the lower average bitrate that was produced. For GGRussell first post of 47.7MB file size, that would have a average bitrate of about 5,800Kbps or so, one had to of lost significant quality, that's sub DVD bitrates.

Jeff

Jeff - The HD4600 is disabled in my BIOS. I was using
2) Pref OpenCL checked, Produce Fast video rendering unchecked (was this "First time"?)

4) Pref OpenCL unchecked, Produce Fast video rendering unchecked (second render)
---------------------
1) Pref OpenCL checked, Produce Fast video rendering checked was the results where the bitrate wasn't correct.



Thanks for that 2014 link. Seems like CL needs to simplify when hardware acceletration is used. Very confusing, but think i got a grasp on it. Intel i7 4770k, 16GB, GTX1060 3GB, Two 240GB SSD, 4TB HD, Sony HDR-TD20V 3D camcorder, Sony SLT-A65VK for still images, Windows 10 Pro, 64bit
Gary Russell -- TN USA

Quote: Jeff - The HD4600 is disabled in my BIOS. I was using
2) Pref OpenCL checked, Produce Fast video rendering unchecked (was this "First time"?)

4) Pref OpenCL unchecked, Produce Fast video rendering unchecked (second render)
---------------------
1) Pref OpenCL checked, Produce Fast video rendering checked was the results where the bitrate wasn't correct.



Thanks for that 2014 link. Seems like CL needs to simplify when hardware acceletration is used. Very confusing, but think i got a grasp on it.

From my experience, your test of item 4 should have a unloaded ATI HD7870, but I guess you say your GPU still has load. The large increase in encode time (3min to 14min) you post indicates the load surely must have shifted to your CPU and unload the GPU which is what item 4 settings will do. Post a pic, I would like to see GPU-Z results during PD encode with item 4 settings.

Yes, I agree, very confusing. What makes things worse is what sales propaganda comes with each new release and trying to understand what they really are providing and might a given user benefit with no real information. Often stuff like 40% improvement in H.264 and many users experience next to nothing or worse a increase in time for their typical timeline.

Also the moving GPU market makes it difficult and confusing in understanding what PD is supporting. Nvidia several years ago only had a CUDA encoder that relied on the CUDA cores for rendering and in 2012 migrated to integrated encoder engine and recently dropped CUDA encoder in drivers on 6/14. PD13 only had the old CUDA encoder support when released in 9/14 and hence CL's note on spec page to go find Nvidia drivers prior to 340.43. ATI went through similar path with the old ATI Avivo package which was dropped entirely in 2013 from drivers and now have the integrated VCE (video codec engine).

Jeff

Quote: From my experience, your test of item 4 should have a unloaded ATI HD7870, but I guess you say your GPU still has load.

You might have read it wrong or I wasn't clear. Item 4 took 14:13 so was definitely CPU only.

CL isn't the only company was an over zealous marketing department. LOL Intel i7 4770k, 16GB, GTX1060 3GB, Two 240GB SSD, 4TB HD, Sony HDR-TD20V 3D camcorder, Sony SLT-A65VK for still images, Windows 10 Pro, 64bit
Gary Russell -- TN USA

GGRussell, EKSVid

I think the issue you are having with too low of bitrate is in fact a PD anomaly. If you wouldn't mind could you post the file sizes and bitrates from MediaInfo for the following 4 runs. Maybe this will be enough info to have CL take a look.

I say it is a a PD issue because of the following. It appears the issue only occurs if one uses a "accelerated" effect, for reference, the ones with a GPU icon in the corner of the effect:

1) 3_3_wall.pds, accelerated effect Gaussian Blur, ISSUE
2) 3_3_wall_abst.pds, accelerated effect Abstractionism, ISSUE
3) 3_3_wall_glass.pds, non accelerated effect Glass, No Issue
4) 3_3_wall_waterrefl.pds, non accelerated effect Water Reflection, No Issue

If one also uses a 3_3_wall generic file with no effects applied the file size and bitrate are fine.

Jeff

All three produced with Pref OpenCL checked, Produce Fast video rendering checked; rendered 1920x1080 60i @24Mbps

3_3_wall_glass: 189MB
3_3_wall_waterrefl: 41.6MB
3_3_wall_Abst: 96.6MB Intel i7 4770k, 16GB, GTX1060 3GB, Two 240GB SSD, 4TB HD, Sony HDR-TD20V 3D camcorder, Sony SLT-A65VK for still images, Windows 10 Pro, 64bit
Gary Russell -- TN USA

I "think" I did it correct.

The first one (with the Gaussian Blur effect) is not the correct size.
The last 3 look correct.


I attached a zip file with the Media info for all of them. Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

I'm a little late to this but I've done a whole bunch of benchmarks on my i7 4770K/HD 4600/GTX 780Ti system with different nVidia drivers, and I have some interesting results.

Here are the detailed outcomes, sorted by nVidia driver version ("QS" is QuickSync):



Three things stand out for me:

1. The 20x Boats bit rates and production times are identical across nVidia driver versions, with the expected outcome of faster GTXxxx times with 344.65. CPU is the slowest production method. This shouldn't be surprising, but it is when compared to the next finding...


2. The 3x3 Wall production times across all 3 production methods are all tightly clustered and are ALL dependent on nVidia driver version! This may be because the 780Ti was still running one monitor when the HD4600 was driving the main monitor with PD13 on it - however I wasn't expecting the nVidia driver to have much effect on CPU production, much less QuickSync, but here we are!


3. The 3x3 Wall bit rate for the 780Ti is marginally affected by the nVidia driver version and it is significantly below the 24Mbps setting used to produce. This is similar to what GGRussell had seen with his AMD card. I produced with Open CL checked and Fast video rendering + HVE checked.

I've attached the spreadsheet with the reults and test setup notes, and all the files are available *here* if anyone wants to verify bit rates, etc.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

The 20 Boats.wmv and performance changes with Nvidia driver versions that only affects "Produce" module not "Create Disc" was sent to CL by Dafydd as referenced earlier in this thread, http://forum.cyberlink.com/forum/posts/list/42749.page. So as you state, item 1 is as expected.

For item 2. I think the results most likely make sense. I'm guessing what you really tested is multi-GPGPU per CL definition. I don't think you will see a QS time of ~5:00 unless it had the aid of the GTX780Ti doing the accelerated effect task of the 3x3wall. If you are still messing around, as proof positive:
1) Start PD, in Pref unselect both HA items, OpenCL and decode
2) Close PD
3) Diasable the 780Ti in device manager
4) Start PD, in Pref selected both HA items, OpenCL and decode
5) Close PD
6) Open PD and load 3x3wall.pds
7) Produce to proper format with HVE checked using QS

I'm guess the results of above will be much more than ~5:00 for QS.

Basically all your test times of 3x3wall are similar as the majority of that time is the handling of the FX applied to the clips which is controlled in pref by the OpenCL setting. My guess is this was always selected and only the HVE changed on the "Produce" page so the 780Ti was ALWAYS handeling the FX load. That's maybe why the Nvidia driver version affects these results as well.

I didn't see excel file or setup notes in OneDrive or here.

Jeff

I had attached the benchmarks spreadsheet when I posted but I guess it didn't take. It's in the OneDrive folder now. I'll take a closer look and run your test in a little while

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

OK. I went through the steps and ran the test using just QuickSync.

For thoroughness, I ran both projects with all three nVidia drivers and found that the 3x3 wall test took 12:09, 12:20 and 12:13 to complete with the three nVidia versions (from newest to oldest). All the production times are >2x longer than before, so it really looks like the GTX780Ti was helping in a multi-GPGPU sort of way. In adddition, the bit rate crept up a bit when the nVidia card was totally out of the picture.

There were no significant changes with the 20x boats project.

I've updated the spreadsheet and added the new output clips to the OneDrive folder, and now I may move on to other things unless there's some merit to re-running the CPU-only benchmarks with the GTX780Ti disabled and/or with OpenCL and HW decode unchecked. All were present and checked and only Fast/HVE was unchecked on the Produce tab the first time through.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°