VideoLAN Wiki - User contributions [en]

VDD16/Attendees

2016-08-31T16:22:32Z

Gramner: /* Departures */

Back to [[VDD16|main VDD page]].

= Arrivals =
Please order chronologically by time of arrival.

{| border="1" class="sortable"
! Name
! IRC
! Time of arrival
! Port of disembarkment
! Vessel
! Notes
|-
| Janne Grunau
| jannau
| Wednesday 22:27
| Central Station
| ICE1090
| from Karlsruhe
|-
| Vittorio Giovara
| koda
| Thursday 8.00
| Flughafen Tegel (TXL)
| UA 692
| from NWR
|-
| Jean-Baptiste Kempf
| j-b
| Thursday 10:25
| Flughafen Tegel (TXL)
| AB 8301
| from ORY
|-
| Henrik Gramner
| Gramner
| Thursday 12:10
| Flughafen Tegel (TXL)
| AB 8003
| from ARN
|-
| Felix Paul Kühne
| feepk
| Thursday afternoon
| Hauptbahnhof
| ICE lines 6 or 8
| from BRE via HAJ
|-
| Rémi Denis-Courmont
| courmisch
| Thursday 20:40
| Flughafen Tegel (TXL)
| AB 8077
| from HEL
|-
| Martin Storsjö
| wbs
| Thursday 20:40
| Flughafen Tegel (TXL)
| AB 8077
| from HEL
|-
| Konstantin Pavlov
| thresh
| Thursday 21:20
| Schönefeld (SXF)
| SU 2316
| from SVO
|-
| François Cartegnie
| inthewings
| Friday 09:35
| Tegel (TXL)
| TK 1721
| from IST
|-
| Hugo Beauzée-Luyssen
| chouquette
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Alexandre Perraud
| corbax
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Geoffrey Métais
| dekans
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Duncan McNamara
| skantes
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Thomas Guillem
| tguillem
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Thomas Nigro
| tnigro
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Ludovic Fauvet
| etix
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Filip Roséen
| refp
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Denis Charmet
| TypX
| Friday 10:55
| Flughafen Tegel (TXL)
| 4U 8407
| from CDG
|-
|}

= Departures =
Please order chronologically by time of departure.

{| border="1" class="sortable"
! Name
! IRC
! Time of departure
! Port of embarkment
! Vessel
! Notes
|-
| Konstantin Pavlov
| thresh
| Sunday 13:00
| Flughafen Tegel (TXL)
| AB 7248
| to JFK
|-
| François Cartegnie
| inthewings
| Sunday 15:15
| Schönefeld (SXF)
| U2 4372
| to LYS
|-
| Martin Storsjö
| wbs
| Sunday 18:10
| Flughafen Tegel (TXL)
| AB 8078
| to HEL
|-
| Denis Charmet
| TypX
| Sunday 18:10
| Flughafen Tegel (TXL)
| 4U 8404
| to CDG
|-
| Hugo Beauzée-Luyssen
| chouquette
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Alexandre Perraud
| corbax
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Geoffrey Métais
| dekans
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Duncan McNamara
| skantes
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Thomas Guillem
| tguillem
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Thomas Nigro
| tnigro
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Ludovic Fauvet
| etix
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Filip Roséen
| refp
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Jean-Baptiste Kempf
| j-b
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Felix Paul Kühne
| feepk
| Sunday 20:23
| Hauptbahnhof
| ICE 2504 / IC 2021
| to BRE via HAM
|-
| Rémi Denis-Courmont
| courmisch
| Sunday 21:25
| Flughafen Tegel (TXL)
| AB 8070
| to HEL
|-
| Henrik Gramner
| Gramner
| Monday 12:40
| Flughafen Tegel (TXL)
| AB 8004
| to ARN
|-
| Vittorio Giovara
| koda
| Monday afternoon
| Schönefeld (SXF)
| easyjet
| to NCE
|-
| Janne Grunau
| jannau
| probably Wednesday 18:00
| Central Station
| ICE Sprinter
| to Karlsruhe
|-
|}

= Locals =
People who do not need to travel:

VDD16/Attendees

2016-08-31T16:20:04Z

Gramner: /* Arrivals */

Back to [[VDD16|main VDD page]].

= Arrivals =
Please order chronologically by time of arrival.

{| border="1" class="sortable"
! Name
! IRC
! Time of arrival
! Port of disembarkment
! Vessel
! Notes
|-
| Janne Grunau
| jannau
| Wednesday 22:27
| Central Station
| ICE1090
| from Karlsruhe
|-
| Vittorio Giovara
| koda
| Thursday 8.00
| Flughafen Tegel (TXL)
| UA 692
| from NWR
|-
| Jean-Baptiste Kempf
| j-b
| Thursday 10:25
| Flughafen Tegel (TXL)
| AB 8301
| from ORY
|-
| Henrik Gramner
| Gramner
| Thursday 12:10
| Flughafen Tegel (TXL)
| AB 8003
| from ARN
|-
| Felix Paul Kühne
| feepk
| Thursday afternoon
| Hauptbahnhof
| ICE lines 6 or 8
| from BRE via HAJ
|-
| Rémi Denis-Courmont
| courmisch
| Thursday 20:40
| Flughafen Tegel (TXL)
| AB 8077
| from HEL
|-
| Martin Storsjö
| wbs
| Thursday 20:40
| Flughafen Tegel (TXL)
| AB 8077
| from HEL
|-
| Konstantin Pavlov
| thresh
| Thursday 21:20
| Schönefeld (SXF)
| SU 2316
| from SVO
|-
| François Cartegnie
| inthewings
| Friday 09:35
| Tegel (TXL)
| TK 1721
| from IST
|-
| Hugo Beauzée-Luyssen
| chouquette
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Alexandre Perraud
| corbax
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Geoffrey Métais
| dekans
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Duncan McNamara
| skantes
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Thomas Guillem
| tguillem
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Thomas Nigro
| tnigro
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Ludovic Fauvet
| etix
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Filip Roséen
| refp
| Friday 10:25
| Tegel (TXL)
| AB 8301
| From ORY
|-
| Denis Charmet
| TypX
| Friday 10:55
| Flughafen Tegel (TXL)
| 4U 8407
| from CDG
|-
|}

= Departures =
Please order chronologically by time of departure.

{| border="1" class="sortable"
! Name
! IRC
! Time of departure
! Port of embarkment
! Vessel
! Notes
|-
| Konstantin Pavlov
| thresh
| Sunday 13:00
| Flughafen Tegel (TXL)
| AB 7248
| to JFK
|-
| François Cartegnie
| inthewings
| Sunday 15:15
| Schönefeld (SXF)
| U2 4372
| to LYS
|-
| Martin Storsjö
| wbs
| Sunday 18:10
| Flughafen Tegel (TXL)
| AB 8078
| to HEL
|-
| Denis Charmet
| TypX
| Sunday 18:10
| Flughafen Tegel (TXL)
| 4U 8404
| to CDG
|-
| Hugo Beauzée-Luyssen
| chouquette
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Alexandre Perraud
| corbax
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Geoffrey Métais
| dekans
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Duncan McNamara
| skantes
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Thomas Guillem
| tguillem
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Thomas Nigro
| tnigro
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Ludovic Fauvet
| etix
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Filip Roséen
| refp
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Jean-Baptiste Kempf
| j-b
| Sunday 18:35
| Flughafen Tegel (TXL)
| AB 8308
| to ORY
|-
| Felix Paul Kühne
| feepk
| Sunday 20:23
| Hauptbahnhof
| ICE 2504 / IC 2021
| to BRE via HAM
|-
| Rémi Denis-Courmont
| courmisch
| Sunday 21:25
| Flughafen Tegel (TXL)
| AB 8070
| to HEL
|-
| Vittorio Giovara
| koda
| Monday afternoon
| Schönefeld (SXF)
| easyjet
| to NCE
|-
| Janne Grunau
| jannau
| probably Wednesday 18:00
| Central Station
| ICE Sprinter
| to Karlsruhe
|-
|}

= Locals =
People who do not need to travel:

X264 TODO

2016-02-23T21:20:10Z

Gramner: Remove section about holger

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?

=== Other assembly ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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]
*Support for SMPTE timecodes
*Merge speedcontrol
*Mixed lossless/lossy encoding.
*Segment re-encoding

=== x264CLI ===

*Finish audio support. Talk to Kovensky about this one.
*Make the filtering system aware of BT.601 vs BT.709.
*Use libavfilter instead of duplicating the filters in x264.
*Add --device support.
*Add automatic --level restriction support.

[[Category:x264]]

X264 TODO

2016-02-23T21:17:44Z

Gramner: /* Other features */ Remove xvp8

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?

=== x86 assembly ===

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

=== Other assembly ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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]
*Support for SMPTE timecodes
*Merge speedcontrol
*Mixed lossless/lossy encoding.
*Segment re-encoding

=== x264CLI ===

*Finish audio support. Talk to Kovensky about this one.
*Make the filtering system aware of BT.601 vs BT.709.
*Use libavfilter instead of duplicating the filters in x264.
*Add --device support.
*Add automatic --level restriction support.

[[Category:x264]]

X264 TODO

2016-02-23T21:15:22Z

Gramner: /* x264CLI */ Libavfilter support

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?

=== x86 assembly ===

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

=== Other assembly ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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

=== x264CLI ===

*Finish audio support. Talk to Kovensky about this one.
*Make the filtering system aware of BT.601 vs BT.709.
*Use libavfilter instead of duplicating the filters in x264.
*Add --device support.
*Add automatic --level restriction support.

[[Category:x264]]

X264 TODO

2016-02-23T21:13:28Z

Gramner: /* x264CLI */ L-SMASH support has been committed

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?

=== x86 assembly ===

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

=== Other assembly ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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

=== 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?
*Add --device support.
*Add automatic --level restriction support.

[[Category:x264]]

X264 TODO

2016-02-23T21:10:13Z

Gramner: /* GPU */ OpenCL lookahead was commited years ago

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?

=== x86 assembly ===

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

=== Other assembly ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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

=== 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 --device support.
*Add automatic --level restriction support.

[[Category:x264]]

X264 TODO

2016-02-23T21:09:01Z

Gramner: /* Other assembly */ Drop mentions of SPARC

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 ===

* A lot of ARM assembly is done. Missing is mostly for Hi-Depth bitrate.
* Altivec assembly is very lacking.

=== 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

=== 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 --device support.
*Add automatic --level restriction support.

[[Category:x264]]

VDD15

2015-09-20T08:35:36Z

Gramner: /* Sunday, September 20th 2015 */

= Welcome to VideoLAN Dev Days 2015 =

'''The Open Multimedia Conference that frees the cone in you!'''

This is a technical un-conference; please bring laptops, power cords, power extensions, RJ45 cables and a '''good mood''' with you.

= Schedule =
Download a printable copy [http://images.videolan.org/images/events/VDD15.pdf here].

== Thursday, September 17th 2015 ==

Nothing is prepared for that day, but for people early at the hotel, we will get drinks at the hotel, at around 21:00.

Find Felix :D

== Friday, September 18th 2015 ==

=== Community day ===
If you subscribed for the community day, you should have received instructions by e-mail.

Meeting point is '''at''' EuroDisney at '''9:45'''. The theme park opens at '''10:00''' and closes at '''21:00'''.

We will leave from the park at '''18:30'''

==== How to get there ====
The best option is to take the Metro/RER. This takes approximately 1 hour and 5 minutes:
* take metro ''Line 13'' from the hotel to '''St Lazare''', then
* take metro ''Line 3'' from '''St Lazare''' to '''Havre-Caumartin''' (1 stop only),
* take the express train ''RER A'' to '''Marne La Vallée-Chessy'''
** check on the platform display before boarding: not all trains go to Marne La Vallée-Chessy!

'''N.B.:''' You should buy a ticket to Marne La Vallée at the metro station. The ticket is valid for the entire journey.

=== Evening drinks ===
We will meet at a bar, in front of the hotel, for drinks (soft and beers), at around '''20:30'''.

'''L'Industrie'''

125 boulevard Bessières
75017 Paris

== Saturday, September 19th 2015 ==

=== Morning ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time || Description
|-
| '''8:45 - 9:45''' || Registration and Breakfast
|-
| '''9:45 - 10:00''' || '''Opening remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''10:00 - 10:45''' || '''Daala''' by Timothy Terriberry ''(Mozilla)''
|-
| '''10:45 - 11:10''' || '''A new AAC free and open-source encoder''' by Rostislav Pehlivanov ''(FFmpeg)''
|-
| '''11:10 - 11:20''' || ''Coffee break''
|-
| '''11:20 - 11:55''' || '''New video compression techniques under consideration for VP10''' by Alex Converse ''(Google)''
|-
| '''11:55 - 12:25''' || '''An update to x265''' by Deepthi Nandakumar ''(MCW)''
|-
| '''12:25 - 12:30''' || '''Spice''' by Lord Julien Navas ''(Vodkaster)''
|}

=== Afternoon ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time !! Description
|-
| '''14:10 - 14:50''' || '''VLC 3.0''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''14:50 - 15:30''' || '''The Thor Codec''' by Thomas Davies ''(Cisco)''
|-
| '''15:30 - 15:40''' || ''Coffee break''
|-
| '''15:40 - 16:00''' || '''How to optimize press coverage for FLOSS projects''' by Sebastian Grüner ''(golem.de)''
|-
| '''16:00 - 16:20''' || '''VP9 encoding/decoding performance vs. H.264/HEVC''' by Ronald Bultje ''(FFmpeg)''
|-
| '''16:20 - 18:00''' || ''Break-out sessions''
|}

'''GROUP PHOTO''' at '''18:00''', before the VideoLAN meeting!

==== Break-out sessions, Saturday ====
{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 16:30 - 17:30
|
| '''VLC technical discussion'''
| FFmpeg
| Libav
|
|-
! 17:30 - 18:00
|
| VLC Mobile Ports discussion
| FFmpeg
| Generic Hacking
|
|-
! 18:10 - 19:40
|
| '''VideoLAN annual meeting''' Assemblée Générale Ordinaire, Assemblée Générale Extraordinaire && Réunion 
This is for '''VideoLAN non-profit''' members.
|
|
|
|}

=== Dinner ===
Dinner is at '''20:00''' next to the place, at The Royal Trinité.

59 Rue de Châteaudun, 75009 Paris, France

[https://goo.gl/maps/30dCb Royal Trinité]

You '''must''' choose your food before, by [http://goo.gl/forms/4yZx5l8bZg selecting here].

== Sunday, September 20th 2015 ==

{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 15%;"| Auditorium
! style="width: 15%;"| Room 1
! style="width: 15%;"| Room 2
! style="width: 15%;"| Room 3
! style="width: 15%;"| Room 4
! style="width: 15%;"| Room 5
|-
! 9:30 - 10:00
| colspan="5" | ''Breakfast''
|-
! 10:00 - 10:45
|
| Localisation/Weblate
| VLC/iOS meetup
| FFmpeg general meeting
| Libav
| Daala hackathon
|-
! 10:45 - 11:30
|
|
| VLC/Android meetup
| FFmpeg general meeting
| x264 meeting
| Daala hackathon
|-
! 11:30 - 11:45
| colspan="5" | ''Coffee break''
|-
! 11:45 - 12:45
| ''nothing''
|
|
|
|
| Daala hackathon
|-
! 12:45 - 14:00
| colspan="5" | ''Lunch break''
|-
! 14:00 - 14:45
|
| FFmpeg / Libav discussion? Possibly with just Ff/av devels and jb to mod
|
|
|
|
|-
! 14:45 - 15:30
|
| FFmpeg / Libav discussion?
|
|
|
|
|-
! 15:30 - 15:45
| '''Closing Remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
| —
| —
| —
| —
| —
|-
! 15:45 - 17:00
|
| open source music production
|
|
|
|
|-
! 17:00 - 18:00
|
|
|
| VideoLAN '''roots''' meeting
|
|
|}

=== Daala hackathon ===
Open to anyone curious about Daala or video coding in general, we can help you write your first patch or teach you things!

To get started you can clone the Daala repository:

<code>
git clone https://github.com/xiph/daala.git
</code>

* How to build and run Daala: https://wiki.xiph.org/Daala_Quickstart
* Demonstrations and explanations of some of the techniques used in Daala: https://people.xiph.org/~xiphmont/demo/
** Note that some of the older demos do not match what is in Daala anymore.
** For more details see https://wiki.xiph.org/Daala#Documents and https://wiki.xiph.org/Daala#Presentations
* Easy bugs to fix: https://github.com/xiph/daala/labels/easy

=== Dinner ===
Around 19:00 at ''Au Metro''.

19 Rue de Malte, 75011 Paris
Metro ''Filles du Calvaire'' or ''Oberkampf''

This dinner is '''not''' sponsored by VideoLAN.

= Practical information =

== Emergency situation ==
In case of emergency, call the European emergency number '''112'''.

== Location / main venue ==
The venue is in Paris (France), 9th district, near St Lazare:

Criteo 
32 rue Blanche 
75009 Paris, France

[https://www.google.fr/maps/place/Criteo/@48.878914,2.3315591,17z/data=!4m6!1m3!3m2!1s0x47e66e04d509ec8f:0xbf35e94464e752f7!2sCriteo!3m1!1s0x47e66e04d509ec8f:0xbf35e94464e752f7 Google Maps]

== Accomodation / Hotel ==
For sponsored participants, the hotel is:

Timhotel Berthier Paris 17 
4 Boulevard Berthier 
75017 Paris, France

http://www.timhotel-berthier-paris-17.com/ 
[https://www.google.fi/maps/place/Timhotel+Berthier+Paris+17/@48.894398,2.312611,17z/data=!3m1!4b1!4m2!3m1!1s0x47e66f9878ba126d:0x24a180f7131eebe5 Google Maps]

== Payment ==
The local currency is the Euro. Merchants are forbidden from accepting other currencies (except exchange).

Most venues will accept EMV credit and debit cards (i.e. Chip & PIN), at least VISA and MasterCard. Swipe-only cards can be more tricky (it has been illegal for banks to issue them for years in France, so only foreign visitors use them). American Express is widely but not universally accepted. Diners/Discovery, UnionPay, JCB, etc. are mostly only accepted in shops catering to tourists.

Best change rates are close to the Hotel, Metro Bourse, Vivienne Street.

== Transportation ==

* Public transport: [http://www.ratp.fr/itineraires/en/ratp/recherche-avancee RATP]
* Attendees arrival & departure list: [[VDD15/Attendees]]

'''NOTE''': VideoLAN does not refund taxi expenses nor car rentals.

=== Paris-CDG / Roissy airport ===

'''Important note:''' there are works on the RER B line at night until Friday, included. The RER B service is interrupted between the airport and the Aulnay-sous-Bois station at 11pm. There is a replacement bus available but this incurs a much higher trip time. More information: http://www.transilien.com/contents/fr/Docs---PDF/Travaux/20150720-B-Roissy-2007au3010bis.pdf

[[Image:Paris_Metro_box.jpg|thumb|175px|Ticket vending machines]]

* Upon landing, follow the signs for local trains. There is one station for T1/T3 and one for T2 (A-G).
* At the station, look for '''red/green''' ticket vending machines.
** Do not use the yellow/grey machines (at terminal 2), those are for long distance trains only.
* Buy a ticket for zones 1-5 (to Paris). The cost is 10€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the regional express(RER) line B (blue). You can use any train toward Paris.
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

* 2€ Alternative From/To ''Palais Royal /Louvre'': http://www.easybus.com/fr/paris-cdg (online booking), takes 50min

=== Orly (ORY) airport ===
* Upon landing, follow the signs for Orlyval.
* At the station, buy the ticket from the vending machines, before boarding.
* Buy a ticket for Paris. The cost is 12€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the Orlyval to Antony. Then take the regional express(RER) line B (blue) to Paris (Direction Charles de Gaulle Airport).
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

=== Beauvais (BVA) airport ===
We feel sorry for you. Take the bus.

=== Gare du Nord (North railway station) ===

If you arrive at Gare du Nord or Gare de l'Est, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====
* Transfer to regional express train (RER) line E (magenta) toward ''Haussmann St Lazare''.
* Alight at the final stop, ''Haussman St Lazare''.

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
** Check the metro destination, as there are two branches on the line. DO NOT go toward Saint Denis.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Gare de l'Est (East railway station) ===
Routes are essentially the same as from Gare du Nord. The Magenta express train station is located between Gare du Nord and Gare de l'Est. See above.

=== Gare de Lyon (South/East railway station) ===
If you arrive at Gare de Lyon, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====

* Take subway(M) '''line 14''' toward ''Saint Lazare''
* Alight at the final stop '''Saint Lazare''' (5 stops)

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Other? ===

== From the hotel to the conference ==
* Take subway(M) line 13 toward ''Chatillon-Montrouge''
* Get off at ''Liège'' and walk

Feel free to ask for advice on the mailing list if your station is missing.

== Connectivity ==

=== Power supply ===

The AC power sockets are "French" '''IEC type E'''. Connectors from "German" '''IEC type F''' countries should fit safely, as they are usually bi-standards. There should have a hole for the French-style ground pin.

The electrical system is '''220V / 50Hz'''. If you come from outside Europe, please make sure your devices are compatible beforehand.

=== Internet ===
Hopefully, there will be Wi-Fi.

== Weather forecast ==

:Fri Sep 18 Occasional rain 20°C Low 12°C
:Sat Sep 19 Occasional rain 19°C Low 10°C
:Sun Sep 20 Fog 20°C Low 12°C
:Mon Sep 21 Mostly cloudy 18°C Low 12°C

In Fahrenheit, this is a high of 64°F-66°F and a low of 50°F.

[[Category:About VideoLAN]]

VDD15

2015-09-20T08:32:15Z

Gramner: /* Sunday, September 20th 2015 */

= Welcome to VideoLAN Dev Days 2015 =

'''The Open Multimedia Conference that frees the cone in you!'''

This is a technical un-conference; please bring laptops, power cords, power extensions, RJ45 cables and a '''good mood''' with you.

= Schedule =
Download a printable copy [http://images.videolan.org/images/events/VDD15.pdf here].

== Thursday, September 17th 2015 ==

Nothing is prepared for that day, but for people early at the hotel, we will get drinks at the hotel, at around 21:00.

Find Felix :D

== Friday, September 18th 2015 ==

=== Community day ===
If you subscribed for the community day, you should have received instructions by e-mail.

Meeting point is '''at''' EuroDisney at '''9:45'''. The theme park opens at '''10:00''' and closes at '''21:00'''.

We will leave from the park at '''18:30'''

==== How to get there ====
The best option is to take the Metro/RER. This takes approximately 1 hour and 5 minutes:
* take metro ''Line 13'' from the hotel to '''St Lazare''', then
* take metro ''Line 3'' from '''St Lazare''' to '''Havre-Caumartin''' (1 stop only),
* take the express train ''RER A'' to '''Marne La Vallée-Chessy'''
** check on the platform display before boarding: not all trains go to Marne La Vallée-Chessy!

'''N.B.:''' You should buy a ticket to Marne La Vallée at the metro station. The ticket is valid for the entire journey.

=== Evening drinks ===
We will meet at a bar, in front of the hotel, for drinks (soft and beers), at around '''20:30'''.

'''L'Industrie'''

125 boulevard Bessières
75017 Paris

== Saturday, September 19th 2015 ==

=== Morning ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time || Description
|-
| '''8:45 - 9:45''' || Registration and Breakfast
|-
| '''9:45 - 10:00''' || '''Opening remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''10:00 - 10:45''' || '''Daala''' by Timothy Terriberry ''(Mozilla)''
|-
| '''10:45 - 11:10''' || '''A new AAC free and open-source encoder''' by Rostislav Pehlivanov ''(FFmpeg)''
|-
| '''11:10 - 11:20''' || ''Coffee break''
|-
| '''11:20 - 11:55''' || '''New video compression techniques under consideration for VP10''' by Alex Converse ''(Google)''
|-
| '''11:55 - 12:25''' || '''An update to x265''' by Deepthi Nandakumar ''(MCW)''
|-
| '''12:25 - 12:30''' || '''Spice''' by Lord Julien Navas ''(Vodkaster)''
|}

=== Afternoon ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time !! Description
|-
| '''14:10 - 14:50''' || '''VLC 3.0''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''14:50 - 15:30''' || '''The Thor Codec''' by Thomas Davies ''(Cisco)''
|-
| '''15:30 - 15:40''' || ''Coffee break''
|-
| '''15:40 - 16:00''' || '''How to optimize press coverage for FLOSS projects''' by Sebastian Grüner ''(golem.de)''
|-
| '''16:00 - 16:20''' || '''VP9 encoding/decoding performance vs. H.264/HEVC''' by Ronald Bultje ''(FFmpeg)''
|-
| '''16:20 - 18:00''' || ''Break-out sessions''
|}

'''GROUP PHOTO''' at '''18:00''', before the VideoLAN meeting!

==== Break-out sessions, Saturday ====
{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 16:30 - 17:30
|
| '''VLC technical discussion'''
| FFmpeg
| Libav
|
|-
! 17:30 - 18:00
|
| VLC Mobile Ports discussion
| FFmpeg
| Generic Hacking
|
|-
! 18:10 - 19:40
|
| '''VideoLAN annual meeting''' Assemblée Générale Ordinaire, Assemblée Générale Extraordinaire && Réunion 
This is for '''VideoLAN non-profit''' members.
|
|
|
|}

=== Dinner ===
Dinner is at '''20:00''' next to the place, at The Royal Trinité.

59 Rue de Châteaudun, 75009 Paris, France

[https://goo.gl/maps/30dCb Royal Trinité]

You '''must''' choose your food before, by [http://goo.gl/forms/4yZx5l8bZg selecting here].

== Sunday, September 20th 2015 ==

{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 15%;"| Auditorium
! style="width: 15%;"| Room 1
! style="width: 15%;"| Room 2
! style="width: 15%;"| Room 3
! style="width: 15%;"| Room 4
! style="width: 15%;"| Room 5
|-
! 9:30 - 10:00
| colspan="5" | ''Breakfast''
|-
! 10:00 - 10:45
|
| VLC/iOS meetup
| Localisation/Weblate
| FFmpeg general meeting
|
| Daala hackathon
|-
! 10:45 - 11:30
|
| VLC/Android meetup
|
| FFmpeg general meeting
| x264 meeting
| Daala hackathon
|-
! 11:30 - 11:45
| colspan="5" | ''Coffee break''
|-
! 11:45 - 12:45
| ''nothing''
|
|
|
|
| Daala hackathon
|-
! 12:45 - 14:00
| colspan="5" | ''Lunch break''
|-
! 14:00 - 14:45
|
| FFmpeg / Libav discussion? Possibly with just Ff/av devels and jb to mod
|
|
|
|
|-
! 14:45 - 15:30
|
| FFmpeg / Libav discussion?
|
|
|
|
|-
! 15:30 - 15:45
| '''Closing Remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
| —
| —
| —
| —
| —
|-
! 15:45 - 17:00
|
| open source music production
|
|
|
|
|-
! 17:00 - 18:00
|
|
|
| VideoLAN '''roots''' meeting
|
|
|}

=== Daala hackathon ===
Open to anyone curious about Daala or video coding in general, we can help you write your first patch or teach you things!

To get started you can clone the Daala repository:

<code>
git clone https://github.com/xiph/daala.git
</code>

* How to build and run Daala: https://wiki.xiph.org/Daala_Quickstart
* Demonstrations and explanations of some of the techniques used in Daala: https://people.xiph.org/~xiphmont/demo/
** Note that some of the older demos do not match what is in Daala anymore.
** For more details see https://wiki.xiph.org/Daala#Documents and https://wiki.xiph.org/Daala#Presentations
* Easy bugs to fix: https://github.com/xiph/daala/labels/easy

=== Dinner ===
Around 19:00 at ''Au Metro''.

19 Rue de Malte, 75011 Paris
Metro ''Filles du Calvaire'' or ''Oberkampf''

This dinner is '''not''' sponsored by VideoLAN.

= Practical information =

== Emergency situation ==
In case of emergency, call the European emergency number '''112'''.

== Location / main venue ==
The venue is in Paris (France), 9th district, near St Lazare:

Criteo 
32 rue Blanche 
75009 Paris, France

[https://www.google.fr/maps/place/Criteo/@48.878914,2.3315591,17z/data=!4m6!1m3!3m2!1s0x47e66e04d509ec8f:0xbf35e94464e752f7!2sCriteo!3m1!1s0x47e66e04d509ec8f:0xbf35e94464e752f7 Google Maps]

== Accomodation / Hotel ==
For sponsored participants, the hotel is:

Timhotel Berthier Paris 17 
4 Boulevard Berthier 
75017 Paris, France

http://www.timhotel-berthier-paris-17.com/ 
[https://www.google.fi/maps/place/Timhotel+Berthier+Paris+17/@48.894398,2.312611,17z/data=!3m1!4b1!4m2!3m1!1s0x47e66f9878ba126d:0x24a180f7131eebe5 Google Maps]

== Payment ==
The local currency is the Euro. Merchants are forbidden from accepting other currencies (except exchange).

Most venues will accept EMV credit and debit cards (i.e. Chip & PIN), at least VISA and MasterCard. Swipe-only cards can be more tricky (it has been illegal for banks to issue them for years in France, so only foreign visitors use them). American Express is widely but not universally accepted. Diners/Discovery, UnionPay, JCB, etc. are mostly only accepted in shops catering to tourists.

Best change rates are close to the Hotel, Metro Bourse, Vivienne Street.

== Transportation ==

* Public transport: [http://www.ratp.fr/itineraires/en/ratp/recherche-avancee RATP]
* Attendees arrival & departure list: [[VDD15/Attendees]]

'''NOTE''': VideoLAN does not refund taxi expenses nor car rentals.

=== Paris-CDG / Roissy airport ===

'''Important note:''' there are works on the RER B line at night until Friday, included. The RER B service is interrupted between the airport and the Aulnay-sous-Bois station at 11pm. There is a replacement bus available but this incurs a much higher trip time. More information: http://www.transilien.com/contents/fr/Docs---PDF/Travaux/20150720-B-Roissy-2007au3010bis.pdf

[[Image:Paris_Metro_box.jpg|thumb|175px|Ticket vending machines]]

* Upon landing, follow the signs for local trains. There is one station for T1/T3 and one for T2 (A-G).
* At the station, look for '''red/green''' ticket vending machines.
** Do not use the yellow/grey machines (at terminal 2), those are for long distance trains only.
* Buy a ticket for zones 1-5 (to Paris). The cost is 10€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the regional express(RER) line B (blue). You can use any train toward Paris.
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

* 2€ Alternative From/To ''Palais Royal /Louvre'': http://www.easybus.com/fr/paris-cdg (online booking), takes 50min

=== Orly (ORY) airport ===
* Upon landing, follow the signs for Orlyval.
* At the station, buy the ticket from the vending machines, before boarding.
* Buy a ticket for Paris. The cost is 12€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the Orlyval to Antony. Then take the regional express(RER) line B (blue) to Paris (Direction Charles de Gaulle Airport).
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

=== Beauvais (BVA) airport ===
We feel sorry for you. Take the bus.

=== Gare du Nord (North railway station) ===

If you arrive at Gare du Nord or Gare de l'Est, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====
* Transfer to regional express train (RER) line E (magenta) toward ''Haussmann St Lazare''.
* Alight at the final stop, ''Haussman St Lazare''.

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
** Check the metro destination, as there are two branches on the line. DO NOT go toward Saint Denis.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Gare de l'Est (East railway station) ===
Routes are essentially the same as from Gare du Nord. The Magenta express train station is located between Gare du Nord and Gare de l'Est. See above.

=== Gare de Lyon (South/East railway station) ===
If you arrive at Gare de Lyon, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====

* Take subway(M) '''line 14''' toward ''Saint Lazare''
* Alight at the final stop '''Saint Lazare''' (5 stops)

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Other? ===

== From the hotel to the conference ==
* Take subway(M) line 13 toward ''Chatillon-Montrouge''
* Get off at ''Liège'' and walk

Feel free to ask for advice on the mailing list if your station is missing.

== Connectivity ==

=== Power supply ===

The AC power sockets are "French" '''IEC type E'''. Connectors from "German" '''IEC type F''' countries should fit safely, as they are usually bi-standards. There should have a hole for the French-style ground pin.

The electrical system is '''220V / 50Hz'''. If you come from outside Europe, please make sure your devices are compatible beforehand.

=== Internet ===
Hopefully, there will be Wi-Fi.

== Weather forecast ==

:Fri Sep 18 Occasional rain 20°C Low 12°C
:Sat Sep 19 Occasional rain 19°C Low 10°C
:Sun Sep 20 Fog 20°C Low 12°C
:Mon Sep 21 Mostly cloudy 18°C Low 12°C

In Fahrenheit, this is a high of 64°F-66°F and a low of 50°F.

[[Category:About VideoLAN]]

VDD15

2015-09-19T16:27:45Z

Gramner: /* Break-out sessions, Saturday */

= Welcome to VideoLAN Dev Days 2015 =

'''The Open Multimedia Conference that frees the cone in you!'''

This is a technical un-conference; please bring laptops, power cords, power extensions, RJ45 cables and a '''good mood''' with you.

= Schedule =
Download a printable copy [http://images.videolan.org/images/events/VDD15.pdf here].

== Thursday, September 17th 2015 ==

Nothing is prepared for that day, but for people early at the hotel, we will get drinks at the hotel, at around 21:00.

Find Felix :D

== Friday, September 18th 2015 ==

=== Community day ===
If you subscribed for the community day, you should have received instructions by e-mail.

Meeting point is '''at''' EuroDisney at '''9:45'''. The theme park opens at '''10:00''' and closes at '''21:00'''.

We will leave from the park at '''18:30'''

==== How to get there ====
The best option is to take the Metro/RER. This takes approximately 1 hour and 5 minutes:
* take metro ''Line 13'' from the hotel to '''St Lazare''', then
* take metro ''Line 3'' from '''St Lazare''' to '''Havre-Caumartin''' (1 stop only),
* take the express train ''RER A'' to '''Marne La Vallée-Chessy'''
** check on the platform display before boarding: not all trains go to Marne La Vallée-Chessy!

'''N.B.:''' You should buy a ticket to Marne La Vallée at the metro station. The ticket is valid for the entire journey.

=== Evening drinks ===
We will meet at a bar, in front of the hotel, for drinks (soft and beers), at around '''20:30'''.

'''L'Industrie'''

125 boulevard Bessières
75017 Paris

== Saturday, September 19th 2015 ==

=== Morning ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time || Description
|-
| '''8:45 - 9:45''' || Registration and Breakfast
|-
| '''9:45 - 10:00''' || '''Opening remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''10:00 - 10:45''' || '''Daala''' by Timothy Terriberry ''(Mozilla)''
|-
| '''10:45 - 11:10''' || '''A new AAC free and open-source encoder''' by Rostislav Pehlivanov ''(FFmpeg)''
|-
| '''11:10 - 11:20''' || ''Coffee break''
|-
| '''11:20 - 11:55''' || '''New video compression techniques under consideration for VP10''' by Alex Converse ''(Google)''
|-
| '''11:55 - 12:25''' || '''An update to x265''' by Deepthi Nandakumar ''(MCW)''
|-
| '''12:25 - 12:30''' || '''Spice''' by Lord Julien Navas ''(Vodkaster)''
|}

=== Afternoon ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time !! Description
|-
| '''14:10 - 14:50''' || '''VLC 3.0''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''14:50 - 15:30''' || '''The Thor Codec''' by Thomas Davies ''(Cisco)''
|-
| '''15:30 - 15:40''' || ''Coffee break''
|-
| '''15:40 - 16:00''' || '''How to optimize press coverage for FLOSS projects''' by Sebastian Grüner ''(golem.de)''
|-
| '''16:00 - 16:20''' || '''VP9 encoding/decoding performance vs. H.264/HEVC''' by Ronald Bultje ''(FFmpeg)''
|-
| '''16:20 - 18:00''' || ''Break-out sessions''
|}

'''GROUP PHOTO''' at '''18:00''', before the VideoLAN meeting!

==== Break-out sessions, Saturday ====
{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 16:30 - 17:30
|
| '''VLC technical discussion'''
| FFmpeg
| Libav
|
|-
! 17:30 - 18:00
|
| VLC Mobile Ports discussion
| FFmpeg
| Generic Hacking
|
|-
! 18:10 - 19:40
|
| '''VideoLAN annual meeting''' Assemblée Générale Ordinaire, Assemblée Générale Extraordinaire && Réunion 
This is for '''VideoLAN non-profit''' members.
|
|
|
|}

=== Dinner ===
Dinner is at '''20:00''' next to the place, at The Royal Trinité.

59 Rue de Châteaudun, 75009 Paris, France

[https://goo.gl/maps/30dCb Royal Trinité]

You '''must''' choose your food before, by [http://goo.gl/forms/4yZx5l8bZg selecting here].

== Sunday, September 20th 2015 ==

{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 9:30 - 10:00
| colspan="5" | ''Breakfast''
|-
! 10:00 - 10:45
|
| VLC/iOS meetup
| Localisation/Weblate
| FFmpeg general meeting
|
|-
! 10:45 - 11:30
|
| VLC/Android meetup
|
| FFmpeg general meeting
|
|-
! 11:30 - 11:45
| colspan="5" | ''Coffee break''
|-
! 11:45 - 12:45
| ''3d expo showing off''
|
|
|
|
|-
! 12:45 - 14:00
| colspan="5" | ''Lunch break''
|-
! 14:00 - 14:45
|
|
| x264 meeting
| FFmpeg / Libav discussion?
|
|-
! 14:45 - 15:30
|
|
|
| FFmpeg / Libav discussion?
|
|-
! 15:30 - 15:45
| '''Closing Remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
| —
| —
| —
| —
|-
! 15:45 - 17:00
|
|
|
|
|
|-
! 17:00 - 18:00
|
|
|
| VideoLAN '''roots''' meeting
|
|}

=== Dinner ===
Around 19:00 at ''Au Metro''.

19 Rue de Malte, 75011 Paris
Metro ''Filles du Calvaire'' or ''Oberkampf''

This dinner is '''not''' sponsored by VideoLAN.

= Practical information =

== Emergency situation ==
In case of emergency, call the European emergency number '''112'''.

== Location / main venue ==
The venue is in Paris (France), 9th district, near St Lazare:

Criteo 
32 rue Blanche 
75009 Paris, France

[https://www.google.fr/maps/place/Criteo/@48.878914,2.3315591,17z/data=!4m6!1m3!3m2!1s0x47e66e04d509ec8f:0xbf35e94464e752f7!2sCriteo!3m1!1s0x47e66e04d509ec8f:0xbf35e94464e752f7 Google Maps]

== Accomodation / Hotel ==
For sponsored participants, the hotel is:

Timhotel Berthier Paris 17 
4 Boulevard Berthier 
75017 Paris, France

http://www.timhotel-berthier-paris-17.com/ 
[https://www.google.fi/maps/place/Timhotel+Berthier+Paris+17/@48.894398,2.312611,17z/data=!3m1!4b1!4m2!3m1!1s0x47e66f9878ba126d:0x24a180f7131eebe5 Google Maps]

== Payment ==
The local currency is the Euro. Merchants are forbidden from accepting other currencies (except exchange).

Most venues will accept EMV credit and debit cards (i.e. Chip & PIN), at least VISA and MasterCard. Swipe-only cards can be more tricky (it has been illegal for banks to issue them for years in France, so only foreign visitors use them). American Express is widely but not universally accepted. Diners/Discovery, UnionPay, JCB, etc. are mostly only accepted in shops catering to tourists.

Best change rates are close to the Hotel, Metro Bourse, Vivienne Street.

== Transportation ==

* Public transport: [http://www.ratp.fr/itineraires/en/ratp/recherche-avancee RATP]
* Attendees arrival & departure list: [[VDD15/Attendees]]

'''NOTE''': VideoLAN does not refund taxi expenses nor car rentals.

=== Paris-CDG / Roissy airport ===

'''Important note:''' there are works on the RER B line at night until Friday, included. The RER B service is interrupted between the airport and the Aulnay-sous-Bois station at 11pm. There is a replacement bus available but this incurs a much higher trip time. More information: http://www.transilien.com/contents/fr/Docs---PDF/Travaux/20150720-B-Roissy-2007au3010bis.pdf

[[Image:Paris_Metro_box.jpg|thumb|175px|Ticket vending machines]]

* Upon landing, follow the signs for local trains. There is one station for T1/T3 and one for T2 (A-G).
* At the station, look for '''red/green''' ticket vending machines.
** Do not use the yellow/grey machines (at terminal 2), those are for long distance trains only.
* Buy a ticket for zones 1-5 (to Paris). The cost is 10€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the regional express(RER) line B (blue). You can use any train toward Paris.
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

* 2€ Alternative From/To ''Palais Royal /Louvre'': http://www.easybus.com/fr/paris-cdg (online booking), takes 50min

=== Orly (ORY) airport ===
* Upon landing, follow the signs for Orlyval.
* At the station, buy the ticket from the vending machines, before boarding.
* Buy a ticket for Paris. The cost is 12€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the Orlyval to Antony. Then take the regional express(RER) line B (blue) to Paris (Direction Charles de Gaulle Airport).
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

=== Beauvais (BVA) airport ===
We feel sorry for you. Take the bus.

=== Gare du Nord (North railway station) ===

If you arrive at Gare du Nord or Gare de l'Est, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====
* Transfer to regional express train (RER) line E (magenta) toward ''Haussmann St Lazare''.
* Alight at the final stop, ''Haussman St Lazare''.

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
** Check the metro destination, as there are two branches on the line. DO NOT go toward Saint Denis.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Gare de l'Est (East railway station) ===
Routes are essentially the same as from Gare du Nord. The Magenta express train station is located between Gare du Nord and Gare de l'Est. See above.

=== Gare de Lyon (South/East railway station) ===
If you arrive at Gare de Lyon, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====

* Take subway(M) '''line 14''' toward ''Saint Lazare''
* Alight at the final stop '''Saint Lazare''' (5 stops)

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Other? ===

== From the hotel to the conference ==
* Take subway(M) line 13 toward ''Chatillon-Montrouge''
* Get off at ''Liège'' and walk

Feel free to ask for advice on the mailing list if your station is missing.

== Connectivity ==

=== Power supply ===

The AC power sockets are "French" '''IEC type E'''. Connectors from "German" '''IEC type F''' countries should fit safely, as they are usually bi-standards. There should have a hole for the French-style ground pin.

The electrical system is '''220V / 50Hz'''. If you come from outside Europe, please make sure your devices are compatible beforehand.

=== Internet ===
Hopefully, there will be Wi-Fi.

== Weather forecast ==

:Fri Sep 18 Occasional rain 20°C Low 12°C
:Sat Sep 19 Occasional rain 19°C Low 10°C
:Sun Sep 20 Fog 20°C Low 12°C
:Mon Sep 21 Mostly cloudy 18°C Low 12°C

In Fahrenheit, this is a high of 64°F-66°F and a low of 50°F.

[[Category:About VideoLAN]]

VDD15

2015-09-19T11:57:49Z

Gramner: /* Sunday, September 20th 2015 */

= Welcome to VideoLAN Dev Days 2015 =

'''The Open Multimedia Conference that frees the cone in you!'''

This is a technical un-conference; please bring laptops, power cords, power extensions, RJ45 cables and a '''good mood''' with you.

= Schedule =
Download a printable copy [http://images.videolan.org/images/events/VDD15.pdf here].

== Thursday, September 17th 2015 ==

Nothing is prepared for that day, but for people early at the hotel, we will get drinks at the hotel, at around 21:00.

Find Felix :D

== Friday, September 18th 2015 ==

=== Community day ===
If you subscribed for the community day, you should have received instructions by e-mail.

Meeting point is '''at''' EuroDisney at '''9:45'''. The theme park opens at '''10:00''' and closes at '''21:00'''.

We will leave from the park at '''18:30'''

==== How to get there ====
The best option is to take the Metro/RER. This takes approximately 1 hour and 5 minutes:
* take metro ''Line 13'' from the hotel to '''St Lazare''', then
* take metro ''Line 3'' from '''St Lazare''' to '''Havre-Caumartin''' (1 stop only),
* take the express train ''RER A'' to '''Marne La Vallée-Chessy'''
** check on the platform display before boarding: not all trains go to Marne La Vallée-Chessy!

'''N.B.:''' You should buy a ticket to Marne La Vallée at the metro station. The ticket is valid for the entire journey.

=== Evening drinks ===
We will meet at a bar, in front of the hotel, for drinks (soft and beers), at around '''20:30'''.

'''L'Industrie'''

125 boulevard Bessières
75017 Paris

== Saturday, September 19th 2015 ==

=== Morning ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time || Description
|-
| '''8:45 - 9:45''' || Registration and Breakfast
|-
| '''9:45 - 10:00''' || '''Opening remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''10:00 - 10:45''' || '''Daala''' by Timothy Terriberry ''(Mozilla)''
|-
| '''10:45 - 11:10''' || '''A new AAC free and open-source encoder''' by Rostislav Pehlivanov ''(FFmpeg)''
|-
| '''11:10 - 11:20''' || ''Coffee break''
|-
| '''11:20 - 11:55''' || '''New video compression techniques under consideration for VP10''' by Alex Converse ''(Google)''
|-
| '''11:55 - 12:25''' || '''An update to x265''' by Deepthi Nandakumar ''(MCW)''
|-
| '''12:25 - 12:30''' || '''Spice''' by Lord Julien Navas ''(Vodkaster)''
|}

=== Afternoon ===

{| class="wikitable" style="width: 100%;"
|-
!style="width: 10%;"| Time !! Description
|-
| '''14:00 - 14:30''' || '''VLC 3.0''' by Jean-Baptiste Kempf ''(VideoLAN)''
|-
| '''14:30 - 15:10''' || '''The Thor Codec''' by Thomas Davies ''(Cisco)''
|-
| '''15:10 - 15:30''' || '''How to optimize press coverage for FLOSS projects''' by Sebastian Grüner ''(golem.de)''
|-
| '''15:30 - 15:50''' || '''VP9 encoding/decoding performance vs. H.264/HEVC''' by Ronald Bultje ''(FFmpeg)''
|-
| '''15:50 - 16:00''' || ''Coffee break''
|-
| '''16:00 - 18:00''' || ''Break-out sessions''
|}

'''GROUP PHOTO''' at '''18:00''', before the VideoLAN meeting!

==== Break-out sessions, Saturday ====
{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 16:00 - 17:00
|
| '''VLC technical discussion'''
|
|
|
|-
! 17:00 - 18:00
|
| VLC Mobile Ports discussion
|
|
|
|-
! 18:10 - 19:40
|
| '''VideoLAN annual meeting''' Assemblée Générale Ordinaire, Assemblée Générale Extraordinaire && Réunion 
This is for '''VideoLAN non-profit''' members.
|
|
|
|}

=== Dinner ===
Dinner is at '''20:00''' next to the place, at The Royal Trinité.

59 Rue de Châteaudun, 75009 Paris, France

[https://goo.gl/maps/30dCb Royal Trinité]

You '''must''' choose your food before, by [http://goo.gl/forms/4yZx5l8bZg selecting here].

== Sunday, September 20th 2015 ==

{| class="wikitable" style="width: 100%; text-align: center"
|-
! style="width: 10%;"| Time
! style="width: 18%;"| Auditorium
! style="width: 18%;"| Room 1
! style="width: 18%;"| Room 2
! style="width: 18%;"| Room 3
! style="width: 18%;"| Room 4
|-
! 9:30 - 10:00
| colspan="5" | ''Breakfast''
|-
! 10:00 - 10:45
|
| VLC/iOS meetup
|
|
|
|-
! 10:45 - 11:30
|
| VLC/Android meetup
|
|
|
|-
! 11:30 - 11:45
| colspan="5" | ''Coffee break''
|-
! 11:45 - 12:45
| ''3d expo showing off''
|
|
|
|
|-
! 12:45 - 14:00
| colspan="5" | ''Lunch break''
|-
! 14:00 - 14:45
|
|
| x264 meeting
|
|
|-
! 14:45 - 15:30
|
|
|
|
|
|-
! 15:30 - 15:45
| '''Closing Remarks''' by Jean-Baptiste Kempf ''(VideoLAN)''
| —
| —
| —
| —
|-
! 15:45 - 17:00
|
|
|
|
|
|-
! 17:00 - 18:00
|
|
|
| VideoLAN '''roots''' meeting
|
|}

=== Dinner ===
Around 19:00 at ''Au Metro''.

19 Rue de Malte, 75011 Paris
Metro ''Filles du Calvaire'' or ''Oberkampf''

This dinner is '''not''' sponsored by VideoLAN.

= Practical information =

== Emergency situation ==
In case of emergency, call the European emergency number '''112'''.

== Location / main venue ==
The venue is in Paris (France), 9th district, near St Lazare:

Criteo 
32 rue Blanche 
75009 Paris, France

[https://www.google.fr/maps/place/Criteo/@48.878914,2.3315591,17z/data=!4m6!1m3!3m2!1s0x47e66e04d509ec8f:0xbf35e94464e752f7!2sCriteo!3m1!1s0x47e66e04d509ec8f:0xbf35e94464e752f7 Google Maps]

== Accomodation / Hotel ==
For sponsored participants, the hotel is:

Timhotel Berthier Paris 17 
4 Boulevard Berthier 
75017 Paris, France

http://www.timhotel-berthier-paris-17.com/ 
[https://www.google.fi/maps/place/Timhotel+Berthier+Paris+17/@48.894398,2.312611,17z/data=!3m1!4b1!4m2!3m1!1s0x47e66f9878ba126d:0x24a180f7131eebe5 Google Maps]

== Payment ==
The local currency is the Euro. Merchants are forbidden from accepting other currencies (except exchange).

Most venues will accept EMV credit and debit cards (i.e. Chip & PIN), at least VISA and MasterCard. Swipe-only cards can be more tricky (it has been illegal for banks to issue them for years in France, so only foreign visitors use them). American Express is widely but not universally accepted. Diners/Discovery, UnionPay, JCB, etc. are mostly only accepted in shops catering to tourists.

Best change rates are close to the Hotel, Metro Bourse, Vivienne Street.

== Transportation ==

* Public transport: [http://www.ratp.fr/itineraires/en/ratp/recherche-avancee RATP]
* Attendees arrival & departure list: [[VDD15/Attendees]]

'''NOTE''': VideoLAN does not refund taxi expenses nor car rentals.

=== Paris-CDG / Roissy airport ===

'''Important note:''' there are works on the RER B line at night until Friday, included. The RER B service is interrupted between the airport and the Aulnay-sous-Bois station at 11pm. There is a replacement bus available but this incurs a much higher trip time. More information: http://www.transilien.com/contents/fr/Docs---PDF/Travaux/20150720-B-Roissy-2007au3010bis.pdf

[[Image:Paris_Metro_box.jpg|thumb|175px|Ticket vending machines]]

* Upon landing, follow the signs for local trains. There is one station for T1/T3 and one for T2 (A-G).
* At the station, look for '''red/green''' ticket vending machines.
** Do not use the yellow/grey machines (at terminal 2), those are for long distance trains only.
* Buy a ticket for zones 1-5 (to Paris). The cost is 10€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the regional express(RER) line B (blue). You can use any train toward Paris.
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

* 2€ Alternative From/To ''Palais Royal /Louvre'': http://www.easybus.com/fr/paris-cdg (online booking), takes 50min

=== Orly (ORY) airport ===
* Upon landing, follow the signs for Orlyval.
* At the station, buy the ticket from the vending machines, before boarding.
* Buy a ticket for Paris. The cost is 12€ one way. Credit cards are accepted.
** If you only have cash, you have to queue at the staffed ticketing booth ("''Billeterie''" in French)
* Take the Orlyval to Antony. Then take the regional express(RER) line B (blue) to Paris (Direction Charles de Gaulle Airport).
* Alight at ''Gare du Nord''.
* See below from Gare du Nord.

=== Beauvais (BVA) airport ===
We feel sorry for you. Take the bus.

=== Gare du Nord (North railway station) ===

If you arrive at Gare du Nord or Gare de l'Est, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====
* Transfer to regional express train (RER) line E (magenta) toward ''Haussmann St Lazare''.
* Alight at the final stop, ''Haussman St Lazare''.

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
** Check the metro destination, as there are two branches on the line. DO NOT go toward Saint Denis.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Gare de l'Est (East railway station) ===
Routes are essentially the same as from Gare du Nord. The Magenta express train station is located between Gare du Nord and Gare de l'Est. See above.

=== Gare de Lyon (South/East railway station) ===
If you arrive at Gare de Lyon, you need to buy a zone 1 / Paris ticket. It is valid on the subway, the tramway, busses and, '''within the Paris city limits''', on the regional express trains (RER).

==== To the conference venue ====

* Take subway(M) '''line 14''' toward ''Saint Lazare''
* Alight at the final stop '''Saint Lazare''' (5 stops)

Walking route:
[https://www.google.fr/maps/dir/32+Rue+Blanche,+75009+Paris,+France/Haussmann+-+Saint-Lazare,+France/@48.8767778,2.3281097,17z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e49a8a4ba55:0x95f959c0c70dfded!2m2!1d2.3316096!2d48.8788866!1m5!1m1!1s0x47e66e35df16346b:0x5b4b229d8b94e143!2m2!1d2.329037!2d48.875188!3e2 Google Maps]

==== To the sponsored hotel ====
* Continue from ''Haussman Saint Lazare'' (2 stops) above
* Transfer to subway(M) '''line 13''' toward ''Asnières'' or ''Gennevilliers''.
* Get off at '''Porte de Clichy''' (6 stops)

The hotel is just around the corner.

=== Other? ===

== From the hotel to the conference ==
* Take subway(M) line 13 toward ''Chatillon-Montrouge''
* Get off at ''Liège'' and walk

Feel free to ask for advice on the mailing list if your station is missing.

== Connectivity ==

=== Power supply ===

The AC power sockets are "French" '''IEC type E'''. Connectors from "German" '''IEC type F''' countries should fit safely, as they are usually bi-standards. There should have a hole for the French-style ground pin.

The electrical system is '''220V / 50Hz'''. If you come from outside Europe, please make sure your devices are compatible beforehand.

=== Internet ===
Hopefully, there will be Wi-Fi.

== Weather forecast ==

:Fri Sep 18 Occasional rain 20°C Low 12°C
:Sat Sep 19 Occasional rain 19°C Low 10°C
:Sun Sep 20 Fog 20°C Low 12°C
:Mon Sep 21 Mostly cloudy 18°C Low 12°C

In Fahrenheit, this is a high of 64°F-66°F and a low of 50°F.

[[Category:About VideoLAN]]

VDD15/Attendees

2015-09-17T13:28:44Z

Gramner: /* Arrivals */

Back to [[VDD15|main VDD page]].

= Arrivals =
Please order chronologically by time of arrival.

{| border="1" class="sortable"
! Name
! IRC
! Time
! Port
! Vessel
! Notes
|-
| John Stebbins
| j45
| 2015-09-16 07:35
| CDG airport T2A
| BA 5046
| from SAN
|-
| Diego Elio Pettenò
| flameeyes
| 2015-09-16 17:35
| CDG airport T2E
| AF 1817
| from DUB
|-
| Arwa Arif
| arwa
| 2015-09-17 08:20
| CDG airport
| 9W 126
| from BOM
|-
| Tim Miller
| drasticactions
| 2015-09-17 08:35
| CDG airport
| DL 243 (AF 3655)
| from BOS
|-
| Rostislav Pehlivanov
| atomnuker
| 2015-09-17 10:17
| Gare du Nord
| TGV TMST
| from London
|-
| Alex Converse
| peloverde
| 2015-09-17 10:45
| CDG airport
| UA 990
| from SFO
|-
| Manfred Georg
|
| 2015-09-17 11:35
| CDG airport
| AF 83 (DL 8599)
| from SFO
|-
| Christoph Miebach
| No_se
| 2015-09-17 11:59
| Gare du Nord
| Thalys
| from Cologne
|-
| Thomas B. Rücker
| tbr
| 2015-09-17 14:20
| CDG airport T2D
| AY 875
| from HEL(l)
|-
| Edward Wang
| edwardw
| 2015-09-17 16:20
| CDG airport
| EI 526
| from DUB
|-
| Kieran Kunhya
| kierank
| 2015-09-17 16:47
| Gare du Nord
| Eurostar
| from London
|-
| Ludmila Glinskih
| lglinskih
| 2015-09-17 17:35
| CDG airport
| AF 1465
| from LED
|-
| Petri Hintukainen
| hpi
| 2015-09-17 18:10
| CDG airport
| AY 873
| from HEL
|-
| Henrik Gramner
| Gramner
| 2015-09-17 18:55
| CDG airport
| SK 559
| from Copenhagen/CPH
|-
| Derek Buitenhuis
| Daemon404
| 2015-09-17 20:00
| CDG airport
| 4U 8404
| from Berlin
|-
| David Fuhrmann
| d-fu
| 2015-09-17 20:54
| Gare de Est
| TGV 9552
|
|-
| Francois Cartegnie
|
| 2015-09-17 21:16
| Gare de Lyon
| TGV 6198
|
|-
| Martin Storsjö
| wbs
| 2015-09-17 21:35
| CDG airport T2D
| AY 877
| from HEL
|-
| Konstantin Pavlov
| thresh
| 2015-09-17 22:30
| CDG airport T2C
| SU 2460
| from Moscow/SVO
|-
| Tristan Matthews
| tmatth
| 2015-09-18 07:35
| CDG airport
| AC 884
| from Montreal/YUL
|-
| Sean McGovern
| Sean_McG
| 2015-09-18 07:35
| CDG airport
| AC 884
| from Montreal/YUL
|-
| Julian Scheel
| _julian
| 2015-09-18 07:55
| CDG airport
| AF 1611
| from Hamburg/HAM
|-
| Ronald S. Bultje
| BBB
| 2015-09-18 09:20
| CDG airport
| DL 400 (AF 3577)
| from NY/JFK
|-
| Tim Walker
| Rodeo
| 2015-09-18 10:20
| LFPG (CDG airport)
| AF 1543
| from LSGG (GVA)
|-
| Thierry Foucu
| lotharkript
| 2015-09-18 10:45
| CDG airport
| UA 990
| from SFO
|-
| Federico Hlawaczek
|
| 2015-09-18 10:45
| CDG airport
| UA 990
| from SFO
|-
| Devin Heitmueller
| devinheitmueller
| 2015-09-18 11:10
| CDG airport
| DL 1014
| from JFK
|-
| Andrew Kelley
| andrewrk
| 2015-09-18 11:15
| CDG airport
| AF 689
|
|-
| Stefano Sabatini
| saste
| 2015-09-18 12:20
| BVA airport
| FR 4831
|
|-
| Sergio Ammirata
| ringo
| 2015-09-18 13:00
| Orly airport
| EZY 4202
| from Palermo
|-
| Ilkka Ollakka
| ILEoo
| 2015-09-18 14:20
| CDG airport T2
| AY 875
| from HEL
|-
| Jan Ekström
| JEEB
| 2015-09-18 14:20
| CDG airport T2
| AY 875
|
|-
| Lars Kiesow
| lkiesow
| 2015-09-18 15:59
| Gare du Nord
| TGH 9448
|
|-
| Michal Čihař
| nijel
| 2015-09-18 17:35
| CDG airport
| AF 1083 (OK 4766)
| from PRG
|-
| Thomas Goyne
| plorkyeran
| 2015-09-18 17:40
| CDG airport
| AF 1851
| from CPH
|-
| Dave Rice
| dericed
| 2015-09-18 20:50
| CDG airport
| LX 646
| from ZRH
|-
| Rémi Denis-Courmont
| courmisch
| 2015-09-18 21:35
| CDG airport T2D
| AY 877
| Industrial action may disrupt
|-
| Bruno Siqueira
|
| 2015-09-18 21:55
| Orly airport
| TP 448
| from LIS
|-
| Janne Grunau
| jannau
| 2015-09-18 22:35
| Gare de l'Est
| TGV 9570
| from Karlsruhe
|-
|}

= Departures =
Please order chronologically by time of departure.

{| border="1" class="sortable"
! Name
! IRC
! Time
! Port
! Vessel
! Notes
|-
| Mc Fly Marty
| mcfly
| 1985-10-26 01:22
| Hill Valley, California
| DeLorean OUTATIME
| to Hill Valley
|-
| Dave Rice
| dericed
| 2015-09-20 07:00
| CDG airport
| LX 647
| to ZRH (then NYC)
|-
| Christoph Miebach
| No_se
| 2015-09-20 16:01
| Gare du Nord
| Thalys
| to Cologne
|-
| Tim Miller
| drasticactions
| 2015-09-20 16:45
| CDG airport
| AF 338
| to BOS
|-
| Janne Grunau
| jannau
| 2015-09-20 17:25
| Gare de l'Est
| TGV 9577
| to Karlsruhe
|-
| David Fuhrmann
| d-fu
| 2015-09-20 17:25
| Gare de l'Est
| TGV 9577
|
|-
| Francois Cartegnie
|
| 2015-09-20 17:49
| Gare de Lyon
| TGV 6949
|
|-
| Rémi Denis-Courmont
| courmisch
| 2015-09-20 19:00
| CDG airport T2D
| AY 874
|
|-
| Ilkka Ollakka
| ILEoo
| 2015-09-20 19:00
| CDG airport T2
| AY 874
| to HEL
|-
| Jan Ekström
| JEEB
| 2015-09-20 19:00
| CDG airport T2
| AY 874
|
|-
| Martin Storsjö
| wbs
| 2015-09-20 19:00
| CDG airport T2D
| AY 874
| to HEL
|-
| Petri Hintukainen
| hpi
| 2015-09-20 19:00
| CDG airport T2D
| AY 874
| to HEL
|-
| Devin Heitmueller
| devinheitmueller
| 2015-09-20 19:10
| CDG airport
| AF 8
| to JFK
|-
| Alex Converse
| peloverde
| 2015-09-20 19:13
| Gare Du Nord
|
| to London
|-
| Michal Čihař
| nijel
| 2015-09-20 20:10
| CDG airport
| OK 706
| to PRG
|-
| Julian Scheel
| _julian
| 2015-09-20 21:05
| CDG airport
| AF 1610
| to Hamburg/HAM
|-
| Stefano Sabatini
| saste
| 2015-09-20 22:45
| Gallieni
|
| to Tourin
|-
| Bruno Siqueira
|
| 2015-09-21 06:30
| Orly airport
| TP 447
| to LIS
|-
| Derek Buitenhuis
| Daemon404
| 2015-09-21 09:00
| CDG airport
| 4U 8407
|
|-
| Ludmila Glinskih
| lglinskih
| 2015-09-21 09:55
| CDG airport
| AF 1464
| to LED
|-
| Federico Hlawaczek
|
| 2015-09-21 10:05
| CDG airport
| UA 991
| to SFO
|-
| Rostislav Pehlivanov
| atomnuker
| 2015-09-21 10:13
| Gare du Nord
| TGV TMST
| to London
|-
| Diego Elio Pettenò
| flameeyes
| 2015-09-21 10:15
| CDG airport T2E
| AF 1716
| to DUB
|-
| Edward Wang
| edwardw
| 2015-09-21 10:20
| CDG airport
| EI 521
| to DUB
|-
| Konstantin Pavlov
| thresh
| 2015-09-21 10:40
| CDG airport T2E
| AF 84
| to SFO
|-
| Thomas Goyne
| plorkyeran
| 2015-09-21 10:40
| CDG airport T2E
| AF 84
| to SFO
|-
| Arwa Arif
| arwa
| 2015-09-21 10:50
| CDG airport
| EY 32
| to HYD
|-
| Ben littler
|
| 2015-09-21 13:30
| CDG airport
| AF 378
| to DTW
|-
| Henrik Gramner
| Gramner
| 2015-09-21 14:00
| CDG airport
| SK 2572
| to Stockholm/ARN
|-
| Ronald S. Bultje
| BBB
| 2015-09-21 14:00
| CDG airport
| AF 6
| to NY/JFK
|-
| Sergio Ammirata
| ringo
| 2015-09-21 14:10
| CDG airport
| AF 090
| to Miami
|-
| Tim Walker
| Rodeo
| 2015-09-21 18:30
| LFPG (CDG airport)
| AF 1042
| to LSGG (GVA)
|-
| Thomas B. Rücker
| tbr
| 2015-09-21 19:00
| CDG airport T2D
| AY 874
| to HEL(l)
|-
| Thierry Foucu
| lotharkript
| 2015-09-22 10:05
| CDG airport
| UA 991
| to SFO
|-
| Andrew Kelley
| andrewrk
| 2015-09-22 10:30
| CDG airport
| DL 88 (AF 8990)
| to SLC
|-
| John Stebbins
| j45
| 2015-09-22 13:55
| CDG airport
| BA 315
| to SAN
|-
| Sean McGovern
| Sean_McG
| 2015-09-23 14:25
| CDG airport
| AC 871
| to YUL
|-
| Manfred Georg
|
| 2015-09-27 14:00
| CDG airport
| AF 6 (DL 1020)
| to SFO
|-
| Tristan Matthews
| tmatth
| 2015-09-28 14:45
| CDG airport
| AC 885
| to YUL
|-
|}

= Locals =
People who do not need to travel:

VDD15/Attendees

2015-09-05T20:36:58Z

Gramner:

= Arrivals =
Please order chronologically by time of arrival.

{| border="1" class="sortable"
! Name
! IRC
! Time
! Port
! Vessel
! Notes
|-
| Arwa Arif
| arwa
| 2015-09-17 08:20
| CDG airport
| 9W 126
| from BOM
|-
| Tim Miller
| drasticactions
| 2015-09-17 08:35
| CDG airport
| DL 243 (AF 3655)
| from BOS
|-
| Rostislav Pehlivanov
| atomnuker
| 2015-09-17 10:17
| Gare du Nord
| TGV TMST
| from London
|-
| Kieran Kunhya
| kierank
| 2015-09-17 16:47
| Gare du Nord
| Eurostar
| from London
|-
| Henrik Gramner
| Gramner
| 2015-09-17 17:25
| CDG airport
| SK559
| from Copenhagen/CPH
|-
| David Fuhrmann
| d-fu
| 2015-09-17 20:54
| Gare de Est
| TGV 9552
|
|-
| Francois Cartegnie
|
| 2015-09-17 21:16
| Gare de Lyon
| TGV 6198
|
|-
| Konstantin Pavlov
| thresh
| 2015-09-17 22:30
| CDG airport T2C
| SU 2460
| from Moscow/SVO
|-
| Ronald S. Bultje
| BBB
| 2015-09-18 9:20
| CDG airport
| DL 400 (AF 3577)
| from NY/JFK
|-
| Thierry Foucu
| lotharkript
| 2015-09-18 10:45
| CDG airport
| UA 990
| from SFO
|-
| Federico Hlawaczek
|
| 2015-09-18 10:45
| CDG airport
| UA 990
| from SFO
|-
| Rémi Denis-Courmont
| courmisch
| 2015-09-18 21:35
| CDG airport T2D
| AY 877
| from HEL
|-
| Janne Grunau
| jannau
| 2015-09-18 22:35
| Gare de l'Est
| TGV 9570
| from Karlsruhe
|-
|}

= Departures =
Please order chronologically by time of departure.

{| border="1" class="sortable"
! Name
! IRC
! Time
! Port
! Vessel
! Notes
|-
| Mc Fly Marty
| mcfly
| 1985-10-26 01:22
| Hill Valley, California
| DeLorean OUTATIME
| to Hill Valley
|-
| Tim Miller
| drasticactions
| 2015-09-20 16:45
| CDG airport
| AF 338
| to BOS
|-
| Janne Grunau
| jannau
| 2015-09-20 17:25
| Gare de l'Est
| TGV 9577
| to Karlsruhe
|-
| David Fuhrmann
| d-fu
| 2015-09-20 17:25
| Match found
| -- same train --
|
|-
| Francois Cartegnie
|
| 2015-09-20 17:49
| Gare de Lyon
| TGV 6949
|
|-
| Rémi Denis-Courmont
| courmisch
| 2015-09-20 19:00
| CDG airport T2D
| AY 874
| to HEL
|-
| Federico Hlawaczek
|
| 2015-09-21 10:05
| CDG airport
| UA 991
| to SFO
|-
| Rostislav Pehlivanov
| atomnuker
| 2015-09-21 10:13
| Gare du Nord
| TGV TMST
| to London
|-
| Konstantin Pavlov
| thresh
| 2015-09-21 10:40
| CDG airport T2E
| AF 84
| to SFO
|-
| Arwa Arif
| arwa
| 2015-09-21 10:50
| CDG airport
| EY 32
| to HYD
|-
| Ben littler
|
| 2015-09-21 13:30
| CDG airport
| AF 378
| to DTW
|-
| Henrik Gramner
| Gramner
| 2015-09-21 14:00
| CDG airport
| SK2572
| to Stockholm/ARN
|-
| Ronald S. Bultje
| BBB
| 2015-09-21 14:00
| CDG airport
| AF 6
| to NY/JFK
|-
| Thierry Foucu
| lotharkript
| 2015-09-22 10:05
| CDG airport
| UA 991
| to SFO
|-
|}

= Locals =
People who do not need to travel: