x264 development [Archive] - Page 7

Marsu42

27th December 2005, 16:52

My intended method of realtime streaming (if I ever implement it) is: Have some list of presets at different speeds, and select between them based on how full the encoding buffer is. That would be "constant fps"; I don't plan to implement "average fps", but it wouldn't be any harder.

Constant fps should do ok for my purpose, too, but I guess when encoding a dvd through an avs script x264 is the bottleneck, so the encoding buffer would be alway full and the lowest quality options would be locked in? Therefore, it would be nice - if possible - to have this --fps switch which tells x264 when to reduce quality and gain speed as an alternative to measurement of the buffer.

akupenguin

27th December 2005, 23:34

The speed option would control how fast input frames are copied into the buffer.

mgh

28th December 2005, 07:05

The latest profiles do not have adaptive quantization?

unmei

28th December 2005, 15:13

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)

Yong

28th December 2005, 17:53

Ive noticed this problem sometime already(XviD have the same problem too)...
the video look flashy with some blockiness when it fade-out(white to black).

Here is the link for the part of x264(rev389 with AQ, subme7.. patch applied) encoded video snapshot(png):
http://rapidshare.de/files/9978648/x264-Snapshot.7z.html
i can upload the full x264 encoded if someone really need to watch it :rolleyes:
Here is the link to original source:
http://www.sp-janis.com/download/heaven_anime.mpg

Please correct me if im wrong, here is the x264 options i used:
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 1 -f -6:-6 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --b-pyramid
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 3 -r 5 -f -6:-6 -A all -m 7 -w --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --b-pyramid --me umh -8 --mixed-refs -t 2 --aq-strength 1.1 --aq-sensitivity 15 --b-rdo

Now im tring to encode with higher bitrate see the problem solved or not :p

28th December 2005, 18:04

The answer is right above your post: try --no-fast-pskip instead of AQ.

Yong

28th December 2005, 19:10

The answer is right above your post: try --no-fast-pskip instead of AQ.
Nope, the problem still persist after i removed aq options and add --no-fast-pskip. :eek:
But the flashy and blockiness reduced alot @ 600kbps :rolleyes:

28th December 2005, 19:54

Yong

28th December 2005, 21:48

You have set the deblocking parameters to very low values. That probably causes blocking at low bitrates, so it's better to try the default values (0) first.

By the way, there are also thin black borders left in your sample images. It is better to crop the borders entirely if you aim for maximal quality.

The blockiness and flashy problem still there even set loop filter alpha:beta to 6:6...

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already :)

28th December 2005, 22:25

and the source is 640x480 and the x264 encoded was cropped with .Crop(0,56,-0,-56), =640x368, no more black borders already :)
There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).

Yong

29th December 2005, 11:58

There is a 1-pixel dark line on top even if you crop with (0,64,-0,-64) so for "best" results you'll need to crop 15 lines of actual image with (0,72,-0,72).
The problems still there even i cropped the video clips with (0,72,0,-72)....
May be im not suppose to encode video clips at such low bitrate :p

foxyshadis

29th December 2005, 14:21

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.

Yong

30th December 2005, 11:04

Have you tried removing b-frames? For extremely low bitrates they're not really a good idea, and in fact, deaththesheep had a few other suggestions in his quality guide.
Just now i finished the encoding with this options:

start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 1 -A none -w -m 1 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress --no-fast-pskip
start /belownormal /b /w x264 -I 300 -i 30 -B 256 -b 0 -r 5 -f -w -m 7 --me umh -t 2 --chroma-qp-offset 2 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress --no-fast-pskip --mixed-refs
I still couldnt get rid those flashy and blocky problem...

forgot to mention, the video snapshot i uploaded all are p-frames.

Here is the link to download the splitted mkv:
http://www.geocities.com/y0ngc/heaven_anime-002.zip
(thnks for someone reminds me that MKVtoolnix have splitting function :p )

bond

30th December 2005, 11:34

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)fastpskip has been changed too, so it doesnt show the blue blocks problem anymore

redfordxx

30th December 2005, 11:43

adaptive quantisation was dropped a few revs ago.
Instead there is now something called --no-fast-pskip that supposedly fixes the same problems as AQ "once and for all" :)Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?

bond

30th December 2005, 11:48

Does it mean, that once using --no-fast-pskip option, some AQ settings couldn't add any quality at all?no, "some" AQ can still add quality, but not the AQ that has been tested till now

so to say there were two fixes for the blue blocks problem:
1) the AQ patch from haali
2) a tuned fastpskip

as solution 2) was chosen, so there is no need for 1) anymore

30th December 2005, 14:40

I tried Yong's source with the default (tuned) fastpskip, and there is annoying flicker and blocking in the end. 256 kbps is a low bitrate, so edges are not so sharp anymore, but the blocking is generally stationary and not so annoying elsewhere in the clip. The slow fade seems to trigger it.

squid_80

1st January 2006, 11:40

Does anyone have any idea how to extend x264.c to print the avisynth error when it fails to open a script? I got it to work but unfortunately it only works by compiling as c++ rather than c and I'd prefer not to do that.

redfordxx

1st January 2006, 15:38

I've been doing 1sp pass now and the power supply failed. Some precious encoding time already behind, so I continue with --seek option (with 1000 frames overlap). Then will I join the stat files. I will have to renumber the second stats file because x264 starts numbering the frames from zero again.

Wouldn't it be useful to keep original frame numbers?

BTW: Capital 'I' is the IDR frame in stats file - that's where I can join it, correct?
When on the topic already: is somewhere the stats file syntax description to find?

LigH

5th January 2006, 20:41

I have a little annoyance with Sharktooth's download link - not x264 related, more MIME/client behaviour:

When I click on the link for a download (e.g. http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe at the moment), Opera detects the file type "application/force-download" and wants to save the file as "x264-Std_r395.force-download".

Any ideas how I could convince Opera to use the submitted filename, not a constructed one? In previous versions, there was an option to toggle between "trust MIME type" and "guess by extension", but this does not exist anymore in the options dialog - and I'm not even sure if it would help here. I probably have to edit some config file instead, I'm afraid...

bob0r

5th January 2006, 21:06

Change http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r395.exe to

http://files.x264.nl/Sharktooth/x264-Std_r395.exe and it should work.

virus

5th January 2006, 21:25

@LigH:
I don't have such a problem when clicking the force.php link in your post. Opera (version 8.5-Win32) shows me type "application/force-download" as you, but when I choose "Save" the filename is simply "x264-Std_r395.exe".

Don't ask me why this happens for you, though. Maybe you can search/ask at the forums over at opera.com - maybe some mess in the config files (did you upgraded from, say, version 7 or older or is it a clean 8.x install?) or perhaps you unintentionally changed something in Tools->Preferences->Advanced tab->Downloads?

LigH

5th January 2006, 22:29

It was an update.

And I wonder what I could "mess up"... I just changed the settings from "Show download dialog" to "Save to disk" (or similar, I'm using the german language file).

But meanwhile, x264-Std_r395.exe does not exist anymore - boy, Sharktooth is fast!

http://files.x264.nl/Sharktooth/force.php?file=./x264-Std_r396A.exe

Dayvon

6th January 2006, 21:05

Just a quick note to you x264 developers and supporters.

You guys have done awesome work bringing the most cutting edge technology to the public. Keep up the great work. Loving your creations.

Dave

CEC

7th January 2006, 15:42

Is there any updated guide with all the new x264 features? The one i found in doom9 is old!

LigH

7th January 2006, 16:22

If you can read german - Selur's x264 documentations are usually quite up to date.

x264 VfW (http://www.flaskmpeg.info/board/thread.php?postid=54931) / x264 CLI (http://www.flaskmpeg.info/board/thread.php?threadid=5571)

CEC

7th January 2006, 23:03

LigH

8th January 2006, 03:04

So what is your preferred language?

And what is the CEC, a software for creating computer aided art?

DeathTheSheep

10th January 2006, 20:56

<> Bi-directional ME
<> DCT-domain NR

2 new badboys that haven't been touched upon yet ;)

and....
http://www.myfilehut.com/userfiles/5120/untitled.PNG

Piper

10th January 2006, 22:38

I just want to echo other comments of praise for those developing x264. I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final (http://www.doom9.org/codecs-final-105-1.htm#intro) and I'm astonished with what this codec is capable of. Thanks for all your continued hard work on this project!!

Marsu42

11th January 2006, 11:24

I've been playing with x264 ever since seeing the recent Codec shoot-out 2005 - final and I'm astonished with what this codec is capable of.

While being an absolutely convinced x264 user, I have to admit I don't quite understand how the ateme codec could have lost the competition because x264 shows some annoying washed blocks I have been experiencing in my own encodes, too: Take e.g. the "Scene 7: Neo faces Agent Smith" and look at the rain in middle and right of the picture. Is it just me or does the encode really look blurred? I am wondering if this is a bug or just unlucky rate control during exactly this scene?

foxyshadis

11th January 2006, 17:14

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene? Doom9 specifically says do not study captures too closely, because they don't accurately reflect how the encode fared while being watched closely. It might be a B-frame in one encode and an I in another.

It's somewhere in his faq.

Marsu42

11th January 2006, 18:22

Do you mean the capture, or did you get ahold of (or replicate) the encode of the full scene?
I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

max-holz

11th January 2006, 18:44

I just looked at the capture, but it strikingly reminded my of the phenomenon I exprerienced w/ my own encodes - sometimes, the background tends to be very blurred. Of course, It were lower bitrate encodes (~900-1000) and I might have chosen bad filter settings, but in comparison to XviD, I was still surprised. On the other hand, maybe it's due to XviD's tendency to "restore" detail as described in Doom9's test and perfectly normal behavior for any other codec.

Simply use --no-fast-pskip for me the best solution.

DarkFoon

12th January 2006, 00:13

I've experienced a wierd X264 "bug" you might say.
In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
A picture is worth a thousand words, and I have a few thousand to show, but no way to do it.

bob0r

12th January 2006, 00:23

@DarkFoon
You may send files to files@x264.nl and ill host them for you.
(Please be sure to give a link to the right forum thread also, so i know where to add a reply with the file(s), this is more a general message for others)

Edit:
BTW, paste your command line used (or screenshot of settings used in gui, if not megui (show commandline)
Also what x264 version did you use? sharktooth's? x264.nl's other?... info info info)!

DarkFoon

12th January 2006, 04:53

Well, I'm going to take those screne shots now and email them.

unfortunately, I did the projects over a month ago, and I have since forgotten the commandline. I used one of sharktooth's builds, probably around 375.
I should try to re-encode the source (I may have lost it ) with a more recent build to see if the problem is still there.

and lastly, (but not the least) Thanks bob0r for hosting these files!

omion

12th January 2006, 05:03

In animated encodes, when something moves very fast (and this is the only thing I could notice that might have an effect) a white block appears in its former place for a moment. It doesn't even do this for all fast motion parts.
I'd love to post some screen shots, but I don't know of a convenient image hosting service. (any reccomendations?)
Does it look anything like the first picture on this thread (http://forum.doom9.org/showthread.php?p=766051)? It came out right after somebody walked past the frame, and I think it may be related. For me, all of Sharktooth's builds from 379 do it, but I'm still not sure what it is.

[edit: I guess I'll find out when the screenshots are posted. I really need to read posts when I quote them...:rolleyes:]

DarkFoon

12th January 2006, 18:26

@ Omion,
yeah sorta like that, but a little different.
Here are my screenshots:
Example 1 - Frame 1 (http://files.x264.nl/DarkFoon/example1-1.png)
Example 1 - Frame 2 (http://files.x264.nl/DarkFoon/example1-2.png)
Example 1 - Frame 3 (http://files.x264.nl/DarkFoon/example1-3.png)

Example 2 - Frame 1 (http://files.x264.nl/DarkFoon/example2-1.png)
Example 2 - Frame 2 (http://files.x264.nl/DarkFoon/example2-2.png)
Example 2 - Frame 3 (http://files.x264.nl/DarkFoon/example2-3.png)

In example 2, that half of the frame is supposed to be white (its a camera 'flash') the bad part is the little black block in the top left of that white area.

Example 1, his hand was next to his head, and then he moved it quickly away, and well, you can see the picture.

These screenshots aren't superb, and I apologize for that. Directshowsource() doesn't really allow frame-accurate seeking. and VLC player doesn't pause when I tell it to.

@Omion (again)
The only time I saw that effect as bad as those images you showed me was when I used FFDshow's X264 almost a year ago to encode a test clip, and all motion in that clip had that effect.

lspbeyond

13th January 2006, 12:55

CREXbzh

13th January 2006, 13:02

However, how about your opinions in developing own decoder in x264 project?

I think patches to improve/fix the decoder will certainly be considered for inclusion; however, don't expect too much enthousiasm to help you as the code team of x264 already maintains part of ffmpeg h264 decoder, and probably doesn't feel like duplicating efforts (to work on x264 own decoder).

bond

13th January 2006, 13:53

hi, everybody, I have a question about x264 decoder.
I know ffmpeg-libavcodec is the first choice in decoding x264 streams currently and it works well. However, how about your opinions in developing own decoder in x264 project?man, its time for you to :search:

1) the question about the x264 decoder is as old as x264 itself. basically one point of an open standard, like avc, is that you can use any avc decoder you want for decoding an avc stream. this means there is absolutely no need for a x264 decoder
2) the fastest decoder supporting as good as all available avc features and still being freely available is coreavc (http://forum.doom9.org/showthread.php?t=104277)

lspbeyond

13th January 2006, 16:46

Thanks CREXbzh and bond, I have learned very more.
But I also have three different opinions?
1. we know encoder include the reconstruction loop, it has already implemented mostly part of decoder, expect stream parsing and entropy decoding . So I think develop decoder in x264 project is not a hard work.
2. The decoder can share the improvement of x264 encoder directly, e.g. the mc function, dct, deblock ... are all common.
3. If somebody have been familar with x264 encoder, they can learn the decoder part quickly. IMO, if x264 has more things be needed to do, then there will be more people join in developing it.

akupenguin

13th January 2006, 17:58

1. Reconstruction != construction. While it would be mostly cut-and-paste, it's not as simple as calling the existing code.
2. The optimal way of coding mc and deblock are not the same between encoder and decoder.
3. Do I hear you volunteering?

lspbeyond

14th January 2006, 06:11

to akupenguin, thank u
1. I don't think so. I think the mc, deblock and etc functions can called without any modification.
2. I am interesting in this point very much. If you can tell me in detail, I will appreciate of you. Thank u very much.
3. Though I'm a fresh man in video coding area, if I can do my little contribution to x264 project, I will.

akupenguin

14th January 2006, 07:08

I'll describe mc, because it's the most different:

x264 has one function that performs all 3 halfpel interpolations on the whole frame (note that the computation of the center halfpel includes one of the other positions, so we get one for free). Thus we have 4 versions of the luma plane. We also mc enough pixels past the edge of the frame to deal with unlimited mvs, and a bit more to simplify motion estimation.
Thereafter, any fullpel or halfpel-aligned mv can be retrieved with only pointer math, no pixel operations. And the remaining qpel mvs require just a PAVGB operation. Since the encoder tests many mvs, this is a big win.

But when decoding, that would be slow. Each pixel only involves 1 mv (or up to 2 in B-frames), and it's quite often the 0,0 mv that doesn't need any interpolation, and then there's intra... So we don't want to compute all 3 halfpels everywhere. Furthermore, we'd need to not only break even in terms of pixel operations, but get over the fact that the extra planes increase cache pressure.
So the optimal mc method for decoding is to have functions which do halfpel and qpel mc just on one block, for each of the 7 block sizes.
And (I haven't benchmarked this, but michaelni says so) instead of padding the edges of the frames enough to account for all concievable mvs, it's better to pad only a little bit, and then copy the rest of the pixels on demand.

--
If you are interested in writing the decoder, I would be happy to answer any technical questions you have. (well, I answer stuff anyway, but potential contributors get first pick.)

lspbeyond

14th January 2006, 11:02

very good.
I have thought of this problem of mc.
And I have bethought of the method that interpolating the pixels when used. But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.

ps: I used intel vtune analysing the t264 decoder, and I found the memset function cost a big proportion. I know mostly video encoder or decoder program have used this function frequently, is there any faster fuction can instead of it?

Manao

14th January 2006, 13:23

But I am uncertain if the overlap case (i mean the repeated interpolation of a pixel) is frequent or not.On the encoder side - definitely. A rough guesstimate of the number of subpel positions analysed would be around 20 per macroblock. On these interpolated positions, qpel are computed using 2 hpels, and represents ~12 ( second guesstimate ). So in the end, for each macroblocks, you end up doing 8 + 12 + 12 hpel interpolations. So it's definitely worth it to do it once and for all, especially if you think that a reference frame may serve more than once ( bframes, multiref ).

On the decoder side - definitely not, since 1 macroblock = 1 or 2 hpel interpolations at most, so doing the 3 hpels for the whole picture make you lose time ( not speaking of the cache miss increase ).

Selur

15th January 2006, 12:03

dump,.. asked this before but nobody answered:
What are the min/max values for aq-sensitivity and aq-strength ?

Cu Selur

dimzon

25th January 2006, 17:30

to all x264 developers:
please take look at this post:
http://forum.doom9.org/showthread.php?p=774869#post774869

Thanx!

Manao

25th January 2006, 19:31

x264 opens avs scripts through the vfw interface, so it doesn't work.

dimzon

25th January 2006, 19:33

x264 opens avs scripts through the vfw interface, so it doesn't work.
ok, thanx!

Isochroma

25th January 2006, 21:41

Is it possible for x264 to support encoding to 4:2:2 (YUY2) & 4:4:4 colorspaces? I know it's probably impossible to do RGB24, but some research this morning turned up support for the above two colorspaces in High profile extended fidelity extensions. Since x264 already supports at least one of the extensions (lossless), perhaps it could support more?

akupenguin

25th January 2006, 22:41

What makes you think RGB is any less possible than 4:4:4 ?

Isochroma

25th January 2006, 23:26

You may be correct (see below). Previously, I had assumed RGB wasn't supportable in any MPEG-4 standard because both 4:4:4 and 4:2:2 are mentioned as supported in the High profile extended fidelity extensions, but no RGB is ever mentioned for any MPEG stream - at least, I'd never heard of such a thing. Also, MPEG-2 supports 4:4:4 in High Profile.

From http://en.wikipedia.org/wiki/H.264:

"The JVT recently completed the development of some extensions to the original standard that are known as the Fidelity Range Extensions (FRExt). These extensions support higher-fidelity video coding by supporting increased sample accuracy (including 10-bit and 12-bit coding) and higher-resolution color information (including sampling structures known as YUV 4:2:2 and YUV 4:4:4). Several other features are also included in the Fidelity Range Extensions project (such as adaptive switching between 4×4 and 8×8 integer transforms, encoder-specified perceptual-based quantization weighting matrices, efficient inter-picture lossless coding, support of additional color spaces, and a residual color transform)."

foxyshadis

26th January 2006, 02:29

Dizmon is requesting input colorspace conversion, though, not direct storage of RGB or YUY2. :p

Isochroma

26th January 2006, 03:24

There's more than one way to cut a pie... x264 having more colorspace modes would solve his problem and simultaneously help preserve the quality of video much better than it currently can be - also giving it a significant advantage over other YV12-limited AVC and ASP codecs. I think that with the advanced compression capabilities of h.264 in general, and this implementation in particular, the extra input data should be of little concern.

The opportunities for very 'cheap' quality improvement and the widening of x264's scope to include professional archiving requirements (as has already been started by the introduction of one FREXT - lossless mode) should not be overlooked. Even 4:2:2 provides much better color sampling than 4:2:0 (I can see the chroma blocking due to YV12 between source and encoded frames with lossless mode).

I see at least the YUV 4:4:4 and 4:2:2 modes as mere extensions of the direction x264 is already moving in, and probably easy to implement. It seems RGB might be more difficult due to the different way colors are represented.

Also, the differences between 4:4:4 and RGB are bound to be almost indiscernably small (if any) so RGB support should probably be on the back-burner while YUY might be a higher priority.

Manao

26th January 2006, 06:44

Isochroma : most people only handle 4:2:0 material, so there's little use right now for support of the other colorspaces ( that falls into the scope "you need it, you code it" ).

Isochroma

26th January 2006, 08:15

They may start with 4:2:0 material, but many avisynth filters output yuy2 and some even rgb data. Having to downsample the chroma after processing is a disadvantage for certain. For example, I'm using two denoisers in sequence (fft3d and neat image) to process video. FFT3d gets fed YUY2 data from a resizer earlier in the filterchain, and outputs the same (I think). Neat Image takes the output (converted to RGB24 by the Imagewriter() plugin) and produces really nice 48-bit TIFFs which then get downsampled to 24-bit PNGs by Irfanview thru commandline interface. Chroma blocking is easily distinguished on output frames compressed in YV12 from the original, even losslessly.

In industry, 4:2:2 is considered just barely good enough for pro work, and 4:1:1 and 4:2:0 are used as capture and output only, respectively. DV50 is certainly superior to DV25, especially for multigeneration work. Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!

It is my hope that all filters and codecs which only run in YUV colorspace will support 4:4:4, or at least 4:2:2, someday. When a complete non-downsampled path exists from source to finished product, these tools will be considered to have reached the pinnacle of their capabilities.

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflow. In output compressors, (excluding lossless edit & storage types) the commercial products seem to include only 4:2:0, excepting Windows Media 9, which can do all of them (!). It seems a fertile field for independent innovators to make inroads...

Manao

26th January 2006, 09:08

Starting from a 4:2:0 video and wanting to encode it in 4:4:4 is dumb ( except if you use a filter that properly interpolate chroma, which you don't, since there's none ). If your input is really 4:4:4, it's another matter, but unless you're doing CGI animation, it won't be 4:4:4

It will give professionals in NLE studios and others in industry even more reasons to incorporate the great works of open-source and free development into their workflowNot at all. They'll never use x264, because they'll never go the open source way.

Episodio1

26th January 2006, 10:13

SW: III and SIN CITY were filmed with Sony HDC-F950 and HDC-950 respectively (4:4:4)
http://us.imdb.com/title/tt0121766/technical

I guess Sin City doesnt take advantage at all, as it is B&W and heavy filtered. xD

Manao

26th January 2006, 10:26

I doubt you have access to the 4:4:4 material for these movies anyway :p

You only have access to the DVDs ( 4:2:0 ), and HDTV ( 4:2:0, perhaps 4:2:2 sometimes, but I doubt it )

Wilbert

26th January 2006, 11:15

Also, it seems likely that avisynth 3.0 will support 4:4:4, which will give users yet another path to a better product; it may even support >8-bit per channel color!
Many filters in avs v2.60 are already working in YUV 4:4:4 (8 bit) :)

Raptus

26th January 2006, 17:19

It seems CLI x264 is less anal with levels than MeGUI is. For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?

On a sidenote, I'd appreciate if someone had a link to a detailed list of the different AVC level constraints. (I can't find the damn h.264 doc where they supposedly are specified in Appendix A. Best I dug up so far was: http://www.cdt.luth.se/~peppar/kurs/smd151/spie04-h264OverviewPaper.pdf )

CruNcher

26th January 2006, 17:29

Raptus also my problem with level 4 reading the level specs shows it should be fine so i force it on cmd no problem just lets wait for Standalones then we'll see whats correct :P

Doom9

26th January 2006, 17:31

For instance, while MeGUI won't let me use level 3 together with P4x4 x264 doesn't even issue a warning. Oversight or feature? In such cases where contradictory params are used, will x264 enforce or ignore levels?The level tag only flags the level in the resulting stream.. it does not actually limit the encoder to a certain level.

As far as the level constraints go, they are in this very forum.. I don't recall thread urls by heart but I know they're there since it's what I used to enforce levels in MeGUI (along with aku's help.. the P4x4 limitation was added after he suggested that it was required).

Kostarum Rex Persia

11th February 2006, 01:48

New build came out, data is below:

r429 | pengvado | 2006-02-10 22:58:43 +0100 (Fri, 10 Feb 2006) | 3 lines
Changed paths:
M /trunk/Makefile
M /trunk/common/amd64/predict-a.asm
D /trunk/common/amd64/predict.c
M /trunk/common/i386/predict-a.asm
M /trunk/common/i386/predict.c

amd64 mmx for some intra pred functions

So, I suppose that amd64 mmx predictions will speed-up encoding on Athlon 64 based computers, am I right. Sorry if I don't understand this very well, but I am not a programmer.

Can x264 32-bit version, now work without problems on Windows XP 64-bit edition?

bob0r

12th February 2006, 00:31

Kostarum Rex Persia will be happy:

VFW updated:
r430(and r431)
VfW: support trellis, brdo, nr, bime.
patch by Dan Nelson (dnelson at allantgroup dot com).

So About the missing option in the x264 VfW (http://forum.doom9.org/showthread.php?t=105899) can be updated , not in VFW:

- Constant quality mode
- Fast P-Skip
- Custom quantization matrices
- Buffer control
- Zones
- AQ (only available in Sharktooth's build, not an official x264 feature at this point)

LoRd_MuldeR

12th February 2006, 01:29

Kostarum Rex Persia

12th February 2006, 01:29

Wow, thanks. Great news, bob0r.

celtic_druid

12th February 2006, 02:06

I actually added those features to the build I included with my FairUse Wizard compile back in Dec or whenever.

I was just waiting to see if anyone would notice...

LoRd_MuldeR

12th February 2006, 02:14

Noticed a small bug with the new VFW settings:

If I check "Bidirectional ME" and klick "OK" and later go back to the config window, then "Bidirectional ME" is unckeckd. So it seems not to remember this setting. I got no idea if "Bidirectional ME" is enabled when I check it, click OK and don't go back to the config window before encoding. At least someone should take a look at this issue...

Kostarum Rex Persia

12th February 2006, 03:49

Yes, and I noticed that bug. I think that if "Bidirectional ME" is enabled when I check it, it's disabled when I start encoding, because encoding speed is same with or without checking Bidirectional ME. And we know that "Bidirectional ME" slowdown encoding speed.

And Trellis Quantization is only "on the Final MB", not on value "Always".

LoRd_MuldeR

12th February 2006, 05:27

And Trellis Quantization is only "on the Final MB", not on value "Always".

Is that a probelm?

The x264.nl notes say:
not in vfw: Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip)

Is there hope we'll get this soon?

bob0r

12th February 2006, 06:04

The Bidirectional ME and Max Ref. frames(try backspace and enter 2, its kinds fucked... or was) bugs are found and fixed, only have to be submitted.

@celtic_druid

^^ And your what? url?

But why not submit to x264 SVN? :)

bob0r

12th February 2006, 06:13

And Trellis Quantization is only "on the Final MB", not on value "Always".

Trellis 1 = recommended value. (So no thats not a problem or bug)

For EXTREME settings use x264.exe (with megui.exe if you will), then you can max out everything.

VFW must be simple and easy to use.

@all

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

Do you guys think this will be a good layout for Tab More... ?
http://files.x264.nl/x264_vfw_tab_more.jpg

akupenguin

12th February 2006, 07:21

maybe vertically align the checkboxes (chroma/pskip/mixed and cabac/trellis/deblock)

SeeMoreDigital

12th February 2006, 11:45

I think "Sample AR" boxes need to be wide enough to accommodate/display "three" numbers in each box.

Cheers

bob0r

12th February 2006, 13:59

Something like:
http://files.x264.nl/x264_vfw_tab_more_3.jpg

Btw, 4 more boxes are buggy with pressing backspace and adding new values.
Reported and confirmed, hopefully last submit about these issues soon, i should have tested some more :o

r434 buggy are:
VFW - Rate Control TAB: MIN QP
VFW - Rate Control TAB: MAX QP
VFW - Rate Control TAB: MAX QP Step
VFW - More... TAB: Threads

@SeeMoreDigital
I was too tired i forgot to press submit, so your idea is not in this concept :)

LoRd_MuldeR

12th February 2006, 14:12

Hopefully Quality-based VBR (--crf *), Fast P-Skip (--no-fast-pskip) will be added to VFW shortly, Fast P-Skip is very easy, Quality-based VBR will take a bit longer.

Hopefully Dan will make us happy soon! (or at least bond)

I'm looking forward :D

LoRd_MuldeR

12th February 2006, 16:47

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....

12th February 2006, 17:02

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
I had a strange blocking problem (http://forum.doom9.org/showthread.php?p=773296#post773296) with it at all settings, with larger values (over 100) causing significant problems in some scenes. It could be just something in my systems because there were no other similar reports. I haven't tried x264 noise reduction since those tests, so it could be fixed now, if there ever was a bug. If you are using it for anything important, watch the result through to make sure there are no strange artifacts.

As for the values, I wouldn't recommend going over 500 for normal DVD sources. At high values --nr will introduce smaller 4x4 blocks all over the image as can be seen here (http://forum.doom9.org/showthread.php?p=773241#post773241).

Kostarum Rex Persia

12th February 2006, 17:11

Bob0r, can you include sub me 7 in your future builds, like Shark tooth in revision 408? And, or course, let us to choose between Trellis quantization values, "On The Final MB" or "Always" value.

shon3i

12th February 2006, 17:27

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

LoRd_MuldeR

12th February 2006, 17:51

And CQM, is there any option to add decoding function in vfw like xvid, so we can manipulate with x264 files in virtualdub.

You can use ffdshow to open x264 videos in VirtualDub. Of course they need to be in AVI. All you have to do is, enable H.264 support in ffdshow's VFW configuration. Or isn't that what you need?

AFAIK x264 (VFW and CLI) is for encoding only and does not include any kind of decoder.

Kostarum Rex Persia

12th February 2006, 18:17

I think that shon3i don't think on that, he has something else in mind. Shron3i, please explain in details your idea.

shon3i

12th February 2006, 18:25

is for encoding only and does not include any kind of decoder. I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

LoRd_MuldeR

12th February 2006, 18:28

I know that but xvidwfv can be a decoder. So i think why can be x264vfw has own decoder

Because it is not needed. ffdshow is x264's decoder...

I think there is a decoder on the x264 CVS, but it has not been developed any further. Last change was 1 year ago. If I remember correctly, sombody said the decoder doesn't even compile...

shon3i

12th February 2006, 18:32

Ok but you want open x264 avi file i virtual dub to split there is error message.

Kostarum Rex Persia

12th February 2006, 18:45

Correct, VirtualDub always show error message when I try to open x264 encoded AVI file. Error message:

"Couldn't locate decompressor for format H264(unknown). VirtualDub requires a Video for Windows(VFW)compatible codec to decompress video. Directshow codecs, such as those used by Windows Media Player, are not suitable".

But I installed ffdshow from december and put ffdshow plug-in in VirtualDub folder.

LoRd_MuldeR

12th February 2006, 18:46

Ok but you want open x264 avi file i virtual dub to split there is error message.

What is the error message ???
I think you are just missing a VFW decoder that supports H.264

Do you have an up-to-date build of ffdshow installed? If not so, you'll have to do this!
And after ffdshow is installed, go to START -> Programs -> "ffdshow" -> "VFW codec configuration" and enable "H.264" on the Decoder tab (you need to change value from "disabled" to "libavcodec")
This will work :)

BTW: The "ffvdub" plugin is needed to use the ffdshow video-filters in VirtualDub, it is *not* required for the decoding!

Kurtnoise

12th February 2006, 20:26

What values are aviable (recommended) for new "Noise Reduction" setting in VFW interface? Seems like I can choose any value from 0 to 999999....
.....zzz

LoRd_MuldeR

12th February 2006, 20:57

With the cli, min=0/max=16...

Now I'm confused :scared:

You say the Noise Reduction value should be between 0 and 16.
Other people talk about values of 100 or even much higher...

So, what is correct ???

Kurtnoise

13th February 2006, 03:52

Sorry,...I was confused by the << and <>.

LoRd_MuldeR

13th February 2006, 03:57

Sorry,...I was confused by the << and <>.

So this means I should look for a good setting in there range of 0 to about 100, correct?

celtic_druid

13th February 2006, 03:58

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

LoRd_MuldeR

13th February 2006, 04:00

Well mencoder uses 0, 100,000 but yes x264 does appear to use 0, 1<<16.

:eek: :confused:

And what does the x264 VFW inrerface use?

celtic_druid

13th February 2006, 04:02

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

LoRd_MuldeR

13th February 2006, 04:08

It doesn't use anything. There is no limit, although that doesn't mean that you can really use a value of 56487897897984948949889489879878998. It is just that it will let you enter it.

Arrrghhh, please be a little more patient with me :(

I already noticed that it lets my enter whatever I want to. But what values are actually supported and do make sens?
Is the range where I can find a "good" setting only between 0 and 16 or can/should I go much higher, like 100 and even above? I still don't got that...

:thanks:

foxyshadis

13th February 2006, 05:03

It means the range is 0-65535. I have no idea if anything over 1000 actually does anything, that's the highest I've tried.

Koti

13th February 2006, 05:13

Ok but you want open x264 avi file i virtual dub to split there is error message.

Correct, VirtualDub always show error message when I try to open x264 encoded AVI file. Error message:

"Couldn't locate decompressor for format H264(unknown). VirtualDub requires a Video for Windows(VFW)compatible codec to decompress video. Directshow codecs, such as those used by Windows Media Player, are not suitable".

http://forum.doom9.org/showthread.php?t=93572 <---- April 2005 :search:

celtic_druid

13th February 2006, 05:15

Actually I think you can go about as high as you want although really high values (30,000) would look like crap and if you go too high, then you end up back at 0. 250 or so is probably about as high as you would want to go. Guess it would depend on the source and bitrate though. A value of 250 will result in a lower size per quant than 0, so if the bitrate is low enough, then I guess a high value might pay off.

shon3i

13th February 2006, 12:42

Do you have an up-to-date build of ffdshow installed? If not so, you'll have to do this!
And after ffdshow is installed, go to START -> Programs -> "ffdshow" -> "VFW codec configuration" and enable "H.264" on the Decoder tab (you need to change value from "disabled" to "libavcodec")
This will work OK this work. I dont see this options before. btw on my machine have trouble with ffdshow. i used last build on x264.nl and try other builds but same problem in something memory leak. have someone other vfw decoder.

LoRd_MuldeR

13th February 2006, 16:38

OK this work. I dont see this options before. btw on my machine have trouble with ffdshow. i used last build on x264.nl and try other builds but same problem in something memory leak. have someone other vfw decoder.

I think ffdshow is what you will have to use, if you need to decode x264 content via VFW. One other way I can think of is this: Open the file with AviSynth and then frameserve it to VirtualDub. But then you still would need a decoder - ffdshow. Maybe the official "daily build" works better for you...

bob0r

13th February 2006, 16:42

I actually added those features to the build I included with my FairUse Wizard compile back in Dec or whenever.

I was just waiting to see if anyone would notice...

Where can this be downloaded, and why not add to x264 SVN? :)

celtic_druid

13th February 2006, 17:06

http://mirror05.x264.nl/celtic_druid/force.php?file=././fu2.2-setup.exe

Whenever I have done a FU build, I have updated all tools, codecs, etc. and since it includes x264vfw I added a few options to make it more uptodate.

Since I didn't want to encourage VfW use, I stopped uploading VfW builds some time back. Like I said, I was waiting to see if anyone would actually notice.

bob0r

13th February 2006, 17:11

Ahhhh no wonder, i never added you to files.x264.nl :D
Ill fix you an account on there later, mirror05 should only be used if files breaks down.

Hehehe, totally forgot about that path :p

Kostarum Rex Persia

13th February 2006, 17:19

celtic_druid, do you planning to compile your new build, based on recent builds from pengvado, with your new settings and stuff?

You have no excuse now, because bob0r will create a account for you on files.x264.nl:D

[edit] I just visited files.x264.nl, and I saw ready vfw patch for fast-p-skip( http://files.x264.nl/force.php?file=./x264_vfw_fast_pskip.diff ) But what about no-fast-p-skip patch?

ChronoCross

13th February 2006, 17:23

damnit C_D. don't update the vfw -_-. cause now we are gonna have about 100000000000 new threads figuring out problems with vfw and why it's output is damaged. which would be fine if it were the cli cause then it would be a big problem but now we have to waste time trying to figure out if these issues are just vfw or if it's cli.

I'm just kidding at you C_D it's fine I just hope people realize how stupid AVC in avi is. Kostarum Rex Persia however won't so I look forward to more annoying "when is this feature going to be implemented" threads.

celtic_druid

13th February 2006, 17:29

I think mirror05 has a nicer ring to it anyway. Next time I do a FU build, I will once again make sure that all included tools, codecs, etc. are upto date. Other than that I don't think I will be updating or releasing x264vfw builds.

My cli build is at revision 434 and r435 was just cosmetics.

Those who want AVC in avi can always use mencoder.

Edit: Looks like the FU source got updated Sunday, 12 February.
Edit2: Zip is still the same. Don't know why the date as changed.

Kostarum Rex Persia

13th February 2006, 17:38

I'm just kidding at you C_D it's fine I just hope people realize how stupid AVC in avi is. Kostarum Rex Persia however won't so I look forward to more annoying "when is this feature going to be implemented" threads.

Well, if you wanna to insult me, fine. Before that, I suggest to, once again, read forum rules, rule number 4. I never want to insult you, so I, certainly, never expect something like that from you, ChronoCross.

Sirber

13th February 2006, 18:08

Well, if you wanna to insult me, fine. Before that, I suggest to, once again, read forum rules, rule number 4. I never want to insult you, so I, certainly, never expect something like that from you, ChronoCross.It's not an insult, it's a guess on your next move ;)

ChronoCross

13th February 2006, 18:15

It's not an insult, it's a guess on your next move ;)

exactly. if I wanted to insult you I would have done so. plus it wasn't just aimed at you I just happened to have used you as an example since your the leader of the we need vfw movement.

bob0r

13th February 2006, 20:15

I think if x264 developers allow VFW, when it does not create bugs outside VFW, and pengvado allows it obviously, then i see no problem in developing, testing and posting about VFW.
If people want it, why not?

A seperate x264-vfw-development thread ofcourse would prefered, so VFW haters don't have to read it, and requests/bugs/questions can be placed without starting a flame war each time.

MeGUI style threads would be recommended (bug/feature requests/help-manual-questions).

But only if x264-VFW is being seriously developed.

Celtric_druid certainly has the skills to develope VFW, but has no time or is not motivated to do so.

Sharktooh also has the skills, but he can't figure out if he's a girl or a boy (no seriously, health problems prevent him from being active on any level)

Dan "Genesys" Nelson can update certain options also, but to quote him:
"whatever features translate into checkboxes or other simple UI objects, I can do :)"

So, motivation by both user and developer is key issue here, i like VFW, i bug test it and share my thoughts on it, but x264.exe (+ a gui if you must) is simply perfect, each option explained and clear.

Its true any gui(or vfw) can indeed bind options, like mixed-refs can only be used when you have 2 or more reference frames, this makes you learn the options better, for the best result.

One-Click tools will come/are available anyway, so or you just use a program as is, or you fully try to understand its options and make the best of it.

Kostarum Rex Persia

13th February 2006, 20:17

Well, ok then, ChronoCross. I am not a leader, and other peoples wanted and asked for updating vfw, not just I. For example, DeathTheSheep.

Kostarum Rex Persia

13th February 2006, 20:22

SeeMoreDigital

13th February 2006, 20:30

That's wonderful idea, bob0r. Let create separate x264-vfw-development thread. Of course, like MeGUI, and vfw would get thread " Feature requests ", " x264 vfw bug reporting ".

Doom9, what do you think about bob0r suggestion?It sounds quite sensible to me!

Sirber

13th February 2006, 20:31

Well, ok then, ChronoCross. I am not a leader, and other peoples wanted and asked for updating vfw, not just I. For example, DeathTheSheep.The only one beside you ;)

Kostarum Rex Persia

13th February 2006, 20:36

Well, they are hiding. vfw respecters are quite numerous here, but most of them don't talk about it.

LoRd_MuldeR

13th February 2006, 20:48

Well, they are hiding. vfw respecters are quite numerous here, but most of them don't talk about it.

I'm here too :D

shon3i

13th February 2006, 20:58

I think ffdshow is what you will have to use, if you need to decode x264 content via VFW. One other way I can think of is this: Open the file with AviSynth and then frameserve it to VirtualDub. But then you still would need a decoder - ffdshow. Maybe the official "daily build" works better for you...And what is hapen if i won't recompress video. I tell you that i can using ffdshow beacouse is not working in some reason. I can open any file in virtualdub via avisynth but i must recompress video.

Let create separate x264-vfw-development thread That was be cool

LoRd_MuldeR

13th February 2006, 21:06

That's wonderful idea, bob0r. Let create separate x264-vfw-development thread.

They will close and delete it one minute after it is created :(

Sirber

13th February 2006, 21:06

They will close and delete it one minute after it is created :(For your own good ;)

LoRd_MuldeR

13th February 2006, 21:07

And what is hapen if i won't recompress video. I tell you that i can using ffdshow beacouse is not working in some reason. I can open any file in virtualdub via avisynth but i must recompress video.

I think you'll have to get ffdshow working.
What exactly is the problem? And what builds did you test so far?
Did you try a clean(!) re-install of the official "daily build" ???

valipod

13th February 2006, 21:12

I searched the entire MPEG-4 AVC forum for keyword 29.970 and then only for 29, nothing. I figure there must be a bug in the search, nevertheless I didn't find a post regarding my problem.

I have a movie 29.970 FPS, I open the AVS (in VirtualDubMod), it shows 29.970 FPS. I encode it with MeGui x264, and the resulted .264 i convert to AVI with the x264 AVC2AVI embedded in the x264 Full Package. The problem is, the resulted AVI is 25 FPS!!! And 20% longer (seconds), of course. I am of course missing something here, but what?

The same AVS encoded via VfW in VirtualDub produces a correct 29.970 FPS AVI.

LoRd_MuldeR

13th February 2006, 21:14

shon3i

13th February 2006, 21:21

I think you'll have to get ffdshow working. I can menage this beacouse my windows is crasheed and i have no time to reinstall it. So i using lastest build from x264.nl i think is 21/12/2005 gcc sse i olso tried some build from free-codecs.com but nothing hapen.

valipod

13th February 2006, 21:26

Can't you change the Framerate of the AVI in VirtualDub and set it to the correct value? Just use direct-stream-copy for audio and video.

Well, I did that now, and it works (thanks). But let's call this a "workaround". Is this a bug in the CLI or in the AVC2AVI converter?

LoRd_MuldeR

13th February 2006, 21:27

I can menage this beacouse my windows is crasheed and i have no time to reinstall it. So i using lastest build from x264.nl i think is 21/12/2005 gcc sse i olso tried some build from free-codecs.com but nothing hapen.

Give this one a try:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

shon3i

13th February 2006, 21:37

Give this one a try:
http://ffdshow.sourceforge.net/tikiw...etting+ffdshowI try later thanks for all help

valipod

13th February 2006, 21:45

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.

Dayvon

13th February 2006, 21:48

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.
It probably is AVC2AVI because MP4 files default to 25 fps unless label otherwise. Are you rendering to a RAW .264 stream? Because if you are rendering to MP4, you more than most likely will have this problem.

shon3i

13th February 2006, 21:57

Is there a way I could find out what framerate the intermediate .264 file is? Because I am pretty sure the bug is in the AVC2AVI converter.
You must use avc2avi comandline and add -f or -fs switch i dont now at the moment use avc2avi -h for help
ex. myfile.264 -f 25 myfile.avi

valipod

13th February 2006, 22:01

It probably is AVC2AVI because MP4 files default to 25 fps unless label otherwise. Are you rendering to a RAW .264 stream? Because if you are rendering to MP4, you more than most likely will have this problem.

I created a RAW .264 stream from a 29.97 FPS AVS. And I converted the RAW .264 to avi, where I could observe the 25 FPS.

I tried now the AVC2AVI -h, it says there it defaults to 25 FPS. Still, since the source is 29.97, it should keep that, not expect a parameter from me, or default to something else. Or is there no FPS information in the .264 RAW stream?

shon3i

13th February 2006, 22:02

I created a RAW .264 stream from a 29.97 FPS AVS. And I converted the RAW .264 to avi, where I could observe the 25 FPS.
Look my uper post but here is example for you avc2avi myfile.264 -fs 29.976 myfile.avi

SeeMoreDigital

13th February 2006, 22:06

Is there a GUI for avc2avi.exe?

valipod

13th February 2006, 22:07

Look my uper post but here is example for you avc2avi myfile.264 -fs 29.976 myfile.avi.

I figured out the sintax, even if there is no avc2avi /? (and -h instead :)) The issue now was only to discover where bug is, in the CLI or in the AVC2AVI. I tend to think is the AVC2AVI, with that defaulting to 25FPS. And again, is there no FPS information in the RAW .264 stream?

valipod

13th February 2006, 22:13

Is there a GUI for avc2avi.exe?

:) There is AVC2AVI_GUI from the x264 full package, which offers the smallest of functionalty, that is "browse for input" and "Mux".

shon3i

13th February 2006, 22:16

And again, is there no FPS information in the RAW .264 stream?I know that but if you want convert .264->AVI default fps from avc2avi.exe is 25, using -fs or -f switch you can corect that. You can't use avc2avi gui beacouse there is not option to change fps. Use run and type cmd, then go to dir where is located avc2avi.exe not gui exe. type avc2avi.exe you should be get all switches. I have avc2avi.exe from lastest sharktooth build 408.

valipod

13th February 2006, 22:23

I know that but if you want convert .264->AVI default fps from avc2avi.exe is 25, using -fs or -f switch you can corect that. You can't use avc2avi gui beacouse there is not option to change fps. Use run and type cmd, then go to dir where is located avc2avi.exe not gui exe. type avc2avi.exe you should be get all switches. I have avc2avi.exe from lastest sharktooth build 408.

Actually I was asking. Is there no FPS information in the raw .264 stream? It seems like it isn't.

I have always tried the /? switch whenever I needed help from a commandline exe. Didn't work here. So I figured there's no help offered. I have now tried the -h switch (mentioned here a few posts up) and I got the options. Thanx.

akupenguin

13th February 2006, 22:51

Actually I was asking. Is there no FPS information in the raw .264 stream? It seems like it isn't.
There is. avc2avi just ignores it.

fuxor123

14th February 2006, 02:13

I encoded some transport streams lately on hte hg-slow settings with megui and couple of times there's some pixelation while a scene changes in the encoded file. The bitrate I used was around 4200kbs. It didn't seem to matter though if it was in a fast or slow moving part of the movie. Just from times to times in a scene change.
Is there any chance of avoiding such an effect in future encodings?

Kostarum Rex Persia

14th February 2006, 02:18

OK, guys, raw streams aren't my field, so...

Let's get back on introduce separate threads about VFW development, like Bobrow suggested earlier yesterday on page 82, I think.

Doom9, you didn't answer me anything about new threads. What do you think about opening separate VFW threads, " X VFW development", " X VFW error reporting ", and " X feature requests " ?

Can Bob0r or someone else start these threads, please? :)

asdfsauce

14th February 2006, 06:12

Profiles for VFW would be nice. :scared:

ChronoCross

14th February 2006, 07:38

As you can see I have made two new topics for you vfw people. Don't make a development thread because it's not needed. The development can be done in the feature request thread as that's probably where the updates on developer progress will go.

For you cli people eager for a new custom build I have made the following

Custom x264 Builds with patches. (http://chronocrossdev.com/apps/x264)

I updated sharktooths patches...well all except the one with vfw in the title of the .diff. I also removed the Signature.diff vfw changes. If you encounter any problems let me know and I'll see if I can narrow it down.

Sharktooth

14th February 2006, 11:19

Is there a GUI for avc2avi.exe?
http://files.x264.nl/Sharktooth/utils/avc2avi_rev267+gui.7z
requires .NET 2.0, it muxes the file in the same dir as source and uses the same filename (except the extension that will be .avi).
just let me know if you need more functionalities (well there isnt much to do but...) and i will add them when i will be able to re-start coding.
i was thinking to add fps, batch muxing and maybe splitting (but it requires another prog).

SeeMoreDigital

14th February 2006, 12:21

http://files.x264.nl/force.php?file=./Sharktooth/utils/avc2avi_rev267+gui.7z
requires .NET 2.0, it muxes the file in the same dir as source and uses the same filename (except the extension that will be .avi).
just let me know if you need more functionalities (well there isnt much to do but...) and i will add them when i will be able to re-start coding.
i was thinking to add fps, batch muxing and maybe splitting (but it requires another prog).Thanks Sharktooth,

I downloaded the x264 Standard R408 package yesterday :D

I wanted to see how well it worked muxing raw ".h264" streams that had been extracted using YAMB.

The thing I noticed straight away is that the ".h264" file extension is not listed, only the ".264" file extension... Although the muxing worked fine :)

Support for specifying the required FPS would be the most useful implementation at the moment, I think.

Hope you start feeling a little better soon.... Speaking as somebody who was forced into giving up full-time work due to a chronic illness (and had to re-build my immune system from scratch), I sympathise with you....

Cheers

Doom9

14th February 2006, 12:32

It's not really an x264 development issue but it's rather technical: Recently, a number of megui users ran into x264.exe aborting the first pass without notice, and then the the second pass would abort immediately with a message about a mismatch of number of frames between the source and the statsfile. However, megui never gets those error messages. Even though I redirect both stdout and stderr of x264.exe, and make sure I keep reading from both as long as neither reports null (that goes beyond the process reporting it has exited), megui can never pick up those messages. I used to have the same issue with encraw but when I changed the code to keep reading beyond the process.Exited event until attempting to read from stdout and stderr just reports null, I managed to catch all the lines from encraw. I'm wondering if anybody has an idea why this doesn't work for x264.exe and what there is fundamentally different from x264 exiting immediately with an an error like the mentioned one, and other errors (like unsupported commandline option.. those are picked up just fine).

Sirber

14th February 2006, 13:50

Profiles for VFW would be nice. :scared:
VFW is like VHS... You can still use it but it's time is over.

kurt

14th February 2006, 19:25

Sharktooth

15th February 2006, 08:40

damn redirector doesnt like "+" in filenames... i should fix it...
try this direct link: http://files.x264.nl/Sharktooth/utils/avc2avi_rev267+gui.7z

nickolasemp

28th February 2006, 13:05

leowai

28th February 2006, 13:35

Hello everybody!
Does anyone know how I can put zones (in order to encode a movie's credits in grayscale) in x.264?
I have searched x.264's options but I can't seem to find anywhere such thing as grayscale encoding...
MeGUI support zones. It provides encoding of the movies's credit with less bitrate using x264.exe. The bitrate are reserved for higher bitrate for main movie. However, I'm not sure is this the grayscale encoding that your refer to.

You can download MeGUI binary builds from ChronoCross:
http://chronocrossdev.com/apps/megui/

Doom9

28th February 2006, 14:15

there's no grayscale mode in x246 and why is this in the development thread?

Kostarum Rex Persia

28th February 2006, 14:27

What about build 445? It seems that some error appearing from build 443.:confused:

lurui: Hi,I use r445 to encode the same file under the same parameter set as r440,but the result is not the same in PSNR and bin bitstream. So I think there is an error in the r445.

and:

Hi,
I test more and find the difference is between r442 and r443. I set b_bframe_adaptive=0,
so the frametype decision function is not used at all. There must be some other reason.

LoRd_MuldeR

28th February 2006, 22:21

Downloads on x264.nl broken:
"The requested URL /x264/revision446/x264-446-install.exe was not found on this server."

//EDIT

Okay, it's fixed now

bob0r

1st March 2006, 11:08

Ya, it uploads rev.txt first, because it only took 5 minutes to compile, now with a working make fprofiled, my 5m18s test video takes up to 1h30m to compile fully.

I will change the order of files being uploaded later on...

Inventive Software

1st March 2006, 12:03

Profiles for VFW would be nice. :scared:
I have tried some dabbling in the source code, and only got as far as making a new tab, which says "Profiles". I should be able to work on it more during the holidays, about 6 weeks, where I'll try and add some drop-down boxes et-al, but don't get your hopes up. My coding knowledge extends to reading the manual (if there is one) and trial-and-error.

Sharktooth

1st March 2006, 12:17

why waste time on VFW? Let it die.

ChronoCross

1st March 2006, 17:36

why waste time on VFW? Let it die.
I second that.

IgorC

1st March 2006, 18:47

I'm third.

shon3i

1st March 2006, 19:24

And i am First who is against

ChronoCross

1st March 2006, 19:48

And i am First who is against

I don;t get it. Is compatibility the only reason you want it to stay. the native mp4 editing tools are appearing now. It's like telling nintendo that they have to make their new console compatible with the original NES.

Sharktooth

1st March 2006, 19:50

Eretria-chan

1st March 2006, 19:58

And i am First who is against
I second that.
There is nothing prevent something new to replace VFW and until that time, VFW should stay around methinks.

nexus

1st March 2006, 20:05

I don't know if this bug is known. Sorry, if it was mentioned a few pages before.

Since a few revisions of x264 I get the following error message if I turn on "turbo":

shon3i

1st March 2006, 20:06

Tommy Carrot

1st March 2006, 20:18

VFW is old, is buggy, is slow, is limited, doesnt support many of the new codecs features, creates problems when editing, doesnt support variable bitrate, doesnt support variable framerate, doesnt support streaming, etc...
it's simply old and outdated and must die so a new tech can replace it.
Ehh, not again... :( We already had this debate several times, and i explained you several times that most of your arguments are simply not true.

VFW is old indeed (then again, quicktime, which mp4 is based on, is even older), but it is not buggy, no matter how many times you keep repeating it. AVC in vfw interface has exactly the same issue ASP had (b-frame lag at editing, no issues at playbacking), and i don't remember that anyone had any problems with xvid or divx in this regard. VFW is not slower (as only the interface is different, and it has nearly no overhead), and there is no feature in the AVC standard what couldn't be used in VFW interface (the fact that not every feature is implemented in the vfw version is a completely different question). Variable frame rate and streaming are indeed not supported, but i cannot imagine why would i need these features.

I just cannot understand why you guys feel so threatened by the vfw version that you have to keep spreading these misinformations.

LigH

1st March 2006, 20:34

bond

1st March 2006, 20:42

Ehh, not again... :( We already had this debate several times, and i explained you several times that most of your arguments are simply not true.

VFW is old indeed (then again, quicktime, which mp4 is based on, is even older), but it is not buggy, no matter how many times you keep repeating it. AVC in vfw interface has exactly the same issue ASP had (b-frame lag at editing, no issues at playbacking), and i don't remember that anyone had any problems with xvid or divx in this regard. VFW is not slower (as only the interface is different, and it has nearly no overhead), and there is no feature in the AVC standard what couldn't be used in VFW interface (the fact that not every feature is implemented in the vfw version is a completely different question). Variable frame rate and streaming are indeed not supported, but i cannot imagine why would i need these features.

I just cannot understand why you guys feel so threatened by the vfw version that you have to keep spreading these misinformations.tommy carrot, you tell us we dont listen to your arguments?

i tell you you dont listen to ours, cause if you would, you would not "keep spreading these misinformations"

Sharktooth

1st March 2006, 20:52

You can watch the image of the error message already in a thread in the german board (http://forum.gleitz.info/showpost.php?p=255782&postcount=1). But it looks rather like a MeGUI problem than a x264 bug.
__

@ nexus:

The MeGUI thread is here (http://forum.doom9.org/showthread.php?t=96032).
yeah, it's related to megui and not to x264.

@Tommy Carrot: it's not limited to b.frames, there are also other features (forward and backward multiple reference frames, frames reordering etc.) that are NOT COMPATIBLE NOR SUPPORTED by VFW (and AVI).
Until VFW is alive there will be small or no interest in creating editing software based on other techs just coz there's virtual dub(mod).
Let vfw die and let the coders develop software based on new technologies.

Tommy Carrot

1st March 2006, 20:55

Bond, i think every argument i said is true. I don't say people should use vfw, and i'm perfectly aware of the limitations of it, but sometimes the "anti-vfw league" is saying ridiculous things here, and i feel i have to address the issue. Spreading misinformations, even with good intentions, just to convince people is not ok IMO.

Sharktooth: the mentioned problems are all related to the b-frames, p-frames have no problem with multiple references.

Anyway, i don't wish to continue this debate, let's just say that theoretically i agree with you, i just think you are too quick to bury vfw before any proper alternative could emerge. I'm following closely the developments of the mkv and mp4 manipulator applications, but they are nowhere close to being usable for more complex editing jobs. I think until then the vfw version is still necessary.

Sharktooth

1st March 2006, 20:57

spreading misinformation?!?
MPEG-4 ASP was HACKED in VFW... AVC is HACKED in VFW...
what misinformation? VFW doesnt support MPEG-4 (both v3 and v10).
If you say something different it's you spreading misinformation.

Eretria-chan

1st March 2006, 21:01

So far, I can see the VFW is good enough for the casual user. And the more advanced tools out there means you have to download additional huge programs and learn them.
I don't see why VFW is so incredibly bad. Make another system like VFW if you think it is so bad. If it really is as good as VFW, it might just one day replace it.

bond

1st March 2006, 21:02

guys, lets cool down plz ;)

Sharktooth

1st March 2006, 21:02

There is... GStreamer... DirectShow...
But no virtual dub for DirectShow nor for GStreamer...
Thanx to VFW.
BTW, VFW is not good at all... it causes big problems with AVC.

bond

1st March 2006, 21:05

well once avidemux supports mp4 output correctly, there will be no reason for using x264 with avi/vfw anymore

shon3i

1st March 2006, 21:10

But still is not same. Nobody can change virtualdub

Sharktooth

1st March 2006, 21:14

infact it's much better...
stick with your jurassical software and tech then and speak for yourself.

shon3i

1st March 2006, 21:18

This software comlete all my jobs whitout any bug. This going nowhere. I want say anything about that.

Sharktooth

1st March 2006, 21:21

well, AVC in AVI thru VFW is buggy.
using AVC with VFW is buggy.
using Virtual Dub with AVC is buggy...
since we're talking about x264, and x264 IS AVC... virtual dub and x264 = buggy.
it's not so difficult to understand...

shon3i

1st March 2006, 21:25

Relax man i won't mad you i understand you man. But this can fix like says Tommy Carrot

Sharktooth

1st March 2006, 21:28

it cant be fixed. there is nothing to fix.
it's just VFW that lacks support for a series of features.
they cant be added without breaking everything.
thats why MS created DirectShow.

bond

1st March 2006, 21:30

guys, plz calm down, especially newbies who definitely dont know the technical details

shon3i

1st March 2006, 21:33

guys, plz calm down, especially newbies who definitely dont know the technical details
@bond I am not a newbie and i know the technical details
Maybe I am newbie on this forum.

bond

1st March 2006, 21:35

how did you know that i mean you? ;)

Sharktooth

1st March 2006, 21:36

i know the technical details
it doesnt seem so

shon3i

1st March 2006, 21:36

how did you know that i mean you? ;)
Just Easy :)

nexus

1st March 2006, 21:48

@ nexus:

The MeGUI thread is here (http://forum.doom9.org/showthread.php?t=96032).
Damn, wrong thread.

Kurtnoise

1st March 2006, 23:31

First of all, I understand Tommy Carrot point of view...

Second, I'd say let people choose by themself. I think there are already some good explanations here and there to choose by himself which is good or which is bad for our own needs. In addition, most often problems caused by these tricks can be the break point to change our point of view or at least to change the methods used to create/edit video streams. And don't forget that vfw codecs are also used for captures and all existing methods are not perfect...

But no virtual dub for DirectShow
not true...what about ffdshow. Some dshow filters work with vdub.

nor for GStreamer...
There are some vdub-like in *nix world which use GStreamer.

Sharktooth

1st March 2006, 23:38

not true...what about ffdshow. Some dshow filters work with vdub.
the problem is that it will still make use of vdub... and so vfw...
There are some vdub-like in *nix world which use GStreamer.
but not in windows:(

LoRd_MuldeR

2nd March 2006, 00:10

Kostarum Rex Persia

2nd March 2006, 01:27

Kostarum Rex Persia

2nd March 2006, 01:30

And, for the record, Shon3i is very very good in encoding jobs. He knows everything about video encoding for 7 years.

ChronoCross

2nd March 2006, 02:02

which explains why he is living in the past. VFW needs to be killed off and new technologies be embraced. Why waste the developers times on vfw when the cli could just implement all the features without worry of having to conform to something that was old and outdated even when xvid first came around. The reason we still have xvid vfw is because of the simple fact of no one wanting to leave vfw. are we seriously gonna keep using vfw 25 years from now just because n00b's think it's easy? Come on seriously.

Let it die.

Kostarum Rex Persia

2nd March 2006, 02:48

No, not 25 years, but only 2 or 3 more years. Until MP4 tools get ready for market.

And what about direct recording in Xvid or x264 from TV recording programs? That's why VFW needs to exist, until recording programs(and the market) accept MP4 container, properly.

bob0r

2nd March 2006, 02:54

x264.nl > configure --disable-vfw :devil: ?

ChronoCross

2nd March 2006, 03:00

There is no reason to use x264 for recording captures. we have huffy and xvid/divx for that. They are already vfw.

The question at hand is should we continue to support vfw for upcoming codecs. The answer is no. We already have codecs that do the jobs that vfw were meant to. If we continue to develop x264's vfw then the full switchover to cli will NEVER happen. WHy change when you can get by with the current. If we dump the vfw in x264 we can continue to use the older codecs for direct capturing.

Else we will still be having this conversation when the next level codec comes out in 3-5 years. Are we gonna still beg for vfw when no tools for .mp5 are here?

Adub

2nd March 2006, 03:05

I am currious about this whole argument.
When people say "no vfw" I wonder what could we use as a replacement? I heard some one mention GStreamer, so I looked it up. It looks really promising, for my very limited knowledge of it.

Are there any others? Some maybe be developed by the brilliant people who populate this maginficent forum? What else would work, because I like my Virtualdub, yet I am starting to really like MeGUI as well.
Thoughts/Suggestions?

Kostarum Rex Persia

2nd March 2006, 03:18

BTW, can anyone explain to me what is GStreamer? Never heard for that.

ChronoCross

2nd March 2006, 03:20

BTW, can anyone explain to me what is GStreamer? Never heard for that.

it's called google. repeat after me. google.

http://www.gstreamer.net/

Sharktooth

2nd March 2006, 10:03

bond

2nd March 2006, 10:24

ok as this is the x264 development thread my proposal to bring this topic back to the topic:

split the x264vfw windows centric code from the x264 svn and let vfw advocats take it over and develop it in an own project
just like other x264 guis (megui, staxrip, whatever), and x264vfw is only a gui and not more, are also developed in own projects

Inventive Software

2nd March 2006, 10:28

Bloody hell, I think I opened a can of compressed worms with the VFW mention.

My 2 cents: Firstly, VFW is still used quite a lot, and until a viable and WORKING alternative arises, I'll continue to help along the development. Secondly, the developers of x264 deserve to have a VFW implementation to give the masses what they want.

Inventive Software

2nd March 2006, 10:30

celtic_druid

2nd March 2006, 10:32

Not sure that giving the masses what they want is ever a good idea.

No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?

Eretria-chan

2nd March 2006, 14:05

No one really edits AVC avi's via VfW do they? If they only use it for encoding then surely there are plenty of viable alternatives already?
If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:

bond

2nd March 2006, 14:13

If it works, then it works for me. I just want an easy-to-use GUI and no CLI crap. That's all I ask for. But no one seems to heed that :scared:we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post

Eretria-chan

2nd March 2006, 14:18

we have an own forum for x264 gui encoders that are not using vfw and virtualdub

read up before you post
I know that. But they are not VFW.
And I like vdub =)

bill_baroud

2nd March 2006, 14:38

Sharktooth

2nd March 2006, 14:40

I know that. But they are not VFW.
And I like vdub =)they must not be VFW, since it's VFW that causes problems with AVC and unfortunately vdub is based on VFW.
so, it's only a matter of learning to use other tools instead of vdub.

edit: also with megui you dont even have to set the options every time, just use pre-made profiles or create your own ones...

Eretria-chan

2nd March 2006, 14:45

so what ? with them, you choose an avs file, set the encoding options, and then encode. With vdub, you open an avs file, set the encoding options and then encode. Why the f*** do you want to use vdub ?
Setting encoding options is even faster in megui, there is less mouse movements to access them, so if you're really that lazy (because you doesn't want to change) you should use megui !
Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.

bond

2nd March 2006, 14:50

realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:

Sharktooth

2nd March 2006, 14:53

Dude, there is a reason I use RA4. I don't know avisynth. I don't know CLI. I want to know neither. I just want an easy-to-use GUI that does it all for me.
I agree RA4 is pretty much all I need (because it handles everything for me), but that doesn't mean VFW is bad. If it works, then it is all we need. If it does not work, then we must use something else.
And I know vdub more than megui and other encoding tools.
well, you dont need to know CLI, avisynth or anything... megui has a script creator, creates the command line for CLI etc... for you.
just use the ONE CLICK ENCODER function and you're set up.
VFW creates non compliant files that can create problems for playback and for editing.
AVC is not supported in VFW and you may end up with unplayable files in a near future.
BTW, RA4 doesnt use VFW nor vdub... it uses x264 CLI...

Eretria-chan

2nd March 2006, 14:54

realanime encodes with x264 to mp4/mkv without vfw/avi too :rolleyes:
Sure, but I don't have to do anything. Just like VFW. No CLI and no avisynth - just like I want it.
And now I don't want to continue this discussion, so this shall be my final comment.

Sharktooth

2nd March 2006, 14:57

Eretria-chan... you're telling us there are programs just easy to use as vdub/vfw... so what's the problem??!?
RA4 is good and does the encoding the right way as does megui and staxrip...

Eretria-chan

2nd March 2006, 15:01

I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt). I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
BUT, I don't mind using a program that handles it.
I'm not against those tools. But I'm not against VFW either.
I AM against, however, those who badmouth VFW. Because VFW works for me and I like it and it is easy to use. When I use VFW, I have no need for the "not supported" features so VFW is quite adequate for me.

Conclusion:
Direct use of CLI + avisynth = BAD.
Use of tools like RA or MeHUI = Okay.
Use of VFW = Okay (NOT BAD).

Sharktooth

2nd March 2006, 15:04

well, what im trying to say is VFW and AVC is a bad choice coz AVC is basically incompatible with VFW and even if the devs made some hacks to make it "work", it causes problems.
So, it's better to use other codecs with vdub (or VFW in general).

Eretria-chan

2nd March 2006, 15:07

If it works, if I can do what I need with VFW and AVC, I'm happy. That's all I need. Therefore I don't agree with your when you badmouth VFW. Sure, it may be old, sure it may require hacks - but it works! And it's easy!

If I need more advanced features, I would try some more advanced products.

bond

2nd March 2006, 15:11

it doesnt work correctly, and thats the point

you get a slight desync and you have missing frames (just two of the many problems)...

inform yourself before you mix yourself into such discussions, clueless newbies kicking in only lead to bad blood

Sharktooth

2nd March 2006, 15:11

you didnt understand... the advanced features are already in AVC and it uses it everytime you encode...
it's not safe to say it "works"...

Yong

2nd March 2006, 16:29

I suppose I can clarify to you a little :)
I'm AGAINST using CLI directly (eg typing a lot of options as a dos prompt).
There is someting called "batch file"(it just a text file),
it can execute alot of command at once as you defined in the batch script...
I'm AGAINST using avisynth directly (because there is hundreds of command which I can't possibly remember, plus I don't understand anything about what those commands do).
http://www.avisynth.org/index.php?page=AviSynthManual

imo a simple batch file isnt too hard to write. ;)

example(dgindex -> generate a simple avisynth script -> encode):

@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF

Eretria-chan

2nd March 2006, 17:00

I did use AVC in VFW some time long ago and it worked fine (at least it looked fine to me), so that adds to my argument. Although I don't use AVC in VFW so much because I let programs handle all the settings for me (RA), so I will not speak of it much.

As long as you get a file that can be watched, then it works, by my definition. And it has in the past. Dunno about now.

As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.

In vdub, select the frames you want to delete and select edit -> delete. To resize, add a filter, enter the new size and select a method. What is good here is that I can see a preview of what the result will be with the specified resize method. Piece of cake. But not in avisynth.

But I shan't talk of VFW anymore since you only seem to bounce it back on me and it makes matters worse.

708145

2nd March 2006, 17:13

As for batch files, CLI & co: that is old school. That was used when DOS was around, and now it isn't anymore. The future is GUI. At least, that is what I think. I don't want to fool around with command lines or batch files and write 20 lines just to encode a file. And even the avisynth manual is confusing for those who don't know how video encoding really works.

mental arithmetic is old-school as well ever since people have calculators, right? :rolleyes:

My point: Both variants, CLI and GUI, have it's use. But this is independent of the VFW discussion!

edit: We should separate editing from encoding. For editing use whatever you like, preferably lossless keyframe-only AVI, but for encoding either use:
a) VFW to encode to an ancient codec of the pre ASP era (before 1999); AVI is fine here as well.
b) use a proper chain and container to encode to advanced codecs
But please don't bug developers with VFW support for advanced codecs. It is disturbing and annoying!

Adub

2nd March 2006, 17:33

Okay for curiousity sake, how would one go about designing a codec interface through Directshow? My guess is that it would look alot like FFDShow? If so, developers go crazy. I love FFDShow, and if it would replace VFW altogether that would be fine by me.

Am I wrong? Are there other designs for Directshow?

Eretria-chan

2nd March 2006, 17:38

@echo off
IF '%1'=='' GOTO EOF
IF "%~1"=="%~dpn1.avs" (GOTO ENC) ELSE (IF "%~1"=="%~dpn1.avi" (GOTO AVI) ELSE (IF "%~1"=="%~dpn1.mpg" GOTO AVS))
:AVI
echo AVISource("%~1" ,false) > "%~dpn1.avs"
GOTO ENC
:AVS
IF EXIST "%~dpn1.avs" GOTO ENC
start /low /b /w D:\DGIndex\DGIndex.exe -IA=5 -OM=0 -IF=[%~1] -OF=[%~dpn1] -exit
rem 1=MMX, 2=SSEMMX, 3=SSE2MMX, 4=64-bit Floating Point, 5=IEEE-1180 Reference, "6=Skal MMX", 7=Simple MMX
echo loadplugin("D:\DGIndex\DGDecode.dll") >> "%~dpn1.avs"
echo mpeg2source("%~dpn1.d2v").Crop(0,56,-0,-56).hqdn3d() >> "%~dpn1.avs"
GOTO ENC
rem fps=23.976.Crop(0,64,-0,-64)..ChangeFPS(15)
:ENC
echo %date% %time%
echo Avisyth Script loaded:
more < "%~dpn1.avs"
set x=start /belownormal /b /w x264 -I 300 -i 30 "%~dpn1.avs" --progress
title X264 Encoder [%1]
%x% -B 600 --me umh -A none --filter -6:-6 -o "%userprofile%\desktop\%~n1.264" --bframes 0 --frames 500
echo %date% %time%
pause>nul:
:EOF
How long did it take to write that example? That's exactly what I want to avoid. I do not want to write batch files to use with encoding. Using GUIs is much easier.

708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded. It works and that is what an end user wants. Don't kill it! :scared:

And DirectShow scares me :scared:
It's so easy to b0rk. But when used properly, it works like a charm and it is easy to extend (NOTE: This does not include actually programming a new filter >_<).

bond

2nd March 2006, 17:46

there is no need for a directshow interface

x264.exe is perfect as it is, its portable, it outputs perfect files
and there are great guis even the dumbest user can use

so what else is needed?

yeah, dumb people not wanting to learn how to push the "start encoding" button in megui will never stop using vfw

708145

2nd March 2006, 17:54

708145: Again, you also seem to miss the point, unless you typed wrong. ASP codecs with VFW works perfectly fine. I have done it many times. I have been able to encode/decode and even edit with mostly no problems. Which is another example of what I try to point out: If it works, then whatever it is, buggy, old or whatever, there is no reason not to use it, as long as it works. And with ASP codecs, if you hve not noticed, it works. And therefore I am happy to use VFW with ASP codecs.
Again, note, that even if it might have some limits, it has worked fine for my purposes, and thus it should not be excluded.

Dear Eretria-chan,

please have a look at the posts earlier in this thread stating that ASP (with B frames) in AVI is a hack which needs support by every tool involved in the chain including decoder!

It made tools break which were correct but didn't include that hack! Besides it is becoming more and more a stretch to inlcude advanced codec capabilities like b-pyramid and the likes into AVI. Yeah sure it would work if developers would spend 90% of their time for supporting obsolete tech. Let them concentrate on improving stuff and learn to use a proper GUI instead.

A small related question: :devil: You obviously don't seem to be interested in advanced codecs so why are you discussing here at all. Just use AVI with MPEG1 and be happy. :angry: You miss all the advanced stuff anyway.

edit: I won't post about this topic in this thread anymore. This leads to nothing. Coding some ELDER instead :>

Eretria-chan

2nd March 2006, 17:59

I must repeat: it works, does it not? You can play files and encode and edit them, right?
I DO care for new techs. Let me tell you...
See, I don't think it is bad to use VFW for things such as ASP, so don't kill it! Obviously, in time, it will become obsolete because it doesn't support all the new advanced stuff, but... that is then.

Maybe you shouldn't use VFW with AVC... but that is a small problem since good GUIs like RA exists. But what for ASP? It works! It works! Let VFW remain for the sake of ASP, where it works.

And bond seems to hate everything but CLI and obvious GUIs like RA. That's a shame... why can't evenyone use something in their own way - like they want to?

bond

2nd March 2006, 18:03

you get a slight desync and you have missing frames (just two of the many problems)...read that a thousand times...

Eretria-chan

2nd March 2006, 18:14

Whatever... this is leading nowhere anyway.

JimiK

2nd March 2006, 18:57

Right, this is leading nowhere. Why don't you guys just let everybody encode the way he/she likes too. There is no law that everybody has to make good encodes. If people use VfW and are happy with the result, so be it. And just ignore all the "we need this and that in VfW" requests. If people that develop the codec feel no need to work on the VfW interface, than thats o.k. There are people that use VfW that are capable of extending the interface. When they do so, they can let others benefit from their work. If people want to use VfW and are not capable of extending it, well, then that's bad luck.
One word to the batch script of Yong: I don't think it took too long to write that. Compared to the encoding time of a 2 hour movie, such a thing is done in no time. And you can reuse it with slight alterations for your next encode. Some time ago, I was using a batch-script to encode some episodes of a series where all files should come out the same size. I also did cut the intro out. All I had to do was to tell the starting and end frame of the intro and the script cutted it out from audio and video and muxed the files in the end. So command line can be extremely helpful. By the way, Linux is one of the comming OS and with its commandline it's just faster to use.

ChronoCross

2nd March 2006, 19:14

Or we could just remove it and not have it cluttering up space in the svn. Just like I got rid of my windows 98 CD's so should we get rid of the vfw.

Revgen

2nd March 2006, 19:15

@Eretria-Chan

You really should be asking for better encoding tools, not codecs. Once there is a Vdub-like program that can cut and edit MP4 and MKV containers all this pro-VFW anti-VFW crap can stop.

I honestly can't understand why these two camps can't come together and find an editing solution that can work for everyone. The codec devs shouldn't be blamed for this at all.

ChronoCross

2nd March 2006, 19:28

Just typical. Someone steps in and says "everyone should agree," then someone comes and throws it down the recycle bin.
Ffs, this is just like company vs company who use DRM to hinder both users and other companies and demand that their own technology should be used.
Let people use what they like! Let developers create solutions like THEY want!
There is no right or wrong...
Though I am sure someone will come in and reply something the other way around and completely disagree with anything sane that is written around here.

ChronoCross's last reply was the most stupid and idiotic reply I've seen today. I give it a 10 of 10 in stupidity.

listen *insert bad word here* you haven't even given one good reason other than your a too big of a lazy *insert bad word here* to learn cli and avisynth. Meanwhile myself, sharktooth, bond have given technical reasons(read the million other threads on this) as well as future practical reasons as to why vfw support in x264 should be canned. but you vfw lovers and your "because it's easy" excuse we have to continue to listen to countless people wondering when support for new features will be added to vfw, or why doesn't my vfw encode work right, why is my audio, etc.

if your gonna call me stupid please read every other thread on this issue and then call bond, sharktooth, doom9 and others idiots as well because they have said the same things I have.

Revgen

2nd March 2006, 19:51

Here's an idea.

How about you guys delete your posts and PM each other. That way you both don't get striked by Bond. He's not here right now, so you both have time.

Eretria-chan

2nd March 2006, 20:00

That is a good idea. I retract my statement since it offends someone.

foxyshadis

2nd March 2006, 21:53

The last 4-5 pages should probably be split and merged into the vfw thread (http://forum.doom9.org/showthread.php?t=105929) instead. Really, discussing the topic is about as useful as abortion at a pta meeting, because no one changes their mind and everyone leaves angry anyway.

Kostarum Rex Persia

3rd March 2006, 01:46

Yes, Doom9, please split last 3 pages into vfw thread.

Zero1

3rd March 2006, 01:56

Bleeding hell, just accept that ASP + AVC in AVI/VfW is wrong and requires hacks.

There is a right way and a wrong way of doing this. Both "work", except the wrong way means you are restricted quality wise due to some missing features. Why not just do things the right way and have a HQ working video that no one will have (or should have) issues with?

celtic_druid

3rd March 2006, 02:38

I could always update the VfW code. Remove bframes, etc.

ChronoCross

3rd March 2006, 03:04

I could always update the VfW code. Remove bframes, etc.

yeah but really what would be th epoint of that? our whole arguement is that vfw limits the features and you just proved that. why settle for less features simply because your too lazy to learn the new stuff(not talking to you c_d, but to the vfw people)

celtic_druid

3rd March 2006, 04:25

The point would be that it would work. No lag, no dropped frames. No more arguments.

leowai

3rd March 2006, 07:18

The point would be that it would work. No lag, no dropped frames. No more arguments.
This make me thinking of the someone is driving a ferrari on an uneven country road with extremely limited speed. Yes, it runs on the road and it's OK if that's the only feature he/she really needs from that ferrari.

Now, why don't we drive that fantastic car on the high way with its full power? If you've never tried the full potential of the car, would you know how much the car is considered "wasted" when it has been only used on the country roads?

*For those who don't know what ferrari is, please simply ignore this thread. :D

celtic_druid

3rd March 2006, 07:59

I'd still rather have an NSX-R GT. My point is that is basically how it is currently with VfW. If you want the Ferrari, then you don't use VfW.

SeeMoreDigital

3rd March 2006, 10:14

I could always update the VfW code. Remove bframes, etc.Most of my tests with MPEG-4 AVC have been without B-VOP's....So I think it would be interesting to have a "no-frills" version of the x264 encoder.

By-the-way, what is the correct term to refer to an AVC codec which does not offer stuff like B-frames, Qpel, etc.... Is it "baseline"?

Cheers

Sharktooth

3rd March 2006, 10:27

Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...

bond

3rd March 2006, 10:49

microsoft also doesnt allow using b-frames in their wmv9 vfw encoder, cause they know avi and vfw simply are not useable for b-frames

apart from that using avi not only sucks because of vfw but also because of the lack of interoperability
what we see with the mpeg-4 asp mess is that avi causes a pita as every decoder needs to support specific codec stuff (like different fourccs and other codec specialities)
if people simply use mp4 or native mkv that mess problem is totally gone and interoperability is reached

there are so many arguments against avi/vfw i guess i should write a summary or so :D

SeeMoreDigital

3rd March 2006, 11:11

Cripled.
At that point is better cutting off VFW before ppl start to say x264 doesnt support b-frames and other stuff...Taking this point further.....

If we don't want the same mistakes to occure with MPEG-4 AVC as it did with MPEG-4 ASP in AVI, then I agree, development in the VfW encoder should either totally cease "or" just a no-frills baseline encoder should be offered.

Cheers