Opened 17 years ago
Closed 17 years ago
#2796 closed patch (duplicate)
Silent audio track created using MythArchive
Reported by: | anonymous | Owned by: | paulh |
---|---|---|---|
Priority: | major | Milestone: | unknown |
Component: | mytharchive | Version: | 0.20 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
MythArchive? gives presidence to lower audio PID's, but this is not always the case. In the UK, DVB-T includes a hard-of-hearing audio track (which sometimes is just silence), and MythArchive? is sometimes picking this instead of the correct track. Could we instead use the track which has the highest bitrate? I've attached a diff that will do this. Another idea would be to use bitrate as the first measure, and PID second maybe?
Attachments (1)
Change History (9)
comment:1 Changed 17 years ago by
Type: | defect → patch |
---|
comment:2 Changed 17 years ago by
Looking into this further, the Audio Description track should be detectable from the stream rather than relying on the bitrate being low. The nebula software seems to support this, if you go to http://www.doom9.org/index.html?/DigiTV/nebula.html and search for 'Audio description' you will see what I mean.
Unfortunately I am unable to provide any details of what stream headers need to be checked to determine whether each track is an audio description track. Maybe it could be analysed somehow???
comment:3 Changed 17 years ago by
I've just stumbled across the mpgtx package (http://mpgtx.sourceforge.net/) which find information about a stream and can detect the hearing impaired track. Maybe we could call this and parse its output, or incorporate what it does into libavformat?
comment:4 Changed 17 years ago by
Thanks for you effort to fix this, it is much appreciated, but we have to be carefull not to break things for other parts of the world. Using the highest bitrate isn't going to work in all cases and this can happen with any audio streams not just the Audio Described ones.
I think MythArchive? is using the correct method to select the audio tracks. The audio track with the lowest PID should be the main audio track at least that is correct with a virgin DVB-t recording. The problem is actually caused by mythtranscode --mpeg2 which sometimes changes the order of the audio tracks causing the stream IDs to become mixed up.
I've never actually been able to reproduce this myself so if you can provide a small sample file that you know produces this problem that would help to get this fixed. Obviously I need the original file before its been processed by mythtranscode so I can see what's going on when mythtranscode --mpeg processes it. This problem is just one of several problems caused by mythtranscode and mythreplex so John Drescher is currently working on adding an option to use projectX rather than mythtranscode to do the commercial cutting and the demuxing which should hopefully fix many of these problems. It isn't an ideal solution but if it works.....
comment:5 Changed 17 years ago by
I have seen the mixing up of the audio files on DVB-T here in the UK, and I don't believe that it had been run through transcode.
I'll have a look this afternoon, and see if that did occur. If so, I'll attach a small sample file here
comment:6 Changed 17 years ago by
I've done a couple of recordings but the PID's seem to be in order like you mentioned. I'll look into all my existing recordings and get back to you (I've only run mythtranscode on four of them)...
PS. Regarding ProjectX, this would be very useful - I've noticed av sync issues with mythtranscode too.
comment:7 Changed 17 years ago by
I think you're right, looking through my recordings it must be mythtranscode thats mixing up the PID's. Should I re-categorise this ticket under mythtv instead of mytharchive?
diff