Description
When I made the optimizations in https://github.com/moonlight-stream/moonlight-common-c/commit/f395d3056a6ca1ac4cfd632ffde8588918bc91f8 I didn't realize that there were downstream users relying on the way moonlight-common-c was allocating buffers. Before this change, we would always allocate a LENTRY that had the data appended to it. After the change, the LENTRY is stored inside moonlight-common-c's packet buffer and it has internal bookkeeping data that is not safe to copy or modify.
When the Pi decoder queues a new LENTRY itself, it corrupts the state of the buffer chain which causes moonlight-common-c to crash when trying to access internal fields of the LENTRY in order to free it.
The effect of this bug is that Moonlight Embedded 2.4.8 segfaults immediately on the first frame of video on the Pi :(
I also included a fix for an unintended assignment of initial_width in the SPS processing code.
Purpose
Make Moonlight Embedded work on the Pi again
Description When I made the optimizations in https://github.com/moonlight-stream/moonlight-common-c/commit/f395d3056a6ca1ac4cfd632ffde8588918bc91f8 I didn't realize that there were downstream users relying on the way moonlight-common-c was allocating buffers. Before this change, we would always allocate a LENTRY that had the data appended to it. After the change, the LENTRY is stored inside moonlight-common-c's packet buffer and it has internal bookkeeping data that is not safe to copy or modify.
When the Pi decoder queues a new LENTRY itself, it corrupts the state of the buffer chain which causes moonlight-common-c to crash when trying to access internal fields of the LENTRY in order to free it.
The effect of this bug is that Moonlight Embedded 2.4.8 segfaults immediately on the first frame of video on the Pi :(
I also included a fix for an unintended assignment of
initial_widthin the SPS processing code.Purpose Make Moonlight Embedded work on the Pi again