E9を弊社アプリで視聴しているとたまにdecode errorが発生。
発生する間隔は毎回違う。どんな環境で発生するかは不明。
原因調査
E9がまれに30数バイトの”ゴミ”データを送って来る。
その時にerrorが発生。
firmwareはV6でもV7でも発生。
B7ではこの現象は発生しない。
弊社としてはE9のfirmwareに不具合があるとの見解。
error発生時にE9からのデータを示しますので、確認をしていただき、firmware不具合であれば急ぎ修正をして下さい。
Rating
55
Native
Translation / English
- Posted at 31 Oct 2019 at 12:43
Viewing the E9 using our company's app occasionally generates a decode error.
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.
rinaka3 likes this translation
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.
Rating
50
Translation / English
- Posted at 31 Oct 2019 at 12:42
When listening to E9 with your application, sometimes, decode error happens.
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.
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の時に発生。
次に”ゴミ”データには２つのパターンがある。
フレームデータの先頭に混じって送られて来る場合
添付1を参照。
pic_0x.datが取得した各フレームデータ。xxの順に受信。
拡張子.datは便宜上付けたもので.binでも何でも構いません。
error.txtを見てください。
Pフレームのpic_01.datでerrorとなり、それに続けて
2つのPフレームがerrorとなりましたが、次のIフレーム
pic_02.datで正常に戻る。
Rating
55
Native
Translation / English
- Posted at 31 Oct 2019 at 12:52
It happens during H.264.
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.
rinaka3 likes this translation
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.
Rating
50
Translation / English
- Posted at 31 Oct 2019 at 12:42
It occurred at H.264.
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.
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.
Rating
50
Translation / English
- Posted at 31 Oct 2019 at 12:50
The phenomenon happens when it is H.264.
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.
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.
Rating
52
Translation / English
- Posted at 31 Oct 2019 at 12:51
The phenomenon caused when it was H.264.
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.
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.
Rating
50
Translation / English
- Posted at 21 Nov 2019 at 21:24
The phenomenon occurs at H.264.
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.
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の”ゴミ”が
混ざって送られて来たのが原因と考えられる。
Rating
52
Translation / English
- Posted at 31 Oct 2019 at 12:42
Experimentally, when we decoded by removing the first 38 byte of pic_01.dat which caused an error at the first time, there was non decode error at all. Thus, it can be considered a cause that needless 38byte "A dust" mixed in the beginning of original data of pic_01.dat.
![[deleted user]](https://secure.gravatar.com/avatar/695023b4efd563721d13716b1457bc73.png?d=identicon&mode=crop&r=PG&s=42)
Rating
52
Translation / English
- Posted at 31 Oct 2019 at 12:51
Experimentally, decode error couldn't be occurred if trying to decode the pic_01.dat just after eliminating the beginning of its 38byte, originally error happened.
Therefore this unnecessary garbage section at the beginning mixed with main data seems to be the reason.
Therefore this unnecessary garbage section at the beginning mixed with main data seems to be the reason.
Rating
50
Translation / English
- Posted at 31 Oct 2019 at 12:54
In experiment, the initial error, pic_01.dat's top 39byte is deleted and then to decode, decode error never occurs.
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, 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.
Rating
50
Translation / English
- Posted at 03 Dec 2019 at 21:46
Experimentally, decode error doesn’t occur in the case that you decode after removed the head 38 byte of pic_01.dat which became error at first.
Therefore, I thought the problem has occurred due to the “gavage”, the unnecessary 38byte at the head of the original data of that.
Therefore, I thought the problem has occurred due to the “gavage”, the unnecessary 38byte at the head of the original data of that.
１つのフレームデータとして送られてくる場合
pic_01.dat、pic_02.datなど5か所で34byteのフレームデータが
送られて来ており、ここで各々errorが発生。
これら34byteのフレームデータを除いてdecodeしていけば問題は
発生せず。
よって34byteの”ゴミ”フレームデータが送られてくるのが原因と考えられる。
ファイルの先頭のデータパターンが違う。ファイル先頭 38byte に続くデータが本来のデータのように見える。
error1が原因と思われる。
Rating
52
Translation / English
- Posted at 31 Oct 2019 at 12:47
When one frame data to be transmitted, the frame data at 34byte of each 5 data such as pic_01.dat, pic_02.dat and others are sent but each error has been occurred.
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.
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.
Rating
52
Translation / English
- Posted at 31 Oct 2019 at 12:46
When it is sent as 1 frame data
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.
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.
Rating
50
Translation / English
- Posted at 31 Oct 2019 at 12:47
If it is sent as one frame data, frame data of 34 byte is sent at five places such as pic_01.dat and pic_02.dat,
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.
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.
Rating
50
Translation / English
- Posted at 03 Dec 2019 at 22:43
When sent as a frame data, at the 5 place such as pic_01.dat, pic_02.dat and so on, 34 byte frame datas were sent, here occurred each error.
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.
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.
