x264 development

[MasterNobody]

Phil_L
The latest version (from the link above) was with:
MD5: dcc6721a4e1b1bb8c576005077f0f72d
SHA-1: 59bbffd4348bae2d3bd4f51fd331f19d129d1f82

And it doesn't have any debug logging in it. So you probably tested incorrect build.

[Phil_L]

Hi

I did wonder, I've downloaded again and the hash values match yours now.

Many thanks, I will update you once completed another run through.

Regards

Phil

[MasterNobody]

Phil_L
If you want debuging info (for easy bad frames founding) here is build x264dgb.exe (http://www.mediafire.com/?gb99v7wic4sflxg) (I renamed it to don't confuse with other builds).

P.S. But if it really fixed problem then result log file must be empty

[Phil_L]

Hi

I've run through with the debug version and nothing logged, and checking the problem scenes they are all okay, so looks like all fixed.

I take it this fix will find it's way into the usual builds at some point and until then is there any reason I can't use the fixed version you've sent?

Thanks again for your time on this.

Regards

Phil

[jpsdr]

Will this fix be included in the next commit ?

[LoRd_MuldeR]

Will this fix be included in the next commit ?

Have a look here for upcoming commits:
https://github.com/DarkShikari/x264-devel/commits/master

[burfadel]

I apologise if this has already been in some way answered, I did search but might have used the wrong search terms.

Are the FMA4 and XOP instructions introduced with the upcoming AMD FX processors useful? if so, what benefit could they potentially bring (I realise the answer would be hypothetical)? If they are potentially useful, any plans on implementing them and if so what timeframe?

I'm just curious at this stage, if I did get a FX-8150P or FX-8170P later in the year it would be nice to fully utilise it!

[Dark Shikari]

I apologise if this has already been in some way answered, I did search but might have used the wrong search terms.

Are the FMA4 and XOP instructions introduced with the upcoming AMD FX processors useful? if so, what benefit could they potentially bring (I realise the answer would be hypothetical)? If they are potentially useful, any plans on implementing them and if so what timeframe?

I'm just curious at this stage, if I did get a FX-8150P or FX-8170P later in the year it would be nice to fully utilise it!XOP: possibly, but I need SSH access to a Bulldozer to do such optimizations.

[Didée]

Ha, the $64 question of BD - will it burn x264 due to the doubled integer units, or will it not ... We won't know until it's there.

[unix_sansei]

How about incorporating the meta-data into the files so that they will stream properly without having to post-hack them with other tools?

[CAFxX]

Haswell+AVX2 (http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/) :eek:

Gather
Useful for vectorizing codes with nonadjacent data elements. Haswell gathers are masked for safety, (like the conditional loads and stores introduced in Intel® AVX) , which favors their use in codes with clipping or other conditionals.

Bit manipulation instructions
Useful for [compression] and a variety of general purpose codes.

AVX2 - Integer data types expanded to 256-bit SIMD.
AVX2’s integer support is particularly useful for processing visual data commonly encountered in consumer imaging and video processing workloads. With Haswell, we have both Intel® Advanced Vector Extensions (Intel® AVX) for floating point, and AVX2 for integer data types.

[Dark Shikari]

http://i.imgur.com/REy9M.jpg

[iwod]

Integer Performance related. May be major improvement for x264?

[aegisofrime]

Integer Performance related. May be major improvement for x264?

DS did say that AVX1 was mostly useless because it's mostly floating point. Guess AVX2 would be more useful.

However, Haswell is still quite far off in the horizon. We still have Ivy Bridge to get through first :(

[imcold]

More useful? You bet!

[Biggiesized]

Well, I decided to wait on Haswell anyway (from Conroe). I'm glad things are going to get exciting.

[CAFxX]

http://i.imgur.com/REy9M.jpg

ymmd :D

[iwod]

No more Xvp8? Latest newsletter doesn't have a word for it.

[Dark Shikari]

No more Xvp8? Latest newsletter doesn't have a word for it.As usual, the prospect of the existence of xvp8 disappeared when Ronald was absorbed into the Google hive-mind. Ask him about it, and he'll apparently have forgotten the project ever existed, let alone the fact that he promised to do it.

If a few tens of thousands of dollars came my way, I'd do it instead.

[iwod]

As usual, the prospect of the existence of xvp8 disappeared when Ronald was absorbed into the Google hive-mind. Ask him about it, and he'll apparently have forgotten the project ever existed, let alone the fact that he promised to do it.

If a few tens of thousands of dollars came my way, I'd do it instead.

Which basically means Google paid him to shut him up or not working on it.

Oh Well..

As much as i hate patents, I hate vp8. I love x264, but i hate MPEG LA. I guess just like everything in this world nothing is perfect.

[Dark Shikari]

Which basically means Google paid him to shut him up or not working on it. Or he's a lazy bum :p

[CruNcher]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)

[Dark Shikari]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)He's not working on that either :p

[CruNcher]

He's not working on that either :p

So hes working entirely on the Decoder ?

Btw Decoder
Is there a known bug with interlaced Studio Mpeg-2 input (on the internal decoder side) on the chroma layer --tff ?
i get strange chroma distortions and much different (better quality) results from Mainconcepts Decoder as Input.
Though it seems to be more a general libav/ffmpeg interlace 4:2:2 decoder issue it seems.


EDIT needs further evaluation

I can change settings on the FFMpeg decoder side like crazy (ffdshow) it has 0 effect Dscaler does better but it uses another field and overwriting doesn't seem to work so you have very hardly visible motion issues in some scenes (strange blending @ object edges, slightly visible on bright colors for the background object, the foreground object is moving on (like a head moving fast on a full blue background the head gets strange black blending edges in motion after deinterlacing) ). Though i heavily doubt a untrained eye would see both of those effects (chroma off,edge issues) in motion :)

[mandarinka]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)

However the result everyone was expecting was to come entirely from the "x264 terminology" :devil:

[HJRodrigo]

He is too involved in the petty squabble of libav versus FFmpeg to focus on xvp8. I will be honest though, I way prefer the name libva over FFmpeg. I wish he would make peace and just work from the inside to fix problems with the management, rather than create this confusion of libav.

[CruNcher]

is it possible to disable the indexing of ffms i see only a --index option but nothing like --no-index or is --demuxer lavf thought to be used without indexing ?

[kemuri-_9]

is it possible to disable the indexing of ffms i see only a --index option but nothing like --no-index or is --demuxer lavf thought to be used without indexing ?

ffms mandatorily requires indexing.
use --demuxer lavf if you don't want to index.

[CruNcher]

ffms mandatorily requires indexing.
use --demuxer lavf if you don't want to index.

ok i thought that just wanted to be sure so both fail with the above result though ffms with indexing seems to create even funnier issues with indexing in some camera motion sequences resulting in jumping forward and backwards (changing the field order for several frames ?, doesn't happen with --demuxer lavf ) :( Might be a build issue though, i better try several ones.

[Thunderbolt8]

when just caring about quality and not about filesize, is GOP size = 1 then the best solution? same question for number of b-frames = 0?

[Dark Shikari]

when just caring about quality and not about filesize, is GOP size = 1 then the best solution? same question for number of b-frames = 0?If you care just about quality, use lossless mode.

[Thunderbolt8]

hm the problem is I use x/h264 within TMPGEnc and they dont have such a setting. best I can do is constant quality at 62.500 kbbs

I guess its also not possible to exchange their x264 dlls with more recent ones from regular x264 binaries?

edit: as I see it I can select 1 pass constant quantization. but I cannot choose a general quantizier like 0,0, I can only set Quantization for I-picture B-picture and P-picture. so when setting all three of them to 0, would this equal lossless mode?

would the quality in this case by definition (at least theoretically) be better than choosing a constant bitrate of 62500? (here in case of a source of ~30.000 kbbs average, 50.000max)

edit²: lol, my computer cannot play 152.000 kbps compression smoothly. will have to stick to those high bitrates like 62500 then. so coming back to my initial question, if I have to specify a size for GOP and number of b-frames are 1 and 0 respectively the best settings then for quality?

[xv]

Great that there is 4:4:4 support soon in x264!
For me it already produces watchable output with I-frame only (a lot of frames do no not work or are not coded at all, the percentages in the statistics also do not sum to 100%).

For lossless RGB encoding (screen capture for example) it actually needs to encode the RGB data without any YUV conversion. I´m not sure if it´s useful at this stage, but I made a patch for that (against 4:4:4 part 13):
It adds a function to convert packed rgb to planar rgb (picture->frame copy), automatically sets colormatrix to RGB (GBR) and turns fullrange on (can be overridden by command-line). I think it´s quite clean, except for this VFLIP flag. It makes x264 crash, so I removed it and made the flip in the packed->planar conversion. Probably some internal RGB->YV12 conversion does not work correctly anymore.

Unfortunately ffmpeg ignores the colormatrix flag and treats the RGB as YUV, resulting in a completely wrong colored picture. Adding RGB support there does not seem to be that simple, because ffmpeg does not have any planar RGB colorspace.

[mandarinka]

It should be at least possible to test compression in lossless stil image coding now, for example against jpeg2k :)

[upyzl]

when seen the posts by CruNcher and kemuri-_9 before

As far as I know, most useful info is in the header of a media file (for h264, that is SEI in h264 stream header, right?), and ffms index is aiming to find that (so we need not to manual such as --fps, right?).
so, isn't there any method to force ffms do just header index to save time??

[kemuri-_9]

when seen the posts by CruNcher and kemuri-_9 before

As far as I know, most useful info is in the header of a media file (for h264, that is SEI in h264 stream header, right?), and ffms index is aiming to find that (so we need not to manual such as --fps, right?).
so, isn't there any method to force ffms do just header index to save time??

ffms's indexing is more targeted towards accurate seeking in the video than just plainly reading the header of whatever file you have.
this seeking feature is more primarily useful in avisynth than in x264cli.

[upyzl]

ffms's indexing is more targeted towards accurate seeking in the video than just plainly reading the header of whatever file you have.
this seeking feature is more primarily useful in avisynth than in x264cli.

It explains the matter...thanks

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?

[LoRd_MuldeR]

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?

It depends solely on the individual DirectShow source filter (splitter) how seeking is implemented internally.

There's nothing that would prevent a DirectShow source filter from creating its own index (either in memory or in a file), I think.

After all DirectShow is mainly targeted at playback, not at frame-accurate editing. Quite often it won't be frame-accurate...

[Atak_Snajpera]

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?
If you want accurate seeking you should use DSS2() instead.

[upyzl]

@ LoRd_MuldeR & Atak_Snajpera

Thank you for the explanation/advice
In fact I always choose the most suitable demuxer I think...luckily there's no anomaly with it :)

then wait for x264 4:4:4 support version release...:D

[xv]

It seems Dark Shikari completed 4:4:4 in x264. I´ve updated and improved my patch for that.
Added:
-Add support for BGRA and RGB (only BGR before)
Fixed:
-Removed some debug lines included in previous patch
-Removed original code instead commenting
-VFLIP bug fixed (was caused by x264_frame_internal_csp) and support for not-flipped RGB colorspaces
-Found code where x264 lowers quality of U/V planes for I444 input, but not for YV24. Changed to I444/YV24, but not RGB.

4:4:4 works great for me, but I won´t upload a binary, because I don´t know if Dark Shikari likes the idea to have binaries of his development branch here (if he says it´s ok I´ll post a link). Also current ffdshow builds crashes on 4:4:4 files, you can use latest ffmpeg to decode.

[Dark Shikari]

Binaries are okay, but please submit these patches on IRC; my 4:4:4 has lots of bugs and fixes/improvements are welcome.

By the way, G should probably be in the Y plane, for purposes of motion estimation.

[xv]

Link to binary: http://www.mediafire.com/?xagqd6o6t026o7y (most likely buggy! Use it for testing only!)
By the way, G should probably be in the Y plane, for purposes of motion estimation.
Yes, it is Y=G, Cb=B and Cr=R. It´s defined in E.2.1 VUI Parameter Semantics (page 379 in 3/2010 standard).

There is also a very interesting system for lossless RGB->YCoCg transform, but it does not work with x264 (yet?), because it needs 1 bit more chroma precision than luma (8 Bit RGB will be converted lossless to 8 Bit Y, 9 Bit Co and 9 Bit Cg). The YCoCg colorspace is similar to normal YCbCr, but designed for better compressibility instead of being based on analog PAL/NTSC transforms, and there is the option of lossless RGB conversion that needs increased chroma precision.

[Dark Shikari]

Can you come on IRC (x264-devel on Freenode) to discuss and submit your patches?

[Anakunda]

I have a feature request, called AUTORESUME. I had several long runs (counting tens of hours in total) whose some of them were interrupted by system crash. A facility to periodically save state to some temporary file and enabling to fully resume on broken process would spend much time in such a cases. If the encoder builds encoding on previous frames it wouldnot be problem to go that amount of frames back , still better than start again from scratch.

[mandarinka]

1) Mux the result to mkv.
2) Cut off the part from last keyframe till end. (Use mkvmerge splititng after timecode for this. You can look up the keyframe in f.e. aegisub or guess based on scenechanges).
3) Encode the mising part using crf (use raw .264 as output or demux afterwards).
4) Demux first streams to raw ES.
5) copy /B part1_crashed.264+part2.264 combined.264
6) mux...

[jpsdr]

If you have crashes, you may have a problem somewhere else. I often make encodes wich takes days, and never had any trouble, neither less crashes.

[LigH]

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

:goodpost: I still agree....

http://paste.frubar.net/13902 -- probably not yet valid. Please check.

[DVD Logic]

Hi all!

Can anybody please provide detailed B-pyramid structure description or AVC specification with such description ?

Send please to support@dvd-logic.com

Thanks,
Valery.

[kieranrk]

Hi all!

Can anybody please provide detailed B-pyramid structure description or AVC specification with such description ?

Send please to support@dvd-logic.com

Thanks,
Valery.

This isn't actually answering your question, but for Blu-Ray you shouldn't care much about that - you should just follow the information in the picture_timing_sei for muxing.