Closed 0x24D closed 8 months ago
Your bisect suggests that our old, third-party transmuxer (mux.js) could handle this content, but that our own transmuxer can't.
@avelad, when you are available, can you look into this?
@0x24D, while you are waiting for a fix, you may use v4.3.x, which is still being bugfixed today because of the Cast platform's use of it.
@0x24D you url returns a 403, can you fix it? Thanks!
@avelad I've updated the manifest URL in the original post. It looks like it'll expire in 6 hours so let me know if you need a new one after then.
It seems that for the audio segments we are not able to do the parsing correctly, and we issue this warning: https://github.com/shaka-project/shaka-player/blob/main/lib/util/ts_parser.js#L202, we should investigate the syncOffset function to see where the error is. @joeyparrish can you review it? Thanks!
@0x24D, I need to capture a failed segment to compare our parser with another one. Can you refresh the URL for me, please? Or send a zip of the TS audio segments? I'm not sure if when you'll see this, what time zone you're in, or when I'll see your reply...
@joeyparrish I've updated the manifest URL again
Got it, thanks!
Your first TS audio segment does not seem to be valid. Our parser doesn't understand it, and neither does an independent web-based parser called https://thumb.co.il/.
Looking at the placement of start codes in the first 1000 bytes of the segment, I see these positions for 0x47:
Not all of those will be actual start codes, but each TS packet should begin with 0x47, and those packets should each be 188 bytes. Here are the distances between those with their most likely neighbors:
Since none of those 0x47 bytes are 188 bytes away from any others, none of the first 1000 bytes of the segment could realistically be the start of TS packets within the segment.
The parser looks for three evenly spaced 0x47 bytes in a "scan window", which maxes at 1000 bytes, then chooses the first of those three as the start of the first TS packet. If I increase the "scan window" to the entire segment, I still find no candidates.
So, as far as I can tell, this is an encoding issue, and you should look at your transcoder/transmuxer on the server, if you are transcoding/transmuxing the original streams.
Have you considered streaming fMP4 instead of TS? It's generally a better format for streaming, has clearer structure and metadata, and doesn't require transmuxing in the player.
I've had a look, after working out how everything works, and the error occurs with the raw input data too. We take the data and just proxy it through a web server (no transcoding/transmuxing) so the data coming in is the same data coming out.
The manifest we give to shaka-player is a list of #EXT-X-INDEPENDENT-SEGMENTS
as #EXT_X_MEDIA:URIs
. These URIs themselves are a list of segments seg.ts
. Somehow two of the #EXT_X_MEDIA:URIs
are chosen and used, one for video and one for audio. The video URI works fine whereas the audio URI fails as you've seen before. I can also confirm what you've seen with the 0x47 bytes.
file detects the audio segments as seg.ts: Audio file with ID3 version 2.3.0, contains:\012- MPEG ADTS, AAC, v4 LC, 44.1 kHz, stereo
and mpv plays them correctly: [cplayer] (+) Audio --aid=1 (aac 2ch 44100Hz)
[cplayer] AO: [pulse] 44100Hz stereo 2ch float
Then it looks like it's not TS at all, but raw/packed AAC being mislabeled as TS.
Then it looks like it's not TS at all, but raw/packed AAC being mislabeled as TS.
Having the same exact issue with other stream. Using 4.3.15 also helps (mux.js)
Stream coming from Akamai, so seems is quite common practice (even it is wrong)
TS_AAC | stringAAC low complexity packed MPEG-2 transport stream (AAC-LC). |
---|
@joeyparrish
That enum from the Cast SDK both doesn't have relevance for this GitHub repo and doesn't match your content. Your audio content is not MPEG-2 transport stream.
If there's no explicit MIME type in the playlist, we have to guess what format it is based on the extension. The extension says TS, but it's not. How should we know it's containerless AAC in this situation?
@0x24D you url returns a 403, can you fix it? Thanks!
@avelad To stop the URL from 403ing I've updated the manifest URL to be where I get the manifest from
Although technically, as @joeyparrish says, it is bad content, I am going to do a little workaround to support this case since mux.js and hls.js support it
Thank you @avelad ! Even for bad content, I'm always happy to have a workaround if it doesn't complicate things too much. And I trust your judgement.
Have you read the FAQ and checked for duplicate open issues? Yes
If the problem is related to FairPlay, have you read the tutorial?
N/A
What version of Shaka Player are you using?
4.7.9
Can you reproduce the issue with our latest release version? Yes
Can you reproduce the issue with the latest code from
main
? YesAre you using the demo app or your own custom app? Custom
If custom app, can you reproduce the issue using our demo app? Yes
What browser and OS are you using? Browser: Firefox 115.8.0esr OS: Arch Linux
For embedded devices (smart TVs, etc.), what model and firmware version are you using? N/A
What are the manifest and license server URIs?
hls
field from https://pipedapi.adminforge.de/streams/w9uJg68CV4gWhat configuration are you using? What is the output of
player.getConfiguration()
?What did you do?
What did you expect to happen? Livestream to play normally, like it did before v4.4.0
What actually happened?
Livestream failed to load. Shaka Error: MEDIA.TRANSMUXING_FAILED received
Extra information Additionally, after git bisecting the custom app and shaka-player this error was introduced by https://github.com/shaka-project/shaka-player/commit/eec25b2c6efc1cccc35509131c37bd4569d54b9e - https://github.com/TeamPiped/Piped/issues/3407#issuecomment-1974866164