https://wiki.xiph.org/api.php?action=feedcontributions&user=Jack&feedformat=atomXiphWiki - User contributions [en]2024-03-28T21:31:18ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=DaalaMeeting20150519&diff=15843DaalaMeeting201505192015-05-19T20:05:17Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-05-19 Mumble: mf..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-05-19<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- PCS<br />
- WebM Summit<br />
<br />
# Attending<br />
<br />
azita, derf, jack, jmspeex, mbx, MrZeus, tmatth, unlord, yushin, TD-Linux<br />
<br />
# reviews<br />
<br />
# PCS<br />
<br />
- j: We're submitting Daala. Thomas is preparing the code and Nathan is writing the paper. They'll both fly out to present it in Australia.<br />
<br />
# WebM Summit<br />
<br />
- d: I got invites yesterday. Does anyone else want to go?<br />
- a: What is the WebM Summit?<br />
- d: Put on by google every 6-9mo about VP8/VP9. June 17th this year.<br />
- j: Probably should be local people only.<br />
- d: I'll get those who are interested invitations.<br />
- a: Probably mbx and I should go too.<br />
- j: Great idea.<br />
<br />
(rest of discussion about schedule adjustments. resulting PDF to be posted to wiki later)<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15842Daala Weekly Meetings2015-05-19T20:04:40Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] by installing and using [http://wiki.mumble.info Mumble].<br /><br />
The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150519|2015 May 19]] - PCS, WebM Summit<br />
* [[DaalaMeeting20150421|2015 April 21]] - full precision refs, no sad, haar, mv grids & borders<br />
* [[DaalaMeeting20150414|2015 April 14]] - <br />
* [[DaalaMeeting20150407|2015 April 07]] - multi-ref, MV prediction<br />
* [[DaalaMeeting20150330|2015 March 30]] - screencasting, quilting, MC refinement<br />
* [[DaalaMeeting20150317|2015 March 17]] - IETF92, new lapping, quilting, rate control<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
=== 2013 ===<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
=== 2012 ===<br />
* [https://people.xiph.org/~giles/2012/daala_20121207.txt 2012-12-07]<br />
* [https://people.xiph.org/~giles/2012/daala_20121005.opus 2012-10-05 recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120928.txt 2012-09-28] - [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120921.txt 2012-09-21]<br />
* [https://people.xiph.org/~giles/2012/daala_20120824.txt 2012-08-24] - [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120810.txt 2012-08-10]<br />
* [https://people.xiph.org/~giles/2012/daala_20120803.txt 2012-08-03] - [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120727.txt 2012-07-27]<br />
* [https://people.xiph.org/~giles/2012/daala_20120720.txt 2012-07-20]<br />
* [https://people.xiph.org/~giles/2012/daala_20120713.txt 2012-07-13]<br />
* [https://people.xiph.org/~giles/2012/daala_20120706.txt 2012-07-06]<br />
* [https://people.xiph.org/~giles/2012/daala_20120629.txt 2012-06-29] - [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120622.txt 2012-06-22]<br />
* [https://people.xiph.org/~giles/2012/daala_20120604.txt 2012-06-04] (actually a work week)<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15781Daala Weekly Meetings2015-04-28T15:47:05Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150421|2015 April 21]] - full precision refs, no sad, haar, mv grids & borders<br />
* [[DaalaMeeting20150414|2015 April 14]] - <br />
* [[DaalaMeeting20150407|2015 April 07]] - multi-ref, MV prediction<br />
* [[DaalaMeeting20150330|2015 March 30]] - screencasting, quilting, MC refinement<br />
* [[DaalaMeeting20150317|2015 March 17]] - IETF92, new lapping, quilting, rate control<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
=== 2013 ===<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
=== 2012 ===<br />
* [https://people.xiph.org/~giles/2012/daala_20121207.txt 2012-12-07]<br />
* [https://people.xiph.org/~giles/2012/daala_20121005.opus 2012-10-05 recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120928.txt 2012-09-28] - [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120921.txt 2012-09-21]<br />
* [https://people.xiph.org/~giles/2012/daala_20120824.txt 2012-08-24] - [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120810.txt 2012-08-10]<br />
* [https://people.xiph.org/~giles/2012/daala_20120803.txt 2012-08-03] - [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120727.txt 2012-07-27]<br />
* [https://people.xiph.org/~giles/2012/daala_20120720.txt 2012-07-20]<br />
* [https://people.xiph.org/~giles/2012/daala_20120713.txt 2012-07-13]<br />
* [https://people.xiph.org/~giles/2012/daala_20120706.txt 2012-07-06]<br />
* [https://people.xiph.org/~giles/2012/daala_20120629.txt 2012-06-29] - [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* [https://people.xiph.org/~giles/2012/daala_20120622.txt 2012-06-22]<br />
* [https://people.xiph.org/~giles/2012/daala_20120604.txt 2012-06-04] (actually a work week)<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15679Daala Weekly Meetings2015-04-14T15:51:26Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150317|2015 March 17]] - IETF92, new lapping, quilting, rate control<br />
* [[DaalaMeeting20150330|2015 March 30]] - screencasting, quilting, MC refinement<br />
* [[DaalaMeeting20150407|2015 April 07]] - multi-ref, MV prediction<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150407&diff=15678DaalaMeeting201504072015-04-14T15:50:50Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-04-07 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-04-07<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- multi-ref<br />
<br />
# Attending<br />
<br />
daala-person, derf, jack, jmspeex, td-linux, tmatth, unlord, yushin<br />
<br />
# reviews<br />
<br />
- jm: I gave one to Thomas.<br />
- t: I was afraid.<br />
<br />
few patches from IETF92 waiting on various people.<br />
<br />
# multi-ref<br />
<br />
- t: I have a blend function that works and have a prediction function that predicts the right frame.<br />
- d: Which prediciton? Pixels or MVs?<br />
- t: The MVs also worked. So far it looked like the MVs don't get screwed up, but I need to look at them more. For coding the predictors, I haven't touched that so it's bad.<br />
- d: I've also been working on changing that code.<br />
<br />
# MV prediction<br />
<br />
- jm: I did some quick experiments. The current median of 4 predictors that we are using is still doing much better than previous MV as a prediction. Is that expected?<br />
- d: I don't know what you mean.<br />
- jm: Looking at previous frame and using the same MV for the prediction.<br />
- d: That isn't always available; we don't have a gridpoint there in all cases.<br />
- jm: I only looked at level 0.<br />
- d: It's very often not a great predictor. Sometimes it's really good and sometimes it's really bad. Every scheme that used temporal prediction used it as one of the possible predictors but there is always a spatial prediction fallback.<br />
- jm: I tested on johnny so it seems like it should have worked well there.<br />
- d: Why would it work well there?<br />
- jm: Why would it not work well?<br />
- d: ... The boundary between background and foreground is where you are going to run into problems and temporal is not going to do well there either (just like spatial). I would expect temporal to do worse than median of 4 spatial on large areas that move consistently. On the background which doesn't move, it doesn't matter which one you use. ON the foreground, it doesn't make a big difference but I expect spatial to do a little bit better. I've never seen it where temporal is the only predictor you have.<br />
- j: Could chose from both but not account for signaling cost to check.<br />
- jm: Also I could see how often it is used in that case.<br />
- d: One thing I could think of is that it would do a good job if something is spinning.<br />
- jm: Why?<br />
- d: Always the same motion in the same place, but it varies spatially. So the spatial prediction is a bit off and the temporal predictor is pretty good.<br />
- jm: Do we have any spinning videos?<br />
- d: Some stuff spins in mobile and in cactus. Tractor has huge spinning wheels.<br />
- jm: has anyone done long range predictors?<br />
- d: People have done it with two pass. You use explicit signalling. It stinks.<br />
- jm: The general idea I had is to compute a running histogram and the one or two most likely ones we can make a predictor out of them.<br />
- d: When you say 1 or 2, that gets "complex" in the computational sense. One is perhaps not that bad. Maybe one is that bad.<br />
- jm: It could be the top non-zero one.<br />
- t: How does this help over median predictors?<br />
- d: You have some kind of pan and the background has consistent motion. I'm not sure it's that great because you still have up-right in most cases. Something should intersect the background. The current issue is the median of 4, when up-right is the only good predictor, you are going to throw it out. This is where HEVC and VP9 got gains, because instead of discarding, they collect them as multiple predictors and signal which one they use.<br />
- t: You could do something simple by weighting them by tossing them into the median 2 or 3 times.<br />
- d: They build lists of unique MVs.<br />
- jm: Unique as in very close or equal or different?<br />
- d: Equal or different. Then they signal which one from the list they use. In HEVC this is complicated and I can't explain it well. But you do sort of what you said. You have a list, you pick from the list, and you code a residual. In VP9 it's a little different. You build the list and the first entry is the most popular, etc. Then you can either code something using the first one and code a residual, or take the first one with no residual or the second one with no residual. I think there is a fourth option too. And the fourth is use zero with no residual.<br />
- jm: How are the first and second entries built?<br />
- d: The most popular from your neighbors. If you don't have enough unique ones then you fill in with zeros.<br />
<br />
(missed some stuff about packetization)<br />
<br />
- d: The way decoders work is they want all the information for one superblock/macroblock at one time. In order to do that if you have all the info next to each other in the packet, once you get the packet you can decode that area of the screen. Whereas if you have them in different packets, if I get a packet for some set of DCT coeffs, now I need to wait for the packet with MVs before I can go about decoding the screen. And then I have to shuffle state and wait etc. It starts to make things a real mess.<br />
- jm: And yet you can at least parallelize the entropy decoder by a factor of two.<br />
- d: What you're already going to be doing is splitting up into tiles and splitting up that way.<br />
- jm: You can make tiles twice as big.<br />
- d: At the cost of additional complexity though. If you split this then you have dependent packets and they aren't independent.<br />
- jm: You could have two packets per tiles.<br />
- d: Packets per tile depends on how complex the tile is. You might get 3 packets for residual and 2 packets for MVs and then you have to wait. We have things more separable than other codecs, but I'm hoping to fix that instead of institutionalizing it. Part of 32x32 block size stuff is removing the border region around the grid. I still don't know if that actually works better. This would have no grid points outside the frame.<br />
- jm: Are you sure that is not hurting us somehow?<br />
- d: That's what I'm trying to test.<br />
- jm: That it's not clamping MVs to 0,0 anywhere? Can we make sure we have smooth MVs across the whole image? It hurts any time we have a border of non-zero; we're paying a price. Why was this done that way?<br />
- d: To make the number of MVs that we had to signal the same as a normal codec. The number of level 0 MVs is the same as the number you'd have if you had one per macroblock. That was a thought I had in 2006 and I don't claim it is a great thought. In any case, I'm working on fixing this. If you are going to center on 32x32 all my borders are 4 grid points instead of 2 grid points, etc.<br />
- u: What happens when we go to 64x64?<br />
- d: If I do it right, nothing changes, because the grid now lines up with the transform blocks. If I instead make all the twos into fours, then I'd have to go back and make fours into eights. So fixing this by changing the structure makes it easier to keep expanding the block size.<br />
<br />
...<br />
<br />
(jack leaves, derf and yushin discuss "stage" vs. "phase" nomenclature)<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15596Daala Weekly Meetings2015-03-31T16:57:03Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150317|2015 March 17]] - IETF92, new lapping, quilting, rate control<br />
* [[DaalaMeeting20150330|2015 March 30]] - screencasting, quilting, MC refinement<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150330&diff=15595DaalaMeeting201503302015-03-31T16:55:20Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-03-31 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-03-31<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- quilting bug<br />
- Screencasting encoding<br />
- Screamcasting<br />
- Icecreamcasting<br />
- MC refinement strategies<br />
<br />
# Attending<br />
<br />
derf, jack, jmspeex, MrZeus, TD-Linux, xiphmont, unlord<br />
<br />
# reviews<br />
<br />
658: shouldn't be doing clamping in the metrics tools. can do this in the decoder instead.<br />
<br />
# screencasting<br />
<br />
(discussion continued from review discussion, and didn't get recorded)<br />
<br />
# quilting bug<br />
<br />
- x: it turns out that the quilting bug is more persistent than expected. Tests over the last few days show that quantization noise that you inject into things gets amplified. The variance keeps expanding. Any time you code an update to the block you might make all the noise worse. Your DC update can cause all HF noise to double in amplitude. Exhaustive search of all 4x4 filters does not find a solution, because it's not the filters, but the way we use them. I found a solution that will avoid amplification when DC-only updates, but any time you update HF you get noise amplification. Quantizing ref frames to 8bit is the source of the noise.<br />
- d: Is this enough to solve the visual artifacts we can see?<br />
- x: Maybe. I'm worried that if you add a single AC coeff, it still amplifies.<br />
- d: I'm worried more about the actual video than constructed test cases. If the problem only exists at low rates where we only code DC, then we have fixed it.<br />
- x: Those are tests I have no run, but I am pessimistic. If it does still pop up in rates we care about, I'm afraid we have to go to full precision reference. That's the only thing I can think of.<br />
- jm: The impression I got was that the reason other codecs don't ge tthis is that they dont' run a prefilter and it gets blurred over and over.<br />
- x: The mismatch is postfilter to prefilter, not the other way around.<br />
- jm: What I'm saying is that postfilter blurs some amount of noise on block boundaries. In a normal codec it blurs things then you code an update and blurs again. So in our codec we unblur, and if there is noise, we don't beep bluring it, but retain it.<br />
- x: The second half of this is that when we quantize (taking ref to 8bit) it injects more noise. Not only do we preserve the noise, but we inject more.<br />
- jm: Exactly, the prefilter is not the cause, but makes sure we keep it around and don't blur it out. You said if you constrain DC you got rid of it, but in the case of AC, what did the quilting look like? Was it accumulation of noise or a pattern?<br />
- x: In between. Those effects are a continuum not different things. There was no pos/neg bias but it is correlated horizontally and vertically.<br />
- jm: So it's not just white noise.<br />
- x: It is not just white noise.<br />
<br />
# MC refinement<br />
<br />
- d: Guillaume was doing experiments with enabling old MC refinement things. My plan was to turn those things off, but I may go back and add a speed level to the encoder today so that would turn these things on and off based on the setting.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15594Daala Weekly Meetings2015-03-31T16:54:53Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150317|2015 March 17]] - TODO<br />
* [[DaalaMeeting20150330|2015 March 30]] - screencasting, quilting, MC refinement<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150317&diff=15534DaalaMeeting201503172015-03-17T17:08:14Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-03-17 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-03-17<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- prepare for IETF 92 hackathon<br />
- lapping approach data from jm, TD, (unlord?)<br />
- quilting bugs<br />
<br />
# Attending<br />
<br />
azita, derf, jac, jmspeex, smarter, td-linux, unlord, xiphmont, yushin<br />
<br />
# reviews<br />
<br />
# IETF hackathon<br />
<br />
- d: We need to identify stuff for people to work on.<br />
- j: Is there a list from code parties?<br />
- d: Best list right now are the issues in GitHub. We have a number of them tagged as Bug or Easy.<br />
- j: We have a week so hopefully others can think of some easy bugs and put them in there.<br />
- jm: What day is the BoF?<br />
- d: Tuesday at 9am Central.<br />
- u: Do you need updated graph for the presentation, Tim?<br />
- d: Yes. I am hoping to get the new lapping added first. I will ping you about that when it's ready. Perhaps after the hackathon.<br />
<br />
# lapping stuff<br />
<br />
- d: Yushin's is the only new experiment that we did, which had some interesting results.<br />
- y: What I tried was use variable lapping from master on top of fixed lapping from Jean-Marc's RDO block size decision. It increases rate 1-2%. And then I have used his basis magnitude compensation. If I turned that off it increases another 1-2%. So we understand that if the block size decision is based on fixed lapping it will only get best efficiency with fixed lapping. The block size decision is somehow better than Thomas's (from the Tran paper).<br />
- d: Given that I think we should go ahead with fixed lapping. The question is does anyone else disagree with that assessment.<br />
- jm: No!<br />
- u: Are we saying that the fact that the lapping ... 4pt being covered with 8pt is the cause of hte improvement?<br />
- d: No.<br />
- u: We still agree that this is a subset of the lapping cases that you get with the full lapping?<br />
- jm: No you would never get that with full lapping; not the way it is structured right now. THis code will keep 8x8 on th exterior of 4x4s because every level is lapped the same. The good news is that if we go with this approach we can revisit things which previously did not work. One of those is TF. I suspect we can use TF to go from 16x16 to 32x32 or as a 64x64 level.<br />
- d: Why do you think that will work?<br />
- jm: Before we weren't willing to add a matrix to compensate for each coefficient. It was causing scaling issues and we didn't want to scale each coefficient differently. But the way the new code works is that I'm doing that anyway.<br />
- d: I thought the issue was that you didn't know how to do that.<br />
- jm: No. It was always a possibility but having to do that versus just doing 32x32 DCT there was just no point. But basically it is an option. Another option is that essentially the way the fixed lapping in structured, you could derive some TF with second stage that give you exactly what the DCT gives you. So there is a matrix that will change the DCT coeffs from one 8x8 block into DCT coeffs of 4 4x4s. And there is a matrix that will change a superblock into 32x32. Whether it is sparse or not is another thing.<br />
- d: That's only if you dont' have interior lapping right?<br />
- jm: No. The interior lapping is still linear.<br />
- d: Sure but it would be undoing that.<br />
- jm: Yes.<br />
- d: That would still be true so long as we had the lapping order done this way right? Nevermind; I'm being stupid.<br />
- u: Going back to the original patch, where is the gain coming from? Is it things like changes to the Haar DC or some of the other places?<br />
- jm: The improvement is due to actually selecting good block sizes and having the block size RDO match what is actually happening.<br />
- d: Yushin's experiment demonstrates that having the actual encoding match wasn't that important.<br />
- jm: Mostly I mean the RDO itself being self-consistent. Having decent metrics in the RDO.<br />
- d: Just looking at the only difference between what Yushin is doing and what master does (changing the decision), it got almost all of the gain.<br />
- u: That's not what I heard. He said hte cost went up.<br />
- d: 1-2% better than JM's branch, which is 7-9% better than master. The point is that all the other things that are not hte decision account for only 1-2% of this.<br />
- jm: The improvements I could make in Haar and compensating for magnitudes, I would say that is on par with what I lose with fixed vs. variable lapping. I lose 1-2% there and get that back by tuning. There are side benefits like fixed lapping being much easier to understand.<br />
- u: I still can't reason about 8pt lapping over a 4x4 block. I'm sure I'll figure that out.<br />
- jm: Look at what's happening in tools/compute_basis.<br />
- d: It means you lose linear phase, which is not the end of the world. We lost it when we switched block sizes anyway. Except now that we don't in some cases where we did before.<br />
- jm: We may be able to split HF even further to get 2x2 resolution. Another one is jointly coding 4 4x4s as if it were 8x8. A bit like what Opus does with short blocks.<br />
- s: Can you explain with more detail?<br />
- jm: You can take coeffs from 4 4x4s and interleave them and pretend that it's 8x8 data.<br />
- d: He's just talking about coeff coding.<br />
- jm: Not just that, also in PVQ itself; quantization coding.<br />
- s: Doesn't that break AM?<br />
- jm: No, it means you'd be able to do it. Now you can use decent bands for 4x4.<br />
- s: Do you do some transform on the coeffs?<br />
- d: No transformation, just rearrangement.<br />
- s: How are they rearranged?<br />
- d: You interleave them.<br />
- s: It still seems like AM would be very different.<br />
- d: It would be, but keep in mind most codecs do AM on a macroblock level, and we don't do it on 4x4 at all because edges.<br />
<br />
# quilting<br />
<br />
- x: Most of the stuff got done this week by Jean-Marc. He replicated my tests and found an error. I determined that full precision ref frames were not going to save us. He ran the test too and found they do save us. We can also eliminate the quilting by setting scale factors to 64 which renders lapping filters perfectly reversible. That also eliminates the quilting. Neither strategy is suitable for production, but the evidence is strong that this just comes down to rounding behavior. The next step is to understand rounding behavior to find another less expensive way to eliminate the artifact.<br />
- jm: The way I like to think of it is that there are two types of quilting. Noise quilting and pattern quilting.<br />
- x: I disagree that these are different.<br />
- jm: It's the same issue but it shows up in two different ways, and they may have solutions that are different. The pattern quilting is a bias in the noise and the other one is growing variance by additive noise. You can prevent a bias in the noise which would get rid of one, but you'd still have the other behavior. The noise is due to non-perfect reversibility and gets amplified by the downshifting to 8bits.<br />
- d: it would take more than 1 unit in 12 bits to push the rounding up across the threshold.<br />
- jm: Not if you have a value of 7 right next to a value of 8.<br />
- d: Why would we have values of 7 if all we're doing is DC.<br />
- jm: Because you are applying the postfilter and you have all the intermediate values.<br />
- x: Even if your four LSBs are all zero and you apply the post filter, then they are smoothed across and are non-zero.<br />
- d: If we only have two postfilters to worry about now that seems like we can do something about it.<br />
- x: We know two things we can fix this, but we need to find ones that we are willing to deploy.<br />
- u: I think he means we could train new filters if we knew what to train.<br />
- d: You could construct the coeffs of the filter so that given a ...<br />
- jm: I don't see how you can do that for every step size possible.<br />
- d: Not at high qualities because you don't have enough resolution.<br />
- jm: High quality is irrelevant here because it only happens at low quality. I thought of things like changing the downshifting code to take one superblock at a time and trying to quantize with different rounding biases and trying to measure the amount of 1bit noise in the output and picking whichever had the least noise and kind of got rid of some of the pattern quilting; you could probably tweak it to get rid of some or all of it, but you'd still get the other one.<br />
- x: I think you are reading far too much into that result.<br />
- jm: It was adaptive. I got rid of all the pattern quilting but still had noise quilting. I tried to do it automatically trying all superblocks and all biases and that got not nearly as good as doing it manually but it was decent at reducing it.<br />
- x: I still think you were poking at something and got some result and reading far too much into it. What happens when you take the full precision frame and downshift? It injects quantization noise. The prefilter takes that noise and blows it up. In sintel, we essentially have a soft gradient that happens block by block. The noise gets preserved when we filter back. Any quantization noise is going to do that. I think you are imagining the bias. I went looking for biases and couldn't find them.<br />
- jm: Look at the image I pasted. I'm not saying there is a bias in the filter itself. I'm saying that the entire loop has a bias.<br />
- x: So we pick some random magic value that gets rid of this bias for DC updates, but screws up the rest of hte filter. These are halfhearted band-aids.<br />
- jm: I'm not saying I want this fix; it's not good. I'm just trying to observe what's happening. If you look at http://jmvalin.ca/video/bias/no_060.png there are very clear lines. I've written some 1D code that plays with the DCs. I can make it such that every single frame gets a full 8bit integer added. After 60 frames the quilting will be 60. If you look at the other one which is a hack I do not recommend (changing the shifting bias), it just removes the bias in the quantization which adds 1 every time.<br />
- x: That does not look different to me.<br />
- jm: In both cases the variance is building.<br />
- x: They are quantitatively different not qualitatively different.<br />
- jm: In the second one there is no bias, just noise. It has clear white lines.<br />
- x: I can do this in Gimp by adding a mask. There's no surprise that changing the rounding point changes the rounding. So we don't actually have a solution to this right now. We're pretty certain at this point that it's a rounding problem.<br />
- d: Well we have a solution which increases memory bandwidth requirements by 2x which will not be popular.<br />
- x: Or requires det1 filters which may impact coding gain.<br />
- d: Also full resolution references requires MC work.<br />
- jm: In any case what's not helping us is that postfilter adds a bit of noise and prefilter blows it up. In normal codecs the filter may add noise, but there is nothing that amplifies it on the next frame.<br />
- d: I'm not sure that fits my model of what's going on.<br />
- jm: In 264, they could have decided to use our postfilter instead of something adaptive. It would not have caused this problem because the postfilter would always be blurring things. You add a bit of noise and it gets blurred on the next pass and is not a big deal. Our things amplifies what the postfilter dampens.<br />
- y: ???<br />
- x: Subtractive dither is still adding noise.<br />
- y: +/- 1 added noise does not change the rounding bias?<br />
- jm: I was going to say something like dithering would completely get rid of the lines from the no060 but you would still get the noise behavior from the shift image http://jmvalin.ca/video/bias/shift_060.png<br />
- y: How about adding noise to the DCT coeffs and iDCT inverse transforms the noise?<br />
- jm: The noise is going to build up no matter what you do.<br />
- y: But we want it to be built up randomly so that it's not visibile.<br />
- jm: Look at shift_060; this is what you are asking for. THe noise is uncorrelated but still there. That's what you get with dithering.<br />
- y: In pixel domain you have 8bit precision right?<br />
- jm: Dithering is only in pixel domain but only where there is lapping. You are rounding to 8bit on every pass, so the noise you are adding is on the order of 1 in 8bit domain.<br />
- y: Coeff size are 12bit though. iDCT transforms this to 12bit and then postfilter works on that right? How about adding small noise in coeffs themselves.<br />
- jm: That will just create more noise. That will prevent bias but not prevent noise; it adds noise. The best you can get by adding noise is the result of the shift_060 image. That being said, maybe we'll decide we can live with this noise pattern.<br />
- x: The next thing was where are the extra LSB spikes coming from. I still don't understand what I'm supposed to be looking for there.<br />
- d: I'd like to be able to point to the calculations that actually cause some of those values to be more likely than others. We're trying to analze this at the level of functional blocks of code and I'd like to look at specific computations that are causing this.<br />
- x: That makes sense but we can talk about that offline. I'm still not sure exactly what I'm supposed to be looking for. The other part was that you had talked about potentially restructuring the filters in some way that would render them more symmetrical. The whole alternating the filter back and forth.<br />
- jm: I tried that and it didn't work.<br />
- x: I don't like that idea because there are many reasons it can't work. But were there more things in that vein that would have a better chance?<br />
- d: We can make it symmetrical with some increased complexity.<br />
- jm: Can you define symmetrical?<br />
- d: If you reverse the inputs, the initial computations are the butterflies. Then we shift down and that introduces an assymmetry.<br />
- x: I thougth we shifted then subtracted.<br />
- d: Actually yes we do do that. Which actually makes this harder.<br />
- jm: If you look at hte no file I showed, the lines are symmetrical. So I don't think fixing the symmetry will help you there.<br />
- x: It will if you flip and negate.<br />
- jm: That doesn't work for another reason. The quilting does not happen if you boost all DCs. The quilting is related to t4 to t7 (the difference terms that are lifted and processed around). These are the terms that are cuasing the quilting.<br />
- d: Those are exactly the terms where the filter is not bidirectionally reversible and where all the asymmetry is.<br />
- jm: Unless you update the DC every frame, it won't help you. If you increase it every other frame, you still get the build up. Whatever you did to reverse the effect on odd frames will never get triggered.<br />
- d: I think we all agreed that alternating the filter won't help. What I'm suggesting is altering the structure of the filter which we can do. I think about two years ago I had tried altering it for a different reason. Currently we have our sums in one place and our differences in another. I flipped it to be the other way and there was less rounding in that path. When I did this, the performance of the codec as a whole got dramatically worse and I didn't understand why at the time. But it seems relevant to try and understand that now. We can talk about this offline.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150310&diff=15533DaalaMeeting201503102015-03-17T15:23:12Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-03-10 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-03-10<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- lapping approach data from jm, TD, (unlord?)<br />
- quilting bugs<br />
<br />
Attending<br />
<br />
azita, daala-person, derf, jack, jmspeex, TD-Linux, tmatth, unlord, xiphmont, yushin<br />
<br />
# reviews<br />
<br />
# lapping approaches<br />
<br />
- x: Do we go with Tran paper or JM's thing. It comes down to the data. Where's the data?<br />
- td: I ran new results: apples to apples (or apples to some similar fruit). It was 16x16 max blocksize (because 32x32 doesn't work yet). I also run PSNR optimized because I don't have PSNRHVS or any of the other metrics that JM has. I switched JM's to max 16x16 too. What I saw this morning is that mine does substantially worse, so I think there is still something wrong.<br />
- d: Can you tell us which results those are?<br />
- td: ntt-short-1 the top three. The first one is wrong, but the second one is the first one that isn't broken.<br />
- jm: Did you compare to master?<br />
- td: I did not do a run with master limited to 16x16 and with PSNR tuning.<br />
- jm: There's master PSNR somewhere we could compare to.<br />
- td: Mine seems to do worse than that one.<br />
- jm: You are slightly better at high bitrate and worse and low bitrate. High bitrate is easier to select blocksize for with this kind of approach.<br />
- d: Yesterday we were talking about the block sizes picked in intra frames sticking for inter frames. Is that still happening?<br />
- td: Not sure yet. I need to run those tests again. I thought it was working, but maybe that is the problem.<br />
- a: What percentage done are you on this task (wearing my PM hat)?<br />
- td: 50%. (90% probably but last 10% will take half the time)<br />
- a: What about JM?<br />
- jm: I have 100% of what's need to make a decision about lapping. Once the decision is made, there will be more work if we pick my appraoch to merge it into the code and retuning everything. Assuming it will land, I'm about 66% of the way to landing this. Then there is another set of work to improve what I have once it's landed. Maybe 40% if you include that extra work.<br />
- j: Is there a next set of steps for TD or just debugging?<br />
- td: Maybe just tuning.<br />
- jm: I find that FourPeople is a good clip for block size decision sanity.<br />
- d: That one is easier to visually inspect for sure.<br />
- td: My code tends to track block sizes more.<br />
- jm: That doesn't make sense. If you skip multiple blocks it should make them a single block.<br />
- td: The problem is the lapping and basis is still changing so it's more likely to still skip. I'm now undecided on this.<br />
- d: It might help if you had some examples, like pictures.<br />
- td: I can prepare that for tomorrow's watercooler.<br />
- d: What work needs to be done to land JM's stuff?<br />
- jm: I need to clean up the code. Guillaume has started cleaning it up, but more work is needed. Right now I've ended up with three different QM that need to be combined. It's probably good to only apply one at a time.<br />
- d: What are the three matrices?<br />
- jm: One is to compensate for the magnitude of the basis functions (1xN array, and matrix is outer product). Second one is the HVS matrix; I've been playing around with a few different ones, including the one from PSNR-HVS.<br />
- d: What other ones have you been playing with for HVS?<br />
- jm: I have four in the code right now. I've only looked at them a little bit, so I'm not claiming that I've enabled the best one. The ones I've tried are the two from the MPEG2 spec (something yushin pointed me to).<br />
- d: There are two there, one for intra and inter.<br />
- jm: I tried both. The other 2 in this second set are the one from PSNR-HVS and the one I'm using now is the intra MPEG2 matrix made symmetric and averaged it with PSNR-HVS.<br />
- d: I thought before all this started we added interpolation because we wanted flatter matrices at lower rates.<br />
- jm: I have a single matrix now, but I need to put back in interpolation. I don't think it's as bad as it was before, but I'm not sure exactly why. I've been focusing on making a decision about blocksize, and interpolating matrices isn't really part of that.<br />
- d: Hmm. You did some testing originally with a flat matrix. But if you have a highly skewed matrix then it will try to flatten it by picking smaller blocks.<br />
- jm: I'm using hte same matrix at all blocksizes and interpolating them.<br />
- d: What??<br />
- jm: I'm using the 8x8 matrix and resampling it for different blocksizes.<br />
- d: I am very confused. We can take this offline.<br />
- u: How do we propose to compare these two approaches with different QMs?<br />
- d: Unfortunately the problems cannot be separated.<br />
- jm: That is why we originally agreed to compare on PSNR.<br />
- d: That is a first step yes.<br />
- jm: The real question is what would convince anyone else that we need to pick one or the other approach?<br />
- y: I think JM's approach improves quality, but because we changed QM, it adds another factor. If you isolate the QM from your RDO I think we can land it quicker.<br />
- jm: Doing the lapping the way I do it changes all the QMs because we change all the basis functions. Once you do magnitude compensation you've changed all your matrices.<br />
- u: At some point, shouldn't we need to take sample videos and figure out what QMs we really need?<br />
- d: What are you optimizing for when you try to learn?<br />
- u: That's what I'm asking.<br />
- td: PSNR-HVS is the best we have.<br />
- d: And that has a very specific QM bias built into it. I don't think any of our metrics do the right thing meaning that if you fed it into a numeric optimizer it would do the right thing.<br />
- jm: Essentially if you take what's currently in master, it's a matrix that I hand optimized for PSNR-HVS.<br />
- d: Producing that matrix seems like a process that could be automated.<br />
- jm: Kind of hard. At some point I also factored in the other metrics. I hand tuned while still looking at the other ones.<br />
- d: That still seems automatable. We will be playing with these for a long time, and having a tool to do this would make it a lot easier.<br />
- jm: It's becoming less clear how we're going to make a decision here.<br />
- d: It was never clear to me! I would like to see an apples-to-fruit comparison of the two techniques. I haven't seen any numbers from TD that he didn't think were broken. We should take a look at intra-only, monochrome, flat QM and PSNR optimized and AM off.<br />
- j: Do we have this for JM's code/<br />
- td: Yes, from smarter's patch we have togglable options that can do that.<br />
- d: This seems like a comparison that we can actually do and get numbers that make any kind of sense.<br />
- j: What's stopping us from doing that today?<br />
- td: Nothing. On it. Wanted to have that done this morning.<br />
- d: Try intra-only first, I don't think you've tried that.<br />
- jm: Intra's easier because of Haar.<br />
- d: The point is he thinks the intra stuff is actually working.<br />
- jm: Another consideration is how much pain it is to choose the blocksize.<br />
- u: Don't we lose something by not using larger lapping.<br />
- jm: JM claimed that the loss was very small, and I certainly don't believe it visually regardless of what the metrics say.<br />
- d: It concerns me when people in IRC say that some images look worse when your metrics show huge gains.<br />
- jm: Who and what?<br />
- d: Fruits and not super low rate.<br />
- jm: http://jmvalin.ca/video/fruits_master_4k.png and http://jmvalin.ca/video/fruits_rdo_4k.png give you the idea of the tradeoff.<br />
- d: No one is ever going to encode fruits at 4k. If it's bad at 2.5bpp then who cares about 4k.<br />
- jm: I'm not claiming this is better; it's showing the tradeoff that is happening.<br />
- y: I noticed that the Q values for JM's branch are quite different.<br />
- jm: Yeah, they are completely different from what's in master.<br />
- y: I compared -v 35 of persimmon and master -v 65 or 70. JM's uses less 4x4. It gives a lot of band skip in the analyzer. Those backgrounds they are surprising represented by just one coeff in 32x32 block.<br />
- d: That's what you want to happen and what happens in both versions of lapping. Just that one of them looks better when you do that.<br />
- jm: One thing I'm thinking of doing is tweaking it to give the first AC coeff a boost.<br />
- u: Have we tried doing BS decisions on what you're doing and then go back and use the largest filtering possible? Do we have an RD curve for that?<br />
- jm: We don't have a curve for that, but you've got the code.<br />
- u: We should at least document that this is an experiment that needs to be run as well.<br />
- j: Isn't that how the Tran paper worked?<br />
- jm: That is how it works at the highest block level. And it does exhaustive search below that.<br />
- j: So you're saying use JM's decisions and then maximize lapping on every edge?<br />
- u: Right.<br />
- td: I thought this experiment should be run as well.<br />
- j: TD is busy so who will run this experiment, and do people think this is an experiment that needs to be run?<br />
- u: There's little to be done, because you just do BSS as normal and then let the normal filters run. Our current code does the maximum filter size for every block edge, so all you need to do is change where you make your decision.<br />
- d: It sounds like a simple experiment to run.<br />
- j: I nominate nathan.<br />
- u: I think JM should do it.<br />
- jm: Absolutely not.<br />
- u: I can give it a go.<br />
<br />
# Quilting<br />
<br />
- x: We need to decide what to do about it and that can be done offline.<br />
- u: I don't think I understand the asymmetric thing from the discussion in IRC.<br />
- x: Did you see the code in IRC? Built it run it and plot the output. The basic problem is that when our ref frame is taken back down to 8 bits, that quantization means that we get ringing in the lapping. It is not perfectly reversible. Maybe that's not the right word. All you need is ht prefilter to see it happen.<br />
- d: Reversible is the word I would use.<br />
- x: The asymmetry means that the positive and negative rounding error tends to pile up in the same places as the negative error. If you have two blocks of different DC values, then you get a little bit of ringing when it goes to the lower bit depth. Then if you bring in another DC block that would be perfectly smooth. Unfortunately that's another step function and when you go through the lapping, transform and reduced ref frame, the positive and negative rounding ends up in the same place and it's additive. And it's high frequency content, so unless you're coding all the coeffs and a high quantizer it will never damp out.<br />
- d: That's not exactly true. We can always dampen high freqs if they show up.<br />
- x: Yes, but we don't do it now.<br />
- d: By using PVQ energy. You don't have to code all the coeffs, just the energy. But we'd rather not spend bits on that. The point is that this is inherent to the structure of the prefilters. Picking particular coeffs will not change this. One thing we can do is do this thing is flip in alternating frames. The other things you can do is change the structure of the filters somewhat. If you look at the filter then ask yourself what happens if I send same stuff negated and you already see the asymmetric easily in 4x4. It's possible to design symmetric ones. The third thing I thought of is that when we do the quantization down to 8 bits we can round to even instead of straight rounding. More expensive but maybe cheaper than changing the filter structures.<br />
- x: And there's always full depth reference.<br />
- d: No there's not.<br />
- x: We have full depth references when doing 10bit right?<br />
- d: Yes, which is why everyone will do their anime encodes with it.<br />
<br />
# MC lines<br />
<br />
- d: What was that?<br />
- x: I suspect pilot error. I went back to reproduce and couldn't reproduce it. One possibility is that I screwed up with Git. I made sure that TD's patch was applied that he told me I needed. The next thing I was going to try and do is go back before that patch and see if the bug reappears.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15532Daala Weekly Meetings2015-03-17T15:22:13Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - block size decisions<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150317|2015 March 17]] - TODO<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15531Daala Weekly Meetings2015-03-17T15:21:48Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - TODO<br />
* [[DaalaMeeting20150310|2015 March 10]] - lapping approaches, quilting bugs<br />
* [[DaalaMeeting20150317|2015 March 17]] - TODO<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150303&diff=15518DaalaMeeting201503032015-03-03T18:01:00Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-03-03 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-03-03<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- State of block size decisions (TD-Linux, yushin)<br />
<br />
# Attending<br />
<br />
smarter, unlord, jack, derf, yushin, gianni, TD-Linux<br />
<br />
# reviews<br />
<br />
572 assigned to monty<br />
<br />
# state of block size decisions<br />
<br />
- td: I worked on the tran paper. I got some results, but not as good as Jean-Marc's. I have not considered how to do activity masking so it's turned off in my branch. I can't figure out hwo to do that other than turn on AM after the block size decisions are made.<br />
- d: How do we get a version of each to compare?<br />
- td: We turn off QM, AM, etc in Jean-Marc's.<br />
- d: You can't turn off QM.<br />
- td: He normalizes them. Maybe I could do that with a table. When he fixed his he got a really small improvement, so it's not a major contribution.<br />
- d: It will definitely be normalized different. THe first results he reported were in the break even stage, and now we're sitting at 18% on PSNR. What changes caused that?<br />
- s: The RDO.<br />
- d: The first changes had RDO in them.<br />
- s: They also had tons of stuff disabled.<br />
- d: They are still disabled.<br />
- s: AM is the only thing still disabled.<br />
- td: That's stuff I can't do yet.<br />
- u: Didn't he add RDO to Haar DC?<br />
- td: Mine also has that.<br />
- y: Haar is only for intra right?<br />
- d: Yes.<br />
- d: We really only need to look at a 16x16 block at a time.<br />
- td: I basically started with the more obvious way to do it. The 16x16 at a time is way more sane. I'm not exhaustively searching all combinations right now, but I could do that at 16x16 only.<br />
- u: Do we still have a problem with the borders?<br />
- d: We are already not account for that. We are doing 4pt on the borders. If you aren't searching all combinations, what are you searching?<br />
- td: I try smallest block size and merge to bigger blocks. Then 32x32 gets compared to the best from that. It worked pretty well but it's not exactly like the tran paper.<br />
- y: What you guys describe as dynamic programming is not really how I understand dynamic programming. What we're doing now is only find local minimum.<br />
- d: Thomas's is computing the global optimum but for a problem that is not exactly the problem we want to solve.<br />
- td: Trans paper searches all space for the optimum.<br />
- d: But he is not using dynamic programming for that, just enumerating all solutions.<br />
- y: I remember if the solution for the subproblem is used more than once then you keep around the solution.<br />
- s: I think we don't care whether it's called dynamic programming or not.<br />
- u: I guess we aren't publishing but we should use the right word.<br />
- y: Before external presentation we should probably check.<br />
- u: So Thomas' approach is not exhaustive because it's not splitting blocks?<br />
- s: It's greedy.<br />
- td: It only tries joining one at a time to see if it improves.<br />
- u: So it's hill climbing?<br />
- d: It would be called iterated conditional modes. It's similar to what WebP was doing with intra modes. They would pick modes for every block, then go back and pick modes given knowledge of the coding artifacts of their neighbors. This is like what nathan did for intrapaint.<br />
- u: I was calling it vterbi trellis.<br />
- d: That was dynamic programming for the updates, but scanning makes it ICM (iterated conditional modes).<br />
- u: We still haven't done the test for exhaustive at 16x16?<br />
- td: No. I should do that as well. Unforutnately what I'm doing is not exactly what's in the paper which goes against some of hte point.<br />
- d: You said you did some comparison vs. Jean-Marc, but where are the numbers?<br />
- td: They were all pasted into IRC in various conversations. I should redo it so that it's compared to the correct Jean-Marc branch.<br />
- s: I was considering refactoring JM's branch so that we have defines for optimize for PSNR etc. Because optimize for PSNR branch of JM is not up to date. At least I think so.<br />
- u: JM only does PSNR?<br />
- d: JM has three different branches at least.<br />
- s: Each one builds on the other ones. What I was thinking of doing is having defines for choosing which metric to optimize for. Switching distortion metric and quantization table.<br />
- y: I was thinking if we did this as a runtime mode, then because JM is using a differnet filter set, based on the rate control mode we could switch the filters. Would that make sense? For example, for current master and JM's branch, the filters are different. So the decoders aren't compatible. So we should signal that.<br />
- d: I think the idea is that we should only have one of these approaches and we just haven't decided yet.<br />
- s: We could have an option for using the full lapping stuff, so that if we figure out how to make an encoder for it we can do it.<br />
- u: If we do exhaustive search we should be able to get better performance.<br />
- d: That remains to be shown. JM has a bunch of fancy metrics in his decision. Is there any reason we can't use the same metrics in your stuff Thomas?<br />
- td: Yes, that is an easy path.<br />
- s: You also need to change your QMs. That's why I want to refactor this stuff so we have a common base.<br />
- td: The QMs have to be retuned.<br />
- d: No one knows how because JM didn't document what he did.<br />
- s: Does it make sense to fastssim on an 8x8 block?<br />
- d: You could do something but it wouldn't be fastssim. The first thing it does is downscale 5 times.<br />
- y: In freq domain, if you exclude high frequency, then I think you can achieve something like downscaling.<br />
- d: You don't have five octaves in an 8x8 block.<br />
- y: For 8pt DCT the 8 basis functions, each freq is close to pi/8 right? No, it's low scale. The HF basis is pi/2 to pi. And then the middle one (2nd left) is close to 16 to pi/8.<br />
- d: They aren't octaves. An octave is a power of 2. In an 8x8 block you have room for 3 octaves. You can compose it into bands that are not octaves. You could do partial downsampling at different scales but...<br />
- s: Would it be a good AM metric?<br />
- d: Prior to Daala I would have said SSIM, but JM made AM which didn't make SSIM go up. When I did this in Theora it went up 3dB.<br />
- s: Seems like it's gotten better since the original implementation for SSIM.<br />
- d: There are papers on how to optimize locally for SSIM. Look at Bovik's papers. Thomas, do you know what you're doing next?<br />
- td: Yes, at least for today. It shouldn't take long.<br />
- y: What I tried is I wanted to have the assumption that JM wanted to avoid. That the amount of lapped pixels are different for each block size. For nxn there are 3*nxn lapped pixels. The reason I wanted to include this lappepd pixel as input and output of current block is that if you view from decoder ... The current result is that there is some improvement, but it is less than half of what JM has right now. If I compare to master it is giving me PSNR of -11%. Others are -3, -6, and -6. This is not a small gain. When we do RDO I added the overhead of splitting because sofar when you are adding the rate for block size information (for example 32x32 block and 4x4) we have added just constant amount for each block size. But when you go from 32x32 to 4x4, you have to consider all the split information all the way to 4x4.<br />
- d: This is the part I don't understand. Think about it as you're going up the tree. You're adding 1 bit for each fo the 4x4s. And now you want to consider whether you are doing 1 8x8 or 4 4x4s (you add one bit), then when you go to do 16x16 vs some 8x8s or 4x4s, the ones that are 4x4s will have an extra 2 bits factored in, and then you'll add another 2 bits for the 16x16. When you consider a decision at the higher level, you aboslutely consider the decisions at the lower level.<br />
- y: Actually it's more than 2 bits. I'm adding some low scale of the level.<br />
- d: You are adding much more than that for the lower sizes.<br />
- y: I penalize more for small blocks.<br />
- s: How do you compute your penalty?<br />
- d: ???<br />
- s: Have you looked at the decisions that your stuff does?<br />
- y: They look reasonable to me. They split when there is an HF edge. I only checked at -v50. I didn't check large values.<br />
- d: You've only looked at intra?<br />
- y: I have tested both now. I use the same code for both. Half the improvement for inter as intra.<br />
- d: JM's code was the other way around.<br />
- y: If you can recall, JM started this RDO approach for inter.<br />
- d: He did a version for intra, and he got about half the gain from inter. It seems odd that yours is the other way around. I was trying to say that I don't think your explanation of why you are penalizing is correct. It's entire a bias that when you have relatively little blocks at that level, it's expensive to code a split there. Adding in a constant 2 bits is definitely not hte right cost. We can measur e this. Take JM's branch and look at the probabilities for his decisions. You can compute an average over all the frames in some subset of videos. That is a better static cost than 2 bits.<br />
- y: I'm not sure JM is including the bit for split information.<br />
- td: He added 1/2 bit for each split. Sorry, 2 bits for each split.<br />
- y: Same at every level?<br />
- d: Yes. Just go take some block size decision that does approximately the right thing, and measure that, and now you have a nice static probability table. If 32/n works better than that, then we don't understand something here.<br />
- s: You're just penalizing more against small block, and it just happens to help for some metrics.<br />
- d: JM already put in a hack to penalize small blocks.<br />
- y: Another part I included was to exclude DC coeff during RDO. The DC part is already encoded by Haar before PVQ is coded.<br />
- d: You have to do something different for DC, and JM did something, but I'm not sure what it is.<br />
- td: I think he does partial Haar, depending on how far down the tree is is.<br />
- u: We talked about doing this for partial prediction right?<br />
- d: Not sure what you mean by partial prediction.<br />
<br />
(discussion about smarter's grayscale tool)<br />
<br />
(discussion of quilting that builds up over time. not a lot of diagnosis of this so far)<br />
<br />
- td: Nathan, are skip decisions in the visualizer yet?<br />
- u: Not quite yet. I've got something and I'll have it posted today.<br />
- d: Figure out the quilting stuff is a pretty high priority for Monty. I'll talk to him about that when he gets in. We now have a test case on a video that we can distribute. It happens on sintel if you do 50 frames.<br />
- u: Yushin, were you able to get the stream analyzer to build?<br />
- y: No, a bunch of compile errors.<br />
- u: I'll work with you to figure that out and then I'll commit it.<br />
- d: Guillaume, I agree we should work with monochrome images for now. But we do have to fix the problem eventually.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150224&diff=15517DaalaMeeting201502242015-03-03T16:16:01Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-02-24 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-02-24<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- block size decision experiments<br />
- Why are some edges not being split on in intra frames?<br />
http://jmvalin.ca/video/bsize_fixed/00000000bsize.png<br />
- How do vert and horz prediction impact intra block decisions?<br />
- quantization matrix experiments<br />
- use a QM across the entire block (not per band)<br />
- use a QM for block based on the lapping<br />
<br />
# Attending<br />
<br />
jack, jmspeex, smarter, td-linux, unlord, xiphmont, yushin, daala-person, MrZeus<br />
<br />
# reviews<br />
<br />
nothing to report except nathan has some backlog<br />
<br />
# block size decision experiments<br />
<br />
- u: Want to coordinate what we're doing with different experiments.<br />
- jm: I'm running only on the recursive fixed lapping branch that I have. This is what I get with the latest experiments: http://jmvalin.ca/video/bsize_fixed/<br />
- x: Are those overlayed on the original frame?<br />
- jm: The actual image you see is the original. One thing I've been experimenting with is doing more calibration with basis functions. What happens is that it's really hard to get exactly the same quantization for different block sizes and you don't want the block size decision to pick whatever block size is best calibrated. Also I've been having a hard time at high rate with 4x4 because AM is disabled and it has a flat QM. Picking the block size based on PSNR means it's picking 4x4 more than it should.<br />
- y: I believe turning off the oldest vectors is the right way. If you play with multiple vectors you can hardly conclude anything.<br />
- jm: You can't fix it first. Properly compensating for the basis functions is something you can only do with fixed lapping.<br />
- x: That's not what we meant. There are a number of confounding factors that are making this more difficult.<br />
- y: QM and AM are dynamic decisions and are risky to include in this experiment.<br />
- jm: That's why the decisions I just shared are based on pure PSNR.<br />
- y: I would be happy if you achieve base PSNR positive change.<br />
- jm: Some of hte NTT stuff that I ran is already much better than master. Already a 5-10% improvement over master.<br />
- x: We need to be comparing block size experiments to each other. You are working on something new and Thomas is trying to implement the Tran paper, and Nathan is working on his own set. We have three sets of experiments to cross compare. Turning off QM and AM....<br />
- jm: You can't turn off QM. As soon as you change anything in the filter you change your QMs even if you don't change the numbers in the arrays.<br />
- y: Not chaning QM means as flat as possible.<br />
- jm: There is no such thing as flat. You can make the values flat but what your quantizing is not flat. When you change the lapping you change all the basis functions.<br />
- x: Yes it's a joint optimization problem but let's try to make it as comparable as possible.<br />
- jm: If you think you can separate then have a shot.<br />
- u: At some point, won't we want to jointly optimizje all these things when we're shipping the codec; what is the best set of constants to use for some set of lambdas?<br />
- d: Nobody knows how to do that.<br />
- jm: My experiments are trying to get QMs out of the way. I've tried it before and I'm trying it again: directly compensating for the scaling of the basis functions. It's not working exactly as I expected, but unsure if that is normal. Optimizing for PSNR and flattening everything, I get slightly worse PSNR when I compensate for the basis functions.<br />
- y: Your RDO is not working it's best right?<br />
- jm: This is on still images. I'm trying to get intra-only working first.<br />
- s: You're not doing RDO on intra?<br />
- jm: Not yet.<br />
- s: So it's normal you are not getting better PSNR.<br />
- jm: No, what I mean is that I'm trying to have flat QMs as opposed to pretending they are flat. The last time I tried to do this I was trying to do this with master's lapping, and with that scaling the basis function only gets you so far.<br />
- s: So you're doing it wrong.<br />
- jm: I don't know if I'm doing it wrong or if there is some other effect I'm not seeing.<br />
- s: Are you turning off AM?<br />
- jm: Yes, and a flat QM.<br />
- s: Does it have something to do with the way PVQ encodes things?<br />
- jm: Maybe. It could be that given that we're not operating at infinite rate, there is some deviation from theoretically optimal flat matrices. The one encouraging thing I'm seeing is that if I look at PSNR as a function of bitrate, PSNR is smaller between different blocksizes in the version where I compensate for the basis functions.<br />
- x: It looks like having a line right in a center of a block causes the block to not get divided. A strong edge horizontal/vertical in the middle of a block causes it not to be split.<br />
- jm: In the stuff I just posted?<br />
- x: Yes. This doesn't look sane, so there may yet be a bug.<br />
- jm: Pure vertical or pure horizontal edges can get away with slightly larger block sizes.<br />
- x: The fact that the algorithm seems blind to it seems like a concern. The images don't fill me with a great deal of confidence.<br />
- jm: Is there anything other than that? If you gave me this image without any segmentation I would also hesitate to spilt there.<br />
- x: That should definitely be split.<br />
- u: That's an experiment that needs to be run and we don't need to argue about this.<br />
- u: One question I still have is what is a good RDO metric? Just PSNR in spatial domain?<br />
- jm: I'm doing that as a first step, but I want to eventually do HVS and even AM in RDO.<br />
(missed some)<br />
- jm: I'm starting to suspect this kind of issue is why most video codecs are mostly optimizing with flat QMs.<br />
- d: It is, but you can see now why that's a bad idea right?<br />
- jm: Why?<br />
- d: Because if you do that you can put yourself into a corner where you can't design anything where it's not flat.<br />
- y: Yes. There is a long list of stuff for the second one.<br />
- jm: Does anyone know of a variable block size encoder that has non-flat QMs?<br />
- d: VP9<br />
- s: H264<br />
- jm: All of AC is flatly quantized right?<br />
- d: Right.<br />
- x: So that's JMs experiment. Nathan?<br />
- u: The one I'm working on is a variation of what I did for intra-paint. I'm trying to do a viterbi style iteration. For some configuration find some new partition that has an improvement in RDO space.<br />
- d: Wouldn't you try to do that in a checkerboard pattern?<br />
- u: It's not quite done done.<br />
- x: This is using fixed lapping like jean-marc?<br />
- u: No, variable lapping. You have to consider your 8 superblock neighbors and the RDO impact that has on them. This won't be optimal but it should converge and keep improving.<br />
- x: Are you running into the same problems with scaling?<br />
- u: I haven't gotten that far yet.<br />
- jm: On the topic of comparing stuff, I believe that if we optimize for PSNR we have a chance of having a decent comparison.<br />
- x: Fair point, but you mentioned that if you did that it gets worse.<br />
- jm: We're talking about 1%. Compared to tuning for one thing or the other, metrics fly around by 20% one direction or the other.<br />
- x: Compared to that it is indeed small. I'm just concerned about it becoming more complex of a problem than is warranted.<br />
- s: I think it makes sense that a flat matrix is worse because you are compressing less coeffs.<br />
- jm: Maybe. You mean we're keeping more HFs that if we tilt the matrix?<br />
- s: Yeah. If you look at how you spend your bits, you probably spend more bits on AC to get the same quality.<br />
- jm: The effect is relative small so I'm still wondering whether I screwed up or not. I'm not that concerned otherwise.<br />
- j: What about Thomas's experiment?<br />
- t: I'm working on what the original paper does based on Nathan's quadtree order of performing the lapping. I do the superblock lapping at smallest lapping. Then I try every possible combination of splitting inside that. So I'll pick a splitting, code that, and then wind back and determine distortion and rate.<br />
- x: Did the tran paper do that in raster scan order?<br />
- t: Yes, and that's what I'm doing too. The whole point of 4pt lapping on the edges is so that superblocks don't influence other superblocks.<br />
- u: As a last pass you just code everything normally and pick the right lapping for superblocks?<br />
- t: Yes.<br />
- u: That's a good idea. How does it perform?<br />
- t: I'm actually having problems, probably bugs. I'm testing on intra because theirs worked on intra. My decisions looked wrong even though it does already work on inter, so I want to fix those first.<br />
- x: It looks like how thomas structured the code, I can't use it directly. It struck me that the tran paper didn't use maximal borrowing on the upper and left border.<br />
- t: It does not find the smallest possible lapping across a whole edge. It will switch in the middle of an edge. That's what the tran paper does, but I don't do that.<br />
<br />
# small issues<br />
<br />
- u: It looks like Jenkins builds are failing due to changes in build scripts that enabled the DCT optimization. It also looks like the BSD_SOURCE #define is breaking the build as well. I pinged Ralph.<br />
- t: I can fix the BSD_SOURCE thing and I'll look at the DCT one.<br />
<br />
# QMs<br />
<br />
- jm: I've revised some previous thoughts that I had on how to do them with PVQ. I was thinking a few things backwards, and now I think we can apply a standard QM on the DCT coeffs before sending anything to PVQ and forget about the per-band thing completely.<br />
- u: Revised in the last 10m?<br />
- jm: No, I've been thinking this for a while. Mostly because the contrast sensitivity function for the noise should be kind of similar.<br />
- s: How is that different from what we do now?<br />
- jm: Right now all the bands are flat. You scale a band compared to another band, but not within the band. But I think now you can do it from outside PVQ and PVQ will preserve the right thing. For some reason, I thought the scaling would be different when I thought about this originally. Right now between two bands I use different scaling, and that is all I'm able to model. Instead I think we should scale the coeffs before PVQ and not bother with different scales per band.<br />
- s: Is what we're doing currently different than using QMs before PVQ where each band uses same coeffs?<br />
- jm: It may be different with some effects with lambda, but conceptually it is the same.<br />
- s: The first step isn't to use the same QMs but before PVQ?<br />
- jm: Something like that. I'd need to make sure there isn't some internal PVQ stuff that works around that. Of course we need to come up with equivalent QMs for different block sizes.<br />
- s: That would solve the problem with 4x4 which is flat. So maybe we should start with this QMs before doing weird stuff with block sizes.<br />
- u: That seems reasonable.<br />
- jm: Yes and no. Because (missed).<br />
- s: OH right. Given fixed lapping like in your branch, can we generate removing of the scaling instead of having magic numbers in the QMs?<br />
- jm: There's a compute_basis and if you give it mag, it will give you the magnitude of the basis functions. What you want to do is compute the outer product of the vector by itself so you get a matrix of scaling factors.<br />
- s: I think we should put that in the encoder to separate concerns with the optimal matrix. Right now when you're tweaking the QMs, you are tweaking both the scaling stuff and whatever you want to optimize for. It would be nice to separate that.<br />
- jm: Absolutely. That's what I'm working on right now.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15516Daala Weekly Meetings2015-03-03T16:15:22Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150217|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - TODO<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150117&diff=15515DaalaMeeting201501172015-03-03T16:15:09Z<p>Jack: moved DaalaMeeting20150117 to DaalaMeeting20150217</p>
<hr />
<div>#REDIRECT [[DaalaMeeting20150217]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150217&diff=15514DaalaMeeting201502172015-03-03T16:15:09Z<p>Jack: moved DaalaMeeting20150117 to DaalaMeeting20150217</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-02-17<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- switch to vidyo? (jack)<br />
- Suggestion: more technical meeting time (jmspeex)<br />
- New lapping branch (jmspeex)<br />
- ??<br />
<br />
# Attending<br />
<br />
daala-person, derf, jack, jmspeex, smarter, td-linux, unlord, yushin<br />
<br />
# reviews<br />
<br />
# vidyo<br />
<br />
several people opposed to having any proprietary software, even though the result is everyone in mountain view sittingin the same room each with headphones on and maximally distant.<br />
<br />
# more technical meeting time<br />
<br />
- jm: I want more meeting time, so I was thinking every day at noon or something<br />
- u: I would like some more structure to them than just that.<br />
- jm: I was thinking more watercooler time.<br />
- d: That's a different thing. I don't think we should make this meeting longer just for that.<br />
- td: I think the other meeting should have particular topics, otherwise we will get unbounded conversation time.<br />
- jm: I'm trying to go one step in the direction of what happens when we have our work weeks. Those are more productive than average.<br />
- d: Did you want to pick a day and time? Once a week to start with and adjust from there? Noon is great if you never want me to show up.<br />
- td: I'm available all the times you met last week.<br />
- jm: For me, after 3pm eastern it gets hard.<br />
- d: Try 11 pacific on Wednesday?<br />
- jm: That works fine. (no objections from others)<br />
- j: Who's coming up with topic?<br />
- jm: Blocksize will be a good topic.<br />
<br />
# new lapping branch<br />
<br />
- jm: There is a new lapping branch.<br />
- u: Is it different than my patch?<br />
- jm: Yes.<br />
- jm: https://github.com/jmvalin/daala/<br />
- jm: Essentially I've come to the conclusion that our lapping is a dead end when it comes to being able to write a reasonable encoder. The github branch I have is doing lapping differently. It uses fixed size lapping everywhere.<br />
- td: On all frames? Or just inter?<br />
- jm: Right now it was simpler to make it hte same on intra and inter. It might be good enough with that. We could always go back and have intra use the old lapping. I'm really focused on inter at this point. What it does it laps recursively just like nathan's patch. The difference is that at each level it is always the same level no matter what the blocksize is. Right now it's configured with superblock at 8pt, 16x16 level at 8pt, 8x8 at 8pt, and at 4x4 it uses 4pt. 16x16 and 32x32 are lapped half of what they would normally be. 4x4 is weird because it's lapped asymmetrically. Running this was 2-3% worse. Part of that is the fact that changing the lapping changes hte basis scaling and I haven't retuned the quant matrices. I figure whatever we lose we have to give up because the other option isn't working. It's either this or ditch lapping completely.<br />
- u: What makes you say it's not working?<br />
- jm: I don't know who else tried block size switching with current master, but whoever works on that will come to the same conclusion. I lot of this idea comes from Guillaume and I pushed it a little further. With the current master there is no reasonable way to search for blocksize with some kind of dynamic programming algorithm. At first we thought the search was just hard, but it's actually much harder than we thought. With current master you can't have a reasonable distortion metric to make the block size decision.<br />
- td: Which branch in your github has this?<br />
- jm: master. On my branch I do the lapping differently and I have some basic block size RDO. On FourPeople at low bitrate the block size decision makes sense already. The metric is trying to optimize for PSNR but it fights with PVQ so Guillaume and I are trying to come up with better metrics there. At low bitrate it's also fighting the untuned quantization matrices, but I know what the problem is there and can make a solution. Intraprediction may be possible now because you can unlap enough.<br />
- u: What about top block in a superblock?<br />
- jm: In all cases you can not unlap everything, but you can unlap enough. The lapped region will always be lapped the same way so you can use these samples. Unlike with freq domain intra where we tried to use the info from lapped pixels without accounting for how they were lapped.<br />
- u: We still have to do the experiments and we can't know this will work until we've tried it.<br />
- jm: Yes, of course. But unlike what we were doing before, this has a chance of working. I wouldn't suggestion doing those experiments now. Let's get inter actually working.<br />
- d: We would also have to do IPR research.<br />
- jm: If you wanted to you could run a 4x4 DCT on the boundary just like what we were doing and we would get to freq domain intra that has a chance of working because all the 4x4s are the same. That's the idea anyway. It potentially undooms intra prediction.<br />
- u: We still have the same problem with intra superblocks in an inter frame?<br />
- jm: I don't see what's special about that one. You have the coefficients and you do the post filtering and you have the pixel domain coeffs. It's not fundamentally different.<br />
- d: We still have the same problem that the motion search does not consider intra.<br />
- jm: Sure, and that will be fun because blocks aren't even aligned.<br />
- d: All that is going to change anyway because we will have bigger blocks.<br />
- jm: The good news is that I've been looking at motion compensation on FourPeople. Not sure about the rate itself, but in terms of prediction it is doing a good job.<br />
- d: I had the same thought after replacing the motion compensation with another codecs was actually worse. I was hoping ours was broken :)<br />
- jm: The known things to do before we get decent BSS on this branch is 1) new quantization matrices and 2) better distortion metric than MSE.<br />
- d: What are your plans for that metric?<br />
- jm: Guillaume?<br />
- s: We talked about doing something different like PSNR-HVS. I don't know if you have a better idea than that.<br />
- td: Doesn't x264 use a hadamard that is weighted?<br />
- s: x264 uses sum of squared error. It also does hadamard at 4x4 and 8x8 levels. It's a way to keep the energy of whatever you are coding.<br />
- td: Ok. psnrhvs seems slow but good, and we can try to make it faster.<br />
- d: Except that we know that psnrhvs is the wrong metrics to optimize for at low bitrates.<br />
- s: Maybe we could interpolate between two metrics based on bitrate?<br />
- d: It all sounds very expensive, but let's get something that works first and then try to make it fast.<br />
(some discussion of metrics used in real time coders (SAD, SATD, MSE))<br />
- d: Have you looked at trying to use TF to get your 4x4s instead of doing 4pt lapping and actual DCTs?<br />
- jm: I have not looked at that. Do you think that would be better?<br />
- d: It's still asymmetric but you might have less leakage on the tail. This was the design I had 3 years ago until Greg shot all my ideas down with this experiments. The thought I had before was that we'd have 8pt lapping and TF down to 4x4 instead of doing 4x4 DCTs with 4pt lapping. If I remember the way the basis functions looked you end up with less ringing but the coding gain may not be as good.<br />
- jm: I think your way would have more ringing because I have supprot of 12 and you're talking about support of 16.<br />
- d: I have graphs of these.<br />
- u: Are your graphs with 4x4 on one side and 8x8 on the other side?<br />
- d: No, 8pt everywhere, with TFed down 4x4s. What I'm looking at is slide 36 from intro to video.<br />
- jm: I don't know what filter you used for that, but what I'm getting with the current lapping filter is much worse than that.<br />
- d: That was with the ramp constraint filter.<br />
- jm: Uploading what it looks like now. http://jmvalin.ca/video/lapping4_tf.png and compared to this which is what the current code is running: http://jmvalin.ca/video/lapping4_8.png One of them has a lot of ringing and the DC goes below zero, and the other does not.<br />
- d: I agree that is still a problem.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15513Daala Weekly Meetings2015-03-03T16:14:48Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to attend the [[Daala Weekly Meetings|weekly progress meetings]] using [http://wiki.mumble.info Mumble]. The address is '''mf4.xiph.org''' and the port is '''64738'''.<br /><br />
They occur on '''Tuesdays''' at '''[http://www.timeanddate.com/worldclock/fixedtime.html?msg=Daala+Weekly+Meeting&iso=20150210T09&p1=1241 9AM Pacific Time]''' (5PM UTC/GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150117|2015 February 17]] - tech watercooler, new lapping branch<br />
* [[DaalaMeeting20150224|2015 February 24]] - block size decisions, quantization matrices<br />
* [[DaalaMeeting20150303|2015 March 3]] - TODO<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaRoadmap&diff=15509DaalaRoadmap2015-02-27T15:23:23Z<p>Jack: /* Estimates of Technique Effectiveness */</p>
<hr />
<div>== Daala Planning ==<br />
<br />
This is an overview of the Daala project roadmap.<br />
<br />
'''Information on this page is highly subject to update and change.'''<br />
<br />
Please help reach out to us if you are interested in contributing to the project. We would love your help!<br />
<br />
=== Plans for 2014 ===<br />
<br />
See [https://daala.etherpad.mozilla.org/daala-plan-2014 this etherpad] for details. Most information has moved there. See also the [[Daala Weekly Meetings|weekly meeting minutes]] on [[Daala]] for current efforts.<br />
<br />
=== Plans for September, 2013 to March, 2014 ===<br />
<br />
==== Improve existing techniques ==== <br />
<br />
Examining and significantly modifying some of the basic coding tools within Daala to improve efficiency and quality:<br />
<br />
1) Lapped Transforms<br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo1.shtml Monty's LT demo]<br />
* [[TDLT|Time-Domain Lapped Transforms]] wiki page<br />
* https://thanglong.ece.jhu.edu/Tran/Pub/prepost.pdf<br />
* https://research.microsoft.com/pubs/102075/malvar_elt_tsp1192.pdf<br />
<br />
2) Frequency Domain Intra-prediction <br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml Monty's Intra-prediction demo]<br />
* [[Intra|Intra-prediction]] wiki page<br />
<br />
3) Time/Frequency resolution switching <br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo3.shtml Monty's TF switching demo]<br />
<br />
4) Chroma from Luma (CfL)<br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo4.shtml Monty's CfL demo]<br />
<br />
5) Motion Compensation tools<br />
<br />
==== Research new techniques ====<br />
<br />
Investigate the following to see if they should be adopted into Daala:<br />
<br />
1) Edge-directed Interpolation <br />
* https://elynxsdk.free.fr/ext-docs/Demosaicing/more/news0/New%20Edge-Directed%20Interpolation.pdf<br />
* [https://exp.martres.me/edi/ smarter's EDI demo in Javascript]<br />
<br />
2) Multi-frame Motion Compensation<br />
<br />
==== Testing tools ====<br />
<br />
1) Experiment with command-line encode/decode/performance tools<br />
* Help people try the codec<br />
* Self-testing<br />
* Improvement metrics for casual contributors to verify changes<br />
<br />
2) Prototype RTP in GIPS/webrtc.org/browser code<br />
<br />
3) Prototype HTTP streaming.<br />
<br />
=== Plans for March, 2014 to September, 2014 ===<br />
<br />
<br />
From March, 2014 to June, 2014: Tuning the various coding tools and components of Daala (assumes investigation and major modifications of the basic coding tools are completed)<br />
<br />
By September, 2014: Be able to show significant quality improvements compared to Daala's performance today (September, 2013).<br />
<br />
=== Progress and Planning Tools ===<br />
* Every week a Mumble meeting will occur to discuss current development.<br />
* Every 6-8 weeks the team will report on what he has accomplished.<br />
* Every month the team will create a detailed task list of what they plan to do for that month.<br />
<br />
=== Estimates of Technique Effectiveness ===<br />
<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-<br />
! Technique<br />
! % of bitrate est.<br />
! risk<br />
|-<br />
| intraprediction<br />
| 10% <br />
| <br />
|-<br />
| rate control<br />
| 10%<br />
| low<br />
|-<br />
| multiple reference frames<br />
| 10%<br />
|<br />
|-<br />
| alternate motion predictors<br />
| 5%<br />
|<br />
|-<br />
| multi-resolution blending<br />
| 2%<br />
|<br />
|-<br />
| edge-directed interpolation<br />
| 4-5%<br />
|<br />
|-<br />
| sub-pel search<br />
| 2%<br />
|<br />
|-<br />
| mixed prediction (intra+inter)<br />
| 12%<br />
| high<br />
|-<br />
| generic encoder replacement/optimization<br />
| 1%<br />
|<br />
|-<br />
| skip work<br />
| 5%<br />
|<br />
|-<br />
| deringing<br />
| 10%<br />
| medium<br />
|-<br />
| bi-prediction<br />
| 15%<br />
|<br />
|-<br />
| k-tokenizer<br />
| +/- 1%<br />
|<br />
|-<br />
| 32x32 motion<br />
| 10%<br />
| low<br />
|-<br />
| don't code outside frame<br />
| 1-2%<br />
|<br />
|-<br />
| adaptive motion compensation work<br />
adjacent blocks differing by more than 1 level<br />
| 10%<br />
| high<br />
|-<br />
| don't use SAD<br />
|<br />
|<br />
|}<br />
<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaRoadmap&diff=15508DaalaRoadmap2015-02-27T15:21:25Z<p>Jack: added technique estimate table</p>
<hr />
<div>== Daala Planning ==<br />
<br />
This is an overview of the Daala project roadmap.<br />
<br />
'''Information on this page is highly subject to update and change.'''<br />
<br />
Please help reach out to us if you are interested in contributing to the project. We would love your help!<br />
<br />
=== Plans for 2014 ===<br />
<br />
See [https://daala.etherpad.mozilla.org/daala-plan-2014 this etherpad] for details. Most information has moved there. See also the [[Daala Weekly Meetings|weekly meeting minutes]] on [[Daala]] for current efforts.<br />
<br />
=== Plans for September, 2013 to March, 2014 ===<br />
<br />
==== Improve existing techniques ==== <br />
<br />
Examining and significantly modifying some of the basic coding tools within Daala to improve efficiency and quality:<br />
<br />
1) Lapped Transforms<br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo1.shtml Monty's LT demo]<br />
* [[TDLT|Time-Domain Lapped Transforms]] wiki page<br />
* https://thanglong.ece.jhu.edu/Tran/Pub/prepost.pdf<br />
* https://research.microsoft.com/pubs/102075/malvar_elt_tsp1192.pdf<br />
<br />
2) Frequency Domain Intra-prediction <br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml Monty's Intra-prediction demo]<br />
* [[Intra|Intra-prediction]] wiki page<br />
<br />
3) Time/Frequency resolution switching <br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo3.shtml Monty's TF switching demo]<br />
<br />
4) Chroma from Luma (CfL)<br />
* [https://people.xiph.org/~xiphmont/demo/daala/demo4.shtml Monty's CfL demo]<br />
<br />
5) Motion Compensation tools<br />
<br />
==== Research new techniques ====<br />
<br />
Investigate the following to see if they should be adopted into Daala:<br />
<br />
1) Edge-directed Interpolation <br />
* https://elynxsdk.free.fr/ext-docs/Demosaicing/more/news0/New%20Edge-Directed%20Interpolation.pdf<br />
* [https://exp.martres.me/edi/ smarter's EDI demo in Javascript]<br />
<br />
2) Multi-frame Motion Compensation<br />
<br />
==== Testing tools ====<br />
<br />
1) Experiment with command-line encode/decode/performance tools<br />
* Help people try the codec<br />
* Self-testing<br />
* Improvement metrics for casual contributors to verify changes<br />
<br />
2) Prototype RTP in GIPS/webrtc.org/browser code<br />
<br />
3) Prototype HTTP streaming.<br />
<br />
=== Plans for March, 2014 to September, 2014 ===<br />
<br />
<br />
From March, 2014 to June, 2014: Tuning the various coding tools and components of Daala (assumes investigation and major modifications of the basic coding tools are completed)<br />
<br />
By September, 2014: Be able to show significant quality improvements compared to Daala's performance today (September, 2013).<br />
<br />
=== Progress and Planning Tools ===<br />
* Every week a Mumble meeting will occur to discuss current development.<br />
* Every 6-8 weeks the team will report on what he has accomplished.<br />
* Every month the team will create a detailed task list of what they plan to do for that month.<br />
<br />
=== Estimates of Technique Effectiveness ===<br />
<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-<br />
! Technique<br />
! % of bitrate est.<br />
! risk<br />
|-<br />
| intraprediction<br />
| 10% <br />
| <br />
|-<br />
| rate control<br />
| 10%<br />
| low<br />
|-<br />
| multiple reference frames<br />
| 10%<br />
|<br />
|-<br />
| alternate motion predictors<br />
| 5%<br />
|<br />
|-<br />
| multi-resolution blending<br />
| 2%<br />
|<br />
|-<br />
| edge-directed interpolation<br />
| 4-5%<br />
|<br />
|-<br />
| sub-pel search<br />
| 2%<br />
|<br />
|-<br />
| mixed prediction (intra+inter)<br />
| 12<br />
| high<br />
|-<br />
| generic encoder replacement/optimization<br />
| 1%<br />
|<br />
|-<br />
| skip work<br />
| 5%<br />
|<br />
|-<br />
| deringing<br />
| 10%<br />
| medium<br />
|-<br />
| bi-prediction<br />
| 15%<br />
|<br />
|-<br />
| k-tokenizer<br />
| +/- 1%<br />
|<br />
|-<br />
| 32x32 motion<br />
| 10%<br />
| low<br />
|-<br />
| don't code outside frame<br />
| 1-2%<br />
|<br />
|-<br />
| adaptive motion compensation work<br />
adjacent blocks differing by more than 1 level<br />
| 10%<br />
| high<br />
|-<br />
| don't use SAD<br />
|<br />
|<br />
|}<br />
<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150217&diff=15502DaalaMeeting201502172015-02-24T16:21:34Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-02-17 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-02-17<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- switch to vidyo? (jack)<br />
- Suggestion: more technical meeting time (jmspeex)<br />
- New lapping branch (jmspeex)<br />
- ??<br />
<br />
# Attending<br />
<br />
daala-person, derf, jack, jmspeex, smarter, td-linux, unlord, yushin<br />
<br />
# reviews<br />
<br />
# vidyo<br />
<br />
several people opposed to having any proprietary software, even though the result is everyone in mountain view sittingin the same room each with headphones on and maximally distant.<br />
<br />
# more technical meeting time<br />
<br />
- jm: I want more meeting time, so I was thinking every day at noon or something<br />
- u: I would like some more structure to them than just that.<br />
- jm: I was thinking more watercooler time.<br />
- d: That's a different thing. I don't think we should make this meeting longer just for that.<br />
- td: I think the other meeting should have particular topics, otherwise we will get unbounded conversation time.<br />
- jm: I'm trying to go one step in the direction of what happens when we have our work weeks. Those are more productive than average.<br />
- d: Did you want to pick a day and time? Once a week to start with and adjust from there? Noon is great if you never want me to show up.<br />
- td: I'm available all the times you met last week.<br />
- jm: For me, after 3pm eastern it gets hard.<br />
- d: Try 11 pacific on Wednesday?<br />
- jm: That works fine. (no objections from others)<br />
- j: Who's coming up with topic?<br />
- jm: Blocksize will be a good topic.<br />
<br />
# new lapping branch<br />
<br />
- jm: There is a new lapping branch.<br />
- u: Is it different than my patch?<br />
- jm: Yes.<br />
- jm: https://github.com/jmvalin/daala/<br />
- jm: Essentially I've come to the conclusion that our lapping is a dead end when it comes to being able to write a reasonable encoder. The github branch I have is doing lapping differently. It uses fixed size lapping everywhere.<br />
- td: On all frames? Or just inter?<br />
- jm: Right now it was simpler to make it hte same on intra and inter. It might be good enough with that. We could always go back and have intra use the old lapping. I'm really focused on inter at this point. What it does it laps recursively just like nathan's patch. The difference is that at each level it is always the same level no matter what the blocksize is. Right now it's configured with superblock at 8pt, 16x16 level at 8pt, 8x8 at 8pt, and at 4x4 it uses 4pt. 16x16 and 32x32 are lapped half of what they would normally be. 4x4 is weird because it's lapped asymmetrically. Running this was 2-3% worse. Part of that is the fact that changing the lapping changes hte basis scaling and I haven't retuned the quant matrices. I figure whatever we lose we have to give up because the other option isn't working. It's either this or ditch lapping completely.<br />
- u: What makes you say it's not working?<br />
- jm: I don't know who else tried block size switching with current master, but whoever works on that will come to the same conclusion. I lot of this idea comes from Guillaume and I pushed it a little further. With the current master there is no reasonable way to search for blocksize with some kind of dynamic programming algorithm. At first we thought the search was just hard, but it's actually much harder than we thought. With current master you can't have a reasonable distortion metric to make the block size decision.<br />
- td: Which branch in your github has this?<br />
- jm: master. On my branch I do the lapping differently and I have some basic block size RDO. On FourPeople at low bitrate the block size decision makes sense already. The metric is trying to optimize for PSNR but it fights with PVQ so Guillaume and I are trying to come up with better metrics there. At low bitrate it's also fighting the untuned quantization matrices, but I know what the problem is there and can make a solution. Intraprediction may be possible now because you can unlap enough.<br />
- u: What about top block in a superblock?<br />
- jm: In all cases you can not unlap everything, but you can unlap enough. The lapped region will always be lapped the same way so you can use these samples. Unlike with freq domain intra where we tried to use the info from lapped pixels without accounting for how they were lapped.<br />
- u: We still have to do the experiments and we can't know this will work until we've tried it.<br />
- jm: Yes, of course. But unlike what we were doing before, this has a chance of working. I wouldn't suggestion doing those experiments now. Let's get inter actually working.<br />
- d: We would also have to do IPR research.<br />
- jm: If you wanted to you could run a 4x4 DCT on the boundary just like what we were doing and we would get to freq domain intra that has a chance of working because all the 4x4s are the same. That's the idea anyway. It potentially undooms intra prediction.<br />
- u: We still have the same problem with intra superblocks in an inter frame?<br />
- jm: I don't see what's special about that one. You have the coefficients and you do the post filtering and you have the pixel domain coeffs. It's not fundamentally different.<br />
- d: We still have the same problem that the motion search does not consider intra.<br />
- jm: Sure, and that will be fun because blocks aren't even aligned.<br />
- d: All that is going to change anyway because we will have bigger blocks.<br />
- jm: The good news is that I've been looking at motion compensation on FourPeople. Not sure about the rate itself, but in terms of prediction it is doing a good job.<br />
- d: I had the same thought after replacing the motion compensation with another codecs was actually worse. I was hoping ours was broken :)<br />
- jm: The known things to do before we get decent BSS on this branch is 1) new quantization matrices and 2) better distortion metric than MSE.<br />
- d: What are your plans for that metric?<br />
- jm: Guillaume?<br />
- s: We talked about doing something different like PSNR-HVS. I don't know if you have a better idea than that.<br />
- td: Doesn't x264 use a hadamard that is weighted?<br />
- s: x264 uses sum of squared error. It also does hadamard at 4x4 and 8x8 levels. It's a way to keep the energy of whatever you are coding.<br />
- td: Ok. psnrhvs seems slow but good, and we can try to make it faster.<br />
- d: Except that we know that psnrhvs is the wrong metrics to optimize for at low bitrates.<br />
- s: Maybe we could interpolate between two metrics based on bitrate?<br />
- d: It all sounds very expensive, but let's get something that works first and then try to make it fast.<br />
(some discussion of metrics used in real time coders (SAD, SATD, MSE))<br />
- d: Have you looked at trying to use TF to get your 4x4s instead of doing 4pt lapping and actual DCTs?<br />
- jm: I have not looked at that. Do you think that would be better?<br />
- d: It's still asymmetric but you might have less leakage on the tail. This was the design I had 3 years ago until Greg shot all my ideas down with this experiments. The thought I had before was that we'd have 8pt lapping and TF down to 4x4 instead of doing 4x4 DCTs with 4pt lapping. If I remember the way the basis functions looked you end up with less ringing but the coding gain may not be as good.<br />
- jm: I think your way would have more ringing because I have supprot of 12 and you're talking about support of 16.<br />
- d: I have graphs of these.<br />
- u: Are your graphs with 4x4 on one side and 8x8 on the other side?<br />
- d: No, 8pt everywhere, with TFed down 4x4s. What I'm looking at is slide 36 from intro to video.<br />
- jm: I don't know what filter you used for that, but what I'm getting with the current lapping filter is much worse than that.<br />
- d: That was with the ramp constraint filter.<br />
- jm: Uploading what it looks like now. http://jmvalin.ca/video/lapping4_tf.png and compared to this which is what the current code is running: http://jmvalin.ca/video/lapping4_8.png One of them has a lot of ringing and the DC goes below zero, and the other does not.<br />
- d: I agree that is still a problem.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15501Daala Weekly Meetings2015-02-24T16:21:02Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to join the weekly progress meetings using [http://wiki.mumble.info Mumble] at '''mf4.xiph.org''' on '''Tuesdays''' at '''[http://www.time.gov/ 9AM PST]''' (5PM GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
* [[DaalaMeeting20150117|2015 February 17]] - tech watercooler, new lapping branch<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150210&diff=15472DaalaMeeting201502102015-02-17T16:55:16Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-02-10 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-02-10<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- od_hv_intra_pred (yushin)<br />
- Block size decision<br />
- AWCY metrics<br />
- Suggestion: more technical meeting time<br />
<br />
# Attending<br />
<br />
azita, yushin, jmspeex, td-linux, mrzeus, jack, tmatth, xiphmont<br />
<br />
# reviews<br />
<br />
reviews are good<br />
<br />
# od_hv_intra_pred<br />
<br />
- jm: I looked into this and discussed with Yushin. I believe the code is actually correct but the encoder is suboptimal. Basically the prediction attempts to put something in all the bins where it actually makes sense and leaves it up to the encoder to encode noref or not. In no case would not putting something in a band make it better.<br />
- y: I checked that. My conclusion is that hte idea is not working well. It works for 4x4 but not for larger block sizes. It fails most of the time. However, there is a noref that will cover up the bad predictor. I made a random change to not code outside of some 4x4 coeff, and there was a gain. But I'd like to check this issue more. I know we've spent a lot of time on TF switching, but that is really for intraprediction.<br />
- jm: In theory, the same thing should work for any blocksize. What probably happened is that in some cases a prediction is only marginally useful that signaling not noref ends up costing more than the prediction is helping. This is an RDO problem in the encoder. It's known that the rate estimates on noref and gain/theta are not very good, and this would be a symptom of that. it would be fixable by fixing the rdo rates.<br />
- y: My take is that it's more than RDO. The correlation between neighbor block and current block is dropping very quickly. The real world doesn't have checkerboards and wallpaper in general.<br />
- jm: This wasn't to say I've solved intraprediction. In cases that are really really easy, this prevents us from looking really bad. It's almost free, so we might as well use it. It's kind of a baseline; it works in a few cases, but it doesn't hurt in other cases, and it's a benchmark for future predictors. If you can't beat this, then don't bother.<br />
- y: There's room for improvement. I think we should enable this for 4x4 and disable elsewhere.<br />
- jm: If you want to disable it for higher blocksizes then do it in the encoder.<br />
- y: We can turn off noref for those higher blocks.<br />
- jm: The way the bitstream is designed you have to code noref. It is jointly coded with gain and theta.<br />
- y: I'll track this as a side task and try to find a slight improvement from the current state.<br />
- jm: If we never code noref, it's free because it's jointly coded and adapted. I think it should work at 16x16. There's nothing fundamental about 4x4. The problem is that the encoder is using it too much.<br />
- y: Beyond 8x8 I can hardly expect that the blocks are correlated.<br />
- j: What happens when the blocksizes don't match?<br />
- jm: Nathan has a patch that TFs, but currently it only applies when they are the same.<br />
- y: The phase might not match, see what I mean? If there's a phase change, the DCT response is really different and you can't copy the coefficient.<br />
- jm: If your pattern is pure horizontal stripes then this will work perfectly.<br />
- y: But there are only rare cases for that.<br />
- jm: I just did a test at forced 8x8 with checkerboard. Without prediction is 98kB and with prediction it is 51kB.<br />
- y: I heard from Tim that this gets up to 50% drop in rate.<br />
- jm: The point is that it works; it's not about the block size.<br />
- y: I don't agree. It would be useful for synthetic images, but real world images don't have these properties. There's no periodicity in real world images.<br />
- jm: This isn't about perodicity. It's about continuing horizontal patterns. It's mostly equivalent to a freq domain version of the standard H and V predictors.<br />
- y: From my small experiment, larger blocks are hardly ever predicted.<br />
- jm: Any sort of intrapredictor works better at 4x4.<br />
- y: Very few blocks are intrapredicted in the current scheme.<br />
- jm: What I'm saying is that there are a lot of cases that are badly predicted. A few cases will be very well predicted, so we might as well catch these. And this has nothing to do with the blocksize. At 16x16 there is still a gain on synthetic stuff. This was never meant to make great gains. I don't see why we wouldn't include it.<br />
- x: If it's only useful on a tenth of a percent, then it's not useful. On the other hand, this may be great if I get the directional transforms working.<br />
- jm: The success ratio on natural stuff is very low.<br />
- y: How much gain do we get from Nathan's adaptive blocksize patch?<br />
- jm: I have no idea anymore.<br />
- y: Ok. I will try to check that after I look more into this basic version.<br />
- jm: Nathans' just TFs the neighbor block to the right size and then pretends they matched. If the current block is 8x8, and the neighbor is 16x16, then it will TF down the neighbor and use the 8x8 to predict.<br />
<br />
# block size decision<br />
<br />
- jm: This still really worries me. I've started making more experiments for BSS, and I think I've come across a problem that would even effect the ridiculous method in the paper Tim pointed out. Who here has looked at this?<br />
- td: I looked a while ago.<br />
- y: I am still very interested in this. Last update I got was that Jean-Marc had a small quick patch that fixed some things.<br />
- jm: Absolutely not. That was a hack until we find the real solution.<br />
- y: But the real solutoin would include that condition. I didn't mean that exact patch.<br />
- jm: Yeah. I've been looking at solving the real problem because this is something that could kill the lapping approach. Right now the approach I tried to take is have fixed lapping and try different block size decisions and see hwat happens. But even the distortion metric itself causes problems with lapping. In the trivial case where the image is not moving at all, measuring the distortion of 4x4 and 8x8, not moving in 4x4 and 8x8 gives you really different distortion estimates because the whole thing is biorthogonal. If we do things in the lapped domain, we can't even resolve a case as simple as everything will be skipped so let's use the largest blocksize.<br />
- td: I'm curious what comes out of smarter's only 4pt lapping thing.<br />
- jm: His approach would have the same problem. If our distortion metrics cannot be equal in the case where we are skipping everything then it's kind of doomed. The minimum you would want is for your metrics of skipping an 8x8 block would be the same as skipping 4 4x4 blocks in the same location.<br />
- td: If he only uses 4pt lapping that is the case.<br />
- jm: No because you'd have interior lapping in one case but not the other.<br />
- td: You should be able to make a distortion metric that would be the same for both. That seems wrong.<br />
- jm: It is wrong, and short of inverting all the lapping I don't see a way.<br />
- j: We can invert the lapping here can't we?<br />
- jm: Yes, but I think it would cause other problems. Where do you ignore distortion and that sort of thing. The more I look into this problem the less I can see how we can solve it. Codecs like 265 do really fancy block size saerch and get the optimal quadtree and we can't come up with something halfway decent.<br />
- y: With other codecs they use real RDO and they do it at the top level. They probe full coding passes. I have changed my approach to block size decision to larger scale. Last meeting I explained we want approximation of lapped transform and pvq coding. And each blocksize we will test the approximated version and then we will get a rough estimate of rate and distortion for that blocksize.<br />
- jm: Does the metric you have in mind give you the same distortion for 1 8x8 vs 4 4x4 in the skip case?<br />
(back and forth explanation of the example)<br />
- td: Why would lapping vs no-lapping change distortion?<br />
- jm: Lapping is not orthogonal and doesn't preserve MSE.<br />
- y: This is why I suggested an approximation of lapped transform and gives a better estimate of distortion.<br />
- td: Greg has those det1 filters that were never completed. Would those give equal MSE?<br />
- jm: Those are also not orthogonal. There are orthogonal ones but they are awful.<br />
- j: Do we pick the wrong blocksize here with the different distortions?<br />
- jm: Absolutely. I simulated this with real rate and it picked 4x4 way more often than it should. What I did was that after figuring out all MVs and before doing the real coding, I run the actual encoder and not make it output bits or modify the image. I run it at everything 4x4 and everything 8x8. In the coeffs domain I look at each 8x8 block and what the distortion is. Then I look at the 4x4 and I sum the four corresponding 4x4s and look at the distortion and then add lambda * rate difference. When I look at the results, the vast majority of hte blocks it tihnks that 8x8 has better rate distortion.<br />
- x: Minor nitpick: you shouldn't be summing should you?<br />
- jm: D over 8x8 is sum of D over 4x4s.<br />
- x: I thought we were concerned with distortion energy not amplitude.<br />
- jm: My metric is MSE and adding energy.<br />
- y: Is it correct ot add 4 4x4s?<br />
- jm: yes.<br />
- y: I cannot see how these are the same. L1 norm is the same, but L2 norm not. I'll check it.<br />
- jm: We're never doing the sqrt. Just summing squares of differences.<br />
- y: Taking the sqrt is the same though right?<br />
- jm: We must be talking about different things. In any case, I end up with 90% 4x4 despite most of the image being actual skips. This is how bad the distortion mismatch is.<br />
- x: The 8x8 has 4x the support. Or rather it scales linearly but you may have the proportion wrong.<br />
- jm: You can't just apply some kind of scaling. We'd like to have a metric where if you are getting the same output the distortion should be the same.<br />
- x: I disagree.<br />
- jm: Considering identical images. The first one is keyframe coded. The second one is identical to the first one. So we'll skip everything at 32x32. But let's consider just 8x8 and 4x4. We'd want to skip everything at 8x8 level. And we would achieve this because distortion would be the same for 8x8 and 4 4x4s.<br />
- x: You're objecting that the answer is different but the answer *is* different. You're not going to solve this looking at individual blocks individually.<br />
- jm: If I look globally then I'd still get diferent distortion.<br />
- x: Don't constrain so far.<br />
- jm: It seems like we're doing contortions in this simple case.<br />
- x: They are not supposed to be equal at that level. So choose a level at which they are equal. In teh current way the problem is set up there is no solution. I do not think that this means there is no solution with different formulations.<br />
- jm: The only case where they would be equal is by undoing the lapping. And if we do that then we aren't considering ringing from block to block., which will bring another set of issues.<br />
- x; You could fix this in the skip decision.<br />
- jm: I don't want to add hacks on top of hacks. I want an actual metric that is not completely silly. I think other people should try to go hit this problem and see if they can come up with better suggestions. This is something that could break the entire toolchain we've created.<br />
- td: are we always going to have time domain for both places? Can we subtract them?<br />
- jm: We can totally subtract them.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15471Daala Weekly Meetings2015-02-17T16:53:37Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to join the weekly progress meetings using [http://wiki.mumble.info Mumble] at '''mf4.xiph.org''' on '''Tuesdays''' at '''[http://www.time.gov/ 9AM PST]''' (5PM GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
* [[DaalaMeeting20150210|2015 February 10]] - od_hv_intra_pred, block size decisions, AWCY metrics<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150127&diff=15456DaalaMeeting201501272015-02-10T16:19:46Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-01-27 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2015-01-27<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- Let's land as much as we can before London<br />
- London meeting agenda<br />
<br />
# Attending<br />
<br />
jmspeex, unlord, jack, yushin, td-linux, xiphmont, derf, smarter<br />
<br />
# reviews<br />
<br />
every is fine with getting reviews done before next week (8-12% improvements in metrics)<br />
<br />
# matrix interpolation<br />
<br />
- y: I want to make sure we are looking at real images. I believe our metrics (fastssim and psnrhvsm especially) gives better score if we use aggressive QM, but this causes artifacts. I want to make sure these QMs look ok visually. I heard that Jean-Marc checked images and it seemed ok.<br />
- jm: I haven't done extensive testing of everything there. The interpolation I'm doing is between Yushin's matrix and a variant of what we had before (what we have in master now) that is tuned for PSNR-HVS and that we use at high rate.<br />
- y: 32 means scale by 2.0. 16 means no scaling. What Jean-Marc is using is the minimum value. When I see other standards, they vary the quantization stepsizes by no more than two times because that's very risky. That's why I wanted to make sure visually.<br />
- jm: At some point I was looking at the jpeg QM, and it had pretty huge values. Using 16 as meaning 1.0. The JPEG matrix has values up to 120.<br />
- y: 8x then?<br />
- jm: yep<br />
- y: JPEG doesn't have inter, so it's quite different. They have very spikey coeffs. After inter and intra prediction, we only represent the residual. The AC coeffs are quite a bit smaller than JPEG. My claim is not really true for our intra picture, but I'm more concerned about our inter picture. It will give us a smaller residue. We must make sure our QM scaling is not too aggressive.<br />
- jm: At some point you pointed me to QMs, and one reason the intra and inter matrices are different is that MPEG2 had a dead-zone quantizer.<br />
- y: They have option for non-linear quantization. Dead-zone means around zero right?<br />
- jm: They have a larger step around zero, which means they need a finer quantizer. If they have a quantizer of 2 then it is really a 3.<br />
- y: If you use a larger quantizer then all the AC values will have less resolution.<br />
- jm: The first reconstruction level is at 1.5 in MPEG2 right?<br />
- d: Yes, I believe that's correct.<br />
- jm: So looking at the QM there, a value of 32 is a value of 48 if you aren't using a deadzone quantizer.<br />
- y: What you say is possible, but I think it's a special case of bias.<br />
- jm: There's a bias, but we already have it (so do 264, etc). My understanding is that the reconstruction values themselves have a deadzone.<br />
- d: This is different than Theora, where we didn't have a deadzone in the reconstruction. The originally VP3 had different QMs for intra and inter, and when I replaced them with the same matrix, I got universal improvement across the board. VP8 uses flat except for DC (which is independently scaled).<br />
- y: I will generate decoded sequences for current master, and then another for the relaxed one, and another flat, and then we can compare the images visually. <br />
- jm: Make sure that you check multiple rates. At low bitrates, relaxed is better. I don't know if the bitrate is too high for us to see much difference, but at v=20, the high bitrate matrix is used as is without interpolation. The interpolation is that anything below v=20 gets high rate, and anything above 70 gets high rate, and anything between is interpolated. So I think it's really 20 that we want to check.<br />
<br />
# block size decisions<br />
<br />
- y: ntt-short got better by using all 16x16 or all 32x32. For intra on video-short1, 16x16 is better. What I want to propose is to use RDO, but lapped transform makes that difficult.<br />
- u: smarter and I talked about this at VDD. You code the image all 4x4 and all 8x8 and you compare the bit costs for each block, ignoring neighbors.<br />
- y: For up to 16x16, there are 17 cases. For 32x32 it's 80k.<br />
- d: If you look at the paper they were able to get decent results even with just up to 16x16. We aren't even doing well up to 16x16 yet, so let's try to make this into a more manageable problem.<br />
- jm: Even that I don't know how to solve because of a minor detail related to us not having an actual distortion metric that can be used across blocksizes.<br />
- d: This is in general a hard problem.<br />
- jm: From what I understand of 264/vp8, they have MSE as a distortion metric. And that can be compared across block sizes. What we have is two levels more complicated. We have QMs and activity masking. Plus we have extra weight on the gain difference, and that changes based on different block sizes.<br />
- y: We need to approximate lapped transforms, PVQ, adaptive quantization. Addressing Tran's paper, I think it can be a helpful reference because it does not do motion estimation. But in our coder, motion block sizes are completely unrelated. What I'm thinking is that usually they estimate bits and simplest way is SAD or SATD.<br />
- jm: I'm not sure how well you can approximate PVQ for inter.<br />
- y: It's possible that in real world that this cannot be done in the encoder, but we should show the maximum performance of our coder.<br />
- d: We need to show ourselves because we need to know what we're approximating.<br />
- u: Do we have an idea for distortion metric?<br />
- y: That's easier, we can use MSE or SAD, or SATD or SSIM.<br />
- jm: You want to run it on each block?<br />
- u: No, run on the final image withe very block decision determined.<br />
- jm: How do they compute the distortion in the Tran paper?<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15455Daala Weekly Meetings2015-02-10T16:19:07Z<p>Jack: /* 2015 */</p>
<hr />
<div>You are encouraged to join the weekly progress meetings using [http://wiki.mumble.info Mumble] at '''mf4.xiph.org''' on '''Tuesdays''' at '''[http://www.time.gov/ 9AM PST]''' (5PM GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 - [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 - [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 - [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 - [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 - [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 - [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 - [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 - [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 - [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 2012 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
* [[DaalaMeeting20150127|2015 January 27]] - matrix interpolation, block size decisions<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15357Daala Weekly Meetings2015-01-27T16:39:34Z<p>Jack: </p>
<hr />
<div>You are encouraged to join the weekly progress meetings using [http://wiki.mumble.info Mumble] at '''mf4.xiph.org''' on '''Tuesdays''' at '''[http://www.time.gov/ 9AM PST]''' (5PM GMT).<br />
<br />
== Progress Meetings ==<br />
<br />
To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
=== 2012 ===<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
=== 2015 ===<br />
<br />
* [[DaalaMeeting20150106|2015 January 6]] - SPIE<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20150106&diff=15356DaalaMeeting201501062015-01-27T16:39:00Z<p>Jack: Created page with "<pre> # Meeting 2015-01-06 Mumble: mf4.xiph.org:64738 # Agenda - reviews - SPIE # Attending derf, jmspeex, azita, td-linux, unlord, yushin # reviews all seems good # SPI..."</p>
<hr />
<div><pre><br />
# Meeting 2015-01-06<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- SPIE<br />
<br />
# Attending<br />
<br />
derf, jmspeex, azita, td-linux, unlord, yushin<br />
<br />
# reviews<br />
<br />
all seems good<br />
<br />
# SPIE<br />
<br />
- jm: What's the status of all the papers? Mine has a completed first draft. So I'd like to get some review from others. http://jmvalin.ca/video/spie_pvq.pdf I've already gotten some good comments Yushin.<br />
- y: There are still a few mysterious parts, but I'm getting much more familiar.<br />
- jm: Which parts are still hard?<br />
- y: Big difference from standard codecs is companding quantization. There are two parameters controlling strength of visual masing is controled by gain, but it seems in the newest version one of the parameters is gone.<br />
- jm: Beta is just 1/(1-alpha). It's just easier notation. Alpha and beta are representing the same thing.<br />
- u: You may want to move the definition of beta up near equation 8 where you first use it.<br />
- jm: Good idea.<br />
- y: Section 5 is coding resolution.<br />
- jm: Yeah, and I introduce beta after equation 9, but I agree with nathan that I should move it after equation 8.<br />
- j: How are the other papers coming?<br />
- d: I still have a lot of writing to do.<br />
- u: Likewise. And yesterday we talked about an additional experiment we need to run.<br />
# Misc<br />
- y: Now that our codec works in Visual Studio, can I get a computer to do that?<br />
- j: Yes, you can get a loaner from IT, or I can approve a second laptop, etc.<br />
- y: Objectively I compared our codec to H.264. For intra, Daala is better than x264 in most of the cases. I checked in the practical quality ranges. 0.25 to 0.5 bpp (not exactly correct because it changes picture by picutre). 30-32dB x264 was better in PSNR and SSIM. x265 I haven't tried. They are using adaptive quantization unlike HM and JM (standard reference). My first conclusion is that we can claim that x265 for intra. I think you already shared this fact. For inter coding, we have a problem that we need to solve. There are two parts, motion estiamtion (temporal prediction) and coefficient coding. The coefficient coding is shared by intra and inter, and we are spending 70-80% to code AC coeffs. If we improve inter, that will make us close H.265 because that's the remaining part. I hope the arithmetic coding is doing a big part for the coding, but transform should give a benefit as well.<br />
- jm: One thing that would be useful to check is are we doing worse because our prediction is iworse, or because we are worse coding the residual? In 264, the coeff coding is the same in both inter and intra, but in Daala, we have PVQ and noref and we are supposed to use the prediction much more often in inter.<br />
- y: I think that's a valid point. Since PVQ is working well in intra, even though a predictor is used for inter, i think PVQ is not bad at inter coding. I don't know the real culprit, but I hope the motion estimation is the reason. There are a lot of AC coefficient still there, but it's possible PVQ is the reason there are still so many coeffs.<br />
- u: Could we do this with a CG computation?<br />
- d: I don't think you can compute a coding gain, but you'd want some distortion metric. But I wouldn't do 264 and Daala but the partner codec and Daala.j<br />
- t: Jack asked why we are worse at low bitrate than the partner codec. From visual comparison the skipping is better than our, and the inter coding. There are a bunch of talking heads videos in the ntt set, but we are coding a lot of flicker and noise in areas that aren't changing.<br />
- jm: That is actually useful information. Are we coding DC flickering or AC flickering?<br />
- t: looks to be AC. In the areas where there is motion, we are coding coeffs up to 20px away from the motion. They seem to have perhaps broken the deblocking filter when they ripped out things. It works but it doesn't seemed well tuned.<br />
- d: Is that something you want to look into jean-marc?<br />
- jm: I think Yushin should look into the flickering. I may be able to fix it once it is identified, but I'm working on a ton of stuff. I'm working on auto-disabling AM on edges. I'm using the motion compensated reference and detecting edges on that, and then using that to control AM.<br />
- y: Is this new code than the block splitting function?<br />
- jm: The issue is that when you have edges, for intra we just rely on 4x4 classification. For inter, you'll have edges that are not 4x4. So what I do instead is that i look at the motion compensated reference, and if it has edges I disable masking.<br />
- d: So this is running in the decoder?<br />
- jm: Yes, running the edge detector in the decoder. I'm using the one from the ptalagform Theora. Most of it could be SIMDable. There was only one division that could be a table but not SIMD.<br />
- y: I'm still investigating the block split function, but haven't come to any conclusion yet. Who designed this?<br />
- jm: I did. Everything weird in Daala is mine.<br />
- d: Not true. I did OBMC :)<br />
- y: One question about block split is that it's purely based on CG and CG is subtle. The decision doesn't seem to prefer smaller blocks. We probably need to adopt some thresholding method instead of continuous decision. If the difference is more than a threshold, then we change the blocksize. Assume we have smaller CG for larger block, then we choose a smaller blocksize, right?<br />
- jm: We're looking at a mix of CG and distortion.<br />
- y: Specifically, instead of just comparing CG with < or >, I'm proposing to use some threshold. If the delta is bigger than the threshold, then switch sizes.<br />
- jm: I'm not sure what you're trying to fix.<br />
- y: It's similar to motion vectors. If neighbor is 0,0 vector, then current motion vector wants to be close so that the motion field is smooth. FOr example if you are shooting a panning scene of a large building with many small windows, you could get false motion vectors.<br />
- jm: You are talking about doing RDO on block size decision...<br />
- y: It splits into smaller blocksizes only when it is very confident.<br />
- jm: this is what the CG parameters do.<br />
- y: It looks like the CG is very dense and continuous.<br />
- jm: If you want to bias large block sizes, you can just change the CG values you have. We already have that bias. If the CG of 32x32 is smaller, then it would use it.<br />
- y: Another point I am checking is if block splitting is identifying texturs and edges well. When I try to encode parkjoy, inter would not spend more than 2Mb. There are some less contrast parts on the right upper side. THey are kind of washed out, and that concerned me. I hope I can find some relation with block size decision and this washed out quality. Maybe there's no relationship but I wanted to check.<br />
- jm: Anything you can find that we're doing wrong would be useful.<br />
- y: PVQ and AM want to preserve quality in low contract part, which is edges.<br />
- jm: No, right now AM is destroying edges.<br />
- y: You're right, AM is turned off for edges.<br />
- jm: For inter, we're not just using 4x4 for edges, which is why AM causes issues there.<br />
- y: The gain companding is adaptive to our quality factor right?<br />
- jm: Yep.<br />
- y: It controls the strengths of AM based on strengths of gain.<br />
- jm: I"m not sure what you're question is. The gain companding gives us non-uniform resolution.<br />
- y: If the resolution (number of vertices in quant space) becomes very low, what would happen to our AM? It can wash out the quality right?<br />
- jm: It would wash out less than if we didn't do companding.<br />
- y: The resolution changes based on bitrate, so lower resolution for lower bitrate will destroy the quality right?<br />
- jm: Lower resolution means worse quality for all codecs. If you compare AM to no-AM, you can see figure 4 in the PVQ paper. You can see the first level of quantization (level 1) on the blue curve with AM is at a lower gain than the first level in the green one.<br />
- y: Gain itself is better coded than standard codec. I was expecting syntheiszed textures there; that's not happening?<br />
- jm: If you are seeing things being completely washed out, then we're below the first level of AM. The quantizer is just too coarse.<br />
- y: How about gain quantization. Is it quantized uniformly?<br />
- jm: No, companding makes it non-uniform.<br />
- d: One thing that would help in figure 4 would be to specify the step size in the caption.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141223&diff=15251DaalaMeeting201412232015-01-06T16:26:59Z<p>Jack: Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2014-12-23 Mumble: mf4.x..."</p>
<hr />
<div><pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
# Meeting 2014-12-23<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- update1<br />
<br />
# Attending<br />
<br />
xiphmont, derf, unlord, jack, yushin, jmspeex<br />
<br />
# reviews<br />
<br />
- 548 and 547 are waiting on feedback<br />
<br />
# update1<br />
<br />
- x: It's ready to go up. I was going to put it on xiph.org and do the standard announcements. Does anyone want to do more than that or are there changes that need to be made?<br />
- u: My recollection is that HEVC destroyed all the branches but not it looks ok.<br />
- t: It still destroys them somewhat.<br />
- x: It got better by about the same amount we got better since the last time we ran metrics.<br />
- j: We should measure that against teh AWCY HEVC we currently test against.<br />
- u: I didn't notice any particular change when I was eyeballing the graph.<br />
- x: We both got better by a noticeable amount. We were consistently better than in July although not by a dramatic amount. It looked like from July we held still and everyone else fell behind.<br />
- u: Maybe I'm missing something but HEVC is doing an incredible job in crepuscular on the trees.<br />
- x: It's still doing stuff, just less of it.<br />
- jm: I think on crepuscular we are beating everyone else.<br />
- x: I still think that end of show looks better. But I seem to be judging differently than everyone else. The reason we look better on end of show is that there is a lot more mid frequency content, and we seem to be the only codec that does well there. The other codecs seem to drop the center frequencies. It's a good hack. If you're going to drop a lot of content then that is the place to do it. .In end of show, it's more obvious.<br />
- jm: I'm wondering if there is a color conversion issue on end of show.<br />
- t: Yeah, it's definitely there. I don't know what happened. Are you using the original PNG file?<br />
- x: yes<br />
- t: So that's 16bit PNG?<br />
- x: I coverted them. I do not have a colorspace problem on mine. Who has color management turned on in Firefox? It's on by default now.<br />
- u: How do I change the image in update1?<br />
- x: Go to the larger test which is linked, which has a dropdown on the bottom.<br />
- t: THe obvious solutoin here is to convert the original images to y4m and back again.<br />
- x: I have gfx.colormanagementmode to 0, which is non-default. Let me flip that bit. Holy shit, I see it now with default settings.<br />
- t: Also if you convert to y4m it will convert it to 420 instead of 444.<br />
- x: I used abcompare, but not sure what it did. I'll have to go look. I bet the original have a colorspace declaration and the others got stripped out by mogrify. I'll figure out why.<br />
update: it was the exact opposite in fact: mogrify was adding unwanted colorspace declarations<br />
- j: Publishing this on moz research blog too?<br />
- x: Not sure how, but I assumed both.<br />
- j: I'll see if I can get it to work this afternoon.<br />
<br />
# bpyramid<br />
<br />
- t: MPEG2 doesn't seem to have bpyramid stuff. Is that true?<br />
- d: Yes.<br />
- t: Should we avoid this? Or should I have the bitstream support it but be turned off?<br />
- d: I'd want to review stuff before deciding.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15250Daala Weekly Meetings2015-01-06T16:26:19Z<p>Jack: </p>
<hr />
<div>To enable text-wrapping within meeting logs, try using:<br />
<pre><br />
<pre style="white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
white-space: -pre-wrap; <br />
white-space: -o-pre-wrap; <br />
word-wrap: break-word;"><br />
</pre><br />
<br />
== Progress Meetings ==<br />
<br />
We've been having weekly progress meetings on [http://wiki.mumble.info Mumble] at '''mf4.xiph.org''' at '''9AM PST''' (5PM GMT) on '''Tuesdays'''.<br />
<br />
=== 2012 ===<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
<br />
=== 2013 ===<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
<br />
=== 2014 ===<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time<br />
* [[DaalaMeeting20141223|2014 December 23]] - update1, bpyramid<br />
<br />
[[Category:Daala]]</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141216&diff=15154DaalaMeeting201412162014-12-23T16:58:49Z<p>Jack: Created page with "<pre> # Meeting 2014-12-16 Mumble: mf4.xiph.org:64738 # Agenda - reviews - update1 - goals - ?? # Attending # reviews - no one waiting on anything # update1 - x: Not a l..."</p>
<hr />
<div><pre><br />
# Meeting 2014-12-16<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- update1<br />
- goals<br />
- ??<br />
<br />
# Attending<br />
<br />
# reviews<br />
<br />
- no one waiting on anything<br />
<br />
# update1<br />
<br />
- x: Not a lot to decide other than if we want to update the pictures and graphs.<br />
- jm: I think we should at the very least update it with more current curves and images. We've had big enough improvements it's worth updating. The question is do we want to add 32x32 DCT to that. Right now we have two things that are big improvements to master. They are actual 32x32 and deringing postfilter.<br />
- x: What is the actual improvement?<br />
- jm: Between the july curve that we have and current master + 32x32, the difference is ~5%.<br />
- u: There are places in our commit history where we broke everything. The 8-18 commit may just be a bad one. The curves I showed Andreas skipped those and doesn't show 15%.<br />
- jm: On still images we got about 5% since July. The most improved metric is PSNR-HVS-M.<br />
- j: I don't think we should gate the release on 32x32 and deringing.<br />
- jm: I think we should include 32x32 and not deringing.<br />
- x: I think we should compare against master. If we have to wait, that's ok.<br />
- u: I agree with Jack. I would rather not commit to 2 days for 32x32.<br />
<br />
# goals<br />
<br />
- j: the plan is for everyone to commit to 1% on metrics in Q1.<br />
- y: which metrics?<br />
- d: focus on fast-ssim and psnr-hvsm. These goals will be evaluated by humans.<br />
- y: How do others (external) consider these metrics?<br />
- j: These metrics are for bonus calculation (the personal portion), and not for external verification.<br />
- jm: If all four metrics say you were worse but the images are better, that's still good.<br />
- j: I'm evaling these, so we can work with that result<br />
<br />
# yushin question time<br />
<br />
- y: already started asking jean-marc and jack questions about pvq. i'm trying to understand the code right now. i'm trying ot understand pvq, and why we are using that and learning about patents.<br />
- x: We loved pvq for audio becuase of gain preservation, and we thought that would be useful for video as well. The patent things are a nice fallout, but it wasn't the first order concern.<br />
- jm: We don't need as much energy preservation for video, but it's still good. Another advantage is that we can do activity masking with no signaling, which means we can do it block by block or treat H and V separately. The last advantage is that from the N parameters it is applied to, it extracts gain and angle which have actual meaning, and we can use better statistics than just the normal statistics on coefficients.<br />
- x: It partitions the search space into spaces with actual meaning.<br />
- y: I don't have a concrete feeling yet how it is introducing errors when you manipulate k value. With scalar, it is known how errors scale with quantizer, but for PVQ I don't have this internalized yet. I will ask jean-marc about this.<br />
- jm: Essentially, the values of k are chosen specifically for PVQ to follow the same quantization rules. With PVQ 1 bit per dimension will give you 6dB improvement on average. I don't have that math in the pvq demo, but it will be in the paper I am writing. k is selected to match the same distortion curves as scalar.<br />
- y: That is very nice.<br />
- jm: If you change q by a factor of 2, you will have twice as many levels for the gain. q is basically first mapped to the gain. The levels for the gain are exactly the same as they would be for scalar. If all your non-zero values are in the same axis, you would have the same scale as with scalar. If you look at the figures in the pvq demo, you can see what a scalar quantizer looks like in 2D. If you scroll to the figure after the two figures side by side, you can see with the same step size what PVQ looks like. The resolution is pretty similar. The difference between your circles is the same as scalar, and k is chosen to have uniform resolution. In the paper I have the actual derivation of what k should be.<br />
- y: I'll ask more questions as they come up.<br />
- d: I encourage you to ask in public IRC so everyone can learn those answers. Probably lots of people have the same question.<br />
- jm: You (yushin) are in a special position now to be able to notice mistakes we made and tell us when we did something stupid.<br />
- y: Companding is quite odd in a video codec.<br />
- jm: That's the part that does the activity masking.<br />
- y: Signal companding is compressing the whole dynamic range and you get better quantization.<br />
- jm: It's the same idea here, we compand the gain so we get better resolution for small gains. For audio we go logarithmic, but for video we don't go that far. In Opus we quantize the log of the gain. For video logarithmic is way too much companding; linear means no activity masking. So we find an exponent that is in the middle (2/3 or 3/2 depending on which way you look). In the PVQ demo, you see a 2D quantizer. If you compare that one to the previous one I showed you, you see that for very small values you have more resolution, so very slight amount of texture you can have code points that are close. As the gain gets larger the spacing gets larger.<br />
- y: That's what I'm calling non-uniform quantization.<br />
- jm: As k gets larger, in all directions you get coarser quantization. This implements activity masking without signaling that you need to increase the resolution or decrease it. In a normal codec, you would have to signal that.<br />
- y: If I do find anything stupid, I will definitely let you know. For now I will need some time to dig into the lapping transform and PVQ. The block size decision is a little odd too, since most codecs choose block sizes at the very last moment. But in our case it's done early, but it's good for me because it's much simpler to follow.<br />
- jm: BS decision is done for two reasons. One is that we can't do RDO like 264 and 265 because of lapping. We need to apply lapping before we do the DCTs, and the lapping will be different depending on the blocksize. We can't just decide to change teh size of one block, because it will change the lapping for previous blocks, including up neighbors. We can't just locally make decisions.<br />
- y: Are we signaling block sizes?<br />
- d: Yes, they are signaled.<br />
- y: I don't see constraint related to lapped transforms then. If you are encoding one super blocks, we can consider two different encoding passes. One is split in 4x4 only, and one no splitting. Can we do this?<br />
- d: THe problem is that the 32x32 superblock is lapped with its neighbours. The decision depends on the block size of your neighbours. We don't encode the lappings to use, the lapping is determined from the block size.<br />
- y: Can we assume the neighbours block sizes are decided?<br />
- jm: No, because some neighbours are in the *next* row.<br />
- y: Ok, I will think this over offline. This is similar to intra-prediction issues right?<br />
- d: You can make greedy optimizations here. Greg tried this but gave up, and you might ask him about this problem.<br />
- jm: The other difference is that the actual decision for blocksize that we code, we don't have exact measures of distortion and rate like 264/5, but we are trying to get a better distortion metric by using something better than MSE. If you look in od_split_superblock, this function tries to measure how visible the ringing would be from different sized transforms. It's assuming that the more texture you have, the more ringing you can have without the artifact being perceptible. It's trying to measure where the image is flat and textures and see how you can split blocks so that you don't have an edge leaking energy into the flat area. It's by no means perfect. It has to change with the rate and that's just approximate. It's attempting to do something there, and it seems to make sensible decisions. Mostly for still images. For video I'm not convinced yet. It's very hard to tune because I've noticed when looking at metrics, biasing to 16x16 gives better metrics despite the images looking pretty bad.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15153Daala Weekly Meetings2014-12-23T16:58:10Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc<br />
* [[DaalaMeeting20141216|2014 December 16]] - update1, goals, yushin question time</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141209&diff=15137DaalaMeeting201412092014-12-16T00:00:52Z<p>Jack: Created page with "<pre> # Meeting 2014-12-09 Mumble: mf4.xiph.org:64738 # Agenda - reviews - status of #485? - 32x32 dct (#506) - SPIE papers - Update1 # Attending unlord, xiphmont, jack, ..."</p>
<hr />
<div><pre><br />
# Meeting 2014-12-09<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- status of #485?<br />
- 32x32 dct (#506)<br />
- SPIE papers<br />
- Update1<br />
<br />
# Attending<br />
<br />
unlord, xiphmont, jack, derf, jmspeex, td-linux<br />
<br />
# reviews<br />
<br />
# 32x32 dct<br />
<br />
- u: I completed the symmetric scaling of the DST. First pass had 21 multiplies 8 shifts and 37 adds. I should be able to replace 3 of the multiplies with just adds. The next thing to do is the asymmetric 16 point DST. I can piece together the 32x32 DCT from that. Does that seem reasonable?<br />
- d: I'd have to look at a diagram or the code. I can't just answer that from a description.<br />
- u: I have one that I will scan and send you a link to that.<br />
- jm: Also if it's too many ops, landing this can happen and we can fix it later.<br />
- d: It seems landable.<br />
<br />
# SPIE papers<br />
<br />
- jm: has anyone been able to figure out the length of the papers?<br />
- d: I didn't see any guidelines on that.<br />
- jm: So it's open ended?<br />
- d: As far as I can tell.<br />
- u: Manuscripts should be a minimum of 6 single sided pages.<br />
- jm: What about copyright assignment?<br />
- d: i'll email them about that.<br />
- j: When is SPIE again?<br />
- d: Mid-Feb.<br />
- jm: The deadline is Jan 12. For pvq I was thinking of taking the entire PVQ demo and putting it in the paper.<br />
- u: Manuscript specifications: http://spie.org/x14101.xml<br />
- u: Your manuscript is due 12 January 2015. You may log in now at http://spie.org/myaccount to begin the manuscript submission process. <br />
- d: All that stuff is good to have, but that shouldn't be all it is.<br />
- jm: All add in the maths, etc. Can we make clickable PDFs?<br />
<br />
# FOSDEM<br />
<br />
- u: Is there somethign to do here yet?<br />
- jm: It's not quite clear what the next steps are except for showing up and presenting. I presume they will schedule your talk somewhere in that devroom, or maybe it has already been scheduled.<br />
- u: My talk request is accepted, but no other info was there.<br />
- jm: Then you just need to figure out where when the talk will be. There are no formal papers or anything.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15136Daala Weekly Meetings2014-12-16T00:00:16Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas<br />
* [[DaalaMeeting20141209|2014 December 9]] - 32x32, misc</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141125&diff=15123DaalaMeeting201411252014-12-09T16:30:09Z<p>Jack: Created page with "<pre> # Meeting 2014-11-25 Mumble: mf4.xiph.org:64738 # Agenda - FOSDEM deadline is Dec 1 - reviews - Doing non-intra work (when?) - yushin # Attending unlord, derf, jack, ..."</p>
<hr />
<div><pre><br />
# Meeting 2014-11-25<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- FOSDEM deadline is Dec 1<br />
- reviews<br />
- Doing non-intra work (when?)<br />
- yushin<br />
<br />
# Attending<br />
<br />
unlord, derf, jack, jmspeex, td-linux<br />
<br />
# FOSDEM<br />
<br />
https://lists.fosdem.org/pipermail/fosdem/2014-October/002041.html<br />
https://penta.fosdem.org/submission/FOSDEM15<br />
- d: talk submission deadline is looming (Dec 1). Who is giving talks?<br />
- u: I will. Jean-Marc and I were going to split it up.<br />
- j: How are you going to split it up?<br />
- jm: One is technical, and one is project overview.<br />
- d: Technical one at FOMS (Friday before), project overview at FOSDEM. But it's kind of the wrong order.<br />
- j: Can't be helped since the general one should be for the more general audience.<br />
- d: Jean-Marc and Nathan, you two can coordinate that. Links are in these notes to do submissions.<br />
<br />
# Reviews<br />
<br />
- j: 312 has too many reviewers. Are all of them reviewing it?<br />
- u: I was reviewing it. I can remove the others.<br />
- td: That bitrotted, so I'll update it.<br />
- j: Who's going to review 534?<br />
- u: I'll do it.<br />
<br />
# Non-intra stuff<br />
<br />
- d: How is multiple reference frames coming?<br />
- td: Not a lot to show for it yet. Coming soon.<br />
- d: By portland?<br />
- td: Sooner.<br />
- j: Did we give up on getting Greg's code?<br />
- td: Yeah. I haven't bothered. At this point it would be hard to put it in. I haven't done the motion search of two frames yet.<br />
- d: I think that was the only piece he was working on.<br />
- td: Ah, that may actually work then.<br />
- d: Go harass him again.<br />
- j: Tim, how is your non-intra stuff right?<br />
- d: I'm still working on jm's paint-deringing stuff. I'm still trying to rethink how to speed up interpolation. I'm trying to move the logic from per pixel to decisions at a higher level. Unfortunately the way it is set up right now there is a bunch of stuff in the middle of rows and winds up being a mess. I'm not sure how to make it SIMDable which is a problem. That's what I'm trying to figure out.<br />
- jm: I think we can get away with a table.<br />
- d: Table of what?<br />
- jm: Interpolation values.<br />
- d: Of the whole block?<br />
- jm: Yes.<br />
- d: I was trying to avoid that.<br />
- jm: The original code was trying to do 32x32 with 128 directions. The current one does 8x8 with 8 directions. Maybe 16 could be nice eventually, but right now it's 8. It wouldn't be that big.<br />
- d: It would be a full k of ROM, but I'm worried about L1 cache impacts.<br />
- jm: If you split it out by direction it's not necessarily that bad. You'll end up with one cache line per direction so if you're using two directions you haven't evicted anything.<br />
- d: I was going to try to avoid the giant table and see how bad that is.<br />
- jm: We can build a table and if people don't want the table at least we know it's reasonable to compute. Are there a bunch of symmetries?<br />
- d: There's really only two. I don't want to do X-Y symmetries because transposing everything is expensive. Reading a column of weights is 8x as expensive as reading a row.<br />
<br />
# Yushin<br />
<br />
- d: What should we get Yushin working on?<br />
- jm: When does he starts?<br />
- j: He starts the 8th. We couldn't make the Portland WW work for him.<br />
- jm: I'm pretty sure after he gets the gist of the codec, he's going to see things are stupid and want to fix them.<br />
- u: Is rate control a thing?<br />
- j: It's a low priority thing. It seems logical that we should put him on something non-intra.<br />
- d: There's figuring out intra + inter. There's mechanical stuff like increasing maximum block size for motion compensation stuff.<br />
- jm: It would be good to get familiar with PVQ since that is an uncommon piece. my thought is that when you join the project the first few weeks is the time you realize all the things that this project does weird, so we should take advantage of that.<br />
<br />
# Jean-Marc's crazy idea # 2818238<br />
<br />
- d: The problem with intrapaint is that there are only so many edges in the image, and intra-paint costs us everywhere. So I would go look at places where there are no edges and compare what you are proposing to a DCT.<br />
- jm: So you seem to think that this will be nowhere near a DCT.<br />
- d: Based on your description, yes.<br />
- jm: The first step is pretty much like a wavelet transform. If you were to do an unaligned mode that predicts from different directions, you'd get the most basic bi-orthogonal wavelet on top of which you could do a DCT for each level. What kind of performance do you get if you run a low order wavelet transform and then run DCTs on the coeffs?<br />
- d: I have absolutely no idea. I know people have tried this before.<br />
- jm: Considering that nobody is using it, it's probably not that great.<br />
- jm: I had a look at the filter coefficents from cisco. I don't remember what the coeffs from other codecs look like, but it struck me that the first half of hte freq response is really flat but the second half is not. I was wondering if there would be a reasonable way to do a multi-resolution prediction by predicting the low freq dct coeffs normally but for all of the top octave trying to find another reference that has full pel alignmnet with the current frame and copy the dct coeffs from these.<br />
- d: I think you still get the phase wrong. If you've got some edge and the actual motion is at a half pel and you pull your HF from an adjacent full pel location, the phase information of hte HF coeffs will be wrong.<br />
- jm: I mean trying to find one where it would be right. Imagine you have motion going from left to right and the motion is 1.5 pel per frame. So you would get the previous frame would give you good LF coeffs, but the HF would be attenuated with itself. But two frames back the LF aren't good, but the HF would line up perfectly.<br />
- d: Somebody has done this. It will take me a little bit to find it. I'll find it and show it to you.<br />
- jm: Did it work?<br />
- d: I don't remember thinking it was that good an idea. But most certainly we can't use it, unless we can with PVQ.<br />
- jm: Another problem that had my head exploding: Considering that we've got relatively little gain from intra, I was trying to think whether we could do what Frank Bossen was doing where he was iteratively requantizing blocks to get back some of the loss from bi-orthogonal filters.<br />
- d: You you understand how that works?<br />
- jm: No, that's why I'm asking.<br />
- d: I'm not sure how to do it aside from making small changes and running it through the whole synthesis.<br />
- jm: The noise is one block would affect neighboring blocks because it's bi-orthogonal not orthogonal. This was 4x4 no block switching or anything. Frank was saying he got significant improvements in quality from doing that.<br />
- d: Who was he working for when he did this?<br />
- j: Wasn't it LG? I looked it up it was DOCOMO probably.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15122Daala Weekly Meetings2014-12-09T16:29:25Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms<br />
* [[DaalaMeeting20141125|2014 November 25]] - non-intra work, jean-marc's crazy ideas</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141118&diff=15077DaalaMeeting201411182014-11-25T17:04:47Z<p>Jack: Created page with "<pre> # Meeting 2014-11-18 Mumble: mf4.xiph.org:64738 # Agenda - reviews - avx intrinsics - directional transforms - Doing non-intra work (when?) # Attending unlord, derf, ..."</p>
<hr />
<div><pre><br />
# Meeting 2014-11-18<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- avx intrinsics<br />
- directional transforms<br />
- Doing non-intra work (when?)<br />
<br />
# Attending<br />
<br />
unlord, derf, jack, jmspeex, td-linux<br />
<br />
# Reviews<br />
<br />
- jm: Nathan, are you done with 516? Or is there more stuff to check?<br />
- u: Looks good. I'm going to try to land it and see if there was any other piece we could remove. I can try to rebase on that version you gave me and see what that does.<br />
- jm: I'd like to land it as an actual merge commit and not have to fix a rebase later. I have a merge ready locally, shall I commit?<br />
- u: Sounds good.<br />
<br />
# AVX Intrinsics<br />
<br />
- d: How's that coming?<br />
- td: I have one mostly done.<br />
- d: Which one?<br />
- td: AVX2 is the one I did first.<br />
<br />
# Unlapping<br />
<br />
- d: Nathan, are you planning to continue on unlapping?<br />
- u: Yes, just updating status now to add that. Will probably work on that before the other things.<br />
<br />
# Directional Transforms<br />
<br />
- x: Filters didn't take the form I expected. Ran a bunch of tests at IETF. What I have now is that instead of just the first row, I use the first row and column. Those behave how I expect. It is not the case with the correct objective I found in ABQ. They converge to work with one specific lapping the best. If I train one to work with a few lappings at once, it splits the difference. I'll verify that is what is actually happening today.<br />
- jm: How would you handle BSS?<br />
- x: I don't know that I would. When I say splitting the difference, the filters aren't all that different. Is that inherent to the filter design? If it is, are they useful anyway? The resulting behavior may be good enough. I'm beginning to feel like they are believable but I'm not sure they are good enough. It's a little better than half the return we were wanting. I was going to stick it in the codec and plot what gain it gets for different directional blocks. I want to run that last test to see if the return is sort of like what Nathan got and what the other directional transform people got. It looks like the additional complexity is fairly high.<br />
- d: The stuff people get with other directional transforms is not a peak at each direction. It's a peak at 45 degrees and that's it.<br />
- x: What I saw in Nathan's stuff was kind of jaggy. THe big peak was at 45 and smaller peaks at different directions.<br />
- u: There are two curves. Jaggy on lapped is because it's just crappy.<br />
- x: The tests I had intended to run I still plan to run and compare to Nathan's results. If it's the same, there is no point to fixing any of this.<br />
- d: Did you look at stability at all?<br />
- x: That looks quite good. In ABQ it was abysmal. I now have an objective that inherently enforces stability. As soon as I was not magnifying error amplitude, the training starting moving energy into the right places. When you inject noise into the original transform or the quantized coeffs, the noise you get out is of a similar magnitude. Unsurprisingly the noise has hte same directional basis nature as the direction of the trained filter.<br />
- d: I'm not surprised you had to go to a row and column.<br />
- x: I was surprised I had to go to a full row and column. At least in the naive stuff, it wants to have full frequency representation in the row and column. I can cut it down the behavior becomes less desirable.<br />
- jm: Setting slightly less ambitious goals, is there anything that we can salvage from all this? What if we use this to predict the diagonal bands? We code the first 15 coeffs, horizontal, and vertical, and then use everything we have to predict the diagonal 8x8 frequencies. I understood what you are doing is essentially a prediction.<br />
- x: I was trying to do that. I can train a predictor and it works, but the form I was using was not yielding a perfect predictor.<br />
- jm: What are you doing now that is not a prediction?<br />
- x: I don't have a filter that is prediction only that is capable of representing the lapping?<br />
- jm: So this is equivalent to an IIR filter?<br />
- x: If it was pure prediction you would be able to predict coeffs from the ones you already have.<br />
- jm: I don't understand why it's not a prediction.<br />
- x: You decode the first row and column, and you predict everything else. If it is a pure edge in that direction, it will predict perfectly.<br />
- jm: If that's the case, then with the current code and we're coding all horizontal and all vertical, you should be able to use that to predict the diagonal.<br />
- x: There is a prefilter that effects a modification to the transform itself. The first row and column you use for input is not the same as the one you'd normally use.<br />
- u: Jean-Marc you're suggesting this is still signal free right? So we could train something like this for the lapping on the four edges.<br />
- jm: The other part of my idea is that you can use horizontal and vertical to figure out the direction without having to signal it. Which means that if it doesn't work at all then we are no worse than we were.<br />
- x: There's an even easier test to do first. Drop it in the way it is now. I suppose I could do it with the partitions you have no (they are overkill). I was suggesting taking the intragain tool and running it and comparing it against the others so I can compare with Nathan's PCA graphs.<br />
- jm: Intragains are completely meaningly. Nathan was testing on synthetic images which was even worse.<br />
- x: I don't think that is actually true. On the other hand, we've already tried the other techniques. If this looks like them then there may not be any point. But the visual qualities given by the directional transforms are quite good.<br />
- x: I'm using more information than is necessary to represent all the degrees of freedom. I need to check if the different lappings are splitting the difference in the training. I also wanted to see what tolerance the training had for leeway in the directions because I am coding more DoF now, it seemed possible I might be able to generate filters that could detune the filters. Or it might be possible to code a filter that might handle more than one direction. The real goal is to do something similar to what nathan did. I do want to see the CG. I agree the CG is not an accurate measure of what this tool is worth, however if the CG is much worse than Nathan's, that could mean something. Since adding the DoF I did not look and see if there were more techniques I could do to get a better pure predictor.<br />
- d: Of all that stuff, the most important to me is hearing about the filter form and why you are using it.<br />
- x: I was simply was using a big linear matrix to predict all the diagonals. What was happening is that I'd get a predictor, but it didn't handle the lapping reflections. If the physical edge was in the block I could get a perfect fit. If the edge was just outside the block, it wouldn't fit that. Or rather I could fit one or the other but not both. The next filter form I added is to add another layer of lifts. That layer was capable of moving energy out of the space I was trying to predict to the space I was predicting from. As soon as I did that, I was able to predict both things. The problem with that is that I was getting error in the things I was coding. The quantization error was very bad. Then ran inverse prefilter after the post filter. I got near unity scaling too. They still aren't even, but they aren't way out there.<br />
- d: That is too high level for me. I need to see the DoF.<br />
- x: I'll make some diagrams and scan them in.<br />
- d: I wonder what would happen if we could do some of this by taking into account the band structure we already have.<br />
- x: It's not too far off.<br />
- d: The first 15 coeffs is the lower 4x4 quadrant.<br />
- x: I'm sure I could train something to use just those.<br />
- d: THe other thought I had is that if we have to code all fo those, perhaps there is enough information there that we can highly bias the probability for the mode, or not code one. If we can code the first three bands, there may be enough information that the decoder itself can do the search for the direction.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15076Daala Weekly Meetings2014-11-25T17:04:10Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc<br />
* [[DaalaMeeting20141118|2014 November 18]] - avx intrinsics, directional transforms</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141104&diff=15068DaalaMeeting201411042014-11-18T16:37:35Z<p>Jack: Created page with "<pre> # Meeting 2014-11-04 Mumble: mf4.xiph.org:64738 # Agenda - reviews # Attending unlord, derf, jmspeex, td-linux # Reviews d: jm were you going to review 498? j: that..."</p>
<hr />
<div><pre><br />
# Meeting 2014-11-04<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
<br />
# Attending<br />
<br />
unlord, derf, jmspeex, td-linux<br />
<br />
# Reviews<br />
<br />
d: jm were you going to review 498?<br />
j: that should go into a branch right?<br />
d: sure, if we want to do that. Someone should probably tell jack this.<br />
j: yeah it was fine.<br />
d: tell jack that too<br />
u: I had the same question about the CfL PVQ tuning branch I reviewed, that is going to go into a branch?<br />
j: yeah, all of these branches should be labeled dump something<br />
d: thomas, any idea why 499 and 505<br />
t: they are being blocked right now on upgrading the jenkins VM.<br />
t: I can commit them to master<br />
d: is that going to go try to run them with out the right software installed<br />
t: yeah<br />
d: lets not do that<br />
<br />
d: basically, we are applying lapping on the inside of the block for the 16x16 and then applying TF to make a 32x32 block, so what this means is that before TF your basis functions overlap. So consider for example just the DC coefficient, all the coefficinetns of your basis function are positive. When hyou apply TF, to these 4 coefficients, one of the outputs will have all of them added up. Another will have the difference between the coefficients, and in the places where they overlap, TF will cancel out the energy of the basis functions.<br />
d: what we hoped we'd be able to do is do something with TF where we turn off the interior lapping and use monty's second stage TF. This still shows some blocking effects which is why we are using an actual 32x32 DCT.<br />
<br />
u: that reminds me of the quantization of the PVQ gains based on the amount of energy that goes into the bands of each block.<br />
d: the thing with counting all the different combinations, was trying to evaluate whether we could do a per coefficient scaling, and I agree if we fix the scaling with the 32x32 DCT like nathan is working on we can do the scaling per band.<br />
j: especially the DC case I think will be useful for Haar DC.<br />
d: although we tried correcting it before and did not have any luck<br />
j: yeah because we were correcting it on the order of 5% when it was 50% and that explains why it didn't work<br />
<br />
j: there were other things, not something precise, but its probably worth experimenting with how we do the lapping around the block size changes<br />
d: okay what kinds of things were you thinking of<br />
j: okay for example, how you lap when you have a bunch of 4x4 blocks that are adjacent to an 8x8 and how you lap the 4x4 boundary that is orthogonal to the 8x8<br />
d: okay but *what* things did you want to experiment with<br />
j: (1) trying to play with applying vertical and horizontal in different orders (2) not applying some of the filters to not mess up larger blocks that are adjacent to smaller blocks (the example I had is 4 4x4 adjacent to an 8x8, there is a boundary where if you apply the 4 point filter between the 4x4s, there is one block boundary between the 4x4s that hits the middle of the 8x8, so there is a discontinuity) (3) modulating the filter <br />
u: how much of a discontinutiy does that actually cause in the 8x8?<br />
j: you saw the basis functions I posted, it creates a bunch of funny things<br />
d: yeah some of them look kind of terrible<br />
j: at this point its more like try messing around with a few things, if they are all within a few percent its probably not worth doing it, but if its a lot more then its worth doing<br />
d: but now we have a list we can hand off to someone to look at<br />
u: I don't know if that causes other blocking artifacts when you don't run the post filter there<br />
j: we'll see<br />
<br />
j: for 485, my name is on it but I think monty should review it<br />
d: okay assign it to him<br />
j: its already assigned to him<br />
j: also I'm no longer sure what we should do with it given the fact that the HV filter is no longer providing such an improvement<br />
u: do we want to back out the HV if its not giving much of an improvlement?<br />
j: no right now its really really simple and overall its not doing much except in the pathological cases where its doing really well<br />
d: right<br />
j: its preventing us from looking really silly and not costing much so I think its worth it<br />
<br />
d: looking at older stuff, thomas whatever happened to andres AVX2 patches?<br />
t: they are still there<br />
d: have they been checked in<br />
t: no<br />
d: can we fix that<br />
t: I have a new version that is in my git some where, I suppose I can put that up for review<br />
d: that seems like a good idea<br />
t: I also have one for stieners generic SSIM patch, the only issue is that I don't think that it is used anywhere<br />
d: I thought he had written one function to test with<br />
d: it is better to get the framework in place so we can start using it with other stuff<br />
d: I think if we add the multiply that all the DCT's use we can convert everything to use this<br />
t: yes<br />
<br />
d: were you still playing around with trying to cap the distortion in the motion vector search<br />
t: yeah but I got sidetracked with trying to put multiple references into the prediction<br />
d: I think it may be easier to support multiple reference frames where one of them is the most recent key frame<br />
t: yeah I can do that too, and the reason I didn't do that is that I tried setting x265 to do that and the actual gain they got was small so its hard to tell if its worth it<br />
d: yeah fair enough<br />
j: yeah I think starting with b-frames is easier because you can actually tell if its working<br />
d: I don't think low latency encoding is a priority for them, I think it took x264 five years to get around to handling that case, basically some company had to contact the devs to do it<br />
<br />
https://people.xiph.org/~jm/daala/pvq_demo/<br />
<br />
j: does anyone have any comments on the PVQ demo I posted<br />
d: I also wasn't sure if you wanted to steal some images from my CELT presentation at LCA<br />
j: do you have a link to that<br />
d: let me find that <br />
j: yeah slide 24, I actually tried reproducing something similar, I didn't want to try drawing vornoi regions because we are not actually using them due to RDO<br />
d: that seems like a subtlety that will be lost on people<br />
j: you think the figures are not clear<br />
d: you say "eh this can be trained" but you are not clear on what happens when you do that<br />
d: if I look at the left VQ latice and the one one the right, its not clear whey the one on the right is better. you look at slide 24 and its very clear why people want to do VQ<br />
j: yeah I chose to not mention that because we are not using it, you have the 3 reasons to use PVQ and I didn't include it because none of them apply<br />
d: the reason I did that then is because I was talking to someone who actually knew what VQ was and had done his PhD research on it, it is specifically to try and contrast it with what VQ is typically used for and specifically say we are not doing that.<br />
j: I can also completely remove the trained VQ figure<br />
d: I have to think about that and look at the surrounding text, but its not really essential to the story<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15067Daala Weekly Meetings2014-11-18T16:35:37Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing<br />
* [[DaalaMeeting20141104|2014 November 4]] - reviews, misc</div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15034Daala Weekly Meetings2014-10-14T19:29:07Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - steinar's tests, intra update<br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20140930&diff=15033DaalaMeeting201409302014-10-14T19:28:46Z<p>Jack: Created page with "<pre> # Meeting 2014-09-30 Mumble: mf4.xiph.org:64738 # Agenda - reviews - work weeks and IETF 91 - planning - Steinar's tests - intra update http://people.xiph.org/~unlord..."</p>
<hr />
<div><pre><br />
# Meeting 2014-09-30<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- work weeks and IETF 91<br />
- planning<br />
- Steinar's tests<br />
- intra update<br />
http://people.xiph.org/~unlord/intra/subset1-mode-8x8-fastssim.png<br />
http://people.xiph.org/~unlord/intra/subset1-mode-bs-fastssim.png<br />
<br />
# Attending<br />
<br />
azita, derf, gmaxwell, jmspeex, jack, unlord, tmatth<br />
<br />
# Steinar's tests<br />
<br />
- jm: Monty and I have been looking at this.<br />
- d: We are worse than 261 on one of these.<br />
- j: Should we put these in video-subset-1?<br />
- d: Not sure if they are redistributable<br />
- j: Can someone volunteer to follow up on that?<br />
(silence)<br />
- j: Random selection has chosen Jean-Marc. Please follow up with Steinar and maybe fbossen to see if we can get permission to redistribute these.<br />
<br />
# planning<br />
<br />
(reviewed new planning doc)<br />
<br />
# intra update<br />
<br />
(discussion of above graphs mostly around what they mean and how to get closer to apples to apples comparison with daala master)<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141014&diff=15032DaalaMeeting201410142014-10-14T19:25:28Z<p>Jack: Created page with "<pre> # Meeting 2014-10-14 Mumble: mf4.xiph.org:64738 # Agenda - What monty's up to - reviews - work week https://daala.etherpad.mozilla.org/forth.orgworkweek-201410 - hv int..."</p>
<hr />
<div><pre><br />
# Meeting 2014-10-14<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- What monty's up to<br />
- reviews<br />
- work week https://daala.etherpad.mozilla.org/forth.orgworkweek-201410<br />
- hv intra now with TF https://review.xiph.org/485/<br />
- gain/theta/skip coding<br />
- deringing<br />
- go(ing) west<br />
<br />
# Attending<br />
<br />
jmspeex, unlord, xiphmont, jack, derf<br />
<br />
# Reviews<br />
<br />
- JM is waiting on review for #478.<br />
<br />
# What Monty is doing<br />
<br />
- x: Still working on pseudo-directional transforms. Though if it works (don't know yet), it is a varaint of Jean-Marc's idea -- encoding a strip of pixels normal to the prediction direction. I'm still trying to do this via a postfilter after the transform that tries to compact the directional edges into a single column or single row. This is the kind of thing that is possible; the question is whether or not there exists a simple filter to do it so that it's practical to compute. That stalled before because I was flailing on the search mechanism, but I figured out how to do that and I've got code for it. If we do manage to compact the energy into a single row, it's a variant of Jean-Marc's thing. We only need to predict that single row and only from other single rows. That may save the original intraprediction. If this works out it dramatically reduces the cycles.<br />
- d: The complexity just moves to this postfilter.<br />
- x: That is the worry, but hoping it still a win. Worried that it won't be a big enough win.<br />
- jm: You're trying to take into account lapping?<br />
- x: Yes, but lapping makes it easier. The lapping increasing compaction, so there are fewer coeffs.<br />
- jm: You are trying to be critically sampled as well?<br />
- x: Of course. For the search, I"m making the assumption that we have a limited number of lifts, and the lifting chains will not end up more than a couple of coeffs deep.<br />
- d: Which block sizes?<br />
- x: 4x4 only.<br />
- d: Good because you can make 4x4 work but not anything else.<br />
- x: I hope that it gives us a pattern for other block sizes.<br />
- d: I'm less hopeful about that.<br />
- jm: Are you considering multiple block sizes?<br />
- x: Not yet, but I was hoping that if we have a single lift pattern that is expanded then that pattern would help us handle multiple block sizes without TF.<br />
- jm: The main issue with block sizes is that your stuff doesn't need to interact with surrounding blocks, but you have the lapping problems on all four sides.<br />
- x: This is entirely transform domain.<br />
- jm: If you're going to have a 16x16 block, the lapping can be for 16, for 8 or for 4, same on bottom, left, and right.<br />
- x: I'm not predicting from entire blocks anymore.<br />
- d: JM is just talking about he transform.<br />
- x: What is the worry?<br />
- jm: The transform needs to account for lapping.<br />
- x: In the transform domain they don't look different.<br />
- jm: It's not the case of lapped and unlapped. There are 81 ways to do lapping for a 16x16 block.<br />
- x: That changes the quantities but no the qualities. Different side lobe heights but not different side lobes. I am pursuing this with the assumption that the block sizes don't change it qualitatively.<br />
- jm: The transform is supposed to predict a 45 degree pattern right?<br />
- x: Right.<br />
- jm: If I have one block with b&w with the limit being 45 degree boundary. Can you code that with N non-zero coeffs.<br />
- x: Have you looked at what the lapping does in transform domain? It causes refractions and reflections along the edge. Those don't change with lapping support, only the strength changes. The filter doesn't eliminate that, there is still some information there. I don't have a filter present yet, but the lapping appears to reduce the amount of information I need to deal with. Given that 4 directional edges our 2d DCT doesn't compact those, the lapping reduces those.<br />
- jm: What is expanding?<br />
- x: Directional edges going through our lapped 2d transform. In the transform domain there is an apparent expansion of complexity. Lapping reduces that apparent expansion. I'm not attempting to find a perfect filter, just a very good filter. I don't think the lapping doesn't change information in such a way that it needs a different filter for the combinations.<br />
- d: I worry that you spend a bunch of time getting 4x4 working but it falls apart at higher sizes. That's what happened to the original stuff.<br />
- x: Did 4x4 actualy work without sparsification?<br />
- u: Yes, it worked well both ways. I can dig up some old graphs if you want.<br />
- d: One possiblity is that we could do intra just for 4x4.<br />
- x: The block size is so small that it can only win if you can do it without signalling.<br />
- d: 4x4 worked when everything was 4x4. I don't think it worked with multiple block sizes.<br />
- u: We need to run these tests again instead of speculating.<br />
<br />
# gain / theta / skip coding<br />
<br />
- jm: Last week Tim suggested adding a special flag for skipping everything beyond this band. In most cases the code we have right now we will use gain=0 more often than skipping for high bands. the reason for this is that there isn't very much in the first place. A large fraction of the predictions we have will have less energy than the quant threshold.<br />
- d: Which is completely expected.<br />
- jm: I'm not exactly sure what to do abou tthis. Especially as gain=0 has better distortion.<br />
- d: Slightly better right? The thing that concerns me is that we have two ways to code this thing, but we should not spend a bit on signalling that. We should figure out a way to prefer one of these in terms of the signaling cost.<br />
- jm: I the case you don't mind a desync, it's easy to see the gain of the reference is below a certain amount so don't allow gain=0 or skipping. This is easy to do. If you do mind desync on error, ...<br />
- d: Which we do.<br />
- jm: I have no idea what to do about that case.<br />
- d: My gut says you prefer to skip always and make skipping cheap to code. But that still leaves this redundancy in there.<br />
- jm: There are things you can do where you pretend you are skipping and the code behind it just sets gain=0 if it's better for distortion. I thing I'm trying to do at the same time is to jointly code theta and the gain. My first attempt didn't work well, so I've started doing this again. I can actually get some slight improvement by doing it as long as I don't attempt to put noref in there. I think noref is more efficiently encoded jointly across all bands.<br />
- d: Maybe using something vaguely like the SPIHT stuff, just on the gains. Basically you would have at the top level you would code the maximum gain of all the bnads below you. Then you signal whether the current band is the maximum or less and do that for the bands below that. In normal SPIHT you'd hierarchically do that for each band. The idea is that if I code that hte maximum gain=0 at the top level then I've told you what all the gains are now.<br />
- jm: A while ago I looked at this correlation and I didn't find very much correlation. Essentially there are a lot of things you could couple, but you can only couple two of them. Also, consider that for inter you are not coding gain, but the gain difference.<br />
- d: My point is that you have some kind of hierarchical way to limit the range of these things up front. I would expect you'd expect larger gain differences in LF vs. HF. If you can expect LF to have larger changes than HF, then when you code the maximum gain then I'm going to have a biased probability for the gain change. And I've cut out a huge amount of possibilities.<br />
- jm: For the lowest quadrant, if there isn't much change, I can code gain=0 or nonzero combined with theta of noref 0 or more than zero combined with do you want to skip everything else. You could have all this in a single symbol.<br />
- d: My concern is less the number of symbols but cutting down the number of possibilities you have to encode. That's the point of coding the max instead of the sum.<br />
- jm: We have 16 so what's the point in having less than 16?<br />
- d: I'm not saying you have less than 16. In a single symbol my maximum gain would be up to 2^16 (log structure) and from there code what is the delta down to the actual gain. It is using two different symbols, but it still uses all 16 values.<br />
- jm: What you're describing sounds like it would work at high bitrate, but I've mostly looking at low bitrate cases.<br />
- d: At low bitrates I think this works well. I could code all gains with one symbol. If one is 1 then it might take two symbols. It's not the hard and fast you have to skip everything or nothing.<br />
- jm: I'd like to be able to, in a single symbol, say I'm coding some residual for a specific quadrant, and nothing for the higher frequencies.<br />
- d: My idea would take two, but I'm not sure that's a huge disadvantage.<br />
- jm: We're pretty much stuck having two schemes? One for robust and one for non-robust?<br />
- d: Yeah, it sucks, but not sure how to avoid it.<br />
<br />
# Deringing<br />
<br />
- d: I have a few bugs in my rewrite of interp_pixel but I'm looking at that.<br />
- jm: Do you want to see this landed?<br />
- d: I don't see any real blockers to it at this point.<br />
- jm: I'd like to add more directions.<br />
- j: Can we signal this in the bitstream so that as complexity budget increases the directional search can increase?<br />
- d: Yes. The limitation is implementation complexity, but this seems doable.<br />
- j: Will this get landed before the work week?<br />
- d: Probably a project for the work week.<br />
- jm: Have you played with it on actual images?<br />
- d: Enough to confirm that my version wasn't working :) It seems to do good things most of the time.<br />
- jm: Are you just rewriting it to avoid sqrt etc?<br />
- d: Exactly?<br />
- jm: Is it bit exact?<br />
- d: Down to rounding error.<br />
- j: Is this one of the projects we can hand off to Andreas to optimize?<br />
- d: Needs a bit of algorithmic optimization first.<br />
- jm: There's a whole bunch of things that I"m considering changing. The direction search is costed on a single block, but probably we want to add up the directions from neighbors so the directions will be more consistent.<br />
- d: Some kind of regularization.<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15031Daala Weekly Meetings2014-10-14T19:16:29Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - <br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects<br />
* [[DaalaMeeting20141014|2014 October 14]] - monty's directional transforms, HV intra, gain/theta/skip coding, deringing</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20141007&diff=15030DaalaMeeting201410072014-10-14T15:57:01Z<p>Jack: Created page with "<pre> # Meeting 2014-10-07 Mumble: mf4.xiph.org:64738 # Agenda - reviews - Reduce PVQ<->entropy coding depencies on intra - Decide the fate of deringing - Scalar's gone, let'..."</p>
<hr />
<div><pre><br />
# Meeting 2014-10-07<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- Reduce PVQ<->entropy coding depencies on intra<br />
- Decide the fate of deringing<br />
- Scalar's gone, let's adapt to PVQ<br />
- intern project brainstorm<br />
<br />
# Attending<br />
<br />
Nathan, Jean-Marc, Thomas, Tim<br />
<br />
# Reviews<br />
<br />
- t: We we JM two, 478 and 479. I wanted you to look at 478, Nathan<br />
- n: So, yeah, what do we want to do about intra?<br />
- j: This is the simplest thing that I could amke work<br />
- n: It has some interesting properties, like it's all in the frequency domain but I don't know if we want to do something else that's more complicated<br />
- t: You guys know more about what stuff works at this point than I do<br />
- n: There was stuff I wanted to try, like adding TF. I also wanted to look at how much noref is used<br />
- j: Oh, quite a lot<br />
- n: Yeah, even when you pick H or V you still copy stuff from the other direction<br />
- j: For the larger block sizes, you have several pure H or pure V bands that you can select with noref. But for the smallest 15-coeff band, you can't pick which one to use with noref<br />
- j: for the lower frequency quadrent, the reasoning is that if I copy boht the horizontal energy and the vertical energy from the block on the left ,one of the two components will hurt the other one and it is going to be useless and I code a no ref<br />
- n: what if the diagonal had more energy than the horizontal and vertical, should you not code either one of the bands<br />
- j: maybe, but its only going to cost you a no ref<br />
- j: you should probably try these other experiments because at the rate I did the experiments I am not willing to say that none of them are better.<br />
- j: The reason I submitted this patch was that it filled the most bands, and the reason for that is because of the interactions between PVQ and entropy decoding<br />
- j: right now, what's in master has CfL which means that with CfL or even the simple intra predictors, our decoder is essentially single threaded. If you run it on a machine that has an infinite number of cpu's you could probably get something that is like 10-15% speedup, assuming your not using slices or stuff.<br />
- j: if we were to use robust bit stream, we would be able to have entropy decoding in a thread and have all the pvq running in parallel<br />
- d: it looks like that was causing us a percent and a half of rate<br />
- j: it may be possible to do better, this is the really early version I have<br />
- d: but does that mean we could use *any* intra prediction strategy we wanted and it would not effect entropy coding<br />
- j: you could use any intra prediction you want<br />
- d: okay good<br />
- j: whatever you attempt to do with the entropy decoder does not depend on prediction, so you would be able to do whatever you want with prediction without messing up the entropy loop<br />
- d: so we've made tradeoffs on the order of this before, the entropy encoder costs you about a percent just to avoid having divisions in it<br />
- u: so the robust stream must cost us something?<br />
- j: most of the cost from the robust bistream is if you code a theta then you cannot use that to change the probabilities of the gain<br />
- d: I keep thinking there should be some way to model this distribution, something like the distribution for theta falls off a cliff, even if you don't know where the cliff is<br />
- j: if you have a whole bunch of blocks that have a gain of 1 or gain of 2<br />
- u: is there a theoretical limit as to how much you lose by removing adaptivity in the entropy coding? <br />
- j: I would assume hardware would be an issue too, you would have these two pieces of silicon that would need to communicate between each other<br />
- d: yes it would be an issue<br />
- d: you essentially have the issue that the entropy decoder is serial while everything else is not, e.g. the idct's are massively parallel but only if you can feed them data fast enough<br />
- j: although if we were to do something like spatial domain intra prediction, the iDCT needs to run in the coding loop<br />
- d: so if we do something like the unlapping, that sits in a pretty similar place as HEVC<br />
- j: in the current state, we already have CfL so we have our blocks not completely independent, like you can run the DCT and the lapping filter fully parallel (n-squared parallel) but you cannot run the chroma parallel<br />
- d: I mean you can do the luma plane parallel<br />
- j: as far as I can tell we're coding a super block at a time, oh wait hold on, if we were to have a robust bistream we would have to do the entropy coding for everything and yeah we could run luma PVQ and chroma PVQ completely parallel<br />
- u: what do we think about entropy coding in wave-front order?<br />
- d: I need to do more research on this before we make major changes to the bitstream<br />
- d: so if we're going to talk aobut this on an actual CPU, the rough division of a workload you want is 10,000 cycles so you are not going to be able to do this on a superblock by superblock level.<br />
- j: yeah I guess not, the way I see it you do not even need to have an actual synchronization point you just shove data in there<br />
- d: the problem is you still have to bounce a cache line from one CPU to the other to know that the number of superblocks that have been decoded has just gone up<br />
- d: yeah one line of superblocks at a time, now you are talking about something reasonable<br />
- d: I just want to get a picture of what the people have done in htis space, because people have tried to do this<br />
- j: I think the way we're structured if you use the robust bitstream, I think you can make use of 3 to 4 cpu's, you would have 1 doing the entropy decoding.... I guess you would be bound by the entropy decoding. If the entropy decoding is 1/4th of the total time you can get 4x speedup<br />
- d: this is something that depends on the bit rate, and unfortunately on the streams that you want to do this the most the bitstream decode is the largest component<br />
- j: right now interframes, even if we don't enable the robustness should be fully parallelized<br />
- d: yeah yeah yeah, parallelized the same way you need the entropy decoder to fininsh<br />
- j: the only stuff we have that beats<br />
- d: I'm talking about inter frames<br />
- j: I'm saying that if we had intra prediction that worked, it would work both on key frames and inter frames<br />
- d: there are two different problems here, one is actually having an intra predictor, the second is how to use intra in an inter frame. My point is we have to do something in the encoder search<br />
- j: what I'm saying is, if the answer to the first one is no-ref, then its all fully parallel<br />
- u: the problem is with intra<br />
- j: so now you are on item 4 of the agenda<br />
- d: fast is what you want for motion search, SAD is good because it is fast and you can consider more candidates<br />
- d: that's sort of what theora did right ,theora had a motion search that is similar to what we do in daala. It uses SAD to get some candidates and then uses some<br />
- j: but like theora didn't have intra prediction<br />
- d: sure it idd<br />
- j: it just copied the DC<br />
- d: some weighted some of the DCs<br />
- j: which I assume isn't much better than picking whatever was your last motion vector and coding whatever was your last DC<br />
- d: I mean we did that on a block by block basis<br />
- d: oh absolutely, when you do this motion vector stuff with a motion vector that makes no sense you mess up the A/C and then have to correct it all<br />
- j: the current problem you have with no-ref, it won't go away<br />
- n: On a different topic, as you descend down in Haar DC, sometimes you have both UR and BL<br />
- j: No, you have a quadrant every time. There's no BL or UR or whatever, you have 4 inputs to your transform and 4 outputs. Once you're done encoding at the superblock level, it's just a quadtree.<br />
- n: And you descend and do it again, and you carry along this horizontal and vertical gradient that use the U and L DCs to predict with, and in some cases you have UR and BL as well<br />
- j: When I code the 8x8 blocks, the gradients I'm using are based on the differences _within_ the superblock. Every time I code something, I update the gradient for the lower levels.<br />
- j: so de-ringing, I'm at least at a point where we need to make a decision on this. I shouldn't be spending any more time on this until we decide if we are actually going to use it<br />
- d: okay, so as I understand the major blocker is actually making the painting part performant.<br />
- j: oh its reasonable now<br />
- d: so did you get the square roots out of it?<br />
- j: no they are still there<br />
- d: so I think you and I have different definitions of performant<br />
- j: its now being done only once or twice per pixel instead of 32x<br />
- d: that is not fast enough<br />
- j: whatever the actual speed I am getting is not actually slowing down the codec. If that is the problem then I can remove them<br />
- d: I need to sit down and actually have a look at it and get more familiar with it<br />
- j: the bottom line is I'm not going to be spending any more time on this if whatever I do is not going to have any impact on if we use it<br />
- d: ok<br />
- j: I think I mentioned that the last problem I had was the strength thing, I think the best that I could come up with is having a per super block strength that changes per factor of two.<br />
- j: the problem is that the block size decision isn't taking chroma into account<br />
- d: is there some way to validate that<br />
- j: http://jmvalin.ca/video/dering/clovis0.png (without deringing)<br />
- j: http://jmvalin.ca/video/dering/clovis1.png (with deringing, still some vertical ringing)<br />
- d: we're now way over time<br />
- j: I am just wondering how good it is to be more parallel<br />
- d: its pretty useful<br />
- j: if we come out and say we are much more parallel than say 265 is that going to help us gain acceptance<br />
- d: it will probably have a small impact<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=15029Daala Weekly Meetings2014-10-14T15:53:57Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping<br />
* [[DaalaMeeting20140923|2014 September 23]] - reviews, VDD debrief, deringing demo, intraprediction tests<br />
* [[DaalaMeeting20140930|2014 September 30]] - <br />
* [[DaalaMeeting20141007|2014 October 7]] - pvq<->entropy coding dependencies on intra, fate of deringing, scalar gone, intern projects</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20140916&diff=14987DaalaMeeting201409162014-09-16T16:50:11Z<p>Jack: Created page with "<pre> # Meeting 2014-09-16 Mumble: mf4.xiph.org:64738 # Agenda - reviews - horizontal and vertical unlapping predictors http://people.xiph.org/~unlord/unlap/fruits-v10-res...."</p>
<hr />
<div><pre><br />
# Meeting 2014-09-16<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- horizontal and vertical unlapping predictors<br />
http://people.xiph.org/~unlord/unlap/fruits-v10-res.png<br />
http://people.xiph.org/~unlord/unlap/fruits-v10-modes.png<br />
rd-curves<br />
http://people.xiph.org/~unlord/unlap/subset1-fastssim.png<br />
http://people.xiph.org/~unlord/unlap/subset1-psnr.png<br />
http://people.xiph.org/~unlord/unlap/subset1-psnrhvs.png<br />
http://people.xiph.org/~unlord/unlap/subset1-ssim.png<br />
fruits at ~0.1 bpp<br />
http://people.xiph.org/~unlord/unlap/fruits-v61-14105-pred.png<br />
http://people.xiph.org/~unlord/unlap/fruits-v82-14030-nopred.png<br />
- ?<br />
<br />
# Attending<br />
<br />
azita, derf, gmaxwell, jack, jmspeex, tmatth, unlord<br />
<br />
# Reviews<br />
<br />
# horizontal and vertical unlapping predictors<br />
<br />
- u: the idea is to find intra prediction modes that work given the lapping. one of the ideas tim had was to try to unlap the lapping on the current block. you want to predict what the lapped values of the current block would be given your lapped neighbors. if you look at the horizontal modes, it's easy to do horizontal and vertical. so i wrote a simple piece of code that does three different modes, no predictor, horizontal and vertical. and i measured SATD and used that as the metric for picking the mode. you don't do haar DC you just use the normal dc and use the k tokenizer for the remainder of the coefficients.<br />
http://people.xiph.org/~unlord/unlap/subset1-fastssim.png<br />
- d: when you compare i'ts with haar dc?<br />
- u: no it's recording the dc as is.<br />
- jm: can you compare to intraprediction and disabling coding of hte mode? this is with modified intraprediction right? you could just do the rd curve were you disable haar dc and reenable the old intra and comment out the part where we code the mode in the old intra.<br />
- u: so you want to know what this looks like compared to the freq domain stuff?<br />
- d: this is all fixed block size right?<br />
- u: yes. 8x8. i think it's possible to do different block sizes.<br />
- jm: you can actually have an apples to apples comparison if you compare to the old intra.<br />
- u: i also put up a graph of what the modes are, and if i did just doing horizontal and vertical so doing some adaptive coding of the modes should be efficient.<br />
- d: if you did some RDO the noise should go away.<br />
- u: that's on my list of things to add. the thing i'm adding now is for modes that are not horiz or vert, just use the unlapped region outside of the block. ie, pulling your predictors from farther away. and you push those across two block sizes and do the prefilter and dct and use that as your predictor. for some of these you see it does a poor job and the modes that aren't horizontal or vertical look like good candidates for doing something else.<br />
- d: the concern is merely that it is not as good. because you are predicting from farther away, the number of directions you have support for is smaller. but it may be better than nothing which is what we're currently doing.<br />
- g: did you look at the actual output images?<br />
- d: you have the two rd curves here, but what do the images look like at 0.1 bpp?<br />
- u: I can tell you that in a minute.<br />
- d: It looks like you have a good half db of separation at those rates, so we should be able to see it.<br />
- u: you want with and without?<br />
- d: yeah.<br />
- g: fastssim is unlikely to be doing something weird, but we have cases where ...<br />
- u: another question i had is even though you have fewer modes you can still adapt your context for that case right? you could just not have that in the cdf for those modes right?<br />
- d: what you'd probably more likely do is make up some data over there so you still could do a prediction but it wouldn't be very good and not chosen very often. the idea is to have fewer special cases.<br />
- u: do you think there would be real savings? have you played with trading those two things off?<br />
- d: no i have not compared them. i'm arguing from design complexity at this point.<br />
<br />
# testing<br />
<br />
- jm: who is doing tests for 265, 264 and vpx? would you be able to have runs that disable the non-realtime stuff?<br />
- td: yeah, I can do that.<br />
- jm: the patch i submitted makes the bitstreams robust to errors<br />
- j: does that mean no vomit tigers?<br />
- d: we'll still have bugs<br />
- g: I think we're already comparable because 264 and 265 won't desync.<br />
- d: jean-marc is also talking about the no lookahead case. if you look in the 265 development use cases they had two, archival storage and relatime. it's perfectly reasonable to test these codecs under both scenarios.<br />
- jm: at the IETF the primary use case is realtime.<br />
- d: this will also make us look better. we only do 1-2% worse between the cases, but in the other codecs they do much worse if you turn off bframes. currently the only thing we're planning to add that would impact this difference is some equivalent of bframes. and actual rate control but these comparisons are theoretically without rate control. if you look at vp9, it takes a large hit for the realtime use cases because they have a bunch of things in addition to altref frames that they have to turn off to deal with dropped frames. they don't do any online updates of prob models. so you have to turn that off, etc. they were showing something like 12-20% drops for running in realtime mode.<br />
- j: does vp8 have similar problems?<br />
- d: vp8 has to shut off altrefs, but it doesn't do feed forward probability adaptation. instead of adapting the probabilities from the previous frame they code what probabilities to use at the beginning of each frame.<br />
- jm: aside from bframe equivalents is there anything else that 26x does for realtime that we are not planning on doing?<br />
- d: i'm trying to think of what the other two things were in vp9. but i'm pretty sure we're not planning on doing them, whatever they were. for 265 there was some stuff i was worried about, but i think they found ways to make them work without desync.265 builds predictor lists and then signal which one to use as a predictor. if you do any kind of consolidation of those lists, then you have a problem if it includes the temporal predictor.<br />
<br />
# unlapping (cont)<br />
<br />
- d: nathan, you need ot add dc prediction before this is a fair comparison.<br />
- u: when i do the prediction i'm in the lapped domain. i do the dct and use that in my predictor. are you suggesting i use dc when i have a mode that is not predictor.<br />
- d: when the mode is no predcitor, you should still predict dc. and learn what the weight is.<br />
- u: would I include blocks that are already horiz and vertical?<br />
- g: i think what he is asking if he should train on all the blocks or just the ones are horizontal and vertical. probably you want all the blocks and go back a retrain with only the blocks that got assigned.i can go over it with you a little later this morning.<br />
<br />
# multiple ref frames<br />
<br />
- d: any progress greg?<br />
- g: not yet, but should be able to make progress this weekend and next week.<br />
- d: i'll be at VDD this week.<br />
- u: I found a link for it. There's a wiki. (https://wiki.videolan.org/VDD14)<br />
- d: Guillaume should be there. I should be talking about some opus and mp4 stuff. I'll be giving a talk on Daala. the way this work is that they invite people since they dont' have a lot of resources and they know who they want to show up.<br />
- tmatth: i will be at vdd \o/<br />
- j: we should have done this for xiph<br />
- d: we kind of do. we have FOMS.<br />
<br />
# awcy<br />
<br />
- jm: what's the status of them avoiding getting shut down?<br />
- td: I'm working on fixing it. i might disable shutdown until i get it fixed.<br />
- jm: I'm using the web interface but there's a commandline tool?<br />
- td: yep. there's a python script.<br />
- jm: what's the name of the script?<br />
- td: submit_awcy.py<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=14986Daala Weekly Meetings2014-09-16T16:49:27Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing<br />
* [[DaalaMeeting20140909|2014 September 9]] - reviews, deringing, intraprediction, non-photographic video<br />
* [[DaalaMeeting20140916|2014 September 16]] - reviews, unlapping</div>Jackhttps://wiki.xiph.org/index.php?title=DaalaMeeting20140902&diff=14944DaalaMeeting201409022014-09-02T17:04:36Z<p>Jack: Created page with "<pre> # Meeting 2014-09-02 Mumble: mf4.xiph.org:64738 # Agenda - reviews - Daala Demo 5? - multi-frame motion compensation - Deringing filter based on paint - Other intra ide..."</p>
<hr />
<div><pre><br />
# Meeting 2014-09-02<br />
<br />
Mumble: mf4.xiph.org:64738<br />
<br />
# Agenda<br />
<br />
- reviews<br />
- Daala Demo 5?<br />
- multi-frame motion compensation<br />
- Deringing filter based on paint<br />
- Other intra ideas<br />
- Publishing<br />
<br />
# Attending<br />
<br />
unlord, smarter, tmatth, jack, jmspeex, derf, gmaxwell, td-linux, xiphmont<br />
<br />
# Reviews<br />
<br />
https://review.xiph.org/437/ - done!<br />
https://review.xiph.org/438/ - asm<br />
<br />
# Demo 5<br />
<br />
- x: update1 is in the same spot, waiting on Andreas. Haven't done anything on demo5. Was working on the crazy idea from last week.<br />
- d: What idea was that?<br />
- x: It was directional transform. The bit that didn't work was rotating the lapping, which made it not reversible. The rotational transform is interesting though. The bit I got distracted on was attempting to remove refractions, but I've convinced myself that isn't possible.<br />
- d: I didn't see how you were going to make it reversible.<br />
<br />
# Multi-frame motion compensation<br />
<br />
- g: I have something kind of working, but I need to rebase it to master. Hopefully it will work better once it's caught up with the current code base. I don't think we have any clips that are great for testing it.<br />
- d: I assume you are just using the keyframe?<br />
- g: Yeah.<br />
- d: I think the real benefit will be when you use frames that are close by.<br />
<br />
# Deringing filter<br />
<br />
- jm: I posted some images of my work in progress and I'll repaste: http://jmvalin.ca/video/fruits_v60a.png http://jmvalin.ca/video/fruits_v60b.png<br />
http://jmvalin.ca/video/fruits_v60c.png http://jmvalin.ca/video/fruits_v60d.png<br />
- jm: a is the no deringing filter, b and c use 16x16 and d uses 8x8 (different settings of the deringing filter)<br />
- g: what else did you test this on?<br />
- jm: IENA and fruits, which are the easiest and hardest cases. Mostly IENA results in blurring right now.<br />
<br />
(some discussion of various artifacts)<br />
<br />
- jm: I'm not sure how and what to signal right now. In theory you could go with on/off but seems like we could do better than that.<br />
- g: I assume it would be reasonable to parameterize the intensity right?<br />
- jm: Yes.<br />
- d: But the intensity can be derived from the quantizer used right? All the activity masking is goign to tell you where you used a coarser quantizer. Also, we should be doing less deringing at higher qualities.<br />
- jm: That's the only thing I'm taking into account right now. There are two gains I can derive. 1) The optimal gain knowing the original. and 2) the theoretically optimal game not knowing the original. The second is the one I'm applying now. It's stddev of the noise divided by stddev of the image.<br />
- g: Currently activity masking will result in us using a less precise quantizer ...<br />
- jm: Activity masking is disabled at 4x4. It's a known issue.<br />
- g: I was going ot suggest we could code a bit that says we need more quantizer here, etc.<br />
- d: I think we code that bit and it's whether to use 4x4. 4x4 is not used exclusively for edges. LIke stars in quebec city bridge.<br />
- jm: These I don't think would look really well in the current deringing filter. That will definitely need some signalling. Mostly because the filter will not see the star itself.<br />
- d: It does not match your model.<br />
- g: How do we run this on moving images/<br />
- jm: I Don't see the problem, but I'm not there yet. We definitely need a way to make it more or less aggressive on both still and moving images. One possibility will be to compute motion compensated frame difference after the fact. How much change did we compute? Then use it as side info for deringing.<br />
- d: Those are two different things. The MC frame difference is comparing the predictor to the original image. Are you talking about that or the difference you actually encoded?<br />
- jm: The latter. I derived the gain in the optimal case where I know the original image. That gain is basically the covariance of the coded image with the original image divided by the variance of the coded image. But you need to signal something because that info is just not available.<br />
- d: Have you looked at the difference between that and the other gain?<br />
- jm: Yeah, that's my next step - do the theoretically optimal gain. If it's not buggy, there's no way to make the image worse. It's optimal for MSE / PSNR.<br />
- d: We all know that's the best thing to optimize for!<br />
- g: How slow is this?<br />
- jm: Right now very, because of the directional search. There are ways to make it faster but I'm not looking at that yet. I still have a few bugs. I get a segfault on one image. I'll have to fix that to get actual RD curves. On fruits it helps PSNR up to 0.3dB at v60.<br />
- d: It's better than basar was seeing with his stuff. I think we should be expecting 0.5 to 1dB.<br />
I didn't think you were expecting that much gain from side information.<br />
- jm: Once you get below the quant threshold, your noise is your actual image, so it will apply at a gain of 1 blindly. Also, is anyone interested in checking my math? If so, I can transcribe from my whiteboard.<br />
- j: Write it down somewhere!<br />
- x: I'm interested, but probably not this week.<br />
- d: I'm also in the worrying about the math later camp.<br />
- jm: Right now the criteria is baed on MSE. How familiar are you guys with audio denoising? You could theoretically optimize the gain for preserving the amount of texture.<br />
- d: Don't we already do a great job of that?<br />
- jm: I mean in the denoiser. Instead of having a wiener filter, you could have something that minimizes the amplitude of the spectrum or whatever. Opus minimizes the log spectrum error. What this does is minimize the MSE of the signal not the spectrum.<br />
- jm: Only concern I'm aware of is the inter one.<br />
- d: That's a big one!<br />
- jm: I have one fix that is guaranteed to work<br />
- d: Don't run it on inter frames?<br />
- jm: Yeah.<br />
- g: Certainly ringing problems on inter are less bad.<br />
- j: How do you prevent progressive blurring on inter frames?<br />
- d: That's what he said, you don't apply it to inter frames.<br />
- jm: Imagine your video is a single image. You apply the filter. When you do the next frame, the gain would be zero because applying it would make the MSE worse.<br />
- d: You hope it's zero. It's not floating point, so there will be rounding errors.<br />
- jm: That is one approach, and the other approach is to look at blocks where we coded a non-zero theta. You'd not be allowed to dering on blocks with zero theta.<br />
- d: Right. Anything it adds will be ghosting aligned with the edge so your thing will enhance them.<br />
- jm: You're assuming the same block size which isn't going to be the case.<br />
- d: The sort of artifacts during MC will be if you get the edge alignment wrong.<br />
- jm: I can't remove that.<br />
- d: Exactly.<br />
- jm: That's why I think we automatically disable it for anything where we don't have any residual.<br />
- d: Then you run into the fun problem of having lapping and what does that mean.<br />
- jm: If it doesn't work on keyframes we should get rid of it, so I want to work on that first.<br />
<br />
# Other intra ideas<br />
<br />
- u: I should have RD curves soon. I wrote some code to do the three tests but I don't have it hooked into rd_collect yet. At some point I want to ask you about the Haar DC. I still don't understand exactly how that works. There's a bunch of magic constants that I don't understand.<br />
- jm: THere are two. The only place where there is prediction is across superblocks. There are constants for up left, etc, only at the superblock level. The only other thing is trying to predict gradient within the block. If it detects there's a gradient, it will attempt to continue that gradient within the block. That's the division by 5.<br />
- u: I see a shift by 5.<br />
- jm: No, there's a /5 somewhere.<br />
- d: hgrad / 5 and vgrad / 5 in quantize_haar_dc. JM, your comment is on the second time you use them.<br />
<br />
# Publishing<br />
<br />
- g: What's the schedule of publishing update1?<br />
- x: I'm going to publish demo pages again as soon as I work on them. Just not update1 until Andreas is ready.<br />
- g: What about intrapaint?<br />
- x: We could, but we don't know if it works yet.<br />
- jm: It's starting to work now<br />
- g: I don't consider the post filter the same thing anymore.<br />
<br />
</pre></div>Jackhttps://wiki.xiph.org/index.php?title=Daala_Weekly_Meetings&diff=14943Daala Weekly Meetings2014-09-02T17:03:28Z<p>Jack: </p>
<hr />
<div>We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
* [[DaalaMeeting20140513|2014 May 13]] - trained vq, intraprediction<br />
* [[DaalaMeeting20140520|2014 May 20]] - dc encoding<br />
* [[DaalaMeeting20140527|2014 May 27]] - standard metrics<br />
* [[DaalaMeeting20140603|2014 June 3]] - deringing filter<br />
* [[DaalaMeeting20140624|2014 June 24]] - deringing filter<br />
* [[DaalaMeeting20140701|2014 July 1]] - multi-frame motion compensation, jean-marc crazy ideas<br />
* [[DaalaMeeting20140708|2014 July 8]] - intrapred ideas, journaling, rd_collect issues<br />
* [[DaalaMeeting20140715|2014 July 15]] - VIPC, intrapred<br />
* [[DaalaMeeting20140722|2014 July 22]] - demo progress, video results, edi, deringing, new intra<br />
* [[DaalaMeeting20140729|2014 July 29]] - edi, intra paint<br />
* [[DaalaMeeting20140805|2014 August 5]] - edi, intra paint<br />
* [[DaalaMeeting20140812|2014 August 12]] - multi-frame MC, intra paint, edi<br />
* [[DaalaMeeting20140826|2014 August 26]] - intra paint, halfpel BMA<br />
* [[DaalaMeeting20140902|2014 September 2]] - demos, multi-frame motion compensation, deringing</div>Jack