Bug#810563: bs1770gain: FTBFS with FFmpeg 2.9/3.0 (Werror)
[Andreas Cadhalpun] > Attached is a patch removing the use of -Werror, which is > a good practice for development builds, but just causes > unnecessary build failures for release builds. Andreas, could you please let us know the cause for the error? Is it the following? ffsox_source.c:157:7: error: 'av_free_packet' is deprecated [-Werror,-Wdeprecated-declarations] av_free_packet(pkt); ^ /usr/local/include/libavcodec/avcodec.h:4040:6: note: 'av_free_packet' has been explicitly marked deprecated here void av_free_packet(AVPacket *pkt); ^ 1 error generated. make[2]: *** [ffsox_source.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Regards, Peter ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
On 19.12.2015 23:24, Andreas Cadhalpun wrote: Now I'm a bit skeptical about "LAME adding some special tags". You've used lame with '--id3v2-utf16 --add-id3v2 --id3v1-only'. What is this supposed to do? Add id3v1 tags, or id3v2 or both? AFAIK it's the so called LAME or XING header. I myself was adding the first version of it to FFmpeg some time ago but unfortunately not based on my proposal (just copy it) but the way the FFmpeg team wants to have it. Meanwhile it's changed anyway. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
On 19.12.2015 20:47, Andreas Cadhalpun wrote: Control: tags -1 moreinfo Hi, On 19.12.2015 20:40, Petter Reinholdtsen wrote: As the bs1770gain developer Peter Belkner explain, this issue is really an issue in ffmpeg and not in bs1770gain. Because of this, I reassign it to ffmpeg. Can you provide a sample for reproducing this problem? Any ffmpeg -i -acodec copy -y should do it. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
On 19.12.2015 20:59, Andreas Cadhalpun wrote: Hi Peter, On 19.12.2015 20:53, Peter Belkner wrote: On 19.12.2015 20:47, Andreas Cadhalpun wrote: On 19.12.2015 20:40, Petter Reinholdtsen wrote: As the bs1770gain developer Peter Belkner explain, this issue is really an issue in ffmpeg and not in bs1770gain. Because of this, I reassign it to ffmpeg. Can you provide a sample for reproducing this problem? Any ffmpeg -i -acodec copy -y should do it. I might be missing what the problem is, but this command seems to work just fine with ffmpeg's test sample [1]. Can you confirm this, or describe more precisely what the problem is? The problem is not mine but the one of Andreas Cadhalpun. You should discuss it with him. Best regards, Andreas 1: https://fate-suite.ffmpeg.org/gapless/gapless.mp3 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797965: BS1770GAIN
On 04.09.2015 23:02, Christoph Anton Mitterer wrote: @Peter: Why exactly do you need to use ffmpeg for writing? Shouldn't it be enough to write some tags? Because bs1770gain is not supposed to have a myriad of backends to deal with. It should be just one: FFmpeg. The hope is that one day FFmpeg will have fixed their errors. They are the experts for those myriads of formats and codecs. Please file these errors under FFmpeg. Thanks, Peter ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#790349: bs1770gain: Fail to build when clock_t is not long int
Many thanks. On 28.06.2015 13:23, Petter Reinholdtsen wrote: Based on the information available from http://stackoverflow.com/questions/1083142/what-s-the-correct-way-to-use-printf-to-print-a-clock-t >, refering to http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html > where it is stated that "clock_t shall be integer or real-floating types", Because "rel-floating types" is mentioned as well I would prefer to fix it as follows diff -rc bs1770gain-0.4.5/bs1770gain/bs1770gain.c bs1770gain/bs1770gain/bs1770gain.c *** bs1770gain-0.4.5/bs1770gain/bs1770gain.c Wed Jun 24 17:30:10 2015 --- bs1770gain/bs1770gain/bs1770gain.c Sun Jun 28 14:24:30 2015 *** *** 305,311 char *odirname=NULL; int loglevel=AV_LOG_QUIET; double overlap; ! clock_t t1,t2; int c; if (1==argc) --- 305,311 char *odirname=NULL; int loglevel=AV_LOG_QUIET; double overlap; ! double t1,t2; int c; if (1==argc) *** *** 644,650 root.vmt->cleanup(&root); if (options.time) ! fprintf(stderr, "Duration: %ld ms.\n",(t2-t1)/CLOCKS_PER_MILLIS); // cleanup: sox_quit(); // still reachable: 9,689 bytes in 51 blocks --- 644,650 root.vmt->cleanup(&root); if (options.time) ! fprintf(stderr, "Duration: %.0f ms.\n",(t2-t1)/CLOCKS_PER_MILLIS); // cleanup: sox_quit(); // still reachable: 9,689 bytes in 51 blocks Regards, Peter ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
Yes. These errors are not real errors. We're working on avoiding them anyway. On 24.06.2015 16:01, Fabian Greffrath wrote: Hi, Am Mittwoch, den 24.06.2015, 07:23 +0200 schrieb Peter Belkner: To fix the error drop "-Wcast-align" from "CFLAGS" in the respective "Makefile.am". is this package built with -Werror?! - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: Generating audio with SoX
On 24.06.2015 12:41, Petter Reinholdtsen wrote: [Peter Belkner] You may use SoX to generate test files. Thank you. I'll try to figure out how to use sox for this. http://notes.tomcarlson.com/sox http://montessorimuddle.org/2012/04/19/generating-and-saving-tones-with-sox/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
On 24.06.2015 12:41, Petter Reinholdtsen wrote:
[Peter Belkner]
BS1770GAIN doesn't make any assumption on buffer alignment itself
(i.e. it relies on FFmpeg), and so myself. Are there any hints that
FFmpeg is broken on the systems in question?
I do not know. But I am more worried about other alignment problems
being hidden if the warning is disabled.
You may use SoX to generate test files.
Thank you. I'll try to figure out how to use sox for this. In the mean
time, I tested on mips if I could find a way to tell the compiler that
the pointer is expected to have the correct alignment, and this patch
solve the build problem related to AVFrame.data:
--- bs1770gain-0.4.3.orig/libffsox-2/ffsox_frame_convert.c
+++ bs1770gain-0.4.3/libffsox-2/ffsox_frame_convert.c
@@ -140,10 +140,10 @@ static int convert_##r##i##_##w##i(conve
R *rp; \
W *wp,*mp; \
\
- rp=(R *)p->fr->frame->data[0]; \
+ rp=(R *)(void*)p->fr->frame->data[0]; \
rp+=channels*p->fr->nb_samples.frame; \
\
- wp=(W *)p->fw->frame->data[0]; \
+ wp=(W *)(void*)p->fw->frame->data[0]; \
wp+=channels*p->fw->nb_samples.frame; \
mp=wp+channels*p->nb_samples; \
\
@@ -281,11 +281,11 @@ static int convert_##r##p##_##w##i(conve
W *wp,*mp; \
\
for (ch=0;chfr->frame->data[ch]; \
+rp[ch]=(R *)(void*)p->fr->frame->data[ch]; \
rp[ch]+=p->fr->nb_samples.frame; \
} \
\
- wp=(W *)p->fw->frame->data[0]; \
+ wp=(W *)(void*)p->fw->frame->data[0]; \
wp+=channels*p->fw->nb_samples.frame; \
mp=wp+channels*p->nb_samples; \
\
--- bs1770gain-0.4.3.orig/libffsox-2/ffsox_frame_convert_sox.c
+++ bs1770gain-0.4.3/libffsox-2/ffsox_frame_convert_sox.c
@@ -98,10 +98,10 @@ static void convert_##sfx##i(convert_t *
\
(void)ch; \
\
- rp=(T *)p->fr->frame->data[0]; \
+ rp=(T *)(void*)p->fr->frame->data[0]; \
rp+=channels*p->fr->nb_samples.frame; \
\
- wp=(sox_sample_t *)p->fw->frame->data[0]; \
+ wp=(sox_sample_t *)(void*)p->fw->frame->data[0]; \
wp+=channels*p->fw->nb_samples.frame; \
mp=wp+channels*p->nb_samples; \
\
@@ -184,11 +184,11 @@ static void convert_##sfx##p(convert_t *
SOX_SAMPLE_LOCALS; \
\
for (ch=0;chfr->frame->data[ch]; \
+rp[ch]=(T *)(void*)p->fr->frame->data[ch]; \
rp[ch]+=p->fr->nb_samples.frame; \
} \
\
- wp=(sox_sample_t *)p->fw->frame->data[0]; \
+ wp=(sox_sample_t *)(void*)p->fw->frame->data[0]; \
wp+=channels*p->fw->nb_samples.frame; \
mp=wp+channels*p->nb_samples; \
\
I like this approach better, as it do not disable strict alignment
checking for the entire code, but only for the selected parts where it
is believed to be OK to disable it. So I plan to keep the
-Wstrict-align warning in place for the Debian package for now.
OK.
Changing the code like that exposes another build error, the cast to
(pull_cb_t) from char * done in this function:
static int getopts(sox_effect_t *e, int argc, char *argv[])
{
priv_t *priv=e->priv;
priv->cb=1data=2
It's a similar problem with the SoX API. The SoX API requires one to
pass arguments to an effect via the function "int
sox_effect_options(sox_effect_t *effp, int argc, char * const argv[])"
(http://sox.sourceforge.net/libsox.html), i.e. as "char * const argv[]".
In the effect's "getopts()" method, the effect has to cast back the real
type of the argument.
It's C after all.
If you like you can avoid the warning also by an additional "(void *)" cast.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
BS1770GAIN doesn't make any assumption on buffer alignment itself (i.e. it relies on FFmpeg), and so myself. Are there any hints that FFmpeg is broken on the systems in question? But you're right: 16 bit is 2 byte, and 32 bit is 4 byte. You may use SoX to generate test files. On 24.06.2015 10:42, Petter Reinholdtsen wrote: [Peter Belkner] Any test using the transcoding feature (i.e. option "-ao") uses this code. It's needed exclusively for that purpose. The code builds the frames to be fed into the FLAC encoder. Right. So a data source with types aligned on more than 1 byte is needed to check that the code do not crash at runtime (for example 2, 4, 8). Any idea how to generate such data source? The test code in debian/tests/ contain this wav file: debian/tests/yell.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz I suspect 16 bit mean aligned on even addresses, but would like to know for sure. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
Any test using the transcoding feature (i.e. option "-ao") uses this code. It's needed exclusively for that purpose. The code builds the frames to be fed into the FLAC encoder. On 24.06.2015 09:58, Petter Reinholdtsen wrote: [Peter Belkner] If you have any doubts whether the alignment of the pointer to the frame buffer is given Thank you for the background information. Is there some way I can test the code in question? What kind of input data do I need and what kind of command line arguments should I use? If such test work on mips, I would be confident that the alignment is correct. As it is, I am reluctant to remove the compiler warning flag from the Debian build. It would be great if such test was executed when running 'make check', as this would ensure the built package was indeed working before uploading it into Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
If you have any doubts whether the alignment of the pointer to the frame
buffer is given you should note that the buffer is allocated using the
respective FFmpeg API function "av_frame_get_buffer()" (cf.
https://www.ffmpeg.org/doxygen/2.6/frame_8c.html).
In "ffsox" the following function in "libffsox-2/ffsox_frame.c"
implements frame buffer allocation:
int ffsox_frame_create_cc(frame_t *f, AVCodecContext *cc)
{
const AVCodec *codec=cc->codec;
AVFrame *frame;
int nb_samples;
if (ffsox_frame_create(f)<0) {
DMESSAGE("creating frame");
goto frame;
}
if (NULL!=codec&&(codec->capabilities&CODEC_CAP_VARIABLE_FRAME_SIZE))
nb_samples=1;
else
nb_samples=cc->frame_size;
frame=f->frame;
frame->format=cc->sample_fmt;
frame->channel_layout=cc->channel_layout;
frame->channels=cc->channels;
frame->sample_rate=cc->sample_rate;
frame->nb_samples=nb_samples;
if (0This code is reminiscent to the FFmpeg example
"ffmpeg/doc/examples/transcode_aac.c". It's up to the FFmpeg API
function "av_frame_get_buffer()" to set the "data" field of an "AVFrame"
to the right alignment and it's not the aim of FFmpeg API client code.
On 24.06.2015 07:23, Peter Belkner wrote:
The first build of bs1770gain on the autobuilders showed an error on at
least the mipsel architecture, that look like this:
ffsox_frame_convert.c: In function 'convert_s16i_s8i':
ffsox_frame_convert.c:143:6: error: cast increases required alignment
of target type [-Werror=cast-align]
rp=(R *)p->fr->frame->data[0]; \
^
ffsox_frame_convert.c:157:1: note: in expansion of macro 'CONVERT_II'
CONVERT_II(s16,s8,int16_t,int8_t,CONVERT_INT_INT_II)
^
ffsox_frame_convert.c: In function 'convert_s32i_s8i':
ffsox_frame_convert.c:143:6: error: cast increases required alignment
of target type [-Werror=cast-align]
rp=(R *)p->fr->frame->data[0]; \
^
ffsox_frame_convert.c:158:1: note: in expansion of macro 'CONVERT_II'
I'm not quite sure how to fix it.
"p->fr->frame->data[0]" is a generic pointer defined in the "AVFrame"
structure from the FFmpeg API. It is of type "uint8_t" (cf. e.g. top
of https://www.ffmpeg.org/doxygen/2.3/structAVFrame.html) but may
point to data of an arbitrary type. The code triggering the error cast
the (generic) pointer back to it's real type.
Those kinds of interfaces utilizing generic pointers which has to be
cast back their real type are a common C technique and not an error.
To fix the error drop "-Wcast-align" from "CFLAGS" in the respective
"Makefile.am".
The fix is available with version 0.4.4 available from
http://sourceforge.net/projects/bs1770gain/files/bs1770gain/0.4.4/.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements
The first build of bs1770gain on the autobuilders showed an error on at least the mipsel architecture, that look like this: ffsox_frame_convert.c: In function 'convert_s16i_s8i': ffsox_frame_convert.c:143:6: error: cast increases required alignment of target type [-Werror=cast-align] rp=(R *)p->fr->frame->data[0]; \ ^ ffsox_frame_convert.c:157:1: note: in expansion of macro 'CONVERT_II' CONVERT_II(s16,s8,int16_t,int8_t,CONVERT_INT_INT_II) ^ ffsox_frame_convert.c: In function 'convert_s32i_s8i': ffsox_frame_convert.c:143:6: error: cast increases required alignment of target type [-Werror=cast-align] rp=(R *)p->fr->frame->data[0]; \ ^ ffsox_frame_convert.c:158:1: note: in expansion of macro 'CONVERT_II' I'm not quite sure how to fix it. "p->fr->frame->data[0]" is a generic pointer defined in the "AVFrame" structure from the FFmpeg API. It is of type "uint8_t" (cf. e.g. top of https://www.ffmpeg.org/doxygen/2.3/structAVFrame.html) but may point to data of an arbitrary type. The code triggering the error cast the (generic) pointer back to it's real type. Those kinds of interfaces utilizing generic pointers which has to be cast back their real type are a common C technique and not an error. To fix the error drop "-Wcast-align" from "CFLAGS" in the respective "Makefile.am". The fix is available with version 0.4.4 available from http://sourceforge.net/projects/bs1770gain/files/bs1770gain/0.4.4/. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
On 22.06.2015 10:09, Carl Eugen Hoyos wrote:
Hi!
On Mon, 22 Jun 2015, Peter Belkner wrote:
if (0!=*got_packet) {
av_packet_rescale_ts(pkt,cc->time_base,st->time_base);
+ // where do the "magic" factor 0.5 come from?
+ pkt->dts>>=1;
+ pkt->pts>>=1;
+ pkt->duration>>=1;
if (ffsox_stream_interleaved_write(so,pkt)<0) {
DMESSAGE("writing packet");
Maybe Carl Eugen can provide some insight into how to align the time
scales between streams.
Your patch looks very wrong to me
Obviously it is not wrong because it does the right thing :-) The
question is why, because, of course, this patch is ad hoc without any
understanding.
but I only commented on a ffmpeg command line that you claimed shows a
problem with FFmpeg (it only showed an issue
with the command line in question).
I don't know what libffsox is.
It's a utility library where this code comes from.
int ffsox_stream_interleaved_write(stream_t *s, AVPacket *pkt)
{
pkt->stream_index=s->stream_index;
#if 0 // {
fprintf(stderr,"%d: %I64d, %I64d\n",pkt->stream_index,pkt->pts,pkt->dts);
#endif // }
return av_interleaved_write_frame(s->fc,pkt);
}
One thing that comes to mind is: Is st->time_base the time_base of the
input or the output stream? They do not have to be identical, not even
if you requested them to be identical.
Stream "st" and codec context "cc" are output.
The packet "pkt" is constructed from a fresh frame which has no direct
link to the decoded frame from the input, except sample frequency,
number of channels, and channel layout.
Carl Eugen
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
On 22.06.2015 09:55, Petter Reinholdtsen wrote:
[Peter Belkner]
I was testing with Winamp and the FFmpeg based "in_ffsox" input plugin.
It was not "stuttering" at all. I discovered "stuttering" only when
testing with VLC player.
Aha.
Meanwhile I've learned that we have two issues:
1. "20030213-cvs.mpeg" had not processed at all (i.e. just loudness
analysis was aborting with an error and hence it could not have
"stuttered")
2. "DavidGallo_2007.dv" stutters.
Aha. That is strange, as I am quite sure I tested it before reporting
the bug. Anyway, I trust your observations and must remember
incorrectly.
The (previous) patch solves the first issue. The idea is to throw away
packages FFmpeg cannot deal with.
Given that it only happen once, I guess the package is at the start or
at the end. Perhaps the message should be extended to mention how far
into the stream the package is dropped.
The FFmpeg example "ffmpeg/doc/examples/decoding_encoding.c" aborts in
such a case:
len = avcodec_decode_audio4(c, decoded_frame, &got_frame, &avpkt);
if (len < 0) {
fprintf(stderr, "Error while decoding\n");
exit(1);
}
On the other hand the FFmpeg program silently deals with the file.
I don't think that it is a good idea to let BS1770GAIN re-implemet large
portions of FFmpeg.
Maybe we should revert to the original behavior of aborting in case
avcodec_decode_audio4() fails and make it in option to continue in case
of an error. It's then up to the user to see whether it makes sense.
Am I right in believing that many such dropped packages in the middle of
the stream will cause audio and video to get out of sync?
The following patch solves "stuttering" (but really is some kind of a
"sledgehammer")
diff -rc ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_writer.c
./bs1770gain-0.4.4-beta3/libffsox-2/ffsox_frame_writer.c
*** ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_writer.c
2015-06-14 18:11:19.0 +0200
--- ./bs1770gain-0.4.4-beta3/libffsox-2/ffsox_frame_writer.c
2015-06-22 09:12:36.0 +0200
***
*** 145,150
--- 145,154
if (0!=*got_packet) {
av_packet_rescale_ts(pkt,cc->time_base,st->time_base);
+ // where do the "magic" factor 0.5 come from?
+ pkt->dts>>=1;
+ pkt->pts>>=1;
+ pkt->duration>>=1;
if (ffsox_stream_interleaved_write(so,pkt)<0) {
DMESSAGE("writing packet");
Maybe Carl Eugen can provide some insight into how to align the time
scales between streams.
I tested and this solve the stuttering for me too, but I have no idea
about the mathematics involved here.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
On 22.06.2015 08:14, Petter Reinholdtsen wrote:
[Peter Belkner]
I've made an educated guess on how to continue: simply skip the
package, and it seems to work smoothly:
How did you test?
I was testing with Winamp and the FFmpeg based "in_ffsox" input plugin.
It was not "stuttering" at all. I discovered "stuttering" only when
testing with VLC player.
Meanwhile I've learned that we have two issues:
1. "20030213-cvs.mpeg" had not processed at all (i.e. just loudness
analysis was aborting with an error and hence it could not have
"stuttered")
2. "DavidGallo_2007.dv" stutters.
The (previous) patch solves the first issue. The idea is to throw away
packages FFmpeg cannot deal with.
After having solved the first issue, "20030213-cvs.mpeg" will also
"stutter". For solving "stuttering" I know have a really "educated"
guess based on the observation that in almost all cases the duration of
processed video files will be double the original length. A further
observation is that the time stamps produced differ by the factor 2
between the video and the audio stream.
The following patch solves "stuttering" (but really is some kind of a
"sledgehammer")
diff -rc ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_writer.c
./bs1770gain-0.4.4-beta3/libffsox-2/ffsox_frame_writer.c
*** ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_writer.c 2015-06-14
18:11:19.0 +0200
--- ./bs1770gain-0.4.4-beta3/libffsox-2/ffsox_frame_writer.c 2015-06-22
09:12:36.0 +0200
***
*** 145,150
--- 145,154
if (0!=*got_packet) {
av_packet_rescale_ts(pkt,cc->time_base,st->time_base);
+ // where do the "magic" factor 0.5 come from?
+ pkt->dts>>=1;
+ pkt->pts>>=1;
+ pkt->duration>>=1;
if (ffsox_stream_interleaved_write(so,pkt)<0) {
DMESSAGE("writing packet");
Maybe Carl Eugen can provide some insight into how to align the time
scales between streams.
I applied the enclosed patch (notice the DMESSAGE) to see how often it
trigger, and processed the MPEG file, and the sound was still
stuttering. This was the output when running bs1770gain:
% ./bs1770gain/bs1770gain 20030213-cvs.mpeg -a -o foo
analyzing ...
[1/1] "20030213-cvs.mpeg": 7%Error decoding audio, skipping audio package:
frame_reader_run(), "ffsox_frame_reader.c" (148).
integrated: -34.7 LUFS / 11.7 LU
transcoding ...
[1/1] "20030213-cvs.mkv" 7%Error decoding audio, skipping audio package:
frame_reader_run(), "ffsox_frame_reader.c" (148).
done.
%
--- bs1770gain-0.4.3.orig/libffsox-2/ffsox_frame_reader.c
+++ bs1770gain-0.4.3/libffsox-2/ffsox_frame_reader.c
@@ -145,8 +145,10 @@ static int frame_reader_run(frame_reader
}
if ((size=avcodec_decode_audio4(cc,frame,&got_frame,pkt))<0) {
-DMESSAGE("decoding audio");
-return -1;
+DMESSAGE("decoding audio, skipping audio package");
+// skip the package.
+pkt->size=0;
+return 0;
}
pkt->size-=size;
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
I've made an educated guess on how to continue: simply skip the package,
and it seems to work smoothly:
diff -rc ./bs1770gain-0.4.3/libffsox-2/ffsox_frame_reader.c
./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_reader.c
*** ./bs1770gain-0.4.3/libffsox-2/ffsox_frame_reader.c 2015-06-14
18:11:19.0 +0200
--- ./bs1770gain-0.4.4-beta2/libffsox-2/ffsox_frame_reader.c 2015-06-22
00:22:18.0 +0200
***
*** 145,152
}
if ((size=avcodec_decode_audio4(cc,frame,&got_frame,pkt))<0) {
! DMESSAGE("decoding audio");
! return -1;
}
pkt->size-=size;
--- 145,153
}
if ((size=avcodec_decode_audio4(cc,frame,&got_frame,pkt))<0) {
! // skip the package.
! pkt->size=0;
! return 0;
}
pkt->size-=size;
On 21.06.2015 23:56, Peter Belkner wrote:
Hi Carl Eugen,
thanks for sharing. The issue under the hood is seems to be that
avcodec_decode_audio4() returns with error "[mp2 @ 0x9e527c0] Header
missing". How to continue in such a case?
Thanks and regards,
Peter
On 21.06.2015 23:09, Carl Eugen Hoyos wrote:
On Sunday 21 June 2015 10:28:55 pm Peter Belkner wrote:
What BS1770GAIN does is best approximated by the following FFmpeg
command (copying the video stream, transcoding the audio stream into
FLAC and muxing both into a MKV container):
$ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y
ffmpeg/20030213-cvs.mkv
$ ffmpeg -fflags +genpts -i 20030213-cvs.mpeg -vcodec copy
-acodec flac out.mkv
Carl Eugen
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
Hi Carl Eugen, thanks for sharing. The issue under the hood is seems to be that avcodec_decode_audio4() returns with error "[mp2 @ 0x9e527c0] Header missing". How to continue in such a case? Thanks and regards, Peter On 21.06.2015 23:09, Carl Eugen Hoyos wrote: On Sunday 21 June 2015 10:28:55 pm Peter Belkner wrote: What BS1770GAIN does is best approximated by the following FFmpeg command (copying the video stream, transcoding the audio stream into FLAC and muxing both into a MKV container): $ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y ffmpeg/20030213-cvs.mkv $ ffmpeg -fflags +genpts -i 20030213-cvs.mpeg -vcodec copy -acodec flac out.mkv Carl Eugen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
What BS1770GAIN does is best approximated by the following FFmpeg command (copying the video stream, transcoding the audio stream into FLAC and muxing both into a MKV container): $ ffmpeg -i sample/20030213-cvs.mpeg -vcodec copy -acodec flac -y ffmpeg/20030213-cvs.mkv FFmpeg aborts with the following error message: [matroska @ 02a9ae00] Can't write packet with unknown timestamp av_interleaved_write_frame(): Invalid argument Google for that error. You will see that it is known for a long time. It's not the aim of BS1770GAIN to work around FFmpeg's bugs (it is impossible anyway). We hope that some day the bugs in FFmpeg will be fixed (a lot of them are meanwhile gone, some fixes I've provided myself.) The best way for organizing your workflow is as a first step before running BS1770gain is to remux all your files into a proper MKV using "mkvmerge". In my opinion, choosing MKV as the intermediate container while working with multimedia files is the best choice anyway. Best regards, Peter ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#789254: This sample seems not to be processable by FFmpeg
BS1770GAIN is based on FFmpeg. If a file is not processable by FFmpeg it
is not processable by BS1770GAIN.
This particular sample file seems not to be processable by FFmpeg. Try
e.g. the following command
$ ffmpeg -i samples/20030213-cvs.mpeg -acodec copy -vcodec copy -y
20030213-cvs.mpeg
The workaround is to pre-process the file first by mkvmerge into an
intermediate MKV file and then process the resulting intermediate MKV
file by BS1770GAIN
$ mkvmerge samples/20030213-cvs.mpeg -o samples/20030213-cvs.mkv
mkvmerge v8.0.0 ('Til The Day That I Die') 64bit
'samples/20030213-cvs.mpeg': Using the demultiplexer for the format 'MPEG
program stream'.
'samples/20030213-cvs.mpeg' track 0: Using the output module for the
format 'MPEG-1/2'.
'samples/20030213-cvs.mpeg' track 1: Using the output module for the
format 'MP3'.
The file 'samples/20030213-cvs.mkv' has been opened for writing.
Warning: 'samples/20030213-cvs.mpeg' track 1: This MPEG audio track
contains 279 bytes of non-MP3 data which were skipped. The audio/video
synchronization may have been lost.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 1 second.
NOTE: Please observe the warning!
$ ./mingw32/bin/bs1770gain ./samples/20030213-cvs.mkv -ao norm
analyzing ...
[1/1] "20030213-cvs.mkv":
integrated: -34.7 LUFS / 11.7 LU
transcoding ...
[1/1] "20030213-cvs.mkv"
done.
Regards,
Peter Belkner
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
