You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sending a large file with thousands of blocks, it doesn't make sense to have the slim possibility of generating data with hundreds or thousands of indices. The generated QR code data is Base64, so every index (four bytes) adds 5.333 characters to the output for the QR code. With the default slice of 1000, adding 250 indices to the payload will double the amount of data to be encoded into a QR code. These problematic frames will fail to encode when they are too large.
I propose a limit to the number of indices per encoded chunk. This would free up bits in the first byte, potentially allowing completion of #13 without increasing the encoded data size.
The text was updated successfully, but these errors were encountered:
When sending a large file with thousands of blocks, it doesn't make sense to have the slim possibility of generating data with hundreds or thousands of indices. The generated QR code data is Base64, so every index (four bytes) adds 5.333 characters to the output for the QR code. With the default slice of 1000, adding 250 indices to the payload will double the amount of data to be encoded into a QR code. These problematic frames will fail to encode when they are too large.
I propose a limit to the number of indices per encoded chunk. This would free up bits in the first byte, potentially allowing completion of #13 without increasing the encoded data size.
The text was updated successfully, but these errors were encountered: