x264 development

[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!)

Originally Posted by Dark Shikari

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]

Originally Posted by 3ds

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

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]

Originally Posted by 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.

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.

[DVD Logic]

Ok. Thanks!

Anyway, just interesting where I can find detailed and accurate description of B-Pyramid for x264?

Regards,
Valery.

[burfadel]

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious

[Dark Shikari]

Originally Posted by burfadel

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious

Output should not change at all; this is part of my regression-testing.

It will probably be marginally slower. I templated all the parts of the code that had significant slowdowns (CABAC, macroblock_encode) to avoid significant speed loss.

[burfadel]

I guess marginally slower and a slight change in output wouldn't matter as long as its not a drop in quality Its quite an impressive amount of code! If it is a little slower, would probably be a good time to release any speed improvements there might be at the same time to help cancel it out. I'm just thinking on the spot here of course, but I'm thinking if people notice a slowdown this thread might get bombarded! Alternatively, if there are any quality tweaks/improvements, that would also help to cancel peoples opinions

That said, thankyou for the work and effort put into x264, its easy to see its a great quality program (the code, quality and speed of results etc) and I personally don't think there are too many programs that would even come close to x264's all-round level when you consider every factor of the program.

[DVD Logic]

Originally Posted by kieranrk

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.

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help, dear developers, what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

[kieranrk]

Originally Posted by DVD Logic

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

Don't do this...If the encoder does not set correct values then you should fail and tell the user to encode using Blu-Ray settings. Silly hacks like this will not work properly as seen by tsmuxer.

[DVD Logic]

tsMuxer works fine with B-pyramids.

[kieranrk]

Originally Posted by DVD Logic

tsMuxer works fine with B-pyramids.

The hacks it uses fail with pulldown though.

[dstln]

I think I've told this to you guys before when I had similar problems, but directly encoding from .avi fraps is again broken in x264. Now it even manages to crash x264 after indexing :O Using avisynth as the intermediary instead of ffms/lavf again works fine. I'm not sure of exactly the point that it's crashing when I try directly.

Using the latest x264 along with fraps 3.40. I'm guessing fraps updates their codec fairly regularly...

[Snowknight26]

Works fine here using latest x264 revision/Fraps. Update your Fraps.