libavformat failing with multiple audio streams

[anonymous]

The mythtv version of av_find_stream_info in libavformat isn't always detecting and returning all audio tracks, and sometimes misses the required track when using MythArchive? (i.e. it returns the hard-of-hearing track that is transmitted in the UK alongside the main track). Details of the problem are here: ​http://mythtv.org/pipermail/mythtv-dev/2006-October/051131.html.

It looks like the mod to speed up channel change is causing this - I've attached a diff that should fix the issue so that non time dependant apps such as MythArchive? can request the stream info in full leaving the channel changing speed as it is.

It is quite possible that the problem in ticket #2468 could also be related to this.

[anonymous]

mythtv.diff

[anonymous]

mythplugins.diff

[J.Pilk@…]

#2468 used to give me problems, but that seems to have gone. I have added a comment to the #2468 entry. Thanks!

[StephenK <mail@…>]

Replying to J.Pilk@tesco.net:

#2468 used to give me problems, but that seems to have gone. I have added a comment to the #2468 entry. Thanks!

The latest version I have been able to test is releases-0-20-fixes@12376, but this still has the problem of libavformat not finding all the streams on occasions. Looking at trunk, it doesn't appear that my patch above has been applied. I'll compile trunk when I get a chance and see if I can still recreate the problem.

[J.Pilk@…]

Although mythtranscode now passes on the stereo channel in BBC recordings, I still see the old behaviour with Five.

Still using the atrpms 0.21-150_trunk_r12545.fc5.at build.

mencoder -aid 0x1782 (etc for DVD PAL output) stripped off the unwanted stuff.

Here's the result of ffmpeg -i <infile> on the original, first and second 'lossless' transcodes of a test recording: one I made yesterday had two 'data' channels as well.

Raw recording:

Stream #0.0[0x1781]: Video: mpeg2video, yuv420p, 720x576, 15000 kb/s, 25.00 fp s(r)

Stream #0.1[0x1782](eng): Audio: mp2, 48000 Hz, stereo, 192 kb/s Stream #0.2[0x1783](eng): Audio: mp2, 48000 Hz, mono, 64 kb/s Stream #0.3[0x1786](eng): Subtitle: dvbsub

After one mythtranscode:

Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x576, 15000 kb/s, 25.00 fps(r)

Stream #0.1[0x1c1]: Audio: mp2, 48000 Hz, mono, 64 kb/s Stream #0.2[0x1c0]: Audio: mp2, 48000 Hz, stereo, 192 kb/s

After second transcode:

Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x576, 15000 kb/s, 25.00 fps(r) Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, mono, 64 kb/s

HTH

[anonymous]

Replying to stuartm:

The patch doesn't patch mythtranscode. There is just one call to av_find_stream_info in mythtranscode/mpeg2fix.cpp, change that to av_find_stream_info_deep and rebuild. It works for me.

[anonymous]

Replying to J.Pilk@tesco.net:

The patch doesn't patch mythtranscode. There is just one call to av_find_stream_info in mythtranscode/mpeg2fix.cpp, change that to av_find_stream_info_deep and rebuild. It works for me.

[J.Pilk@…]

Thanks for this. I'm running the ATrpms trunk builds and haven't so far explored building from source. That being so, I shan't see the effect of this new mini-patch until it has been committed and Axel has rebuilt. Will this happen without testing input from me?

[paulh]

Replying to StephenK <mail@mythbox.co.uk>:

Replying to J.Pilk@tesco.net:

#2468 used to give me problems, but that seems to have gone. I have added a comment to the #2468 entry. Thanks!

The latest version I have been able to test is releases-0-20-fixes@12376, but this still has the problem of libavformat not finding all the streams on occasions. Looking at trunk, it doesn't appear that my patch above has been applied. I'll compile trunk when I get a chance and see if I can still recreate the problem.

Is this patch still needed with current svn?

[J.Pilk@…]

Within the past couple of weeks I have installed the current ATrpms 'bleeding' build under CentOS 5. It is apparent that the audio-track selection problems have not yet been solved. I have seen several DVB-T recordings which, after one pass through mythtranscode for editing, still have the main soundtrack and another, which is sometimes a silent track. The main track is played in 'Watch Recordings' but Mytharchive (with Mythtranscode again) sometimes drops this, sometimes swaps the two. I will try to find out what is actually happening as soon as I can. The internal Mytharchive DVD-image player still has problems with track-selection too; this may be, in part, because the menumusic is supplied only as ac3 and I use mp2 for the content.

[simonwalls@…]

Hi, I've been trying to repeat the fix on my Myth system which is suffering from the posted problem (Trying to make a DVD of a Myth recording .... Mytharchive, when asked to honor cut list, uses mythtranscode, which results in a silent DVD. When cut list turned off, DVD has sound). My system is an Athlon system running MythDora? 4.0 (Fedora Core 6) which I'm hoping to upgrade just mythtranscode on... don't know if this will work.

Anyway I'm not there yet, I am stuck at the stage of trying to compile ffmpeg (and then myth) with the 'fix' in place. I've got hold of the same FFMPEG version (svn 8743) as used on the original system, and have made the edits in libavformat/utils.c but the variables in the patch: hasvideo & hasaudio, are not to be found in the entire ffmpeg package. So I'm stuck...

Could anyone clarify for me where I should find hasaudio & hasvideo - are they in a further fix?

[J.Pilk@…]

This problem hasn't bothered me so much recently because I have been using the workaround suggested in the Mytharchive wiki: making my DVDs with 'eng' and 'undef' sound channels both re-encoded from the native dvb mp2 to ac3. It may also help that I'm now using tuner cards apparently capable of handling the full data streams - Ticket #1907?

Mytharchive takes more time to do this, both because of the re-encoding and because the larger audio files often make it necessary to run requant. Both ac3 streams are the same size - despite the usually low info content of the subsidiary one - and are substantially larger that the mp2 originals.

I have also seen Mytharchive failures when the susidiary channel had a problem and the re-encoding failed: stripping off the bad channel with a mencoder 'copy' script can allow Mytharchive to work but requires more intervention.

Difficulties with the sound channels usually happen just before the start of a programme, I suppose because streams are being dropped or inserted at source. Starting mythtranscode shortly before a BBC Four program change is quite a good way to invite problems.

I'm not sure how much of the above is directly relevant to this ticket, but I hope it's helpful.

Currently running trunk_r15447 from ATrpms on CentOS 5

[danielk]

Janne, does the patch make sense to you?

[Janne Grunau]

not much, for ordinary DVB-T recordings we should find all audio streams from the PMT.

If it's for audio streams which are added later in the recording, it helps only by pure chance.

[J.Pilk@…]

As my old comments above show, I used to get problems with some DVB-T recordings having multiple audio streams. These would become apparent during or after transcoding or within Mytharchive. On my one attempt to use Project-X in Mytharchive it selected the wrong stream, and I haven't tried it since. I've never been clear if these problems are directly relevant to this ticket. Is the PMT used during these processes? Is it used during playback of transcoded recordings?

Nowadays I work around the problem, which may no longer exist, by interactive selection of a single audio stream before doing any further processing: it works, but it doesn't Just Work(TM) and I would prefer something that did. I'm using 0.21 fixes/bijou from ATrpms under CentOS 5.3 and Fedora 10/x86_64.

[stuartm]

Assuming that this is fixed in current trunk, open a new ticket if not.