DivX Kaukura Codec Beta [Archive] - Page 2

dTb

13th August 2003, 02:13

I've just completed testing a couple of methods, coincedently the two your wondering about SeeMoreDigital.

Rules of Attraction, 10mins starting around the end of the opening credits. PAL region 4

LoadPlugin("i:\PROGRA~2\GORDIA~1\mpeg2dec3.dll")
mpeg2source("G:\DVD Movies\Rules of Attraction\ROA.d2v")
trim(22500,37499)
crop(4,12,712,552)
LanczosResize(644,468)

Compress test of 47.16%

Converted to a Huffyuv file.

Standard settings: 1150kbps, bframes, sct 47%, mkt 250, fast pve

1st file
1st pass, standard, no mv: 19mins
2nd pass, slowest, no mv: 1hr57mins
Total: 2hrs16mins

2nd file
1st pass, slowest, write mv: 1hr54mins
2nd pass, slowest, use mv: 1hr14mins
Total: 3hrs8mins

Times taken from vdubmod job control, I was browsing during most of the encoding time so the times will be a little inaccurate but still pretty close.

So even using bframes there's a substantial time reduction with mv reuse although the first method is a lot quicker.
The quality of both files is good but I haven't had a chance to properly evaluate them yet which I'll do later today with psnr values included, just thought I'd post the times for those curious.

Edit: Doh, forgot to mention I used fast pve for both files.

silver_cpu

13th August 2003, 05:28

So what's the purpose of more than two passes, if I may ask? Does it simply increase accuracy/quality by a small measure? Or are there actual processes that are only enabled (or gain significant benefits) with more than 2 passes?

And btw, thanks to all of you for helping with the questions about which features do what and when :)

And while I'm at it, what's a good PSNR to aim for, in an encoding? Or is it something of an arbitrary number? Do the psy enhancements change this?

LordIntruder

13th August 2003, 21:49

So what's the purpose of more than two passes?

With another pass you can have a small increase in quality but the main target is to use the EKG program. With this tool you can reallocate bits wherever you want. Often the codec doesn't encode a scene correctly and You could do 10 passes in slowest mode it would be the same. So you do 2 or 3 passes, you load your video in EKG, you watch and you increase bits in bad encoded areas and can let EKG decrease bits by itself OR (what I do) decrease bits by yourself in good encoded scenes. It takes a very long time of work if you control your whole movie but quality rarely means quick task. ;)

I always do 3 passes but if I get macroblocks, etc... I load my movie into EKG, play with bits, do another pass and i'm done with a beautiful rip. :)

However even without EKG Divx used with good settings brings you a very good quality, but if you want to get the most you know what to do now. :)

nuked

13th August 2003, 23:56

and the best part is by the time you're done with all that, you never want to see the movie again... so you can throw the whole thing away and save 100% file space! :) Don't mind, me... I just kid. Each to his own.

silver_cpu

14th August 2003, 02:55

nuked: LOL! You don't know how many times this has happened to me. I don't have one of the fancy machines most of the enthusiasts here have, so by the time I finish messing up *another* encode, I can get kinda frustrated. I've figured out pretty much everything now, though, and mostly it's just the continually morphing DivX codec which gives me any headaches (and not many at that). Basically, I just wanted to know what these features were intended for, so I could get a better idea what would work with it. Maybe I'll try the EKG utility, but I have to ask: is Dr. DivX better than EKG, besides the addition of some features? Also, is EKG difficult to work with? Thanks, all!

LordIntruder

14th August 2003, 03:24

nuked: ROTFL. A good one! :D

EKG has nothing to do with Dr Divx. Dr Divx is to let people that have no knowledge in encodings to make their own with some clicks. EKG is to let people change the way bits are distributed by the codec. Two programs for two differents things. However I don't know if EKG can be used with Dr Divx.

EKG is very easy to use and there is a guide on divx.com. In less than 10min you'll be able to use it. However keep in mind that EKG doesn't do magic things. If you increase bits in some areas to get a better quality, it means equals bits will be remove somewhere else. It may be clear for you but I already see people increasing bits along all their movies believing it would work. hehe. ;)

To use it the first time I strongly suggest to encode a 1 min clip and to increase bits on the first 30 sec and then make another pass and observe how your last 30sec clip change. The most difficult part is to determine how much percents you have to increase the bad encoded scenes to get a good one because this part is yours and you have no help except your eyes to make a decision and feel, from the current quality, how much you should add in % to reach a good visual quality.

However it's not very hard. I often play between 10% to 25% and most of the time it's sufficient. Nevertheless I no longer use it (EKG) till I play with the beta divx codec in "slow" mode. Redo another 17h pass to get rid of 4 macroblocks in the upper-left corner in two scenes makes me nervous. ;)

dTb

14th August 2003, 05:10

In regards to my test, after visually comparing the two files I find it hard to find much of a difference between the two, the psnr results are also very similar. File 1 total average psnr using psnr4avi.exe = 42.63, File 2 = 42.55.
Also comparing the quant distribution with DRFAnalyser the distribution is very similar, file one with an avg. quant of 4.06, file 2 4.13. The percentage of the quants used was also very similar.

For future use of this codec I think I'll use a method similar to file 1, maybe two passes standard and one slowest, I'm unsure about pve but it didn't introduce anything noticeably bad.

LordIntruder

15th August 2003, 01:00

By the way, speaking of EKG and I've just noticed that since I installed Kaukura, this tool is gone. :( It was still there with Manihi. I don't care because I don't play with it right now due to the encoding times of "slow" passes but others people could need it.

Am I the only one that experience/notice this? Is it intended or a bug?

Also, did anyone tried the chroma option included in the Kaukura codec? I wonder if we can gain a noticeable visual quality. I'm afraid we have to deal with longer encoding times, so.

I quote divx site:

Psychovisual mode is now capable of operating on Chroma. This option is not enabled by default for performance reasons. In order to enable it you must create an empty file in C:\ called "DivxPvShapingChroma.txt" for "fast" mode and "DivxPvSimpleChroma.txt" for slow mode. Results show a very little gain (around 1-2%) in JND tests.

Owen

15th August 2003, 03:24

I may be the only person in on the planet doing real time Divx encoding, :D as no one ever seems to talk about it.
My findings with the Manihi and Kaukura builds compared to 5.05 is that quality of the new builds is great but I cant get low enough bit rates.
Where 5.05 gives me about 2.3gig per hour with good quality (except when it looses the plot and gets stuck on low quants for a second or two.), the new builds give about 6gig per hour when set to 1000kbs on Home theater profile.
Quality is very good, as it should be for that bitrate, but I want 2gig per hour.
What is happening with the new beta’s preventing lower bitrates.
I am encoding 720x576 PAL interlaced with Bidirectional encoding. No QPEL or GCM.
At leased interlaced encoding seems to work now. 5.05 was brocken.

Regards,

Owen

silver_cpu

15th August 2003, 06:21

Just wanted to state that I had not, in fact, tried DrDivx yet when I made that post...I stand corrected, if I'd tried it out already I wouldn't have made the post ;)

And to owen: if you would please tell me how in the world you're getting 25fps on your machine while encoding, I'd love you forever. The closest I've ever come was about 15-18fps. What kind of machine do you have? And what software do you use to encode your movies, and at what resolution?

temporance

15th August 2003, 10:59

Originally posted by Owen
Where 5.05 gives me about 2.3gig per hour with good quality (except when it looses the plot and gets stuck on low quants for a second or two.), the new builds give about 6gig per hour when set to 1000kbs on Home theater profile.
1000kbit/s = 125000 bytes / sec = 450,000,000 bytes / hour = 429MB/hour.

Something strange is happening if this is not what you're getting at 1000kbit/s. Which RC mode are you using?

nuked

15th August 2003, 20:16

Does it hurt the rc or anything to change rate between first and second pass. I managed to make an avs with gknot and some modifications where it was 24fps but gknot was asuming 30 in it's first pass it corrected the bit rate in between passes. The last time this happened I got a file size that was 20% off as well, although I think this has hapened before getting the correct file size, the only difeernce I know was having fast psyc on. I'm not gonna report a file size problem without more research though, but I just want to know.. if I go do another pass and change the bit rate, what effect will that have? I would kinda guess it should make it effectively about as good as a second pass even if it's a third or fouth pass, but I'm guessing.

BoNz1

16th August 2003, 02:40

@ nuked, if the frame rate changes between passes I can see how that would seriously mess up an encode. Just think about it. Say if at frame 1000-1200 you need a lot of bitrate and at 1200-1400 you don't need much. Now, you changed the frame rate from 30 to 24 in the second pass. Now we have a problem. In the second pass the RC will allocate bitrate from the first pass file for those high bitrate scenes in frames 1000-1200 only problem is that those frames don't require that much bitrate any more since they are now mostly the frames 1200-1400 in the first pass. Maybe if you did another pass it would help, but I would just start all over again.

Owen

16th August 2003, 02:42

silver_cpu,
I am using FlyDS (WDM capture app) to capture PAL 720x576 resolution from a MSI TV@nywhere card (WDM drivers) and 196kbs MP3 audio (Radium codec) on a P4 2.8Gig overclocked to 3.3Gig on 932Mhz front side bus with 1Gig Corsair duel channel DDR on ASUS P4P800 M/B.
My old system with P4 3.06Gig overclocked to 3.3Gig with single channel DDR and ASUS P4PE had no problem capturing this as well.

Temperance,
I have tried using Speed/Quality set to Standard, Slow and Slowest (if that is what you mean by RC), but nothing seems to get the bit rate down. I also tried capture at 4000kbs but that resulted in even higher bit rates. (at least that is consistent)
I want to get about 2 hours of video on a DVDR. That would need approx 4000kbs average.
Something is definitely not right with rate control for 1pass real time encoding.
As I said in my last post. 5.05 did give me close to 2Gig per hour. But a rate control bug would often ruin my captures with occasional bursts of macrobocks (low quants).
I have just built a new system with a clean install of WinXP SP1 and Kaukura and it has not helped. So it is not a system related problem.
If I could have the quality I was getting with 5.05 at 4000kbs without the rate control bugs and with working interlaced encoding I would be happy.
I can’t compare quality of new builds with 5.05 because the bit rates are so different.

Regards,

Owen

nuked

16th August 2003, 04:53

only problem is that those frames don't require that much bitrate any more since they are now mostly the frames 1200-1400 i

no, sorry, I was not clear. I did not change the frame rate between passes. I only changed the bitrate. The avs file remained the same. Actually what happened was gknot had a 30fps source of x length in time. Said your-file-size/x=bitrate. But I put telecining in teh avs by hadn cause I wanted some extra options. This should be ok because it doesn't change time or file-size so bitrate should stay the same. However after gknot saw the first pass results, it saw fewer frames than it expected. It assumed this meant the movie time was shorter (of course it was not) and incorectly adjusted the bitrate to compensate in teh second pass.
So actually it turns out the first pass was the correct bit rate and that's why my second pass file size came out too big.

I still have the same question but for a diferent reason. Can I do a thrid pass now at the right bitrate, will it be a) as good a normal thrid pass, b) as good as a normal second pass, or c) worse than all of the above and I should just start over.
Thanks.

LordIntruder

16th August 2003, 05:29

I already made a test of a short clip once to see what would happen if I change the bitrate between passes. Quality was still very good, no artefacts. No difference between the original (which was already very good). However I think (didn't verify it but it's simple to do) if you increase bitrate in the next pass you are going to get an oversized avi and if you decrease it an undersized one from your targeted size.

Gej showed us than we could make a first pass in standard, a second pass in standard and psy and a third pass in slow and psy so that we save time and even if modes are different, each pass gets gain from the precedent one. So I assume it's same here but the size will be different. But I repeat I never verify this point so I may be wrong.

Try and tell us what happens. If you don't want to lose your current work, copy both your current AVI and LOG files in a safe directory. From thoses files you can make as much tests as you want (assuming you know how to do with virtualdub).

BoNz1

16th August 2003, 15:24

nuked, you can change bitrate between passes without any problems. Just make sure of course that the change isn't really drastic like say in the first pass your bitrate was like 1500kbps and now you are changing it to 200kbps. Anyhow this doesn't sound like it is the case so IMO it would have to be a) as good a normal third pass.

U977

16th August 2003, 19:46

Agreed with Sapient:

I already fllow the XviD forum to know about all the advices and bugs.
Yet, I'm very interested in looking at hose new DivX builds.
But I definitively don't have enough time to follow any topic around (avisynth, GKnot, XviD, DivX...).

Even a web page that would summarize the status of teh coded would be fine. It's quite hard to have to read every forum to find out how healthy the codec is.

Anyway, Kaukura is still beta... We are warned that some things may not work. But good advices are still welcome, I guess :-)

nuked

16th August 2003, 20:06

Bonz1, ok.. that's about what I thought. I figured basically the passes are just iterative determinations of quality vs. compression which should be pretty much linear within a reasonable range of bitrate anyway.. More passes just add non-linear corrections when the linear predictions don't quite work out as predicted. That's why I was thinking it may be at least 2 pass quality, as the linear correction should be right already. I don't know if this logic is anywhere close to right, but seemed good to me. I haven't had a chance to try anything yet... actually I'm not sure if I'll be able to recover my settings this time anyway. I'll see, but good to know for reference at the very least that it should work. Thanks.

silver_cpu

16th August 2003, 23:47

U977:

Even a web page that would summarize the status of teh coded would be fine. It's quite hard to have to read every forum to find out how healthy the codec is

Well, if I understand what you're wanting, it's basically a more in-depth version of this site. Doom9 is great for supplying important, pertinent info to the digital video community, but unfortunately the staff is limited, and therefore can't bring you the kind of bleeding-edge news that you're looking for. To do so would require time to visit all of the boards you don't have time for yourself, and to coalate this information into a web update. Either way you go, it's hours' worth of work, and frankly few people have enough spare time for that. Of course, I'm not affiliated with the staff of Doom9 in any way, so they may have their own reasons for not providing the constant coverage that you're asking for.

Owen: that's a mean system, friend. Afraid I'm running an Athlon-tbird 850 OC'd to 950, with 1G of 133Mhz SDRAM. Phew :P I suppose if I were processing 3 times the info I am now, I'd be able to encode real-time, too! (time to upgrade, it's next on my priority list, just after paying the IRS and feeding my face!)

nuked

17th August 2003, 02:32

U977 isn't making anyone do anything. Was just a suggestion, and he didn't say D9 should do it either... maybe DivX or santa-clause could do it.

Lets just say, "not a bad idea IF anybody has the time and feels like doing it" and leave it at that. Cause it's not inherently a bad idea is it? Are we not allowed to present ideas unless we're willing to execute them ourselves?

nuked

17th August 2003, 07:27

if you click on the mv file selection button.. you get a file browser with the file filter set to *.bin. Seems alot like like having it set to *.mv would make more sense, no? The only options are *.bin and *.* with *.bin being the default. Of course *.* will work.

LordIntruder

17th August 2003, 15:37

It is not a bug, "****.bin" has always been here since the dawn of version 5.

nuked

17th August 2003, 16:38

why? all my MV files are labeled as blah.mv. Maybe that's just something gordian knot caused. are they supposed to be labeled blah.bin?

well I did thaat rencode in the right bit rate. Not happy with the results, but there could be a couple of reasons. This encode was already inteded to see if I could get improvement in a particularly tough flick by using fast pve which I had never used before. So I have one done without the bitrate switch with 2 passes at normal, no pve, no MV. Now I have this sorta 3 pass version but with the bitrate reduced in the last pass, with normal and fast pve, read/write MV. The bitrate of the final pass was the same for each and both had b-frames. I really expected this 3 pass attempt to come out better, but there are many dusty and hazy scenes where it looks significantly worse (no blocks, just less detail) and I can't find any place where it looks noticeably better. Oh well. I'd need much more testing to see exactly what's making it worse.

SeeMoreDigital

17th August 2003, 23:15

Well, talking of multipass.

I decided to see how an encoded image would change from pass to pass. The DVD I chose to encode was the PAL version of Star Trek Nemesis (112min).

The settings used were as follows: -
Codec Bitrate - 775kbps
Settings Used - MV/log file only + No other settings
1st pass 'standard'
Nth passes 'standard'

I generated 6passes in all. And saved each pass (5 in total).

Using this method I have concluded that 3 passes is OK but anything after that begins to blur the encode. And when you get up to the 6th pass, quite a bit of detail is lost.

I also have to say that there's not much quality improvement between the 2nd and 3rd passes either (using this bitrate speed anyway). So it's questionable whether the extra pass is worth the effort. Even though it's quite quick to generate!

Cheers

ThePanther

19th August 2003, 09:08

Guys,

I want to encode about 10 DVDs, should I use 5.05 or wait for the final release of "Kaukura". When is there likely to be a final release of "Kaukura"

Thanks A Million

temporance

19th August 2003, 09:17

@SeeMoreDigital,
I've never found that more passes blurs the encode. Are you sure that you never used the output of pass n as input for pass n+1 ?!?!

SeeMoreDigital

19th August 2003, 10:56

Originally posted by temporance
@SeeMoreDigital,
I've never found that more passes blurs the encode. Are you sure that you never used the output of pass n as input for pass n+1 ?!?!
Now you come to mention it. I could have quite easily made that error. I'll have to check. Thanks for the reminder.

Cheers

silver_cpu

19th August 2003, 16:55

Panther: this is on the beta download site:

The Quality Assurance (QA) period will run for about three weeks starting 2003-07-25. All the results must be e-mailed back to us by 2003-08-25 at the latest.

Therefore, it's safe to assume that the final release will be after they've been able to incorporate the various and sundry bug reports into their work, and clean up/modify the code as they desire. So maybe another month? Maybe a little longer, I'm not sure how their release schedule (if they have one) goes.

Also, does anyone know the name of the linux MP4 video codec? It's supposed to be really good, and I've been wanting to try it out, but I can't seem to find it on the web.

zyrill

23rd August 2003, 08:44

i have to report a bug in kaukura. i encoded a movie using vdubmod 1.5.4.1 and the file has a black block in the lower right corner. it seldomly keeps changing the size and in the beginning it wasn't there at all... http://mitglied.lycos.de/zyrill/Die%20Hard_24847.JPG

nuked

23rd August 2003, 18:12

Hey that's amusing. I don't think any of the rest of have seen this though. Are you so sure it's the codec? Can you look at the input to the codec directly... like if you're using a .avs and virtualdub, do you see this block when viewing the avs in virtualdub? This looks a little like the left-side effects I'm used to seeing with probelms arising from the video size not being a multiple of 16. It's a little diferent though. I doubt there was anything important in that corner anyway.

SeeMoreDigital

23rd August 2003, 18:21

Agreed.

It looks more like a VirtualDubMod (VDM) problem rather than an Kaukura problem!

Have you at any time experimented making your own logo's etc with VDM. Maybe something has wondered into one of your 'plugins' folders by mistake - or wherever they have to go!

Cheers

nuked

23rd August 2003, 18:44

This may not be peculiar to kaukura, just I noticed it now. I have a few scenes where the whole picture is jittering. In one case at least it was a problem with the transfer because the image border is shifted about 20 pixels over and I can see the edge of the picture moving with the whole picture. Anyway.. that's not my problem. My problem is this: This jittering scene is encoded with your basic IPBPBPBPBPB type pattern. There are hard edges in the image. In the B-frames the edges get blockwise jagged and start to dance. I seem to have plenty of bits for these scenes as mostly they look beautiful. My guess is some blocks on the edge are taken as P's and some as B's and somehow errors in the diferent motion vectors for the two is causing them to line up slightly diferently. Not sure there is anything much that can really be done about this though. I suppose I could try GMC or qpel. Not sure if I really have a question... just rambling observations.

nuked

23rd August 2003, 19:01

update: gmc and qpel don't help. This is a pretty high contrast edge.. at least in color, maybe not in brightness. I'd expect to motion estimation to lock on pretty hard and acurate to this contrast. There is some noise.. but I'd think it would be litteraly in the noise compared to edge.

nuked

23rd August 2003, 19:11

hehe.. that's kinda subtle.. bright sunlight, pale suface... sky and surface are the same brightness. I just ran "greyscal()" on it. Amazingly enough.. the edge is very low contrast when viewed this way. Kinda makes one think about color based motion vectors( I asume they currently only use limina), but then I'd probably need a faster computer.

SeeMoreDigital

23rd August 2003, 19:18

Hi Nuked

Can you confirm your source's 'image pixel frame size' and your encodes 'image pixel frame size'. And the encoding application you use?

I've noticed that some applications are able to encode the pixels between the matte and the image, better than others!

Cheers

nuked

23rd August 2003, 19:29

crop(4,6,710,268)
BicubicResize(632,268,0,0.5)

I already cropped once before this to keep noise in the black from affecting previous filters. This crop all in all ends up a multiple of four but not on a boundary of 4. I find it safest to do crops like that at the end to avoid some color glitches involving field based filters(I ahve a few pattern glitches to worry about and a cople that must be deinterlaced, but not in this scene. I have a recent post in avisynth about this crop issue.. I think it's on their todo list to fix)... hence the 2 crops. Anyway.. for size all you need is the last 2 numbers.. this is the only resizing done and this crop is exactly to the image....except in teh one scen where the mmiage shifts.. but I see this type fo affect in ohter scenes too. I don't follow why you ask really though. Are you saying the stuff between the matt has it's own fixed motion property? I think I may ahve noticed this type of effect... noise, that isn't quite noise... kinda sits there statically in front of the moving image. I can see how this could screw up motion estimation.

As for software... well now you see I'm using a home brewed avisynth script.. and then just encoding with vdub. I'm not sure how you mean about some software doing a better job of this than others. Do you just mean like using diferent noise filters to filter out this stuff? I've made a 10 second clip with the problem so I can try some things quickly.

ps.. this crop is exactly cropped to the image +/- one pixel maybe.
edit: actually I cropped an extra 2 pixels off one side cause the original had color issues in the last 2 pixels.

SeeMoreDigital

23rd August 2003, 21:13

Hi nuked

Thanks for the detailed reply.

The reasons why I asked the questions is because I'm interested in the methods and the applications people use to create their encodes.

Personally I don't use scripts very often but I do like to use VirtualDubMod and more recently MPEGMediator.

However what I have noticed is, that even when you use the same settings in each application the images they create look slightly different. And as such generate different file sizes. VirtualDubMod, forinstance, seems to do a much better job at encoding the first few horizontal lines of pixels between the image and the matte that MPEGMediator. Especially if you encode at full frame, which is what I tend to do.

nuked

23rd August 2003, 21:41

c-more,

ahh.. I see, I wasn't quite sure what you meant by matte... I was taking your thoughts in completely the wrong direction. You mean the pixels on the edge of the image joining the the black borders right? I have not used anything other than vdub or vdubmod(actualy using vdubmod here.. not vdub as I said above.) If it changes things I always work in yv12 or ocasionaly carefully thought out conversions into yuy2 and back for some filters... but then I use fast-recompress in vdubmod. I have also found these film edges to be handled pretty well and have never quite understood why some people make such a big deal out of problems with them.. I can see some blending with the matte but it's pretty minor.

The dancing edges I'm talking about are of course not atually on the matte edge, but on an edge in the actual image... I suppose the effect is a similar motion estimation problem though. I would think the diference would be the matte edge has higher contrast. I have suggested on the xvid.org board the possibility of allow the user to define an image box and restrict the sign of motion vetors for all blocks along this box so you only mix in stuff from the interior and never from the exterior, and use no motion vector at all for any block entirely outside the box(to prevent the oposite). I got no response. Probably not something your average joe user wants to mess with and honestly not something I care much about either.

Entersting though that the app would make such a diference. I assume if you don't use avisynth that you use filters in your app, like vdub filters. Cropping and resising in combination with yv12 can have issues for instance. I imagine that even with the same "settings" the actual filters used may be a little diferent. Just thoughts though.. As I mentioned, I've mostly stuck to one general method. I'm having a hard enough time learning this one.

edit: of course if your matte edge isn't at a 16 boundary there will always be some mixing even with no motion vectors, no?.. cause quantized dct's just don't handle hard edges perfectly I think..

nuked

23rd August 2003, 21:54

oh and dont' thank me for detailed replies... my long replies are mostly just cause I'm full of..... Don't take anything I say seriously.. I'm ususualy just making stuff up that sounds good :) Every once and awhile I even get soething right.

SeeMoreDigital

23rd August 2003, 22:03

The dancing edges I'm talking about are of course not atually on the matte edge, but on an edge in the actual image... This is why I asked the question about the source. As from time to time some movies are poorly transfered to DVD. You may have already noticed on your PC, that some 1.85:1 DVD's have vertical black borders as well as small horizontal mattes.

Now because these vertical black borders are not as crisp (hard edged) as the horizontal ones, the encoding application finds them more difficult to render.

Well that's the theory anyway.

Personally I can't understand why 1.85:1 DVD's with vertical black borders are released. As they really should be 1.77:1. But that's the film industry for you!

Probably does'nt solve your problem but it might be useful for you to know!

Cheers

nuked

23rd August 2003, 22:14

hehe.. experience says this topic of dvd cropping and sizing leads to long useless heated arguments very quickly with poorly written standards and little hard evidence or support for anything... So I'm gonna say let's not go further with that... but I hear ya.

I had the oposite impression of sharp edges being encodeable though. I actually have read threads about adding egde smoothing borders to make them encode better. This makes sense to me since a square wave in coordinate space takes an infinite number of terms in frequency space to define exactly(edit: okay actually most any arbitray shape will, but particularly making an edge pretty sharp is I thought kinda dificult in frequency space). That's why audiophiles love the square wave test.. it tests the whole frequency range of their equipment in one go. I'm more familiar with continous transforms than discrete one's so maybe it's not quite infinite in this case. I guess this is all going pretty off topic now.. oops.

SeeMoreDigital

23rd August 2003, 23:15

I had the oposite impression of sharp edges being encodeable though. I actually have read threads about adding egde smoothing borders to make them encode better I have not used such tools but it makes sense that they would work. As anything that can create a nice straight hard edge exactly along a row of pixels would be useful.

Wow, please don't go too mad with the technical speak as it gives me a headache. Especially at the weekend. I hear far too much of it at work. Most of it coming out of my mouth!

My real interest is mostly hardware, encoding for me is a sideline activity we do at work. Although converting customers home film and VHS movies to CD-R or DVD R is on the increase at the moment.

I prefer to keep the techno speak simple so the newbies can understand

Cheers

nuked

24th August 2003, 01:19

oh sorry..., math is half what my work is about.. or it's supposed to be anyway, I forget someitmes that frequency transforms are not considered as the basics in all lines of work :). Not trying to sound arrogant.. it's not hard stuff if I can understand it, but you're right it's stuff not everyone is familiar with. To put it simply I actually was under the impression that slow edges, like fades are much easier to encode thatn a quick sharp edge.. that's what I meant by smooth, not smooth as in unjagged, smooth as in unsharp, slow transition...

I think what these edge filters do is make the transition gradual, ramp up from black to the image color; and it makes a border that's easy on the eye and since it's a slow transition.. easier to encode and that's what I've heard, and that makes complete sense from how I understand the math, but I don't have first hand experience or evidence.

To make up for confusing any newbies, if you want, here's the long, hopefully easier to understand explanation. If you're more in the mood to have a beer than learn something (quite understandable on a saturday) then I've already said my point and you can quit reading here.

Mpeg 4 encoders use soemthing called DCT(discrete cosine transform). This is basically a way to describe a picture as a sum of waves starting with low frequeny waves and going up to high frequency waves instead of describing it as a bunch of individual pixels. Every wave has a value everywhere in the "block"(little chunk of the picture) and by adding waves of diferent frequencies which interfere diferently you can make every pixel be different. In theory a picture can be represented this way with no loss of information. Low frequency waves correspond to gradual changes. Many solid color areas like sky or whatnot can easily be described by only the lowest waves because they change slowly, so much information can be cut by essentially not including the higher frequencies, hence compression!(edit, actually the compression mechanism a bit more complicated than this) But a sharp edge is a sudden change.. it's not a wave at all actually, but it's sudden, low frequencies are slow and don't do sudden. You need high frequencies. How you can describe an edge at all with waves is complicated and reauires summing alot of high frequencies as well as some low ones, but it's easy enough for a computer.. and isn't important.. but the point is a sharp edge requires many more pieces to describe it and thus takes more data to encode. Now, I'm familiar with this type of math from diferent contexts entirely and there are many technical fields that use these principles, but I don't see why it would be diferent here and I have read a little about how the mpeg4 encoders actually work, but if I'm off base anywhere here someone pipe in.... Or, if as happens once and while, I'm more or less right.. wouldn't mind getting a "yup" either.

It's not just the math of the encoding transfomation, but might even make motion estimation more effective... like if something is coming slowly from off screen then you can encode it as a small diference singal of a block from the preious frame, where you chose to use a block that was hanging just a little off the screen before to compare to. All the parts that were showing then will match quite well and the parts that were not may not match so terribly badly either cause at least the area out there was basically the right shade and color. All you need to encode your picture then is a small difference signal and a simple 2 number vector that points to the place in the previous frame where the image came from. How much does this help in practice?.. beats me.

dTb

24th August 2003, 06:30

Originally posted by zyrill
i have to report a bug in kaukura. i encoded a movie using vdubmod 1.5.4.1 and the file has a black block in the lower right corner. it seldomly keeps changing the size and in the beginning it wasn't there at all... http://mitglied.lycos.de/zyrill/Die%20Hard_24847.JPG

You've reminded me, I experienced something very similar only for me it was actually square rather than rectangular. The res is 556x400 so not multiples of 16 but I think it's actually a decoder error as it's only visible when kaukura is doing the decoding. Decoding with ffdshow and the problem goes away.

A problem has been discovered with Kaukura, it seems if you use slowest p/q, slow pve and the mvinfo.bin file you might encounter problems, more info here
http://forums.divx.com/viewtopic.php?topic=52998&forum=23