The position should be displayed in pixels and in units of superblock (which is just pixels/32)

In Theora we had a convention that decoder ctl's (listed in include/daaladec.h) were all odd, as documented here https://trac.xiph.org/browser/trunk/theora/include/theora/theoradec.h#L36, so they would fail if accidentally passed to an encoder.

The current decoder controls in Daala do not follow this convention, but should.

The encoder also starts numbering at 4000 instead of 0, and does not use consecutive numbers, to make it less likely that arbitrary values passed to the function will trigger bad behavior, a convention we started during Opus development. The decoder should do something similar.

Right now the stream analyzer plays through the video once and then stops. To play a second time, the video file must be reopened. Add support for looping (via a check box menu item). Internally, this will require implementing the DaalaDecoder::reset() so that the internal state of the decoder is reset rather than creating a new decoder.

YUVplay has this convenient feature: when you click and stay pressed on a pixel it displays a zoomed version of just the region around the pixel in a small box, this box is updated when you move your mouse and disappears when you release the mouse button.

The y4m header output by dump_video.c starts with "YUV4MPEG2 C420jpeg H..." but the header output by od_state_dump_yuv in state.c starts with "YUV4MPEG2 W..." so we cannot check that they match by simply using md5sum. See http://wiki.multimedia.cx/index.php?title=YUV4MPEG2 for a pseudo-spec of y4m headers.

Instead of having OD_ROBUST_STREAM in internal.h

Currently we have something for k=1, but it would be nice to have a fast K=2 tokenizer since that case is common too.

Something like: foo.ogg: Frame 5 of 10 - Daala Stream Analyzer

Right now we only look at luma, which causes bad decisions, especially when the chroma contrast of an edge is much larger than the luma contrast.

echo " CCLD " examples/dump_video;/bin/bash ./libtool --silent --tag=CC --mode=link gcc -I/home/yushin/.linuxbrew/Cellar/libogg/1.3.2/include -std=c89 -pedantic -Wall -Wextra -Wno-parentheses -Wno-long-long -Wno-overlength-strings -g -O2 -o examples/dump_video examples/examples_dump_video-dump_video.o src/libdaalabase.la src/libdaaladec.la -L/home/yushin/.linuxbrew/Cellar/libogg/1.3.2/lib -logg

The stream analyzer should be updated to display the padded region around the encoded frame. Internally the frame size is padded out to the next largest superblock (multiple of 32 currently) and the frame edge is extended. It would be helpful if the stream analyzer could show this region as well. Display the padded decoded frame with 16 pixels of black on all sides and some indication of where the edge extension begins. Bonus points for allowing you to toggle this mode on and off.

Currently there are many defines in internal.h that switch quantization matrices. Because these are actually coded in the bitstream, they can be a runtime encoder option instead.

DC quantization currently has very limited RDO. We only consider RDO for zero vs non-zero, and even then the rate estimate is pretty rough. It considers the cost of coding the zero vs non-zero flag, but not the cost of actually coding the non-zero value itself. This should be improved.

Particularly useful to know if a region of a frame is really uniform or just has imperceptible differences, the display should look something like Y: 42, U: 24, V: 12

Update the status bar to include the frame size and current frame number. Ex:

foo/bar.ogv (800x600) - Frame 10

Larger lapping can provide much of the same effect as the bilinear filter, as well as additional coding gain.

Now that DECCTL codes have been added to extract the motion vectors in:

https://git.xiph.org/?p=daala.git;a=commit;h=5142205e

The stream analyzer should be updated to display them as you step through a video. This will require drawing motion vectors beyond the edge of the decoded frame boundary and is dependent on:

#13 Migrate analyzer to a 2D graphics library
#23 Show the padded region in the stream analyzer

Currently the higher bands of 16x16 and 32x32 don't have it.

The bit accounting code needs to be modified to run in the decoder and exposed as a DECCTL. This will require modifications so that the bit accounting code is not longer enabled / disabled in the decoder via the ./configure flag, but at runtime is enabled / disabled by the presence of a buffer supplied via DECCTL.

Display the bits per pixel per block as an heat map overlay to the image.

Some sources have nonsquare pixels. This is specified by the 'A' parameter in a y4m file. This should be put into daala_info and encoded/decoded so that the final output y4m has the same SAR encoded in it.

player_example would be a better tool for evaluating the quality of encoded videos if it did not play every frame as fast as possible.

Desired functionality:
graphical depiction of motion vectors (direction/magnitude, ala Theora telemetry)
ability to hover on specific blocks/vectors to show actual values of motion vectors

Figure out how to modulate the effect of activity masking based on whether the block/superblock/whatever has texture vs edges.

This got removed when introducing the fixed lapping. Now that the matrices are now "full" (not per band), we'll have to find an efficient way to code them in the bit-stream. Suggested approach is coding the DCT of the log of the matrix.

Currently, you can go to the next frame by pressing '.' but this is impossible to know without reading the source code, having a menu item would improve discoverability.

When Monty zeros all of the motion vectors and turns lapping off, there are lines that appear at the top of the motion compensated blocks.

Awaiting more info from Monty.

Right now you can do CFLAGS="..." ./configure but that will overwrite the default CFLAGS. It'd be nice to have a way to pass extra CFLAGS either to configure or to make, for example in libav you can do make ECFLAGS="..."

We should be quantizing chroma less coarsely than luma at low bit rates. At the low end of the range, the quantization chroma should be a factor of two over luma. At high bit rates we should be quantizing chroma more heavily (Cb more heavily than Cr).

Currently encoder_example has a --limit M option to only encode M frames, it'd be nice to add a --skip M option to skip the first M frames in the input before starting to encode.

The OD_DCT_CHECK_OVERFLOW is enabled only when running dcttest. Add a config option so this can be run on actual video clips.

Haar DC coefficients are currently "rounded to nearest" when doing the quantization. We should be applying RDO to that decision.

Add a #define to internal.h that defines OD_LOG_BSIZE_MAX as OD_LOG_BSIZE0 + OD_NBSIZES - 1.

It would be useful to be able to enter a frame number into the analyzer and have it advance to a specific frame number. If the desired frame is before the current position, the decoder should be reset and the file reopened.

Currently the analyzer always displays the luma plane (Y) and the chroma planes (U and V), we could add the following items to the View menu:

• Y plane
• U plane
• V plane

To choose which planes should be displayed.

../src/x86/sse2dct.c:296:25: warning: unused function 'unbiased_rshift32_256' [-Wunused-function]
OD_SIMD_INLINE od_m256i unbiased_rshift32_256(od_m256i a, int b) {
^
1 warning generated.
CC src/x86/src_libdaalabase_la-sse41dct.lo
CC src/x86/src_libdaalabase_la-avx2dct.lo
../src/x86/avx2dct.c:73:10: error: argument to '__builtin_ia32_permti256' must be a constant integer
return _mm256_permute2x128_si256(a, b, c);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include/avx2intrin.h:847:12: note:
expanded from macro '_mm256_permute2x128_si256'
(__m256i)__builtin_ia32_permti256(__V1, __V2, (M)); })
^ ~~~
../src/x86/avx2dct.c:73:10: error: returning 'void' from a function with incompatible result type
'od_m256i' (aka '__m256i')
return _mm256_permute2x128_si256(a, b, c);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include/avx2intrin.h:844:46: note:
expanded from macro '_mm256_permute2x128_si256'

define _mm256_permute2x128_si256(V1, V2, M) extension ({ \

                                         ^~~~~~~~~~~~~~~~~~

2 errors generated.

Thomas Davies found this. Color patches appear where they shouldn't.

The stream analyzer displays block boundaries by halving the luma channel. This does not work at all in areas where luma is low. Update the code to adapt the offset based on the current luma value so its always visible.

The bilinear filter should be toggleable via an encoder option, and have a per-frame enable/disable flag coded in the bitstream.

The stream analyzer added a number of decoder controls to daaladec.h (see https://git.xiph.org/?p=daala.git;a=blob;f=include/daala/daaladec.h;h=69b58684569e54aa6c2dff9dcd044cc7b5d41cc1;hb=HEAD#l38), but none of these are documented.

See the documentation for Theora's decoder controls at https://trac.xiph.org/browser/trunk/theora/include/theora/theoradec.h#L40 for an example of what information should be included.

Because we predict chroma from luma, we should not be including chroma at all when running comparisons between luma only techniques as changes in luma will change the cost to code chroma. Use smarter's tool for doing monochrome conversion to create a luma only test set:

https://review.xiph.org/572/

Right now you can only step through a video a frame at a time in the stream analyzer. Add support for pressing space to start and stop the video playback in real time. The frame rate is stored in the daala_info struct as timebase_numerator and timebase_denominator.

Cairo or WX's internal wrapper are options. Necessary for advanced visualization effects.

The stream analyzer currently builds with wxWidgets 3.0, but there are UI errors that need to be fixed. Once it works cleanly against 3.0, update the automake scripts so that it requires 3.0.0 to build in configure.ac.

Y4M files can support a number of chroma siting options and colorspaces (Rec. 709, Rec. 2020, etc). Signal these in the bitstream and write the correct values with the encoder when the Y4M input supplies correct information.