VideoLAN Wiki - User contributions [en]

X264 TODO

2013-03-05T22:06:33Z

Irock: /* x86 assembly */

This page contains an incomplete list of things available in x264 for you to do. It's organized into sections covering various parts of x264.

Some useful resources: [http://www.x264.nl/developers/Dark_Shikari/?dir=./src Dark Shikari's pile of junk], [http://akuvian.org/src/x264/ Pengvado's pile of junk].

If you're interested in doing any of this, drop by #x264dev on Freenode IRC. There are no experience or educational requirements for doing any of this, though you are expected to know how to code.

Bolded features may have companies willing to sponsor or provide bounties. This is not complete either; just because it's not bolded doesn't mean there aren't resources out there. If your company is interested in offering a bounty, drop by IRC.

=== Motion Estimation ===

*Sequential elimination (SEA), used for exhaustive search, might be more generally applicable to algorithms like UMH, by letting us skip a lot of SADs. The downside is we won't be able to use SAD_X4 anymore.
*(T)ESA is currently wrong for motion searches done on weightp duplicates. This effect is miniscule, but it still should be fixed.
*Hierarchical motion estimation might be a useful way to catch very long motion vectors without the cost of UMH or ESA. It might also help regularize motion.
**I have a patch for this in the lookahead, but it didn't help much, since it only added predictors.
*Somehow take into account the effect of motion vector decision on future blocks.
**Hierarchical motion estimation
**Approximations from lookahead MVs
**Iterative ME (as per Snow)
**Trellis motion estimation
*We don't need to check all 11 predictors all the time for 16x16 fullpel motion search.
**But how do we know which ones we can afford to skip, and when?
**Xvid and libtheora have algorithms for this, but the former's is almost surely 100% useless and the latter doesn't seem impressive either.
*libtheora does fullpel motion estimation on the source pixels instead of decoded pixels. Does this give a better starting point for the subpel search and discourage "weird" MVs?
*With extremely fast encoding settings (subme 0), can we rip off lookahead MVs instead of doing a real search?
**This seems to be awful from my testing, but maybe there's something we can do?
*Try sub-8x8 partitions in B-frames. Is it at all useful?
*Try bidir motion estimation for fullpel. That is, considering L1's MV when doing L0 (or vice versa). Xvid does this. How much does it help?
*Fullpel chroma ME?
**For TESA?

=== Intra Analysis ===

*Make the early terminations smarter. Currently they're just hacks -- some statistical analysis might be useful.
**With the SSSE3-based fast intra analysis, we no longer do any early terminations for different modes, at least in SAD/SATD analysis. But there might still be improvements to be made.
*SAD (subme 1) i8x8 vs i4x4 decision is a bit bad. Can it be improved without significant speed loss?

=== Mode Decision ===

*Can we find more ways to skip more motion searches in multiref?
**A while back, I tried using weaker motion searches on older refs. This helped a bit for speed-vs-compression, but is ironically the opposite of what one wants; older refs will be harder to find good MVs in, and therefore really need better searches.
*On extremely fast encoding settings, fast skip is actually kind of slow. But anything dumber (e.g. SAD) is completely useless. Is there some better balance that can be achieved here?
**Can we do something smart by analyzing fenc? It's impossible to tell whether a block is motionless by looking at fdec, but looking at the source pixels is useful. There's still complexity such as lower-QP-than-reference though.
*See the TODOs for deblock-aware RD in common/deblock.c.
**I tried correcting weightp references for deblock RDO, but it didn't help.
**I tried chroma, too, and again, it didn't help measurably.
*Is there a faster way than SA8D/SATD to do 8x8dct vs 4x4dct mode decision? At very fast settings, the time this uses is nontrivial.
**Doing a merged 4x4/8x8 SATD would help here, but would require new asm.
*Is there a faster way than RD to do 8x8dct vs 4x4dct mode decision that's still better than SATD? RD takes over an order of magnitude more time than SATD, so it might be useful to have something in the middle.
*Is there some value to swapping the mode decision metric from SATD to SA8D if we think that the macroblock will use 8x8dct? [http://akuvian.org/src/x264/x264_dct8_guess.diff This has been tried before], but only helped if our guess was extremely good (better than we could get in reality).
*With trellis 2, can we skip most of CABAC and CAVLC bit cost calculation?
*How about saving CABAC state between each trellis call, rather than basing them all on the CABAC state at the start of the macroblock?
*Make subme=11 not do thresholding in qpel RD and bidir RD.

=== Psy ===

*Psy-RD is a hack. It works, but it's a hack. If you apply QNS with Psy-RD as the metric, it goes way overboard and gives terrible results. This means that Psy-RD only works because normal mode decision is limited in the way it can modify the image to better suit the metric. Is there a way to make it better?
*Should RD be linear at all? Perhaps we should weight more heavily against low quality blocks and also try to ignore minuscule distortion that viewers can't see.
*Psy-trellis (and maybe psy-RD?) are too strong at very high QPs.
*Psy-trellis should be merged with Psy-RD. There are patches for this, but they probably won't be committed until psy-RD itself is fixed.
*RD should take into account local variance.
*Lambda should be varied on a per-DCT-block basis instead of a per-macroblock basis.
*Lambda should be picked independent of quantizer (i.e. with greater precision).
*Classic problem: a block is mostly high complexity but has a small area of low complexity. How do we judge whether that area is important? Good example: sharp text on background with film grain; grain gets blurred out because of the text.
**If we think it's important all the time, we ruin the quality of many clips that rely on raising complexity on edges (Touhou).
*Should motion estimation lambda be as high as it is at very high quantizers? There's some value to capturing "true motion"...
*Macroblock tree correlates pretty well with visual perception in that its concept of a "high complexity" matches well with the visual concept. Except for local illumination changes. Talk to Dark Shikari for a patch.

=== Lookahead ===

*Temporal MV predictors in lookahead? There's a patch for these somewhere, but they biased heavily in favor of B-frames, likely by improving the motion search.
*Should lookahead use variable lambda based on quantizer (esp. due to adaptive quant)? If so, should it take into account estimated ratecontrol quantizer, too? If so, how?
*B-adapt 1 could be made quite a bit better -- it's important because it's used on all the fast speed modes (and even the defaults). "Harbour 4CIF" is a good example of a clip where it does noticeably badly.

=== Quantization ===

*CAVLC "trellis" is a hack. It works, but it's a hack. Make it better. See the TODOs in encoder/rdo.c.
**This is doubly important now, as CABAC trellis has been made way faster, but CAVLC hasn't. Many of the CABAC trellis improvements can be backported.
*There's room for something between trellis and deadzone in terms of complexity. libvpx has a good example -- it biases towards zero-runs in its "medium speed" quantizer. This can't be SIMD'd easily, but is still vastly faster than trellis. A nonlinear quantizer (be more likely to round up larger coefficients) might also be useful.
**How useful is this with an entropy coder that doesn't really bias towards zero-runs, as in CABAC?
*Floyd-Steinberg for quantization? Try pushing quantization error to nearby DCT coefficients. Should this go from high to low or low to high?
*Energy-preserving quantizer -- maintain L1 (or maybe L2? I'm not sure) energy. Should we maintain it in the spatial domain (post-iDCT) or residual domain? Probably the former.
**See [https://github.com/saintdev/x264-devel/compare/enquant-base...energy-quant saintdev's github] for one attempt at this.
*Decimation is currently just a ripoff of the JVT recommended algorithm. Can we do this more optimally? With RD?

=== Transform ===

*Analyze the error characteristics of the fDCT. Is there any way to make it more accurate without much speed loss? Particularly at extremely low quantizers, this might help.
*Before forward transform, run a "blocking filter" that acts as the approximate inverse of the deblock filter. See [http://akuvian.org/src/x264/Shwang_loopfilter_thesis.pdf this paper].

=== Interlacing ===

*Lookahead currently blend-deinterlaces to get the lowres. Is this a good idea? Is there something better that isn't much slower?
*Constrained intra + adaptive MBAFF. Does anyone care about this?
*PAFF + MBAFF adaptive - PAFF performs better than Adaptive MBAFF on high motion scenes because it can predict from the previous field.

=== Weighted Prediction ===

*'''Make weightp work with interlacing. Preferably abuse reference duplication to make it useful for MBAFF.'''
*Finish K-means decision for weightp. Talk to DylanZA about getting his current patch for this one.
*Add explicit weighting for B-frames, too. This helps in nonlinear fades, among other cases.
*Improve weighted prediction analysis to do more searching based on an estimated offset vs scale gradient.

=== Ratecontrol ===

*Current per-frame VBV is a hack. It only adapts per row and is O(N^2), where N is the number of rows. An O(N) solution would be able to react more often and thus be more accurate.
*Make the frame size and row size predictors better. They currently are kind of crappy.
*Ratecontrol code as a whole is a bit of a mess. It could be improved. There's a lot of cruft left over that is probably not needed now, like qblur.
*1-pass ratecontrol often can't adapt fast enough when there are lots of threads (12, 16, 24, etc), especially with smallish VBV buffers. Improve this?
*2-pass VBV is actually a bit more likely to underflow than 1-pass because it doesn't adapt as aggressively and trusts first pass data a lot. This trust is often misplaced if the first pass was a fast one. This should be improved.
**2-pass is still better in the case of many threads, due to the above.
*2-pass macroblock-tree: if we added the ability to do macroblock-tree on real encoded data, we'd get better results (particularly with repeating patterns and multiref, such as an anime character's mouth moving).
*Macroblock-tree: make it more psy-aware. Maybe we should cap how much it lowers the quantizer on extremely static scenes? This might tie into the "just-noticeable error" issue in RD.

=== GPU ===

*Motion estimation?
**Methods
***Hierarchical?
***2D Wave?
***Something else?
**"Easy": lookahead motion estimation
***Extremely high parallelism, hundreds of frame searches (each with thousands of searches) at once.
**"Hard": main motion estimation
***Difficult synchronization issues, not as heavily parallel in terms of number of macroblocks, but far more partition sizes and refs to search.
***But potentially more useful...
*Other things?
*MultiCoreWare is currently looking on a GPU-based lookahead.

=== x86 assembly ===

*Find holger, lock him in a closet, and make him commit his local patches. It's been years now!

=== Other assembly ===

*There's still a lot of unreviewed NEON assembly. Can we please get this in?
*Altivec assembly is very lacking.
*SPARC VIS assembly is only available when high bit-depth is disabled. But nobody cares about SPARC anyways.

=== Other CPU optimizations ===

*x264 needs more prefetching. How many L1 and L2 cache misses (particularly L1) can we get rid of via smart prefetching in the right places? Warning: this is often hard to benchmark.
*Different CPUs take different relative times for some functions. Is this enough (particularly across architectures) to justify different encoding settings for different CPUs?

=== Other features ===

*MPEG-2 encoding support
**[https://github.com/kierank/x262/wiki/TODO x262]
*VP8 encoding support
**[https://github.com/DarkShikari/xvp8 xvp8]
*Support for SMPTE timecodes
*Merge speedcontrol
*Mixed lossless/lossy encoding.
*Segment re-encoding
*Spec compliant AVC-Intra encoding (ask kierank for spec)
**I tried this, but the problem is that the encoders/decoders in reality don't actually abide by their own spec. This is completely insane.

=== x264CLI ===

*Finish audio support. Talk to Kovensky about this one.
*Make the filtering system aware of BT.601 vs BT.709.
*Add more filters.
**Deinterlacers (YADIF).
**Denoisers (HQDN3D?).
**IVTC, decomb?
*Merge L-SMASH mp4 muxer.
*Add TS muxing support using HRD. Talk to kierank about this one.
*Add --device support.
*Add automatic --level restriction support.

SoC 2010/High Bit Depth Encoding

2010-05-26T12:38:18Z

Irock: /* Timeline */

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimizations are done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| Done || May 30 || 16-bit infrastructure ready for testing
|-
| No problems encountered so far || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| Done || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| Done || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| In progress || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation / extra time
|-
| Not started || July 5 - July 11 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 12 - July 18 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 19 - July 25 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || July 26 - August 1 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

How to test the current code:

$ git clone git://github.com/irock/x264-high-bit-encoding.git
$ cd x264-high-bit-encoding
$ git checkout high-bit-encoding
$ ./configure --disable-asm --enable-16-bit
$ make

SoC 2010/High Bit Depth Encoding

2010-05-26T11:57:17Z

Irock: /* Timeline */

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimizations are done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| Done || May 30 || 16-bit infrastructure ready for testing
|-
| No problems encountered so far || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| Done || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| Done || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| In progress || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

How to test the current code:

$ git clone git://github.com/irock/x264-high-bit-encoding.git
$ cd x264-high-bit-encoding
$ git checkout high-bit-encoding
$ ./configure --disable-asm --enable-16-bit
$ make

SoC 2010/High Bit Depth Encoding

2010-05-26T11:51:36Z

Irock: /* Repository */

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimizations are done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| Done || May 30 || 16-bit infrastructure ready for testing
|-
| No problems encountered so far || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

How to test the current code:

$ git clone git://github.com/irock/x264-high-bit-encoding.git
$ cd x264-high-bit-encoding
$ git checkout high-bit-encoding
$ ./configure --disable-asm --enable-16-bit
$ make

SoC 2010/High Bit Depth Encoding

2010-05-26T11:44:32Z

Irock: /* Milestones */

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimizations are done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| Done || May 30 || 16-bit infrastructure ready for testing
|-
| No problems encountered so far || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

SoC 2010/High Bit Depth Encoding

2010-05-19T19:19:56Z

Irock:

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimizations are done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| - || May 30 || 16-bit infrastructure ready for testing
|-
| - || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

SoC 2010/High Bit Depth Encoding

2010-05-19T19:19:16Z

Irock:

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

A lot of optimization is done with assembly, and will thus also need to be migrated. The secondary goal for this project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| - || May 30 || 16-bit infrastructure ready for testing
|-
| - || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

SoC 2010 projects

2010-05-18T21:13:55Z

Irock: /* Support for high bit encoding */

Here is a list of the accepted projects for Google Summer of Code 2O10.

= List of current VLC projects =
==Shader support for video post-processing==

* '''Project page: [[SoC 2010 Shader Support]]'''
* '''Student''': [[User:Skoruga|Sasha Koruga]]
* '''Mentor''': Adrien Maglo
* '''Abstract''':

A lot of video post-processing such as RGB-YUV conversion can be accelerated by using the GPU. This can either be achieved through a fragment shader, where it is the last step before a pixel is displayed on the screen, or it can be done with DirectCompute/CUDA/OpenCL. The method will vary depending on the task and intent. I will implement support for shaders by using the DirectX and OpenGL API and write a few shaders such as RGB-YUV conversion.

== ASF demuxer ==
* '''Project page: [[SoC 2010 ASF Demuxer]]'''
* '''Student''': [[User:juhovh|Juho Vähä-Herttua]]
* '''Mentor''': Ilkka Ollakka
* '''Abstract''':

I was selected to do a project related to ASF and Matroska demuxers, but since there's some overlap related to Matroska, my main goal now is to improve the ASF demuxer as much as I can and then find another similar project to work on the rest of the time.

== Implementing BD-J support in libbluray and VLC ==
* '''Project page: [[SoC 2010/Implementing BD-J support in libbluray and VLC]]'''
* '''Student''': [[User:Will07c5|William Hahne]]
* '''Mentor''': [[User:Jpsaman|Jean-Paul Saman]]
* '''Abstract''':

This project will focus primarily on getting BD-J (Blu-ray Disc Java) support into libbluray. BD-J support is important because many of the advanced features and extra content in Blu-ray movies uses BD-J. Currently people with Blu-ray drives are tied to Windows if they want to access this content, they are forced to use proprietary Blu-ray software which does not run on Linux or various other operating systems. This project will also integrate the BD-J support into VLC.

= List of current x264 projects =
==Support for high bit depth encoding==
* '''Project page''': [[SoC 2010/High Bit Depth Encoding]]
* '''Student''': [[User:Irock|Oskar Arvidsson]]
* '''Mentor''': [[User:Holger|Holger Lubitz]]
* '''Abstract''':

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

= List of current VLMC projects =
==Enhancing VLMC==

* '''Project page: [[SoC 2010/Youtube Integration VLMC|SoC 2010/Youtube Integration in VLMC]]'''
* '''Student''': [[User:Rohityadav|Rohit Yadav]]
* '''Mentor''': Ludovic 'etix' Fauvet
* '''Abstract''':

Youtube is the most popular video sharing website, right now. VLMC is a video editing software and having features in VLMC to search-retrieve videos, directly upload/update/delete videos on Youtube, within the application itself, would be awesome. The aim of this project is to write a small C++/Qt based Youtube client library for VLMC that provides her all the APIs to perform all those things.

= List of current Phonon projects =
== PCM I/O API ==

* '''Project page''': [[SoC 2010/PCM IO API (Phonon)]]
* '''Student''': [[User:Mforney|Michael Forney]]
* '''Mentor''': Jean-Baptiste Kempf
* '''Abstract''':

Design a fully featured PCM I/O API for Phonon, and provide an implementation for the Phonon-VLC backend and one other (either MPlayer or Xine). This API will allow developers to capture PCM data from devices like a sound card, or to play back raw audio from memory, or elsewhere. This will provide some important missing features in Phonon, and open the door for many applications waiting to make use of an API like this.

[[Category:SoC_2010_Project]][[Category:SoC]]

== Capture API ==

* '''Project page: [[SoC 2010 Phonon Capture API]]'''
* '''Student''': [[User:Skelet|Casian Andrei]]
* '''Mentor''': Hugo Beauzee-Luyssen
* '''Abstract''':

The goal of this project is to enable Phonon applications to access and display input devices, like webcams. The Phonon code-base is well designed and flexible, and apparently no major modifications are needed to the current API. The ease of use for the Phonon application developer is a priority. Features implemented in Phonon will be implemented in the Phonon-VLC back-end in parallel. Various device classes should be supported.

[[Category:SoC_2010_Project]][[Category:SoC]]

SoC 2010 projects

2010-05-18T21:13:18Z

Irock: /* List of current x264 projects */

Here is a list of the accepted projects for Google Summer of Code 2O10.

= List of current VLC projects =
==Shader support for video post-processing==

* '''Project page: [[SoC 2010 Shader Support]]'''
* '''Student''': [[User:Skoruga|Sasha Koruga]]
* '''Mentor''': Adrien Maglo
* '''Abstract''':

A lot of video post-processing such as RGB-YUV conversion can be accelerated by using the GPU. This can either be achieved through a fragment shader, where it is the last step before a pixel is displayed on the screen, or it can be done with DirectCompute/CUDA/OpenCL. The method will vary depending on the task and intent. I will implement support for shaders by using the DirectX and OpenGL API and write a few shaders such as RGB-YUV conversion.

== ASF demuxer ==
* '''Project page: [[SoC 2010 ASF Demuxer]]'''
* '''Student''': [[User:juhovh|Juho Vähä-Herttua]]
* '''Mentor''': Ilkka Ollakka
* '''Abstract''':

I was selected to do a project related to ASF and Matroska demuxers, but since there's some overlap related to Matroska, my main goal now is to improve the ASF demuxer as much as I can and then find another similar project to work on the rest of the time.

== Implementing BD-J support in libbluray and VLC ==
* '''Project page: [[SoC 2010/Implementing BD-J support in libbluray and VLC]]'''
* '''Student''': [[User:Will07c5|William Hahne]]
* '''Mentor''': [[User:Jpsaman|Jean-Paul Saman]]
* '''Abstract''':

This project will focus primarily on getting BD-J (Blu-ray Disc Java) support into libbluray. BD-J support is important because many of the advanced features and extra content in Blu-ray movies uses BD-J. Currently people with Blu-ray drives are tied to Windows if they want to access this content, they are forced to use proprietary Blu-ray software which does not run on Linux or various other operating systems. This project will also integrate the BD-J support into VLC.

= List of current x264 projects =
==Support for high bit encoding==
* '''Project page''': [[SoC 2010/High Bit Depth Encoding]]
* '''Student''': [[User:Irock|Oskar Arvidsson]]
* '''Mentor''': [[User:Holger|Holger Lubitz]]
* '''Abstract''':

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

= List of current VLMC projects =
==Enhancing VLMC==

* '''Project page: [[SoC 2010/Youtube Integration VLMC|SoC 2010/Youtube Integration in VLMC]]'''
* '''Student''': [[User:Rohityadav|Rohit Yadav]]
* '''Mentor''': Ludovic 'etix' Fauvet
* '''Abstract''':

Youtube is the most popular video sharing website, right now. VLMC is a video editing software and having features in VLMC to search-retrieve videos, directly upload/update/delete videos on Youtube, within the application itself, would be awesome. The aim of this project is to write a small C++/Qt based Youtube client library for VLMC that provides her all the APIs to perform all those things.

= List of current Phonon projects =
== PCM I/O API ==

* '''Project page''': [[SoC 2010/PCM IO API (Phonon)]]
* '''Student''': [[User:Mforney|Michael Forney]]
* '''Mentor''': Jean-Baptiste Kempf
* '''Abstract''':

Design a fully featured PCM I/O API for Phonon, and provide an implementation for the Phonon-VLC backend and one other (either MPlayer or Xine). This API will allow developers to capture PCM data from devices like a sound card, or to play back raw audio from memory, or elsewhere. This will provide some important missing features in Phonon, and open the door for many applications waiting to make use of an API like this.

[[Category:SoC_2010_Project]][[Category:SoC]]

== Capture API ==

* '''Project page: [[SoC 2010 Phonon Capture API]]'''
* '''Student''': [[User:Skelet|Casian Andrei]]
* '''Mentor''': Hugo Beauzee-Luyssen
* '''Abstract''':

The goal of this project is to enable Phonon applications to access and display input devices, like webcams. The Phonon code-base is well designed and flexible, and apparently no major modifications are needed to the current API. The ease of use for the Phonon application developer is a priority. Features implemented in Phonon will be implemented in the Phonon-VLC back-end in parallel. Various device classes should be supported.

[[Category:SoC_2010_Project]][[Category:SoC]]

SoC 2010/High Bit Depth Encoding

2010-05-18T21:09:09Z

Irock:

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base of x264 for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

As a lot of the code that handles the actual encoding is written in assembly, templating and migrating the encoder won't suffice to enable support for higher sample depths. The secondary goal for the project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| - || May 30 || 16-bit infrastructure ready for testing
|-
| - || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding

SoC 2010/High Bit Depth Encoding

2010-05-18T21:05:23Z

Irock: Created wiki page for SoC project "Higher bit depth encoding support for x264"

{{SoCProject|year=2010|student=[[User:Irock|Oskar Arvidsson]]|mentor=[[User:Holger|Holger Lubitz]]}}

== Abstract ==

The primary goal for this project is to prepare the code base for encoding H.264 video with user defined sample depths. This will involve templating the encoder and migrating existing C code for use with higher sample depths.

As a lot of the code that handles the actual encoding is written in assembly, templating and migrating the encoder won't suffice to enable support for higher sample depths. The secondary goal for the project is therefore to identify new assembly code to be written.

== Milestones ==

{| class="wikitable"
! Status !! Deadline !! Description
|-
| - || May 30 || 16-bit infrastructure ready for testing
|-
| - || June 6 || Encoding with 16-bit infrastructure produce same results as 8-bit infrastructure.
|}

== Timeline ==

This schedule is preliminary.

{| class="wikitable"
! Status !! Date !! Period !! Description
|-
| In progress || May 17 - May 23 || Week 1 || Identify C code that should be templated.
|-
| In progress || May 24 - May 30 || Week 2 || Start templating the encoder for 16-bit infrastructure.
|-
| Not started || May 31 - June 6 || Week 3 || Test templated encoder. Identify C code that need modification to support higher sample depth.
|-
| Not started || June 7 - June 13 || Week 4 || Start modifying the encoder to support higher sample depth.
|-
| Not started || June 14 - June 20 || Week 5 || Continue work with encoder.
|-
| Not started || June 21 - June 27 || Week 6 || Continue work with encoder.
|-
| Not started || June 28 - July 4 || || Vacation
|-
| Not started || July 5 - July 11 || || Vacation
|-
| Not started || July 12 - July 18 || Week 7 || Test encoder with higher sample depths.
|-
| Not started || July 19 - July 25 || Week 8 || Fix issues encountered during testing.
|-
| Not started || July 26 - August 1 || Week 9 || Modify build chain to allow compilation for higher sample depth. Add options to set sample rate.
|-
| Not started || August 2 - August 8 || Week 10 || Identify assembly code that needs modification to support higher sample depth.
|}

== Repository ==

* http://github.com/irock/x264-high-bit-encoding/tree/high-bit-encoding