notes.txt

   1 Creating a playable file with dirac_encoder:
   2 dirac_encoder -width 320 -height 240 -cformat YUV422P \
   3               -iwlt_filter LEGALL5_3 -num_L1 0 -lossless \
   4               -use_vlc -wlt_depth 4 <in> <out>
   5
   6
   7 Creating a playable file with schroenc:
   8 gst-launch videotestsrc ! schroenc intra_wavelet=1 \
   9             enable_noarith=true transform_depth=4  \
  10             gop_structure=1 rate_control=3 ! \
  11              filesink location=test.drc
  12
  13 Actually -wlt_depth is arbitrary, because the decoder does
  14 just as fine with higher dephts.
  15
  16 Hypotheses for the spatial partitioning error:
  17 * Incorrect partition size calculation (likely!)
  18 * Incorrect quantization calculation
  19
  20 Note that error does not display when encoded with schroenc.
  21 My hypothesis is that schroenc partitions the image differently from
  22 dirac_encoder. That suggests that partition size calculation is
  23 (still) wrong.
  24
  25 On the implementing of a Dirac plugin for jst:
  26 Basically, you have to create to pads, a Sink and a Src,
  27 both subclasses of Pad(), to do the actual work of the plugin.
  28 Then, as dirac is supposed to be muxed by Ogg, implement the
  29 OggPayload interface, which is basically an interface to the
  30 OggDemux plugin.
  31
  32 The plan for subband decoding:
  33 Subbands should decode into a large short[] array which can
  34 be transformed into the final output picture.
  35
  36 Spatial partitioning:
  37 Currently, the bounds of the block in which to decode are precalculated,
  38 and then the block is filled with values from decodeSint() according to
  39 the striding logic. I'm pretty confident the striding logic works; I'm
  40 not so confident the precalculating logic works.
  41
  42 As for colour: visual inspection suggests that the colour bands
  43 are decoded incorrectly even in the no-spatial-partitioning case.
  44
  45 Colour conversion should be much faster. This is probably doable
  46 by changing to integer arithmetic and by not using temporary arrays
  47 (or matrix multiplication).
  48
  49 On cortado again:
  50 I've added SchroDec() to the list of plugins in OggDemux, and
  51 implemented isType(Packet) so cortado should recognize ogg dirac
  52 streams. I'm not sure that will be quite enough because the cortado
  53 player seems to be hardwired on vorbis/theora.
  54
  55
  56 <ds> one thing that might not be clear from the SchroMotion code -- after the stream is parsed, all motion rendering is done at the block level
  57  yes, mv-precision=0
  58 <brrt> ok
  59 <ds> also look at motion-block-size and motion-block-overlap
  60  size: 0,1,2,3 is default,small,medium,large
  61  overlap: 0,1,2,3 is default,none,about half, and full
  62  "medium" translates into 8x8 for SD, 12x12 for HD720, etc.
  63
  64
  65 The current queue's pop() method does not preserve coded order.
  66 This could trigger a bug in which reference pictures are not added
  67 to the reference queue before pictures are loaded. That's why I'm going to
  68 rewrite the queue. (this has been done in the other branch queue).
  69
  70 <<<<<<< HEAD:java/notes.txt
  71
  72 =======
  73 >>>>>>> mc-alt:java/notes.txt
  74 The added dynamic range from the obmc is (hopefully) correctly shifted
  75 out now. Artefacts remain on the image.
  76 The `strange 5 bits shiftout' is explained by the fact that getPixel()
  77 rounded too agressively by using the weight as the shift value, instead
  78 of the weight bits. So that is explained and resolved.
  79
  80 I suspect that there is a similar error in the handling of chroma components
  81 which causes the `stripes' effect. Unfortunately I do not now where.
  82
  83 The blockyness of the image suggests one of four things
  84 1 The prediction of vectors is wrong
  85 2 The decoding (i.e. reading from buffers) of vectors is wrong
  86 3 The applying of vectors is wrong.
  87 4 It is something I don't know yet.
  88
  89 For step 1 and 2 it is unlikely to be either of these because I copied them
  90 nearly verbatim from the schroedinger codebase. Step 3 could well be,
  91 step 4 would be a bit annoying but then again it could be true.
  92
  93 Now for something slightly different, it seems that 320x180 streams
  94 with MC are decoding at somewhat-near-realtime. Which is good, except
  95 for the fact that MC doesn't all work yet.
  96
  97 About cortado: I should probably fix the decoder to handle more
  98 advanced things, like skipping pictures if they are too late. I'm
  99 wondering if I can convince SchroDec to do this since I would hate
 100 having synchronisation logic in the Decoder class. (I probaly can by
 101 adding a skip() method to the decoder).
 102 <<<<<<< HEAD:java/notes.txt
 103
 104 I started on lowdelay decoding in a branch called slice but I can't convince
 105 either dirac_encoder or schroenc to actually make a lowdelay syntax stream,
 106 so that work has stalled.
 107 =======
 108 >>>>>>> mc-alt:java/notes.txt