> On Apr 6, 2023, at 11:38 PM, Firdaus.Muhammad
> wrote:
>
> After trying to understand the logic to decode the frame, finally my decoder
> can accept the rtp data simply by adding first 4 bytes of the buffer with
> 0001 data before sending or doing the merging.
> I suppose that first 4 byt
Hi Mr. Finlayson
After trying to understand the logic to decode the frame, finally my decoder
can accept the rtp data simply by adding first 4 bytes of the buffer with 0001
data before sending or doing the merging.
I suppose that first 4 bytes is where the rtp header stored, since live555
after
> On Feb 25, 2023, at 4:40 AM, Firdaus.Muhammad
> wrote:
>
> For latest HEVC stream camera, the data will look like this
> Nal Remark
> 32 VPS
> 33 SPS
> 34 PPS
> 39 Prefix
> 19 I-Frame (1/3 size)
> 19 I-Frame (1/3 size)
> 19
Hi Mr Finlayson
Sorry just found out that you've replied question, I went through live555 mail
archives trying to find some answer.
? There is no bug in the LIVE555 code. There is perhaps a bug in the custom
code that the server uses to feed NAL units from the camera to the server.
Correct,
First, when replying to a mailing list digest, please trim your message, and
correct the subject line. (This is basic email ’netiquette’; because of this,
all future emails from you to the list will be moderated.)
There is no bug in the LIVE555 code. There is perhaps a bug in the custom code
It’s hard to answer your question, because it’s not clear where your problem is
occurring. You say that you’re using the LIVE555 RTSP server software to
stream from a H.265 camera, so I presume that your server uses custom code to
capture H.265 NAL units from the camera, and feed them to the se
Hello,
I am a software engineer freelancer currently working on fixing bugs for
client's software,
this software is using live555 as a server to get a stream and restream the
packet to our client.
The live555 library works fine for the old generation of h265 Panasonic camera
stream, however, f
