Can anyone tell me or point me to a section of the specification(s) that clearly demonstrates how from an elementary stream with a series of NALUs how these should be written into a ISO BMFF mdat?
I can see looking at samples and other code that I should have something like: AUD, SPS, PPS, SEI, VideoSlice, AUD etc etc
Things that are not entirely clear to me:
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
What is the requirement for AUDs?
If I am generating sample sizes for the trun is the calcuation for this? In the example I am working to recreate the first sample in the trun has a size of 22817 however if I look at the first sample in the mdat the NALU size prefix is 22678. The value in the trun appears to be the size of all the NALUs + sizes up to and including the first sample (see my example below)
>
1 0016E405 (1500165) - box.Size
2 6D646174 (mdat) - box.Type
3 00000002 (2) NAL Size
4 0910 - (2) AUD # 5187
5 00000025 (37)
6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
7 00000004 (4)
8 28DEBCB0 (4) PPS
9 0000000B (11)
10 06000781 36288029 67C080 (? SEI ?)
11 0000000C (12)
12 06010700 00F00000 03020480 (? SEI is type 6)
13 0000002D (45) # 5269
14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
15 00005896 (22678)
16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
No
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
Yes, if you choose to include them, but there is no reason to
What is the requirement for AUDs?
They are optional
If I am generating sample sizes for the trun is the calcuation for this?
The number of bytes in the access unit (AU, aka frame). Which may contain more than one NALU. SPS/PPS/SEI/AUD all counted toward the AU size. The 4 byte size prefixed to each NALUs is also counted in the AU size recored in the trun.
bytes
4 | 3 00000002 (2) NAL Size
2 | 4 0910 - (2) AUD # 5187
4 | 5 00000025 (37)
37 | 6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
4 | 7 00000004 (4)
4 | 8 28DEBCB0 (4) PPS
4 | 9 0000000B (11)
11 | 10 06000781 36288029 67C080 (? SEI ?)
4 | 11 0000000C (12)
12 | 12 06010700 00F00000 03020480 (? SEI is type 6)
4 | 13 0000002D (45) # 5269
45 | 14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
4 | 15 00005896 (22678)
22678 | 16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
------|
22817 | <- bytes total
Related
I have a dataset of measurements of "Y" at different locations, and I am trying to determine how variable Y is influenced by variables A, B, and D by running a lmer() model and analyzing the results. However, when I reach the post hoc step, I receive an error when trying to analyze.
Here is an example of my data:
table <- " ID location A B C D Y
1 1 AA 0 0.6181587 -29.67 14.14 168.041
2 2 AA 1 0.5816176 -29.42 14.21 200.991
3 3 AA 2 0.4289670 -28.57 13.55 200.343
4 4 AA 3 0.4158891 -28.59 12.68 215.638
5 5 AA 4 0.3172721 -28.74 12.28 173.299
6 6 AA 5 0.1540603 -27.86 14.01 104.246
7 7 AA 6 0.1219355 -27.18 14.43 128.141
8 8 AA 7 0.1016643 -26.86 13.75 179.330
9 9 BB 0 0.6831649 -28.93 17.03 210.066
10 10 BB 1 0.6796935 -28.54 18.31 280.249
11 11 BB 2 0.5497743 -27.88 17.33 134.023
12 12 BB 3 0.3631052 -27.48 16.79 142.383
13 13 BB 4 0.3875498 -26.98 17.81 136.647
14 14 BB 5 0.3883785 -26.71 17.56 142.179
15 15 BB 6 0.4058061 -26.72 17.71 109.826
16 16 CC 0 0.8647298 -28.53 11.93 220.464
17 17 CC 1 0.8664036 -28.39 11.59 326.868
18 18 CC 2 0.7480748 -27.61 11.75 322.745
19 19 CC 3 0.5959143 -26.81 13.27 170.064
20 20 CC 4 0.4849077 -26.77 14.68 118.092
21 21 CC 5 0.3584687 -26.65 15.65 95.512
22 22 CC 6 0.3018285 -26.33 16.11 71.717
23 23 CC 7 0.2629121 -26.39 16.16 60.052
24 24 DD 0 0.8673077 -27.93 12.09 234.244
25 25 DD 1 0.8226558 -27.96 12.13 244.903
26 26 DD 2 0.7826429 -27.44 12.38 252.485
27 27 DD 3 0.6620447 -27.23 13.84 150.886
28 28 DD 4 0.4453213 -27.03 15.73 102.787
29 29 DD 5 0.3720257 -27.13 16.27 109.201
30 30 DD 6 0.6040217 -27.79 16.41 101.509
31 31 EE 0 0.8770987 -28.62 12.72 239.036
32 32 EE 1 0.8504547 -28.47 12.92 220.600
33 33 EE 2 0.8329484 -28.45 12.94 174.979
34 34 EE 3 0.8181102 -28.37 13.17 138.412
35 35 EE 4 0.7942685 -28.32 13.69 121.330
36 36 EE 5 0.7319724 -28.22 14.62 111.851
37 37 EE 6 0.7014828 -28.24 15.04 110.447
38 38 EE 7 0.7286984 -28.15 15.18 121.831"
#Create a dataframe with the above table
df <- read.table(text=table, header = TRUE)
df
# Make sure location is a factor
df$location<-as.factor(df$location)
Here is my model:
# Load libraries
library(ggplot2)
library(pscl)
library(lmtest)
library(lme4)
library(car)
mod = lmer(Y ~ A * B * poly(D, 2) * (1|location), data = df)
summary(mod)
plot(mod)
I now need to determine what variables significantly influence Y. Thus I ran Anova() from the package car (output pasted here).
Anova(mod)
# Analysis of Deviance Table (Type II Wald chisquare tests)
#
# Response: Y
# Chisq Df Pr(>Chisq)
# A 8.2754 1 0.004019 **
# B 0.0053 1 0.941974
# poly(D, 2) 40.4618 2 1.636e-09 ***
# A:B 0.1709 1 0.679348
# A:poly(D, 2) 1.6460 2 0.439117
# B:poly(D, 2) 5.2601 2 0.072076 .
# A:B:poly(D, 2) 0.6372 2 0.727175
# Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
This suggests that:
A significantly influences Y
B does not significantly influence Y
D significantly influences Y
So next I would run a post hoc test for each of these variables, but this is where I run into issues. I have tried using both emmeans and multcomp packages below:
library(emmeans)
emmeans(mod, list(pairwise ~ A), adjust = "tukey")
# NOTE: Results may be misleading due to involvement in interactions
# Error in if ((misc$estType == "pairs") && (paste(c("", by), collapse = ",") != :
# missing value where TRUE/FALSE needed
pairs(emmeans(mod, "A"))
# NOTE: Results may be misleading due to involvement in interactions
# Error in if ((misc$estType == "pairs") && (paste(c("", by), collapse = ",") != :
# missing value where TRUE/FALSE needed
library(multcomp)
summary(glht(mod, linfct = mcp(A = "Tukey")), test = adjusted("fdr"))
# Error in h(simpleError(msg, call)) :
# error in evaluating the argument 'object' in selecting a method for function 'summary': Variable(s) ‘depth’ of class ‘integer’ is/are not contained as a factor in ‘model’.
This is the first time I've run an ANOVA/post hoc test on a lmer() model, and though I've read a few introductory sites for this model, I'm not sure I am testing it correctly. Any help would be appreciated.
If I am looking at the data correctly, A is the variable that has values of 0, 1, ..., 7. Now look at your anova table, where you see that A has only 1 d.f., not 7 as it should for a factor having 8 levels. That means your model is taking A to be a numerical predictor -- which is rather meaningless. Make A into a factor and re-fit he model. You'll have better luck.
I also think you meant to have + (1|location) at the end of the model formula, rather than having the random effects interacting with some of the polynomial effects.
I am trying to convert an integer to 3 bytes to send via the SPI protocol to control a MAX6921 serial chip. I am using spi.xfer2() but cannot get it to work as expected.
In my code, I can call spi.xfer2([0b00000000, 0b11101100, 0b10000000]) it displays the letter "H" on my display, but when I try and convert the int value for this 79616, it doesn't give the correct output:
val = 79616
spi.xfer2(val.to_bytes(3, 'little'))
My full code so far is on GitHub, and for comparison, this is my working code for Arduino.
More details
I have an IV-18 VFD tube driver module, which came with some example code for an ESP32 board. The driver module has a 20 output MAX6921 serial chip to drive the vacuum tube.
To sent "H" to the second grid position (as the first grid only displays a dot or a dash) the bits are sent to MAX6921 in order OUT19 --> OUT0, so using the LSB in my table below. The letter "H" has an int value 79616
I can successfully send this, manually, via SPI using:
spi.xfer2([0b00000000, 0b11101100, 0b10000000])
The problem I have is trying to convert other letters in a string to the correct bits. I can retrieve the integer value for any character (0-9, A-Z) in a string, but can't then work out how to convert it to the right format for spi.xfer() / spi.xfer2()
My Code
def display_write(val):
spi.xfer2(val.to_bytes(3, 'little'))
# Loops over the grid positions
def update_display():
global grid_index
val = grids[grid_index] | char_to_code(message[grid_index:grid_index+1])
display_write(val)
grid_index += 1
if (grid_index >= 9):
grid_index = 0
The full source for my code so far is on GitHub
Map for MAX6921 Data out pins to the IV-18 tube pins:
BIT
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
IV-18
G9
G8
G7
G6
G5
G4
G3
G2
G1
A
B
C
D
E
F
G
DP
MAX6921
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
IV-18 Pinout diagram
I have some question related the RISC V manual
It has different types of instruction encoding such as R-type,I-type.
Just like the MIPS encoding.
* R-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| funct7 | rs2 | rs1 |funct3| rd | opcode |
+------------+---------+---------+------+---------+-------------+
* I-type
31 20 19 15 14 12 11 7 6 0
+----------------------+---------+------+---------+-------------+
| imm | rs1 |funct3| rd | opcode |
+----------------------+---------+------+---------+-------------+
* S-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| imm | rs2 | rs1 |funct3| imm | opcode |
+------------+---------+---------+------+---------+-------------+
* U-type
31 11 7 6 0
+---------------------------------------+---------+-------------+
| imm | rd | opcode |
+---------------------------------------+---------+-------------+
But it also have something called immediate format:
such as I-immediate, S-immediate and so on
* I-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 24:21 |20|
+-----------------------------------------+-----------+-------+--+
* S-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 11:8 |7 |
+-----------------------------------------+-----------+-------+--+
* B-immediate
31 12 11 10 5 4 1 0
+--------------------------------------+--+-----------+-------+--+
| <-- 31 |7 | 30:25 | 11:8 |z |
+--------------------------------------+--+-----------+-------+--+
* U-immediate
31 30 20 19 12 11 0
+--+-------------------+---------------+-------------------------+
|31| 30:20 | 19:12 | <-- z |
+--+-------------------+---------------+-------------------------+
* J-immediate
31 20 19 12 11 10 5 4 1 0
+----------------------+---------------+--+-----------+-------+--+
| <-- 31 | 19:12 |20| 30:25 | 24:21 |z |
+----------------------+---------------+--+-----------+-------+--+
According to the manual, it say those immediate is produced by RISC-V instruction but how are the things related?
What is the point to have immediate format?
The 2nd set of diagrams is showing you how the immediate bits are concatenated and sign-extended into a 32-bit integer (so they can work as a source operand for normal 32-bit ALU instructions like addi which need both their inputs to be the same size).
For I-type instructions it's trivial, just arithmetic right-shift the instruction word by 20 bits, because there's only one immediate field, and it's contiguous at the top of the instruction word.
For S-type immediate instructions, there are two separate fields in the instruction word: [31:25] and [11:7], and this shows you that they're in that order, not [11:7, 31:25] and not with any implicit zeros between them.
B-type immediate instructions apparently put bit 7 in front of [30:25], and the low bit is an implicit zero. (So the resulting number is always even). I assume B-type is for branches.
U-type is also interesting, padding the 20-bit immediate with trailing zeros. It's used for lui to create the upper bits of 32-bit constants (with addi supplying the rest). It's not a coincidence that U-type and I-type together have 32 total immediate bits.
To access static data, lui can create the high part of an address while lw can supply the low part directly, instead of using an addi to create the full address in a register. This is typical for RISC ISAs like MIPS and PowerPC as well (see an example on the Godbolt compiler explorer). But unlike most other RISC ISAs, RISC-V has auipc which adds the U-type immediate to the program counter, for efficient PIC without having to load addresses from a GOT (global offset table). (A recent MIPS revision also added an add-to-PC instruction, but for a long time MIPS was quite bad at PIC).
lui can encode any 4k-aligned address, i.e. a page-start address with 4k pages.
need some help to understand how DEFLATE Encoding works. I know that is a combination of the LZSS algorithm and Huffman coding.
So let encode for example "Deflate late". Params: [Search buffer: 8kb and Look-ahead buffer 4kb] Well, the output of LZSS algorithm is "Deflate <5, 4>" The next step uses static huffman coding to reduce the redundancy. Here is my problem, I dont know how should i encode this pair <5, 4> with huffman.
[Edited]
D 000
f 001
l 010
a 011
t 100
_ 101
e 11
So well, according to this table the string "Deflate " is written as 000 11 001 010 011 100 11 101. As a next step lets encode the pair (5, 4). The fixed prefix code of the length 4 according to the book "Data Compression - The Complete Reference" is 258, followed by fixed prefix code of the distance 5 (Code 4 + 1 Extra bit).
That can be summarized as:
length 4 -> 258 -> 0000010
distance 5 -> 4 + 1 extra bit -> 00100|0
So, the encoded string is written as [header: 1 01] 000 11 001 010 011 100 11 101 0000010 001000 [end-of-block: 0000000], BUT if i create a huffman tree, it is not a static huffman anymore, right?
Good day
D 000
f 001
l 010
a 011
t 100
_ 101
e 11
is not the Deflate static code. The static literal/length codes are all 7, 8, or 9 bits, and the distance codes are all 5 bits. You asked about the static codes.
'Deflate late' encoded in static deflate format as the literals 'Deflate ' and a length 4, distance 5 match in hex is:
73 49 4d cb 49 2c 49 55 00 11 00
That is broken down as follows (bits are read from the least significant part of each byte first):
011 - 01 means fixed code, 1 means last block
00101110 - D
10101001 - e
01101001 - f
00111001 - l
10001001 - a
00100101 - t
10101001 - e
00001010 - space
0100000 - length 4
00100 - distance 5 or 6 depending on one extra bit
0 - extra bit -> distance 5
0000000 - end code
0 - fill bit to byte boundary
The . operator in the simplest form is used to index a list. How would you explain its use in english in this code?
if[x~"last";upd:{[t;x].[t;();,;r::select by sym from x]}]
I also don't understand the empty list and the :: operator in this line, but maybe they will make sense once the . is cleared up.
In plain english I would explain it as:
modify the table t at all () indices by applying the append/comma function with the value r.
First consider a few simpler cases of #:
q)l:3 5 7 9
q)l:1.1 2.2 3.3
q)#[l; 0 2; +; 10]
11.1 2.2 13.3
q)d:`p`o`i!4.4 5.5 6.6
q)#[d; `p`i; -; 10]
p| -5.6
o| 5.5
i| -3.4
As you can see the format is
#[dataStructure; indices; function; y-arg]
means to the dataStructure at indices apply the function with the given y-arguments. Notice for the list l the indices 0 2 meant index both 0 and 2 at the topmost level. There's no way using # to index at depth. e.g. given matrix m:(1 2 3; 4 5 6; 7 8 9) how can we use this format to modify just the values 4 and 6?
q)/ # indexes repeatedly at topmost level
q)/ definitely not what we want
q)#[m;(1;0 2);+;100]
101 102 103
104 105 106
107 108 109
q)/ **. indexes into the data structure**
q).[m;1 2;+;100]
1 2 3
4 5 106
7 8 9
q).[m;(1;0 2);+;100]
1 2 3
104 5 106
7 8 9
Lastly the empty list () is a short way of saying, apply to all indices:
q).[m;();+;100]
101 102 103
104 105 106
107 108 109
. In this case means apply , to t and r. r is global updated on each call and contains last values recieved by sym. :: is assignment to global in most cases.
code.kx.com describe . function in great details