2 TLS record layers in the same packet

TCP is a byte-stream protocol. Data that an upper layer (such as but not limited to TLS) provides as a single unit may be sent as (multiple segments using) multiple packets, and multiple data units from the upper layer may be sent in one segment/packet. That is why the TLS record-layer header contains a count of the bytes in the record (after the fixed-length 5-byte header), so the receiver knows where one record ends, and whether more data must be read to complete a record, or more data constituting another record is already available.

If you capture and look at the (full) handshake that set up this session you'll probably see the other case; as BillThor mentioned TLS servers usually use a certificate chain consisting of multiple certificates -- although an IoT device like a camera may be an exception and might pin a private or intermediate CA rather than using a publicly-trusted cert -- and each certificate is usually about 1k or more, so the full chain, plus a little for the rest of the server first flight like ServerKX and CertReq, is very often more than the PMTU, and so must be sent as multiple packets. In this case Wireshark will show you one or more packets as [TCP segment of reassembled PDU] followed by a packet which in addition to its own data will display and decode the combined (reassembled) data from the group of packets.

Many other protocols and applications built on TCP must solve the same problem, and use a variety of methods. Some use counts. Some use delimiters, such as SMTP transferring the content of an email, which may be gigabytes and take many packets, until a line (delimited by CRLF) consisting solely of a period (.). Some use both: HTTP/1.1 can send multiple requests and responses over one connection; each header block is text in 822-like format after the first line and is delimited by an empty line (two CRLF consecutive) while the body (when present) is normally specified either by a Content-length header in the header block, or a series of chunk headers spread through the data each containing a count of part of the data. Of course some applications, like the venerable TELNET, just transfer a series of bytes and don't provide meaningful records at all.

Note TLS (and SSL before it) is similarly defined as a stream protocol, to provide a substitute transport so that applications or protocols designed to work over TCP, like HTTP, can work over SSL-now-TLS and get security with no or very little change. Although TLS does transmit data in the form of Application Data records internally, which have a maximum size of 2^14 (16384) bytes, there is no requirement that a block of data provided by the sender becomes one TLS data record or one TLS data record is delivered as one block of data to the receiver.

In your case, the connection is using TLS1.0. You don't show or describe the handshake that established it, but I'm guessing it isn't using RC4 (or more exactly, a ciphersuite that includes RC4) which has been greatly weakened by attacks and is now generally prohibited from all use including TLS. So it must be using some CBC ciphersuite (in SSL3 through TLS1.1 those were the only alternatives) and I guess again it's an AES-CBC ciphersuite. TLS1.0 (and SSL3) was subject to a chosen-plaintext attack called BEAST which caused most TLS1.0 implementations to do '1/n splitting' (aka fragmenting) -- when the sender provides a block of data (more than 1 byte), the TLS stack actually sends only the first byte of data as one Application Data record (which for an AES-CBC suite with HMAC-SHA1, gets HMACed, padded and encrypted to a 32-byte record) and the remaining data (in your case is at most 27 bytes) as another Application Data record (or several depending on length). Since the TLS stack has both of these records ready to send at the same time, and they both fit (easily) in one TCP segment, they probably get sent as one segment=packet -- but they don't have to. Of course a simpler fix for BEAST is to just prohibit TLS1.0 entirely, and 8 years after BEAST, with TLS1.3 now published and being deployed, many do.

Neardupes on other stacks:
https://crypto.stackexchange.com/questions/41709/weird-size-of-data-transmitted-in-sslv3
https://crypto.stackexchange.com/questions/14349/do-both-client-and-server-need-to-implement-openssl-protections-to-protect-from
https://stackoverflow.com/questions/33357924/mysterious-byte-after-tls-package
https://stackoverflow.com/questions/13528021/java-ssl-streaming-splitted-applicationdata/
https://stackoverflow.com/questions/15224909/jsse-wrap-creates-two-tls-packets-requiring-two-unwraps-why/