Skip to content

Instantly share code, notes, and snippets.

View ericxtang's full-sized avatar

Eric Tang ericxtang

View GitHub Profile
0x374FD5E2a44CAEAcbf8DbBCd8e008D96d348ce5A
Verifying my Blockstack ID is secured with the address 14LeCBeZNatX1bBbQp4QnhCUzL1iAzVnU2 https://explorer.blockstack.org/address/14LeCBeZNatX1bBbQp4QnhCUzL1iAzVnU2
0xdf693d171d235f6a039df1ea59471c6bd568bd7c
0xCc2422601E5E386549970f7c89BFE8C770eC60a6
0x4bFFB75Dca86B1977206F892a1a6D22a797720BB
0xdfe2f802b0624630915dd22ab38e5f60188893e8
0x3418A77F1ace536dC9d54B05be8d71C883cdDbEC
0xcc2422601e5e386549970f7c89bfe8c770ec60a6
```
Watching for events...
Received verify request # 0
{ address: '0x10512991178cbb574f9a1109a7db33d8075750ad',
blockNumber: 6286,
transactionHash: '0xb5cabeb40cb87cf28fa57025003e7c0f1f5e96c18cad3cc96ea961c539f4bf53',
transactionIndex: 0,
blockHash: '0xae72a7dbbb4422cdf05126c46d9336ca9c257978ca23be6c102778c602b4fb17',
logIndex: 0,
removed: false,

Q: Eric made the comment that it's a negative that the current ffmpeg integration wastes disk space by writing segments to disk. I wanted to open a conversation about this.

  • Is it really a negative? Do we need segments to be temporarily remembered prior to the claim/verify loop in our protocol because we need to provide evidence of them later in the verify() transaction? I suppose we could instead just write metadata to disk, such as the hashes/signature that encompass the transcode receipt https://github.com/livepeer/wiki/blob/a117e9590efe4e7c9d986b2579c5ca02b11c54da/SPEC.md#transcode-receipt
  • Also, we have the out of memory issue on the livepeer node because we're currently storing references to the data segments themselves within data structures, and never freeing these references. livepeer/go-livepeer#227. Should we instead be just storing references to the segments in memory, and writing the segments to disk? Or use some sliding buffer which caches a few segments in memory fo