[FFmpeg-trac] #4158(undetermined:new): Audio Stream loss after codec change
FFmpeg
trac at avcodec.org
Thu Dec 4 23:50:14 CET 2014
#4158: Audio Stream loss after codec change
-------------------------------------+-------------------------------------
Reporter: jimbob | Type: defect
Status: new | Priority: important
Component: | Version: git-
undetermined | master
Keywords: Dolby, | Blocked By:
Stereo, Audio, Surround Sound, | Reproduced by developer: 0
Closed Captioning |
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4158>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list