> has this bug been fixed? (no i cant check ... as "file not found") This hasnt been fixed but I know what's wrong now. The problem is that the audio stream header in this sample 'suggests' that the audio is MP2 when in fact it is actually AC3. I say 'suggests' here because there's no public documentation on the content of a dvr-ms audio stream header. I originally submitted a patch (to get dvr-ms audio working) that reads what appears to be a WAVEFORMATEX structure from the middle of the header. This seemed to work well enough for SD content but it turns out that it doesnt typically work for HD content. As far as I know the wFormatTag field of a WAVEFORMATEX should contain 0x50 for MP2 and 0x2000 for AC3. However, for the sample in question, wFormatTag contains 0x50, which means there's currently no way to know in the demuxer that the audio is AC3. Most other HD samples I've seen contain the value 0x00 in wFormatTag if the audio is AC3. I've built an experimental version of mplayer that changes the value to 0x2000 if 0x00 is found, and this allows me to play most HD files I have - except for the sample in question. I doubt this is the basis for a patch though given that at least one sample still doesnt work. There must be some other way to determine the audio stream type but I dont know how to at the minute. If anyone's interested in helping I have a bunch of samples I can post. John
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4