<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">I've done a diff between My decrypted chunk(right) and the chunk corrected by TSDoctor (left). Somebody knows what these differences means ? <img moz-do-not-send="false" src="cid:part1.8E447345.F5CB1AF0@gmail.com" alt="" width="1845" height="887"> Le 10/07/2017 à 16:01, Nicolas Castillejos a écrit : </div> <blockquote type="cite" cite="mid:dd51ba0d-5f39-96b3-1cca-1840258b7175@gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div class="moz-cite-prefix">I've opened my decrypted chunk with TSDoctor software and it tells me this : Scrambled stream areas detected. Maybe the stream is not correctly decrypted. Try to cut out the scrambled areas ? I say yes then I save the corrected files on my disk. When i try to read it now it works fine, there is no more "Bad CRC_32 table". I've put the logs of TSDoctor in attachement. Do you know why my decryption is making these kinds of error ? Cordially, Nicolas Castillejos Le 04/07/2017 à 11:16, Nicolas Castillejos a écrit : </div> <blockquote type="cite" cite="mid:f57fdc03-5196-c235-6615-8ce12c38f912@gmail.com">Hello, I'm contacting you because I think I've found a bug in the gstreamer TS DEMUXER called tsdemux. The thing that it makes me think it is a bug is that VLC or hls.js succeed to read the stream where GStreamer failed. The HLS Live stream is coming from Wowza Streaming Engine. When encryption is disabled on Wowza, Gstreamer has no problem to read the Live stream. it only fails when it is encrypted. I've noticed what problem could be make Gstreamer failed, look what I have tested : When I download a normal HLS chunk from Wowza, I write it to the disk , then I double-click on it and can read it with VLC. When I download an encrypted chunk from Wowza, and I decrypt it with the HLS key, then write it to the disk, I double-click on it and VLC failed to read it, the displayed error is : ts error: libdvbpsi error (misc PSI): Bad CRC_32 table 0x0 !!! In GStreamer log, i can see the same kind of error : 0:00:19.623514731 6948 1558FFA0 WARN mpegts gstmpegtssection.c:161:__common_section_checks: PID:0x0000 table_id:0x00, Bad CRC on section The fact that crc table seems to be bad or not set certainly makes TS DEMUXER failed. VLC or hls.js seems to manage this kind of case, i don't know how but they succeed to read it even if the crc is bad. I've put the gstreamer logs in attachement. Do you know this bug, is there a way to bypass this crc check ? Does somebody will correct it ? Thank you. Cordially, Nicolas Castillejos </blockquote> </blockquote> </body> </html>