Affordable transcode options with OpenCL / GPU support?

[deadrats]

@deadrats -

Some issues with your "test"

What resizing method did you use ? For example , if someone used a sharper or less sharp kernal it will look different . You should attempt to reduce the variables when doing testing

Did you intend to pillar box it to screw with the AR ? For example, the original 16bit 4k TIFF's were not pillarboxed. I didn't download the MOV, but I suspect it wasn't either

whatever the default resize method used by Movie Studio is.

i haven't downloaded the TIFF's so i don't know the a/r of them, as i pointed out early the 720p encode they offer is in reality 1280x534 and i'm guessing Sony's software doesn't like out odd ball resolutions, alternatively it may be because i remuxed it to mp4 and that screwed things up, tomorrow i will remux to an avi and try again and see how that comes out,

[deadrats]

the source is 3840x1714 at 24fps, for an aspect ratio of 2.25:1.

So are you saying this MOV version is cropped and has pillarboxing ? Or was that some mistake you made ? I haven't downloaded the MOV version, just one of your encodes.

For reference, the original TIFFs were 4096x1714 (AR ~2.389) . It was "real" cinema 4K or 4096 width, not "UHDTV" or 3840 width

nope, no mistake, here's the media info for the source:


General
Complete name : H:\Temp\tearsofsteel_4k.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 6.27 GiB
Duration : 12mn 14s
Overall bit rate mode : Variable
Overall bit rate : 73.4 Mbps
Writing application : Lavf54.29.104

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : No
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12mn 14s
Bit rate : 73.2 Mbps
Nominal bit rate : 100.0 Mbps
Width : 3 840 pixels
Height : 1 714 pixels
Display aspect ratio : 2.25:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.464
Stream size : 6.26 GiB (100%)
Writing library : x264 core 118
Encoding settings : cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=dia / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=18 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=18 / rc=cbr / mbtree=1 / bitrate=100000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=100000 / vbv_bufsize=4166 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 12mn 13s
Bit rate mode : Variable
Bit rate : 183 Kbps
Maximum bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Delay relative to video : 83ms
Stream size : 16.0 MiB (0%)
Language : English

and here's the media info for their "720p" offering:

Complete name : H:\DOWNLOADS\tears_of_steel_720p.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 355 MiB
Duration : 12mn 14s
Overall bit rate : 4 056 Kbps
Writing application : Lavf53.32.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : M=4, N=18
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12mn 14s
Bit rate : 4 000 Kbps
Width : 1 280 pixels
Height : 534 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.244
Stream size : 338 MiB (95%)
Writing library : x264 core 122
Encoding settings : cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=dia / subme=6 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 / keyint=18 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=18 / rc=cbr / mbtree=0 / bitrate=4000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=4000 / vbv_bufsize=1835 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Language : English

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : .mp3
Duration : 12mn 14s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Delay relative to video : 42ms
Stream size : 16.8 MiB (5%)
Language : English

i honestly don't know what to make of it, on the one hand they are obviously pros and yet the seemingly arbitrary changing of aspect ratio between their offerings and the x264 settings they use (no CABAC? really?), i don't know what to think.

[poisondeathray]

i haven't downloaded the TIFF's so i don't know the a/r of them, as i pointed out early the 720p encode they offer is in reality 1280x534 and i'm guessing Sony's software doesn't like out odd ball resolutions, alternatively it may be because i remuxed it to mp4 and that screwed things up, tomorrow i will remux to an avi and try again and see how that comes out,

The 1280x534 is 2.39 AR (same at the original, original) , so I doubt it has pillarboxing either.

What people normally do is use the exact same source, no other processing like resizing - because that introduces other variables. Sony , or avisynth, or whatever program might use something different and that will skew the results. When doing scientific testing, you want to eliminate all these other confounding variables and test the only thing that is supposed to be tested (which is supposed to be the encoder, not some resizing algorithm or other processing)

The more thought you put into the testing methodology, the less likely you'll have to redo the tests a few times because of procedural errors




I suspect the "changing AR's" or versions are for different target displays. For example "4K" TV's are 3840 width (or UHDTV, not real cinema 4K) . Usually the UHDTV version is just cropped (there shouldn't be pillarboxing)

[DarrellS]

I won't be able to download anything until after midnight because of bandwidth restrictions.

I would be more interested in encodes created from the TIFF files instead of already stepped on x265 4K files which I assume your source files are from.

A free command line encoder would be nice but the Cuda.exe encoder in Hybrid is the only free one that I know of. I tried the one in mediacoder but it doesn't work and the command line encoder version of mediacoder costs around $500 when it used to be free.

[hello_hello]

Who'd encode using a constant bitrate,

the people that created Tears of Steel for one, check out their 4k encode.

Why, I'm never going to be encoding that way, so what do I care?

I assume you're just going to ignore my previous post regarding the encode aspect ratios and pretend you weren't wrong?

in what way was i wrong? you still believe a patently false premise, one that your own screenshots show is wrong.

you want an apology? sure, here goes: i'm sorry you don't know what you're doing.

I don't know what I'm doing? I'm not the one who wrote a post trying to justify the fudging of the aspect ratio as "expected behaviour" then gave myself whiplash denying it happened. I'm sorry you're obviously not a grown up. Are you really so childish you can't admit the screenshots in post #34, which are there for all to see, show the aspect ratios are different? That's maintaining a level of self denial which would be almost impressive, if it wasn't so downright sad.
Obviously continuing any discussion with you, based on the assumption you're an adult, would be a mistake.

[deadrats]

I don't know what I'm doing? I'm not the one who wrote a post trying to justify the fudging of the aspect ratio as "expected behaviour" then gave myself whiplash denying it happened. I'm sorry you're obviously not a grown up. Are you really so childish you can't admit the screenshots in post #34, which are there for all to see, show the aspect ratios are different? That's maintaining a level of self denial which would be almost impressive, if it wasn't so downright sad.
Obviously continuing any discussion with you, based on the assumption you're an adult, would be a mistake.

the mistake would be in assuming that you ever took a class in understanding what you read.

my first post explained repeatedly that the aspect ratio did not change, just how it was represented, as a fraction rather than a decimal and i showed you the simple math that proved that.

yet you still cling to the belief that media coder somehow messed up the aspect ratio, i didn't realize that Stan needed to include a math lesson in the help file of his app.

Are you really so childish you can't admit the screenshots in post #34, which are there for all to see, show the aspect ratios are different? That's maintaining a level of self denial which would be almost impressive, if it wasn't so downright sad.

this above line is hilarious, i currently work in 2 hospitals and one of them i work in the psychiatric inpatient unit, just say the word and i'll be happy to call in and see if they have an open bed for you, i'm sure we can get you the help you so desperately need.

[hello_hello]

my first post explained repeatedly that the aspect ratio did not change, just how it was represented, as a fraction rather than a decimal and i showed you the simple math that proved that.

If that's the case you're just plain wrong, and I guess I wrongly assumed you were clever enough to see the aspect ratio had actually changed and you weren't frantically trying to deny it.
The original AVI was 704x384 with square pixels. The encoded version was 704x384 with an aspect ratio of 355:192. It's a different aspect ratio, plain and simple. I posted screenshots to prove it, and they show the aspect ratio is different, not that it's being displayed as a "rounded fraction" or whatever imaginings you're having.

The encoded samples I previously uploaded have a different aspect ratio to the original AVI. If you've checked them but you're too clueless to realise that, then I guess that's your problem. You've only got to open the original video and one of the encodes at the same time to see the display widths are slightly different.

yet you still cling to the belief that media coder somehow messed up the aspect ratio

It did. I've re-run the same encode using the same "keep display aspect ratio" settings several times and each time the input aspect ratio was 704x384 (1.833333) while the output aspect ratio was 355:192 (1.8489). CUDA or x264, the result was the same. I don't know how else to explain it. Maybe a couple more pictures might cause the penny to drop given a written explanation seems too much for you to take in. They show the aspect ratios are different exactly as my original screenshots do, even though you're still in some state of serious denial there.

MeGUI displaying the aspect ratio of the original AVI.



MeGUI displaying the aspect ratio of the MediaCoder re-encode. The same samples I uploaded (post #33) so you can check them again for yourself.

[deadrats]

@hello_hello:

ROTFLMAO!!! wow, i don't know what you're on but that is some powerful stuff.

follow me here: your input file was 704x384 with square pixels, your output file is 704x384 with square pixels.

if the number of pixels didn't change and the shape of the pixels didn't change then the DAR didn't change.

maybe it's time for you to consider that MEGUI is inaccurately calculating the DAR and my theory is that the MEGUI author purposely coded his app to mess with your head, he knew you wouldn't be able to handle the seeming change without short circuiting a few neurons and in an evil genius plot he plotted ahead of time to screw with you.

[hello_hello]

Well I tried deadrats, but you're obviously determined to ignore anything you don't want to believe. It's pretty much impossible to take anything you say seriously now. The output file was not 704x384 with square pixels. I've tried to explain that to you numerous times. I posted a screenshot which shows MPC-HC says the aspect ratio has changed, a screenshot which shows MeGUI agrees, yet you're still playing pretends. I suppose now you'll imagine the Handbrake authors are trying to mess with my head, rather than spend any time in reality yourself?
Note the Display Size Handbrake shows.



Handbrake after opening the original AVI.



MPC-HC displaying the original AVI vs MPC-HC displaying the MediaCoder encode. You'll probably find a way to pretend it's not true, but the display widths are different. FFS, that's how I noticed they weren't the same in the first place. I just used my eyes. When I realised they were different, I checked the aspect ratios.

[jagabo]

I originally thought deadrats was right. But ffprobe shows that both of hello_hello's cuda encoded files have the SAR flagged as 111:110.

[hello_hello]

I originally thought deadrats was right. But ffprobe shows that both of hello_hello's cuda encoded files have the SAR flagged as 111:110.

Thank you!!

Maybe it's just some odd bug which is only occurring when using MediaCoder on XP, or even just using this particular PC, but I've re-encoded the same AVI several times using the same aspect ratio settings as my screenshot in post #34 and MediaCoder fudged the aspect ratio every time. Is it doing the same for anyone else?

I tried the same thing using a couple of different source videos, and resolutions of 960x720 and 1280x720 both resulted in square pixel encodes, but it did seem to fudge the aspect ratio of an anamorphic video I tested a tiny bit (I'd need to re-encode a few again to remember which on it was).

I just tried another quick test encode of a different video. It went in looking like this:



And came out looking like this:



So obviously MediaCoder's "keep aspect ratio" setting has it doing some unnecessary rounding at times. If I manually set the aspect ratio to square pixels, it doesn't fudge, but even the "keep pixel aspect ratio" setting sometimes fudges the aspect ratio, even when the input video has square pixels.

The last time I got into a lengthy "debate' with someone in this forum, it was with another MediaCoder user who took days to accept what I was telling him, so maybe there's some requirement for wearing blinkers before using the program I missed before installing it.

I certainly hope the quality of CUDA encoding is dependant on hardware because I've tried several more CUDA encodes using this PC (8600GT) and the quality isn't great, however.... something seems broken.....
The last encode I tried using a constant 8000kbps bitrate had MediaInfo reported an average bitrate of 214kbps and a nominal bitrate of 8000bps (not kbps). I didn't realise what was happening at first and couldn't work out why a VBR 8000kbps encode was producing a much higher quality and bitrate than a CBR 8000kbps encode. Or has arguing with deadrats over the obvious made my brain numb and now I'm missing the obvious too?

MediaInfo after the 8000kbps constant bitrate encode:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29s 987ms
Bit rate mode : Constant
Bit rate : 214 Kbps
Nominal bit rate : 8 000 bps
Maximum bit rate : 576 Kbps
Width : 720 pixels
Height : 404 pixels


This time a 8000kbps variable bitrate encode (I didn't change the Profile/Level, it was set to "auto"):

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29s 987ms
Bit rate mode : Variable
Bit rate : 7 494 Kbps
Maximum bit rate : 80.0 Mbps
Width : 720 pixels
Height : 404 pixels

I wonder if it's some "maximum bitrate limitation" of my video card (8600GT)? Lower bitrate CBR encodes (ie 700kbps) seem to give me something resembling the specified bitrate, but higher bitrate CBR encodes result in much lower bitrates than they should. Although chances are it's just a MediaCoder bug.....

[hello_hello]

Does MediaCoder save a real log file somewhere? One which shows you the commandlines it's using etc to make second guessing what's it doing a little easier? I can't find one.

I thought maybe I'd found some "don't mess with the aspect ratio" settings in it's options but changing them didn't make a difference, and I'm not sure i understand what they do anyway.


[Attachment 24551 - Click to enlarge]

[lasitter]

I wanted to repost about A's Video Converter because I've got some great news about the developer that I think everyone here should know:

He's spectacularly responsive when it comes to resolving problems.

I had a problem getting the right audio stream out of the program, and he released a new version with a pulldown for selecting the specific stream that you want. I had problems with complete audio corruption, and he released a fix for that. I had numerous problems with audio stream sync, and he created another pulldown where you get to enter an arbitrary value to fix your problem.

Along the way I tossed him a couple of modest contributions. I can't imagine how many millions of dollars you'd have to pay M$ to fix bugs in software in twice the time.

Nothing else I've tried lights up the GPU utilization / quiets the CPU like this free utility. What he could use is much more testing of the different options than I can provide. I'm sure he'd love to hear from you guys if anyone else is in a position to try it.