New submission from gnif :
The AC3 encoder has been changed to require float data instead of S16, but
still successfully initializes when asked to take S16 and generates
rubbish output.
--
messages: 13624
nosy: gnif
priority: normal
status: new
substatus: new
title: AC3 encoder has
gnif added the comment:
confirmed, ffmpeg is now reporting stereo output:
> Stream #0.1(eng): Audio: dca, 48000 Hz, stereo, s16, 768 kb/s
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2137>
gnif added the comment:
The issue is nothing to do with the LFE channel as originally suspected,
the reported channel count is completely wrong.
Will apply patches and confirm
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2137>
gnif added the comment:
For reference, here is the workaround I have implemented:
http://trac.xbmc.org/browser/trunk/xbmc/cores/dvdplayer/DVDCodecs/Audio/DV
DAudioCodecFFmpeg.cpp#L243
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2137>
gnif added the comment:
Fair enough, the "fix" is more of a hack, in that I have modified the
XBMC count the number of bits in the channel layout instead of using the
channel count provided by the demuxer.
ge...@geoff:~/Desktop$ ffmpeg -i fix.mkv
FFmpeg version SVN-r23386, Co
gnif added the comment:
Why do you want another dump of ffmpeg's output when I have confirmed
that it is the same issue? ffmpeg -i on the stripped dts produces 2 as
the channel count, which is correct. ffmpeg -i on the mkv produces 6 as
the channel count, which is wrong.
The fact that
gnif added the comment:
Just had another file that exhibits the exact same problem, this time its
a MKV file with a DTS stream. I have attached the file
File 'fix.mkv' not attached - you can download it from
https://roundup.ffmpeg.or
gnif added the comment:
Depends on if the avi header is inconsistent with the encoding information
in the DTS stream, I dont know enough about avi to comment on which is the
problem, but I would expect that ffmpeg should prefer the channel count
provided by the actual codec then the
New submission from gnif :
This program makes multiple uses of open-source libraries including
ffmpeg without source, or any references to the GPL.
http://www.tipard.com/dvd-ripper.html
Files in this program:
avcodec-52.dll
avdevice-52.dll
avfilter-0.dll
avformat-52.dll
avutil-50
gnif added the comment:
Just noticed that the .dts reports 5.1 correctly, but the dts in the avi
container does not, here is the output of ffmpeg -i on the avi.
ge...@geoff:~/Desktop$ ffmpeg -i dts.avi
FFmpeg version SVN-r23386, Copyright (c) 2000-2010 the FFmpeg developers
built on Jun 3
gnif added the comment:
ffmpeg -i output and audio only clip attached... I do not have the full dts file
for testing with as it is a clip provided by a member of the XBMC community, I
can confirm that this behavior is exhibited by the latest trunk version of
libavc/libavf
ge...@geoff:~/Desktop
New submission from gnif :
ffmpeg's channel count reports 5 channels when the channel count of the
attached file is actually 6, the channel layout however is correct.
File 'dts2.avi' not attached - you can download it from
https://roundup.ffmpeg.org/file1008.
--
gnif added the comment:
Added myself to the nosy list
--
nosy: +gnif
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue555>
gnif added the comment:
Attached wrong file, sorry, here is the right one...
It reads in the existing header (if it is set by
libvorbis) and re-builds it with any extra metadata.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue
gnif added the comment:
Attached patch to add support for oggenc metadata when
the contained format is vorbis.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue555>
diff --git a/xbmc
New submission from gnif :
The SPDIF muxer (spdif.c) prepends 8 null bytes to the beginning of every frame
which stops them being decodeable by a capable receiver.
The offending lines are "put_le16(s->pb, 0);" in the end of the function
"spdif_write_header" in spdif.
gnif added the comment:
The file came from a user on the XBMC forums, who is not responding to inquires,
so at current, we do not know where the file came from, or what created it.
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roun
gnif added the comment:
Attached file that has this issue.
I have not seen a specification that notes this as I am not familiar with the
format.
File 'dts-sample.mov' not attached - you can download it from
https://roundup.ffmpeg.org/roundup/ffmpeg/file766.
--
n
New submission from gnif :
This patch adds support to MOV files with DTS streams in them
--
files: movdtsfix.diff
messages: 9203
priority: normal
status: new
substatus: new
title: Add DTS in MOV support
type: patch
_
FFmpeg issue
New submission from gnif :
The function ac3_decode_frame does not return the value of err when an error has
occurred, instead it returns s->frame_size.
To reproduce, just supply an incomplete ac3 frame and note the output of
ac3_decode_frame
--
messages: 9010
priority: normal
sta
20 matches
Mail list logo
