x264 development [Archive] - Page 22

bill_baroud

22nd June 2005, 15:13

If your code keep all your execution units busy correctly, using hyperthreading won't help you, and even will harm performance (by disrupting the instructions flow of your program that you carefuly set and managed with love and care and ... err i need to stop coding in assembly)

But well yeah, in practice, you can't never keep your executions units busy and break all dependances.

dinolib2

23rd June 2005, 21:14

Here (http://forum.doom9.org/showthread.php?t=96059) you can read, under "current issues with AVC/H.264" paragraph, this sentence: .avi: using AVC-in-AVI is nowhere standardized and therefore already causes incompatibilies. The limitations of AVI and VFW (eg regarding b-frames or arbitrary frame coding orders), together with the necessary hacks caused by these two formats, hinder the full implementation of all possible features AVC offers and therefore harm the possible quality or at least the speed of the development, the interoperability and therefore also the competition. AVI is currently used by VSS and x264 (mencoder and vfw)

My question is: in this state of development, is x264 quality limited by avi restrictions? Could be in the future developed some "advanced feature" no more compatible with avi container (and not present in VFW)?

Sorry if I've made a silly question :D

absinthe

24th June 2005, 15:38

Doom9 suggested that I report an odd problem here: x264 from the command line with the --progress parameter does not show any progress output on my box. Therefore, I see no status progression in the ProgressWindow of MeGUI.

Several people seem to be affected by this, including some who do get progress at the command line and still do not get progression in the MeGUI ProgressWindow (though that may not be relevant here). At least one other person has the same problem I do with no progress at the command line.

I use WinXP Pro (SP1), Athlon 1600 XP. Nothing unusual about my box that I can think of. I'm using the latest x264 (revision 270).

Let me know if I can provide more info.

-abs

Sharktooth

24th June 2005, 15:44

Maybe starting with installing all OS updates (including SP2) will exclude a good amount of possible problems...

Doom9

24th June 2005, 15:53

(though that may not be relevant here)It doesn't. I'll take care of of those in my own domain eventually.

kurt

26th June 2005, 12:03

I have the same problem like absinthe (no progress at cli)...
I use WinXp Home on my P4 2ghz with 512 MB RAM - I installed all windows updates (including sp1 for .net 1.1)...
with mencoder there are no problems...
Any idea what's going wrong?

Edit: this is the window during encoding (wich always finished fine)
http://img220.echo.cx/img220/7595/image17ii.th.jpg (http://img220.echo.cx/my.php?image=image17ii.jpg)

Sharktooth

26th June 2005, 12:53

what build are you using?

kurt

26th June 2005, 13:04

what build are you using?
latest revision (270) :) (sorry forgot that to mention)

Sharktooth

26th June 2005, 13:10

my build or other's build? or the problem is still there indipendenlty from which builds you use?

kurt

26th June 2005, 13:24

my build or other's build? or the problem is still there indipendenlty from which builds you use?
normally I use your builds, but I tried bob0r's even too - same problem here....

Sharktooth

26th June 2005, 14:20

well... a compiler issue is excluded then: i use gcc 4.0.0 and bobor 3.4.x (IIRC).

ckjnigel

26th June 2005, 21:16

Can someone explain where Ahead/Nero has positioned itself with regard to H and X .264? It's important for me to know so as to choose which codecs to install; I recreate my X64 partition once a month. This go round I've discovered that that 6/19 ffdshow cannot compare to Videolan VLC player and the latest Nero video decoder is even better playing back an H.264 in an avi container created with Gordian Knot.
I'm guessing that X.264 could be a format for video as well suited to Pocket Pc as AAC+ is for audio.
I'm hoping that Pocket PC freeware BetaPlayer and TCPMP developer Picard is being kept in the loop. ( see http://tinyurl.com/86aq2 )

bond

26th June 2005, 21:46

avc is avc no matter what codec (nero, x264 or whatever) you use to create the stream

place avc in the .mp4 container and you will be able to play the file on as good as all avc enabled players (including nero's stuff)

posix

28th June 2005, 21:28

where do i find a list of all resolutions this codec supports? (searched this thread for "resolution" without success)

LigH

28th June 2005, 21:36

What do you mean with "all resolutions"?

From "poststamp" up to HTDV dimensions - no problems. The only required precondition: Width and height must be multiples of 16 - x264 does not yet support "any" size by virtually filling up the dimensions to multiples of a macroblock.

I only remember one kind of codec which was limited to only a few special resolutions: H.261 (used for ISDN {64 kbps} video telephony).

berrinam

28th June 2005, 21:40

Is there no maximum resolution, or is it just so large that it is irrelevant?

LigH

28th June 2005, 22:08

There is most probably a maximum. But do you really need to encode e.g. 4096x4096 videos? Where do you want to get material larger than 1920i?

Andrey

28th June 2005, 22:14

>>There is most probably a maximum. But do you really need to encode e.g.
>>4096x4096 videos?
Original digital D5 source should be about this resolution. And it will not be stored uncompressed, I think. This is not what is called a "consumer" use, but still it should be handled somehow.

LigH

28th June 2005, 22:50

It is very hard to find useful pages about the D5 format. Mostly copies of the Wikipedia article, which is limited to HD-D5 with resolutions up to 1080 lines.

SeeMoreDigital

28th June 2005, 23:00

When I was last in a TV studio D5 referred to: -

625 line component digital video recorded onto ½" (12mm) tape, using an uncompressed 601 format. The max run/record time was 128 mins with up to 4No digital audio channels

It was used in the UK by Channel 4 in late 1990's as transmission format but was replaced by Digi-Beta due to the high cost of the hardware and the media.

Cheers

EDIT: Don't most production companies use the DPX process to convert film to digital video nowadays?

Andrey

28th June 2005, 23:17

>>When I was last in a TV studio D5 refered to
Hmmm...
Thanks for the info, SeeMoreDigital.
I saw an article, where D5 was reffered as an high definition digital (primary) source digital television sources are produced from.
Need to check it once more...

LigH

28th June 2005, 23:24

The DVD authoring studio I once worked for had a HDTV cinematic film scanner; AFAIR, a hot plug able 10 SCSI HDD RAID. No idea which file format they use. but a hell of a machine! :D

Doom9

29th June 2005, 10:50

I've had a feature request for MeGUI to offer more control over the turbo option. I'm wary of that because I'd like to prevent that incorrect settings will severely degrade the output. So far, I'm reducing subq, 8x8b options (what about the 8x8i and adaptive dct by the way.. can they be safely deactivated) and number of reference frames. Is there anything else that can be safely changed without having visibly adverse effects on the result? Or put the other way round: which options are not a "must-match" and how far can they be tweaked?

Sharktooth

29th June 2005, 11:05

analyze can be set to none
reference frames to 1
8x8dct can be disabled
diamond search ME can be used.
the difference between using the same settings for 2 passes and this method is negligible.

bond

29th June 2005, 11:40

Doom9

29th June 2005, 12:32

pengvado himself once made a post on what should be safe to use, dont find it anymore toughI know.. must be in this thread or in the old MeGUI one and I implemented exactly what he described. But at that time x264's feature set was more limited, especially the VfW version which was taken as template at that time (x264.exe only became useful when it got AviSynth input suport).

berrinam

29th June 2005, 12:39

is it this post? (http://forum.doom9.org/showthread.php?p=595200#post595200)

Doom9

29th June 2005, 12:54

is it this post?yup yup (2nd yup due to the minimum post lengt of 5;)

bond

29th June 2005, 13:18

yup yup (2nd yup due to the minimum post lengt of 5;)
yeah, would be great if this could get changed back to 3 as it was the case in the old board :D

superdump

29th June 2005, 16:52

Doom9: That post that aku made was merely stating what the fast first pass in vfw does. Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold compared to the usual (non-turbo) first pass. My second pass options are -r 5 -m 6 --me umh -A all --8x8dct. I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves.

EDIT: This is using an ABR first pass and bitrate target second pass.
EDIT: Reworded the last section and altered the meaning as it was incorrect to what I actually intended.

cheburashka

29th June 2005, 18:11

...I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves...

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)

Doom9

29th June 2005, 19:02

EDIT: This is using an ABR first pass and bitrate target second pass.Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).

superdump

29th June 2005, 19:29

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)
Pengvado is away and won't be back for a few months. We might be able to contact him at some point though. I did request that it be done but I think Alex_W and algern0n were apprehensive and wanted it to be tested further. So if people can test with a wide variety of sources and post results that would be appreciated. I could always make a patch which alters the fast first pass code as necessary, wouldn't take long.

Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).
If there is a difference it will be that specifying --pass 1 forces stats output.

bond wants profiles/levels? Do you mean setting that flag in the encoder or what? I was thinking of possibly tackling this as one of my first contributions to x264 as it should be quite easy. The hard part is deciphering the standard. :) I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.

Doom9

29th June 2005, 20:10

I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.That's the one. I already implemented parts of this (simple, main and high profile features).. the next step would go into levels within a profile.. where resolutions, vbv, etc comes into play. So if you like to read up on this and share your findings, that would be a very valuable contribution indeed and I think it would also make sense to implement the results of such research into the VfW and have something just like the VfW profiles.

I'll try to prioritize the "update jobs" feature so testing will become much easier. Right now I have to switch between inputs of my flatscreen to set up my new X2 based barebone :) x264 is gonna fly with the new CPU :)

SeeMoreDigital

29th June 2005, 20:36

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.

Cheers

bond

29th June 2005, 20:42

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.nero doesnt want to share the specs of their private profiles, so why should anyone mess around with them...

apart from that, with no really widely useable avc hardware existing, what sense does it make to specify and use private avc profiles different from the official mpeg ones...
they will be changed anyways once the chips arrive

superdump

29th June 2005, 21:30

OK, I've been discussing this with Manao and there is a slight problem. The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. So instead I'm going to direct my efforts elsewhere... more RD maybe. :)

IRMA1024

30th June 2005, 13:59

is x264 stuck on rev270 i don't see any revision after? i hope next, error resilence will be implemented... btw... nice work

Ark

30th June 2005, 14:09

If you look at the daily build sticky thread, you'll see "summer break" written, which means that for a while rev270 will be the last build available, as developers (in particular akupenguin) are enjoing their holidays!

LigH

30th June 2005, 14:10

Did you notice the addition "Summer Break" in the title of the thread with the most recent builds by Sharktooth? In my opinion, this means: Don't expect many updates because most developers are on vacation. ;)

akupenguin

30th June 2005, 16:20

Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold with my second pass (-r 5 -m 6 --me umh -A all --8x8dct).
You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?

The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.

superdump

30th June 2005, 17:41

You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?
Why would I want to reduce the second pass options? That doesn't make sense to me. I use the second pass options I do because they're what I consider to be realistically the maximum I can get out of the codec without wasting time on -r 16 or whatever. The point of increasing the speed of the first pass was to avoid wasting time with encoding complexity when it doesn't significantly affect the output of the second pass with my preferred options. If I were to reduce the second pass options too I would reduce the quality of the output, which is undesirable. Am I misinterpreting what you're saying because it seems an unusual suggestion? (The second part. The first part, comparing the overall speed not just first pass, is reasonable.)

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.
Ah, cool.

EDIT: I reread the section you quoted from me and it reads like I was comparing the first pass speed to the second pass speed. I essentially was because I used the same first and second pass options in the non-turbo encode but what I actually intended was that the first pass with the turbo options I've specified are ~3 times faster than the first pass which uses settings identical (aside from -p) to my second pass settings.

Doom9

30th June 2005, 21:52

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.So it could be done after all.. :) So if we can translate the specs into x264 options I'm all game for implementing it into megui

NuPogodi

1st July 2005, 09:39

Just a stupid question about compressing black'n'white video... till now, i've found the only option ('--no-chroma-me') to accelerate reencoding b&w movies. Did i miss something? any plans to make the b&w-optimized preset which allows to ignore all croma info?

IgorC

1st July 2005, 22:16

rev270B has a EQM AVC-HR matrix. What kind of source and bitrate this matrix is for?
I'd suppose it's like Xvid EQM HR matrix. But how high bitrate? 1.5 Mbit is it enough for DVD 720X480 23.976 fps source to use this kind of matrix ? Any result?

superdump

2nd July 2005, 03:04

Sharktooth

2nd July 2005, 13:11

look at my signature. however 720x480, 23.976fps and 1500kbps should be enaugh to use it (unless the source is really noisy or have bad compressibility).
Some feedback would be really appreciated :)

zombi55

2nd July 2005, 18:24

Hi..

I have some troubles with the x264 VFW codec or the H264 ffdshow. I made a "small" encoder using the windows API functions ICopen, ICDeCompress and ICCompress. All is well but every time I want to use a x/h264 codec, the ICClose function crashes. I code using VC++ and even in debug mode I can't find a solution, I have a message [ User breakpoint at 0x..... ] in NTDLL.

Can anyone help me? (All others VFW codecs work perfectly, even VP62 and VP70)