search

google / sagetv

SageTV is a cross-platform networked DVR and media management system
http://forums.sagetv.com/
Apache License 2.0
266 stars 174 forks source link

Built in remuxer occasionally breaks AC3 audio for the entire recording when using MPEG2-TS container. #149

Closed enternoescape closed 8 years ago

enternoescape commented 8 years ago

After using the built in remuxer for at least a week now using MPEG2-TS output, about every 100 recordings, I will get one that has video, but the audio will not playback on the extenders. The audio will play cleanly on a few programs, but most of them really don't like it. It doesn't seem to matter what channel is being recorded. Re-running the same file through the remuxer into the MPEG2-PS format fixes the broken audio. Remuxing the broken file into TS a second time results in the same broken audio in the file. Extracting a random part of the TS file in hopes that the remuxer just got tripped up somehow and running it back through the remuxer into TS doesn't fix anything either. These broken files are so rare that I haven't caught a native log for one yet. Below is a link to one such file. Running the TS file through VideoRedo into another TS container, doesn't report anything was wrong, but the resulting file is a perfectly playable file.

https://drive.google.com/open?id=0B4AD2tiek6XiS0FlVEVxVVFZdDQ

I know it was suggested to use MPEG2-PS when possible, but this appears to be an interesting bug that should probably be fixed.

Narflex commented 8 years ago

OK, I'll take a look at this...but it'll probably be a couple weeks until I've got a setup where it's convenient to analyze (work travel right after my vacation ends).

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Narflex commented 8 years ago

I took a look at this and the problem appears to be that it is misdetecting the audio format in SageTV's native format detector as 44.1kHz and 4 channels, rather than 48kHz and 6 channels. I'll take a look into it further today and see if I can find the problem and fix it. :)

On Sat, Jul 2, 2016 at 4:41 PM, Jeffrey Kardatzke jkardatzke@google.com wrote:

OK, I'll take a look at this...but it'll probably be a couple weeks until I've got a setup where it's convenient to analyze (work travel right after my vacation ends).

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Narflex commented 8 years ago

OK, I figured out what's wrong...but I need to check with some folks before making the change because I want to know why it was done this way in the first place. In the AC3Format.c file, it looks for either 0x0B77 or 0x770B for a valid AC3 sync code. In this case, it's finding 0x770B which causes it to use the wrong format...if i change the code to only allow 0x0B77, then it works correctly (and 0x0B77 is the AC3 sync code).

On Tue, Jul 12, 2016 at 11:52 AM, Jeffrey Kardatzke jkardatzke@google.com wrote:

I took a look at this and the problem appears to be that it is misdetecting the audio format in SageTV's native format detector as 44.1kHz and 4 channels, rather than 48kHz and 6 channels. I'll take a look into it further today and see if I can find the problem and fix it. :)

On Sat, Jul 2, 2016 at 4:41 PM, Jeffrey Kardatzke jkardatzke@google.com wrote:

OK, I'll take a look at this...but it'll probably be a couple weeks until I've got a setup where it's convenient to analyze (work travel right after my vacation ends).

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

Narflex commented 8 years ago

Apparently there is a format called DNET which is byte-swapped AC3. But I think it only appears in RealMedia files which we don't support. The other devs think we added this in order to pass the Dolby certification tests we had to do for the HD300. Neither of those points seem to matter at all, so I'm going to change it.