E9を弊社アプリで視聴しているとたまにdecode errorが発生。
発生する間隔は毎回違う。どんな環境で発生するかは不明。
原因調査
E9がまれに30数バイトの”ゴミ”データを送って来る。
その時にerrorが発生。
firmwareはV6でもV7でも発生。
B7ではこの現象は発生しない。
弊社としてはE9のfirmwareに不具合があるとの見解。
error発生時にE9からのデータを示しますので、確認をしていただき、firmware不具合であれば急ぎ修正をして下さい。
The moment the error is generated is different everyday.
It's unclear what kind of environment generates the error.
Investigation of the cause
In rare instances, E9 is sent as a 30-byte "garbage" data.
The error is generated during that time.
It happens even when the firmware is V6 or V7.
It doesn't happen when it's B7.
Our company's opinion is that there is a bug in the E9 firmware.
Data is displayed from the E9 when there is an error so please check and if there is a bug in the firmware please fix it right away.
Each time it is different in duration. I cannot see what makes it happen.
Investigate the reason
E9 sends rarely "rubbish" data with 30 figure bite.
Then, error comes out.
It occurs at firmware V6 and V7.
At B7 it does not happen.
As for our firm, we consider there is a problem at E9 firmware.
When error occurs, it shows data from E9, I would you to check it and if the firmware is for this problem, please correct it right away.
現象はH.264の時に発生。
次に”ゴミ”データには2つのパターンがある。
フレームデータの先頭に混じって送られて来る場合
添付1を参照。
pic_0x.datが取得した各フレームデータ。xxの順に受信。
拡張子.datは便宜上付けたもので.binでも何でも構いません。
error.txtを見てください。
Pフレームのpic_01.datでerrorとなり、それに続けて
2つのPフレームがerrorとなりましたが、次のIフレーム
pic_02.datで正常に戻る。
Next, there are 2 patterns to the "garbage" data.
If it is sent mixed with the header of the frame data.
See attachment 1 for your reference.
Each frame data has acquired pic_0x.dat. Transmitted in xx sequence.
I have attached the .dat filename extension for convenience so it doesn't matter if it's .bin.
Please take a look at error.txt
It becomes an error in the P frame pic_01.dat. Then 2 Pframes have errors. Then it returns to normal with the I frame pic_02.dat.
Next, there are two patterns at "domi"(garbage) data.
In case where it is sent mixed in top of frame data, refer to attachment 1.
Each frame data pic_Ox.dat obtained obtained. Receive by the order of xx.
Extension. dat was attached for convenience, and bin and others are fine.
Please see error.txt.
The error occurred at pic_01.dat of P frame, and error continued at two P frames.
But it returned to normal at I frame pic_02.dat that is the next.
Then, "rubbish" data has two patterns.
When sent at the beginning of flame data combined
Please see the attached 1.
Each flame data obtained by pic_0x.dat. Receive from xx in order.
The extension dat is put for expedience, and so bin will do for it too.
Please see error.txt.
With P flame pic_01.dat, it comes error and after that two P flame become error, but the next I flame pic_02.dat becomes normal.
Next, "Dust" data has 2 patterns.
When it sent mixed with the beginning of frame data
Please refer to the attached 1.
Each frame data pic_0x.dat obtained. Received in order of xx.
Extension.dat was attached just for convenience, it can be changed to bin or etc.
Please refer to error.txt.
It caused an error at pic_01.dat of P frame, and followed to it, 2 kinds of P frame caused errors, but it returns to normal at pic_02.dat of next I frame.
And there 2 patterns of “gavage” data.
In case that it is send containing in the head of the frame data, refer the attachment 1.
Each of the frame data acquired by pic_0x.dat. Receive in xx order.
As the extension .dat was attached for convenience, the extension bin is also OK.
Please look at error.txt.
It becomes error in pic_01.dat of the P frame, then 2 P frame becomes error, but in the next I fame, pic_02.dat, it returns nomal.
実験的に、最初にerrorとなったpic_01.datの先頭38byteを
取り除いてからdecodeするとdecode errorはどれも発生せず。
よってpic_01.datの本来のデータの先頭に不要な38byteの”ゴミ”が
混ざって送られて来たのが原因と考えられる。
Therefore this unnecessary garbage section at the beginning mixed with main data seems to be the reason.
Therefore, at the top of the original pic_01.dat data, there might be unnecessary 38byte "rubbish" is included and sent, it seems to be the reason.
Therefore, I thought the problem has occurred due to the “gavage”, the unnecessary 38byte at the head of the original data of that.
1つのフレームデータとして送られてくる場合
pic_01.dat、pic_02.datなど5か所で34byteのフレームデータが
送られて来ており、ここで各々errorが発生。
これら34byteのフレームデータを除いてdecodeしていけば問題は
発生せず。
よって34byteの”ゴミ”フレームデータが送られてくるのが原因と考えられる。
ファイルの先頭のデータパターンが違う。ファイル先頭 38byte に続くデータが本来のデータのように見える。
error1が原因と思われる。
If eliminating frame data at 34byte to be decorded, it will be no problem.
For this reason, the problem was because of this garbage data at 34byte it seems.
The header of the file in data pattern is different. After the header of the file at 38byte, it seems to be the data desired. Error1 it believed to be the cause.
34byte frame data was sent at 5 points, such as pic_01.dat, pic_02.dat, etc., and there was an error at each point.
When we decoded by removing 34 frame data, there was no problem with it.
Thus, it can be considered a cause that 34byte frame data with "a dust" was sent.
The data patterns of the beginning of the file differs. The data continues to 38byte of the beginning of the file seems to be original data. It can considered a cause to be error1.
and each error occurs here.
A problem does not occur if they are decoded except for these frame data of 34 byte.
Therefore, we can think that the cause is "gomi (garbage)" frame data of 34 byte is sent.
Data pattern at top of the file is different. It appears that the data continuing the 38 byte at top of the file is the original data.
The error 1 must be its cause.
If we decode except for those 34 byte data, the problem never occur.
Thus, it can be considered a cause that 34 byte “A dust” frame data sent.
The data pattern at the beginning of the file is different. The data following the beginning 38 byte of the file seems the original data.
It is considered a cause that error 1.