Conversation
My first attempt was more complex: fancybits@a55f10a That approach also works, but the same tests fail for the same reason. |
Are you sure this is an error? 🤔 packet length is supposed to indicate the number of bytes after this field, optional header included. |
|
Regarding the content of the PR, I don't really like the idea of ignoring the problem and rewriting the packet length. As you suggested here, I would implement the CorruptedPacketHandler logic and make the corrupted packet go through it. |
|
Fixed the issue with the tests not passing. |
Thanks @eric, but as I mentioned in my previous comment, I'd rather go the CorruptedPacketHandler route in this case 👍 |
|
Hi, I'd like to share my case which might be related, I set up a muxer from a live stream into srt mpegts via astits.newmuxer and during muxing I have error messages both on go app and ffplay(receiver); I just wonder how to overcome this? What would be CorruptPacketHandler case for muxer? Thanks in advance AyhG |
|
@ayhangenc could you share the next 10 or 20 lines of the panic stack? |
|
Hi @asticode , here is the complete dump of the log screen for the app. the error message on ffplay is this: and the app log: |
|
Can you open an issue including test data which would allow us to reproduce the problem so that it could be traced more easily? |
106bbe5 to
0df190a
Compare
66f3fa5 to
86767b5
Compare
Simple fix for #35
Unfortunately this is breaking some tests which are creating and operating on malformed packets.
Specifically, the
with_headerPES test advertises a packet length of 67 even though it only has 9 bytes of data:go-astits/data_pes_test.go
Lines 258 to 265 in 473f66c
go-astits/data_pes_test.go
Lines 329 to 332 in 473f66c
I tried to fix these tests but they make a lot of assumptions and reuse fixtures like
pesWithHeaderBytes()which creates quite the rabbit hole.