Update the handling of metadata refinement

[SingingTree]

This PR improves upon the existing handling of metadata refinement in the following ways:

• Corrects issues preventing the writing of cues
• Updates handling of offsets so they are relative into segments, as per the spec
• Ensures metadata is rewritten again if the size is unstable. That is to say, that it's possible when calculating the size of the metadata and offsets for the varints storing the offsets to grow in size. requiring another calculation of the header. This could happen an arbitrary number of times based on how many offsets you have, but in practice should be rare, so the code to do so has a hard coded bound (20) and throws an error if it fails
• Updates examples to reflect the above

[legokichi]

1. You are right. I misunderstood that the offset position is from the beginning of the file. The actual offset is the position from the first child element of Segment.
2. I corrected your mistakes.

   [tag: Segment][size: -1][tag: Info][size: n][tag: TimecodeScale][size: m][data: uint]...
   |             |         |          
   + tag start   |         + data start == size end
                 |
                 + size start == tag end
   

   I am sorry that there is no document.
3. There are bugs that do not play the refined video with Firefox Nightly 55.0a1 (2017-05-05) (64bit).

before

+ EBML head at 0
|+ EBML version: 1 at 12
|+ EBML read version: 1 at 16
|+ EBML maximum ID length: 4 at 20
|+ EBML maximum size length: 8 at 24
|+ Doc type: webm at 28
|+ Doc type version: 2 at 35
|+ Doc type read version: 2 at 39
+ Segment, size unknown at 43
|+ Seek head at 55
|+ Segment information at 67
| + Timecode scale: 1000000 at 79
| + Duration: 0.000s (00:00:00.000) at 86
| + Multiplexing application: QTmuxingAppLibWebM-0.0.1 at 97
| + Writing application: QTwritingAppLibWebM-0.0.1 at 124
|+ Segment tracks at 152
| + A track at 164
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0) at 173
|  + Track UID: 377499356 at 176
|  + Codec name: VP8 at 183
|  + Track type: video at 190
|  + Codec ID: V_VP8 at 193
|  + Video track at 200
|   + Pixel width: 640 at 209
|   + Pixel height: 480 at 213
| + A track at 217
|  + Track number: 2 (track ID for mkvmerge & mkvextract: 1) at 226
|  + Track UID: 2575047970 at 229
|  + Track type: audio at 236
|  + Codec delay: 6.500ms (6500000ns) at 239
|  + Seek pre-roll: 80.000ms (80000000ns) at 246
|  + Codec ID: A_OPUS at 253
|  + CodecPrivate, length 19 at 261
|  + Codec name: OPUS at 283
|  + Audio track at 291
|   + Sampling frequency: 44100 at 300
|   + Channels: 1 at 310
|+ Cluster at 313
| + Cluster timecode: 0.000s at 325
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000) at 328
|  + Frame with size 50775
...

after

+ EBML head at 0
|+ EBML version: 1 at 5
|+ EBML read version: 1 at 9
|+ EBML maximum ID length: 4 at 13
|+ EBML maximum size length: 8 at 17
|+ Doc type: webm at 21
|+ Doc type version: 2 at 28
|+ Doc type read version: 2 at 32
+ Segment, size unknown at 36
|+ Seek head at 48
| + Seek entry at 53
|  + Seek ID: 0x1f 0x43 0xb6 0x75 (KaxCluster) at 56
|  + Seek position: 268 at 63
| + Seek entry at 68
|  + Seek ID: 0x1f 0x43 0xb6 0x75 (KaxCluster) at 71
|  + Seek position: 1217513 at 78
|+ Segment information at 84
| + Timecode scale: 1000000 at 89
| + Duration: 9.138s (00:00:09.138) at 96
| + Multiplexing application: QTmuxingAppLibWebM-0.0.1 at 107
| + Writing application: QTwritingAppLibWebM-0.0.1 at 134
|+ Segment tracks at 162
| + A track at 167
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0) at 169
|  + Track UID: 377499356 at 172
|  + Codec name: VP8 at 179
|  + Track type: video at 186
|  + Codec ID: V_VP8 at 189
|  + Video track at 196
|   + Pixel width: 640 at 198
|   + Pixel height: 480 at 202
| + A track at 206
|  + Track number: 2 (track ID for mkvmerge & mkvextract: 1) at 208
|  + Track UID: 2575047970 at 211
|  + Track type: audio at 218
|  + Codec delay: 6.500ms (6500000ns) at 221
|  + Seek pre-roll: 80.000ms (80000000ns) at 228
|  + Codec ID: A_OPUS at 235
|  + CodecPrivate, length 19 at 243
|  + Codec name: OPUS at 265
|  + Audio track at 273
|   + Sampling frequency: 44100 at 275
|   + Channels: 1 at 285
|+ Cues at 288
| + Cue point at 293
|  + Cue time: 0.000s at 295
|  + Cue track positions at 298
|   + Cue track: 1 at 300
|   + Cue cluster position: 268 at 303
| + Cue point at 307
|  + Cue time: 5.202s at 309
|  + Cue track positions at 313
|   + Cue track: 1 at 315
|   + Cue cluster position: 1217513 at 318
|+ Cluster at 323
| + Cluster timecode: 0.000s at 335
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000) at 338
|  + Frame with size 50775
...

The EBMLVersion tag of firefox is in the 12th byte, but when it encodes it comes to the 5th byte. This is because firefox does not use a variable int of the optimal size for the data size of the EBML tag.

I am currently correcting this problem, but I will merge for the moment.

[legokichi]

fix the problem: cd7e188

[SingingTree]

I see there's been a large rework in another commit, but to clarify the above:

For 2. I think dataStart is returning in incorrect values (in my testing it was doing so), which is why I used the alternative calculation.

I'm not sure I follow the issues in 3. The produced file appears to have incorrect seekhead and cue offsets. I think this is because of the changes in 0986b52 (the dataStart issue). Firefox fails to play because of the incorrect seek data.

[legokichi]

Try this sample: https://jsfiddle.net/ub2jej7c/

I checked on Firefox Nightly 55.0a1 (2017-05-08) (64 bit)
If you can not loop play video recorded with firefox, I think it is a firefox bug...
Please copy the video URL and play it on a new tab.

[SingingTree]

Agreed that this is a Firefox bug, and don't think it's to do with the rewriting we're doing here. I had thought this was a FF regression, but am unable to find a time that it worked. I will raise an issue on the Firefox side. Thanks for pointing it out.

[legokichi]

Thank you your pull request 😄