Audio Stream loss after codec change

[Jim]

Summary of the bug:
We are using ffmpeg to transcode live mpeg2 streams from satellite receivers to MP4 streams. Unfortunately reproducing the bug will be extremely difficult without a similar setup that we have.
How to reproduce:

% ffmpeg -vsync 1 -i "udp://239.xxx.xxx.xxx:yyyy?overrun_nonfatal=1" -vf yadif -map 0 -c:a copy -vcodec libx264 -b:v 5000k -bufsize 12000k -g 60 -preset superfast -f mpegts "udp://239.zzz.xxx.xxx:yyyy?pkt_size=1316&ttl=10"

ffmpeg -version
ffmpeg version 2.4.2 Copyright (c) 2000-2014 the FFmpeg developers
built on Oct 30 2014 21:43:28 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
configuration: --prefix=/home/user/ffmpeg_build --extra-cflags=-I/home/user/ffmpeg_build/include --extra-ldflags=-L/home/user/ffmpeg_build/lib --bindir=/home/user/bin --extra-libs=-ldl --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-nonfree --disable-ffplay
libavutil      54.  7.100 / 54.  7.100
libavcodec     56.  1.100 / 56.  1.100
libavformat    56.  4.101 / 56.  4.101
libavdevice    56.  0.100 / 56.  0.100
libavfilter     5.  1.100 /  5.  1.100
libswscale      3.  0.100 /  3.  0.100
libswresample   1.  1.100 /  1.  1.100
libpostproc    53.  0.100 / 53.  0.100

Container: Mpeg2
Audio Codec: Normally AC3.

What we have been able to notice is with channels that change their audio format from Stereo to Dolby or vice versa: ffmpeg appears to drop the audio channel all together (Like it is muted muted or non-existent). We are able to listen to the Closed Captioning PID stream through out this whole time: this is likely because the enm source does not change format. Silencedetect and Volumedetect filters do not indicate that any problem exists with the volume on the output stream. However we have to restart the stream in order for it to start working again. Picture quality is phenomenal.

For example: we're pulling a channel down from one of the various Movie Central's (It affects them all), after a few days to a week the audio will just stop working. We have been unable to identify exactly when it happens as we are unable to watch TV for days on end. We have ruled out that it is not our deployment: it's not our Set Top Boxes, or our delivery network. We have ruled out the source of the video stream and our set top boxes by using muticast capable computers and software.

We suspect that it happens when a relatively new movie is played on this channel, it doesn't appear to affect movies from the early 2000's or older. (As we have gone through the program output for this specified time and looked through the channels. We have been unable to identify one particular movie that does it.)

Volumedetect shows correct dB, Silencedetect does not detect any silence of the audio.

[Carl Eugen Hoyos]

Please record a sample file and please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

[Carl Eugen Hoyos]

And please test current FFmpeg git head.

[Carl Eugen Hoyos]

Please reopen if you can explain how to reproduce this ticket.

[Jim]

cehoyos,

I checked bug reports for this bug but was unable to correct it (except reported for an older version): See #3553, and https://ffmpeg.org/pipermail/ffmpeg-user/2013-May/015184.html. I don't suspect these issues are related.

I have two sample videos now. Only 5 minutes each. I just happened to get lucky and noticed it shortly after restarting the stream. Thankfully I have multiple copies of this problem, it seems to affect both video output as well as video 'input'. Time of occurrence is roughly between 3 minutes to the end of the video. Skipping it in VLC has no effect on the fact that audio is not present; nor is it restored.

Version: FFMPEG 2.8-static and FFMPEG 2.4.2

Original parameters:
/home/user/ffmpeg_run/ffmpeg -i "udp://239.175.2.61:5000?overrun_nonfatal=1" -vf yadif -map 0 -c:a copy -vcodec libx264 -b:v 5000k -bufsize 12000k -g 60 -preset superfast -tune zerolatency -f mpegts "udp://239.175.4.61:5000?pkt_size=1316&ttl=10"

/home/user/ffmpeg_run/ffmpeg -i "udp://239.175.2.61:5000?overrun_nonfatal=1" -y -f mpegts WGN-input.raw

/home/user/ffmpeg_run/ffmpeg -i "udp://239.175.4.61:5000?pkt_size=1316&ttl=10" -y -f mpegts WGN-output.raw

Background:
We receive the stream from an authorized satellite receiver via unicast, it hits a multicast server; this then broadcasts the output which is received by these transcoding servers. We are confident that this issue is not a problem with the multicast server because we can tune into the stream without any problem after the audio has been "muted" after it passes the ffmpeg processes. This issue has been omnipresent since version 2.4 and earlier.

Please feel free to pass input.raw and output.raw through the latest ffmpeg build to see if it corrects the problem: I have a feeling that it doesn't.

I have uploaded WGN-PUT.txt to your file server, as well as the input and output files respectively. The only real output to the screen is the message in WGN-PUT.txt.

[Carl Eugen Hoyos]

To make this a valid ticket, please:

• Test current FFmpeg git head.
• Post the command line that allows to reproduce the issue together with the complete, uncut console output here in the ticket.
• Provide an input sample: Do not use the ffmpeg executable to record the input sample! Use either mplayer -dumpstream or tools/aviocat or any other tool that dumps the input stream unchanged, this is not (easily) possible with the ffmpeg command line tool.

Please avoid uploading output files, they often lead to confusion.

[Jim]

cehoyos,

I apologize about this confusion. I thought for sure I was "going the extra mile".

I am unable to use Mplayer on this current machine; will cvlc work?
cvlc -vvv udp://@239.175.2.51:5000 --sout file/ts:/WGN-input2.raw.ts

Please delete the old files and I will re-upload a resized sample once I am able to reproduce the bug. (Should be a few days - 1 week)

[Carl Eugen Hoyos]

Replying to jimbob:

I am unable to use Mplayer on this current machine;

Then please use tools/aviocat, I believe it works fine for udp streams.

will cvlc work?

I don't know if/how dumpstream is possible with vlc

cvlc -vvv udp://@239.175.2.51:5000 --sout file/ts:/WGN-input2.raw.ts

This remuxes the input stream and is as bad as using ffmpeg -codec copy.

[Jim]

Hi!

I tried getting aviocat to compile but was unsuccessful, it's not available in my repos and compiling it from source errors with missing libraries in libavutil/

So I'm back trying to get mplayer to work, but the only way I can do it is via the following:
./mplayer 'ffmpeg://udp://239.175.2.61:5000' -dumpstream -dumpfile ~/somefile

I have a feeling that this is just as bad as everything else that I have done due to the ffmpeg reference...

I've been googling and man'ing the day away; but can't seem to find anything that will work.

I want to ensure that I provide you guys with the best possible information in hopes of getting this bug fixed.

I anticipate your reply.

[Carl Eugen Hoyos]

Replying to jimbob:

./mplayer 'ffmpeg://udp://239.175.2.61:5000' -dumpstream -dumpfile ~/somefile

This looks perfect.

I have a feeling that this is just as bad as everything else that I have done due to the ffmpeg reference...

Why? FFmpeg is only used to receive the stream, the stream is then written (untouched) to the output file.

[Carl Eugen Hoyos]

This ticket does sound interesting but without a sample, I don't see how it can be reproduced or fixed;-(
Please reopen if you can provide a sample.