Anamorphic encoding with RV9

[karl_lillevold]

I just wanted to mention a feature in RealVideo 9 that is not well known, and quite useful for those high bitrate encodes. Most of you know what anamorphic means. If not, check out http://gregl.net/videophile/anamorphic.htm

The upsize feature in producer is not well documented, but what happens if you specify a resize size that is larger than your input video size, producer will not actually resize the video, but add a flag to the bitstream, such that the player will stretch the video to the desired size. This stretching is a high quality interpolation done by the video card without extra CPU overhead.

So how can you use this to achieve anamorphic encodes? It is quite simple. In your AVISynth script, first crop the video (preferably to a height divisble by four). Then, do not resize to correct aspect ratio like you normally would. No resizing is needed. Add the option to producer (GUI or command line) to resize up such that the aspect ratio on playback will be correct.

Here is an example: After cropping, the video size could be 712x368. The correct aspect ratio after resizing should be 2.35:1. Normally you would resize to 640x272 and encode at this resolution. If you have more than enough bits, but not a lot more than you need, you will get some improvement by resizing to 720x304 instead, but that's only half way there. For true anamorphic encoding at the native resolution, do not resize in AVISynth, but resize in producer to 856x364 (364 * 2.35 = 856). Producer will then encode at 712x368, and RealOne will stretch this to 856x364 on playback. This resolution looks just awesome, and much better than 640x272!

Caveats:

If you play back via TV out, your video card may be limited to a resolution of 640 wide. In this case, the anamorphic encoding technique will probably not gain much quality.

The producer resize feature is available only in the full version, and helix producer from Helix Community.

Edit:

Instructions for Anamorphic encoding with AutoRV9 1.2

1: Setup the encode like you normally would in AutoRV9, including video/audio source, audio bitrate, cropping, possibly pre-filters, and target filesize. The aspect ratio should be 16:9 for anamorphic source material. Pick Neutral bicubic for the resize, since this loads no plugins. We will later edit the .avs script to remove this step.
Do not use separate quality for credits, that's a little too complicated for this manual process.

In my example, I have a semi-slow, darkish source that's 2hr 10mins or so, and with a 2CD encode, the bitrate is clearly high enough to warrant anamorphic encoding. When the resolution is only 640x272, the bits/pixel number os 0.327, which is too high, i.e. higher quality can be achieved by increasing the resolution.

2: Start the encode, and let the audio transcoding complete. Then, when the producer command line window appears, CTRL-C out of it. I copied the command line first though.

3: Edit the .avs script to remove the resizing step. In my example, I also modified it to use YV12 mpeg2dec3. It should now look something like:
LoadPlugin("C:\MISC\Autorv9\SOFTS\AVSFILE\yv12\MPEG2DEC3.DLL")
Video=Mpeg2Source("<path>\source.d2v")
Audio = WavSource("<path>\Stream1.WAV")
Video=AudioDub(Video,Audio)
Video=Crop(Video,10,56,704,364)
#Video=BicubicResize(Video,640,272,0,0.5)
#Do not resize before producer
Return(Video)

** For a YV12 encode, at this point replace the original avisynth.dll with avisynth 2.5 (AutoRV9 requires the original AVISynth)

4: Run a resize capable (see above) producer with the AutoRV9 command line parameters, but with resize added. In this case, it's a 2.35:1 source, so the width will be as follows: height * 2.35 = 364 * 2.35 = 856. The input .avs script is the edited version.

producer.exe -i anamorphic.avs -o anamorphic.rmvb -ad c:\AutoRV9_Movie.rpad -am music -vm normal -lc e,d -rs 856x364

Part of the Diagnostic output from producer should look like:
Diagnostic: Input Filename: anamorphic.avs
Diagnostic: Total Duration: 02:10:04.973
Diagnostic: Video Track
Diagnostic: Dimensions: 704 x 364
Diagnostic: Frame Rate: 23.976 FPS
Diagnostic: Format: YV12

Diagnostic: Using AutoRV9_Movie Audience
Diagnostic: Using audio codec: cook (96468 bps)
Diagnostic: Using video codec: rv9 (1364532 bps)

That should be it, unless I forgot something. My encode is still running, but I ran a short test with '-dt' (no 2-pass) and looked at the first few seconds, which looked fantastic. Will update when complete.

Edit: The encode is complete, and looks fantastic. Every little detail is preserved, and it is almost impossible to tell the difference from the source.

[Sgt_Strider]

the link doesn't work...

[karl_lillevold]

link fixed - extra '.' removed. Thanks!

[31 Flavas]

Originally posted by karl_lillevold

Caveat: If you play back via TV out, your video card may be limited to a resolution of 640 wide. In this case, the anamorphic encoding technique will probably not gain much quality. Also, the free (downloadable) version of Helix Producer can not do any resizing. You must own the paid full version.

I guessing though that if you have the coding skills and a compiler you can get and compile the helix producer source from helixcommunity.org, right?

[karl_lillevold]

Originally posted by 31 Flavas
Also, the free (downloadable) version of Helix Producer can not do any resizing. You must own the paid full version. I guessing though that if you have the coding skills and a compiler you can get and compile the helix producer source from helixcommunity.org, right?

This is true, on both accounts, except no coding skills are needed to compile helix producer, but a little patience in setting up the build environment (help can be found on the helix IRC channel). And also, they will soon make available a binary release of helix producer. This should also be the full version, but I not 100% sure about that.

[31 Flavas]

Originally posted by karl_lillevold

And also, they will soon make available a binary release of helix producer. Well, no matter if it is the free or full version I think what Real is doing with Helix community is awesome. Keep it up, you guys rock!

[karl_lillevold]

Originally posted by karl_lillevold
And also, we will soon make available a binary release of helix producer.
Fully pre-compiled binary releases have now been available for a while for Linux and Win32. This should include the 'resize' feature, which is needed for anamorphic encoding.

Originally posted by 31 Flavas
Well, no matter if it is the free or full version I think what Real is doing with Helix community is awesome. Keep it up, you guys rock!
Thanks! Such feedback makes the extra effort worthwhile.

[karl_lillevold]

I added instructions for how to do anamorphic encoding with AutoRV9 1.2. It requires a 2-step process, where the 1st step is done in AutoRV9. Then when producer starts, you have to CTRL-C out of it, edit the .avs script, before running producer again, with slightly modified command line parameters.

[Dark-Cracker]

Hi,

if u add the anamorphic resize ( 856 * 364) in avisynth and not with the real producer does the encoder will encode it @ 704*364 like in your exemple ?

Ps: when does the yv12 version of producer will be out ?

Bye.

To do for autorv9 :
------------------
- compressibilty check
- yv12 support
- menu creation
- best audio part
- job list
- perhaps anamorphic

héhé.

[karl_lillevold]

Originally posted by Dark-Cracker
if u add the anamorphic resize ( 856 * 364) in avisynth and not with the real producer does the encoder will encode it @ 704*364 like in your exemple ?

Ps: when does the yv12 version of producer will be out ?

No, resizing in avisynth is very different. Then the source image will be resized before being input to producer. Producer sees 856x364 as the original size, and encoding will be much less effective. On the other hand, when resizing is done in producer, it sees that the output size is bigger than the input size, and will not actually do resizing, but encode at 704x364, and then pass a flag in the bitstream, to tell the player to stretch to 856x364 on playback.

YV12 works fine in existing producers. It was never *not* supported, but there may be a 5-15% reduction in encoding speed for the first Helix Community Milestone1 release. In Milestone2, available now, YV12 is handled without any extra color conversion.

[Dark-Cracker]

hi,

where can i download an producer version who support yv12 ? and does producer basic support anamorphic encode or only producer plus ?

Thank,
Bye

[karl_lillevold]

You can download the helix producer from the Helix Community, binary release Milestone 2. This has both anamorphic support (i.e. resizing), and YV12 without extra color conversions.

https://helix-producer.helixcommunity.org/

[kilg0r3]

Hi karl

i have registered on the site but i am unable to get to the milestone section ? do i have to be a devel?

[akabob]

You need to agree Binary EULA licence

[akabob]

I've done a few tests with binary release Milestone 2 & 3 anx x2Real.
Well it work quite great !
Especially encoding speed: My test computer is a P3_700_256MB

Short clip (8.060 sec) of Alien 4 (2.35) :

Real Producer Gold 9.1 -> average 4,8 fps / filesize = 969 Kb
Milestone 2 & 3 -> average 7,0 fps / filesize = 1002 Kb

I didn't use anamorphic capability, everything is done is .avs script:

LoadPlugin ("D:\x2real\bin\avisynth\mpeg2dec3\mpeg2dec3.dll")
m_stream=MPEG2Source("D:\x2real\store\0123_18H31.26\PROJECT.d2v")
m_audiofile=WAVSource("D:\x2real\store\0123_18H31.26\PROJECT AC3 T02 3_2ch 384Kbps DELAY -136ms.wav")
m_stream=AudioDub(m_stream,m_audiofile)
m_stream=Crop(m_stream,0,70,720,434)
m_stream=BilinearResize(m_stream,720,304)
m_stream=Trim(m_stream,2186,2402)
return(m_stream)

see ya++

[karl_lillevold]

I am glad there is an improvement in M2 and 3, but I have to admit I am not quite sure it's coming from :) Everything was fully optimized in Producer Gold 9.1, so perhaps it is the YV12 improvement.


@kilg0r3:

if you still have trouble getting the binary releases after having agreed to the binary EULA, let me know via PM, and I will forward your helixcommunity username to someone who can fix the problem.

[kilg0r3]

found the EULA form. just didn't know that i had to go to my personal helix page for that.

continuing to make a fool of myself: 9.1? i thought 9.01 were the latest. or, is there a difference between helix producer and producer gold? sorry i am new to this

[ranton]

Originally posted by karl_lillevold
[B]I just wanted to mention a feature in RealVideo 9 that is not well known, and quite useful for those high bitrate encodes. Most of you know what anamorphic means. If not, check out http://gregl.net/videophile/anamorphic.htm

Here is an example: After cropping, the video size could be 712x368. The correct aspect ratio after resizing should be 2.35:1. Normally you would resize to 640x272 and encode at this resolution. If you have more than enough bits, but not a lot more than you need, you will get some improvement by resizing to 720x304 instead, but that's only half way there. For true anamorphic encoding at the native resolution, do not resize in AVISynth, but resize in producer to 856x364 (364 * 2.35 = 856). Producer will then encode at 712x368, and RealOne will stretch this to 856x364 on playback. This resolution looks just awesome, and much better than 640x272!

Run a resize capable (see above) producer with the AutoRV9 command line parameters, but with resize added. In this case, it's a 2.35:1 source, so the width will be as follows: height * 2.35 = 364 * 2.35 = 856. The input .avs script is the edited version.

producer.exe -i anamorphic.avs -o anamorphic.rmvb -ad c:\AutoRV9_Movie.rpad -am music -vm normal -lc e,d -rs 856x364


This is for 2.35 source but which are the values for 1.85 and 1.77 sources?

Thanks, Riccardo from Italy.

[karl_lillevold]

Hi there,

then you need to replace the aspect ratio 2.35 in this equation

width = height * 2.35

with 1.85 or 1.77

where height is the height after cropping, but *no* resizing of avisynth.

One really nice thing with anamorphic encoding is that no resizing while encoding is necessary. Like I explained, the "resize" setting to producer when the resize is stretching, does not actually cause any resizing, but a flag in the bitstream to tell the player what the video should be stretched to on playback. This is done by the video card at no extra cost to you. This is why anamorpic encoding is really quite fast.

[Emp3r0r]

This is why anamorpic encoding is really quite fast.

You mean decoding/playback right? ;)

[karl_lillevold]

no, actually I meant encoding, since for YV12 and without slow / high quality resize filters in AVISynth, there is no extra processing in-between the source decoding and the RV9 encoding. So it is really quite fast ;)

[BoNz1]

@karl_lillevoid, I did an anamorphic encode of one of my simpson's episodes yesterday, and I must say I am impressed. There is no doubt it is a lot faster without any resizing. I don't think that I gave it enough bitrate though, it was a little blurrier than I would have liked. I guess something more than 1600kbps would have been better I think I only used 1268kbps, I wasn't that impressed by the audio quality however. I own a minidisc which presumably uses the same audio codec as rv9 but I must say my md sounds a whole lot better at ~ the same bitrate, LP2 is about the same as 132kbps, right? I suppose this is kind of comparing apples and oranges. I guess there is no support for ogg vorbis yet, but I will definitely use that instead once there is.

[karl_lillevold]

Your audio problem is strange. RA8 at 132 kbps is indeed just ATRAC3, which is known to sound very good at that datarate. Maybe you could try to increase the bitrate for audio even more (on a short test clip). If it still sounds bad, there must be something going wrong somewhere in the encoding chain : source conversion, re-sampling, gain control...

By the way, would you not get an aspect ratio problem with full-screen content? When you have 4:3 content with 480 lines, the display aspect ratio corresponds to 640x480. If you encode at ~720x480, the display aspect ratio turns out wrong. If you ask producer to encode at 640x480, it will indeed do actual resizing before encoding. If you ask producer to encode at 720x540 (4:3 aspect ratio), it will encode at 720x480, and the player will stretch vertically on playback to 720x540. This is kind of like anamorphic, but vertical anamorphic :)

[Dark-Cracker]

hi,

@ karl

if i right understand if u encode at a resolution upper than the input resolution realproducer will add a flag to strech the video in order to keep the desired output ratio ? (i suppose i am right even if my english was crap). i hope this streching doesn't use too much CPU and in all case the picture isn't better but bigger.
but could u make a test on the CPU using if u made an anamorphic encode at 856 * 364 and a 704 * 364 encode and use a .smil file to strech the video at 856 * 364 (in order to see the result on the cpu use).

Ps: in producer does the switch "-rs 856x364" only add the flag for the resize because the input resolution is 704x364 and it encode the pictures at 704x364 ? i ask this question to know if producer use extra time for an useless resize and if this could alter the quality of the input source.

Bye.
sorry i can't make some tests i am not at home.

thank u.

[karl_lillevold]

I am glad to see the procedure I described above may be simplified.

You are absolutely correct in how you describe how resizing works in producer, and there's no need to run a test: If the size you provide with the -rs parameter is larger than the input size, producer will not resize the video, it will simply add a flag to the bitstream indicating that the player should resize the video to this larger size (the size provided with the -rs parameter).

To make sure everything is clear:
1) assume your input size after cropping is 704x364
2) if you add the parameter -rs 856x364, producer will encode this the exact same way as if you did not have this parameter, except add this flag in the bitstream, and encoding will take the same amount of time. There will be no useless resizing done.

You could potentially achieve the same effect with a resizing parameter in SMIL, but I have not tried this, and I am not sure if you are allowed to change the aspect ratio, which is what you need to do in this case.

[Sirber]

Is AutoRV9 1.3 on his way? Can't wait!!! :D
Est-ce que AutoRV9 1.3 avance? Jpeux pu attendre!!! :D

@BoNz1

I encode my animes (Futurama, Cowbow Bebop) at 350kbps with 32kbps sound. Quality is #1. Do you really need 1200kbps + 128kbps? RV9 and RA are good at low bitrate, you should try. Also, you will save space :)

[Dark-Cracker]

hi,

autorv9 1.3 is on the good way :)
autorv9 1.3 est sur le bon chemin.

ps: of course anamorphic encode will be added :)

++

[wing1]

indeed RV9 is great at low bitrate. It is too bad that there is no way of convert the encoded clip back to another format, if there are needs to do so :(

[ohliuv]

Originally posted by Dark-Cracker
hi,

autorv9 1.3 is on the good way :)
autorv9 1.3 est sur le bon chemin.

ps: of course anamorphic encode will be added :)

++

1.3 w/anamorphic support will be great :D

[kilg0r3]

Btw, just wanted to mention:

In x2real is also possible and very simple. Just enter the calculated larger resolution into the resize fileds and check 'resize by producer'.

Cheers

EDIT ----------------

oh goaad! just did a test encode of a snippet of VIDOCQ using x2real's 'simulate duration' feature and anamorphic resizing. the result is wonderful.
i have been always complaining (silently) that RV9 is unable to use high bitrates for a detailed picture, but, this is great. folks try it.

btw, does anybody know which bits/pixel*frame ratio is needed for anamorphic encoding for

low motion -
low motion darkish -
med motion -
med motion darkish -
high motion -
high motion darkish -

movies? :)

[wing1]

Anamorphic resize is wonderful: This is true. However, you are the proud owner of a video stream that is true to RealMedia only! Currently, there is no known way of converting the anamorphic resize clip back to any other formats.

[bill_baroud]

Anamorphic resize is wonderful: This is true. However, you are the proud owner of a video stream that is true to RealMedia only!


After see this post, i've asked on matroska mailing list if the format will do the same, and the response is : yes.

if you read the specs you'll see that input _and_ output resolution are stored in the container....so anamorphic content with every supported codec is on the way ;)

[karl_lillevold]

Originally posted by wing1
Anamorphic resize is wonderful: This is true. However, you are the proud owner of a video stream that is true to RealMedia only! Currently, there is no known way of converting the anamorphic resize clip back to any other formats.
It is true that you can currently not convert RM back to another format. However, at anything lower than close to visually lossless compression, would you really want to? In the music domain, I would not consider re-compressing MP3 at anything lower than 192 kbps.

Still, I agree that it is a disadvantage that the content can not be extracted from RM, particularly at the quality levels we get with anamorphic encoding. We get back to the question of opening up the codec APIs, which you will be one of the first to know, when a decision has been made.

[wing1]

@karl and @all,

Please don't read me wrong, because the statement is not meant to be a degraditory for RV9 or anamorphic resize feature by any means. In fact, I am using this feature off and on in my encodings, which depends on my needs.

All I am saying is "There is no current means for trans-code/re-encode the content if the needs arise". This is a temporary roadblock that I have not seen mentioned anywhere. However, normal encoded RV9 can be converted easily using EO video to AVI quite nicely (very slow): However, EO video's VCD/SVCD encoder is something that I would not use at all.

[CaptainCarrot]

@karl
I'm trying to work out anamorphic encoding at the moment, testing it with a couple of codecs, rv9 among them. Now I read your howto and i have a question about producer's resizing-feature:
The resizing is done in the player, right (for outputres higher than inputres)? Now if you watch the movie fullscreen, the player has to do resizing to fullscreen anyway, but is that a single resizing from anamorphic input to fullscreen resolution, or is it a 2-step-process, so that the player first resizes the video to the defined outputres, and then to fullscreen, thus sacrificing some quality and cpu-power? Because then it would be a good idea to tell producer already to resize to the resolution you're most likely gonna watch the movie at.

[karl_lillevold]

CaptainCarrot: there is only one resize in the player, even for anamorphic encodes.

[Sirber]

I encoded Golden Eye, 2 Audio tracks, in 1024x448, on 700MB. The quality is awesome (10/10). The only hic is the buffer. The stream lag sometimes when the HDD is a little busy. It require between 10% and 30% CPU on my AMD XP 2000+.

@Karl

Is there a way to increse the playback buffer?

@All

It's been encodec with a new tool, RMFactory. I'll be posted here when it'll be out of beta stage.

[CaptainCarrot]

I encoded Golden Eye, 2 Audio tracks, in 1024x448, on 700MB. The quality is awesome (10/10)
Hey Sirber, do you want people to take you seriously in the future? Whom do you expect to believ this? If you said "pretty good quality for that bitrate" i'd have said that i'm gonna check myself, but this? In my personal understanding (10/10) means it's perfect. So your statement is basically like "1Mbit for DVD quality? I'll do it at 500k!".
I'd bet you if you encoded it for 800MB it'd look better, and for 1GB it'd look better than 800MB and so on. So a (5/10) would still be hard to believe.
I'm gonna do my own test when I find the time. Do you really think I'll be able to agree with you afterwards?
Is there a way to increse the playback buffer?
Karl wrote somewhere that 25s is the maximum atm, and they're discussing that issue for the next version. But recheck it, i'm not 100% sure about the numbers, i'm only sure that it's already been posted.

And i'll be looking forward to that RMFactory-tool to proove you wrong ;)

[Sirber]

Ok maybe it's not 10/10 all the time, but it's near. A lot of scenes are DVD-Quality. Good scenes are at 10/10, and less good ones, like with far water, smoke or snowfalls, 7/10 - 8/10. Overal quality is 10/10.

Infos:

Video: 626kbps, 712 x 364 ==> 1024x448, YV12
Audio: 2x64kbps
Final size: 706MB

Filters:

DeComb as IVTC

And i'll be looking forward to that RMFactory-tool to proove you wrong ;)
You won't find it. It's not avalible and still in heavy development. And what do you mean, prooving I'm wrong?
Karl wrote somewhere that 25s is the maximum atmWhat you're talking about is the VBR buffer on the encoder side, not the Playback buffer on the player side. :cool:

[Ramirez]

Heya Sirber,plz check your PM.

[Sirber]

Done, check yours ;)

[edit]

Here some screenshots on my lastest RIP:

Infos:

Video: 626kbps, 712 x 364 ==> 1024x448 (anamorphic), YV12
Audio: 2x64kbps
Final size: 706MB

This one is a low-motion shot:
http://www.webernic.com/sites/sirber/Shot1.png

This one, a medium-motion shot:
http://www.webernic.com/sites/sirber/Shot2.png

This one a high-motion shot:
http://www.webernic.com/sites/sirber/Shot3.png

And this ont, a low-motion shot:
http://www.webernic.com/sites/sirber/Shot4.png

[CaptainCarrot]

Video: 626kbps, 712 x 364 ==> 1024x448, YV12
Aha, now this is already something a little bit diffrent than what you said in your first post, I thought you had started from 720x448. The correct resolution in the rmvb-file for this video would be 832x364, it is not necessary to go for a 1024-res, the player will do that anyway. How did you calculate that AR btw.? It's something like 1:2.28... ?
I have a look at those screen-shots, and they're not that impressive (btw they're only 1021 wide, and the player's frame still has to be substracted). Have you had a look at the details? Of course you can call that 712x364, or even 1024x448, but i'd really like to see a xvid-encoded version at the same bitrate with a 512x224 res (or, in a couple of days, a 512x256 with correct AR set in a mkv-container), I don't think the detail-level will be much diffrent.
I.e. in the low motion shot, the faces are pink discs with dark shades for the eyes and mouth, and the numbers on the white label are almost unreadable despite being quite big.


You won't find it. It's not avalible and still in heavy development. And what do you mean, prooving I'm wrong?

That's why I said "looking forward to" which means as much as "I'm waiting for that tool to be available", and then i'll do the above mentioned comparisons with other codecs, and i'll be looking for that "10/10" which I presumably won't find. That 10/10 is what i wanna proove wrong. Btw. you can do that by publishing the dvd-screenshots in addition to your real-video ones. The DVD get's a 10/10, and then you'll see what i mean.
I just think that you are definitely a little bit (maybe more than that) overenthusiastic. 10/10 is the best you can get. Do you really think your video has the best possible quality for that resolution? What would you give an improved rv-codec that gives better quality? 12/10? That would be absurd, and that's what i meant.

[Sirber]

10/10 is for the ripped quality, not how much it looks like the DVD. Try it with XviD at the same rez before resizing, with 128kbps audio (I have 2 track @64). I choose 1024x to have no double resizing in fullscreen, and the screenshots are smaller because it's in windows mode.

Produce shots if you think you can do better, same original size, same bitrate :cool:

I've seen a lot of crappy rips in my life, and this one isn't.

[edit]

I.e. in the low motion shot, the faces are pink discs with dark shades for the eyes and mouth, and the numbers on the white label are almost unreadable despite being quite big.The dvd wasn't digitaly produced, so the detail level isn't very high. Also, numbers are readable. Are you blind? ;) It's 4231-63...

but i'd really like to see a xvid-encoded version at the same bitrate with a 512x224 res You call that a Rez? lol. I want a full-rez movie on 1 CD, and RV9 is the best one to produce it.

[kilg0r3]

You call that a Rez? lol. I want a full-rez movie on 1 CD, and RV9 is the best one to produce it. [/B]

Well, Sirber, you know I respect you, and, I like Rv9. The resolution question is not the only important one especially when using a codec which tends to smooth out everything that it considers to be noise, as e.g. rain or snow. So, if xvid, at a lower res, retains the same amount of detail as rv 9 does, then what do have here?

This 5xx resolution seems a tad low to me btw. Just today i made an xvid rip of a 107 min Movie at full res. The quant goes rarely above 3 even for b-frames. And the detail level is very high.

All da best to you and all others out there. :)

PS: I found a very useful app which allows to capture directly from overlay. It is called Hypersnap DX. (If they integrate a feature that allows to capture every frame of a movie, this will be the death of any copy protection to come :D)

[Sirber]

RV9 doesn't smooth all. This movie is super-sharp, exept for smokes and heavy wind. Look at the shots :)

@Kilg0r3

COULD SOMEBODY PLEASE STOP THIS I-ADVERTISE-MYSELF-WITH THE BIGGEST-UGLIEST-SIGNATURE-POSSIBLE THING GOING ON LATELY? >-( >-P I'll change my sig back within some hours, BTW

I wonder who you are talking about... :rolleyes:

[CaptainCarrot]

I choose 1024x to have no double resizing in fullscreen, and the screenshots are smaller because it's in windows mode.
I asked Karl about this in this thread (go back a few posts), and he answered that the player will always do only one resize, the output res setting is basically just an AR-flag.
Are you blind? It's 4231-63...
That's why I said "almost";).

[Sirber]

Almost for me it's 90% :)

I asked Karl about this in this thread (go back a few posts), and he answered that the player will always do only one resize, the output res setting is basically just an AR-flag.

If we check this:

Movie (720x364)
Codec got flag --> Resize to 864x364
Player get the frame at 864x364
Screen in 1024 --> Resize to 1024x

So there is 2 resizes? Or am I totally wrong and I've got to suicide? ;)

[kilg0r3]

Originally posted by Sirber
Or am I totally wrong and I've got to suicide? ;)

Yes but please don't. :)

[CaptainCarrot]

CaptainCarrot: there is only one resize in the player, even for anamorphic encodes.
This post is the one right before your first Golden Eye Post.
So you're totally wrong :D .
comment removed

[Sirber]

I don't like replys like that, even if it was a joke. Please avoid it next time.