Bug#942734: bs1770gain does not escape file names properly in XML output

2022-09-25 Thread Peter Belkner 

Hi Petter,

finally, I've published a respective ß-version: 
http://pbelkner.de/projects/files/bs1770gain/bs1770gain/0.8.5-beta-2/.


Best regards

Peter


On 22.09.2022 09:42, Petter Reinholdtsen wrote:

[Peter Belkner]

I consider this a dilemma: readable vs. syntactical correct output. For
those who prefer syntactical correct output over readable output I
introduced a variant to option '--xml': '--xml=cdata'. Because this
breaks backward compatibility by introducing CDATA sections to the
output I hesitate  from making it default.

To me that is a ridiculous dilemma, as XML is not really human readable
and only fit for machine consumtion and thus need to be syntactical
correct XML.  If you want humans to read it, do not use XML. :)

Bug#942734: bs1770gain does not escape file names properly in XML output

2022-09-22 Thread Peter Belkner 

Hi Petter,

I consider this a dilemma: readable vs. syntactical correct output. For 
those who prefer syntactical correct output over readable output I 
introduced a variant to option '--xml': '--xml=cdata'. Because this 
breaks backward compatibility by introducing CDATA sections to the 
output I hesitate  from making it default.


Best regards

Peter



On 19.09.2022 19:20, Petter Reinholdtsen wrote:

[Etienne Dechamps 2019-10-20]

Version: 0.6.5-1

Steps to reproduce:

$ sox -n '1 & 2.wav' synth 1 sine 1000
$ bs1770gain --xml --suppress-progress . | xmllint -
-:3: parser error : xmlParseEntityRef: no name
 
  ^

Correct escaping would be "1  2.wav".

This is a regression from bs1770gain 0.5.2-2, which did escape file names.

There is a non-fatal test for this in debian/tests/ now, and I see from
the latest run on amd64 that it is still a problem.  From
https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bs1770gain/26130724/log.gz 
>:

-:2: parser error : xmlParseEntityRef: no name
   
^
error: xmllint rejected XML output with ampersant in filename

Peter, any chance to have proper escaping in the XML output?

Bug#998779: bs1770gain: bashism in configure script

2022-09-20 Thread Peter Belkner 

Hi Petter,

I've tested it with all '=' replaced by '==' and it seemed to be ok.

Many thanks

Peter


On 20.09.2022 07:11, Petter Reinholdtsen wrote:

[Peter Belkner]

is the intention of your patch to substitute all single comparison
singes ('=') by double comparison singes ('==')?

My intention with the patch was the other way, to replace 'test x == y'
with 'test x = y', as he latter is POSIX notation, while the former is
bash notation.  See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html >


I'm asking because on my site 'configure' is derived an hence
unfortunately I cannot simply apply your patch.

Note, my patch was for configure.ac, the source of configure.

Bug#998779: bs1770gain: bashism in configure script

2022-09-19 Thread Peter Belkner 

Hi Petter,

thank you for the clarification!

Best regards

Peter



On 20.09.2022 07:11, Petter Reinholdtsen wrote:

[Peter Belkner]

is the intention of your patch to substitute all single comparison
singes ('=') by double comparison singes ('==')?

My intention with the patch was the other way, to replace 'test x == y'
with 'test x = y', as he latter is POSIX notation, while the former is
bash notation.  See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html >


I'm asking because on my site 'configure' is derived an hence
unfortunately I cannot simply apply your patch.

Note, my patch was for configure.ac, the source of configure.

Bug#883198: Fixed

2018-07-29 Thread Peter Belkner 
For details refer to 
http://bs1770gain.sourceforge.net/index.html#0.5.0-beta-1


Peter

Bug#881132: Fixed

2018-07-29 Thread Peter Belkner 
For details refer to 
http://bs1770gain.sourceforge.net/index.html#0.5.0-beta-1


Peter

Bug#881131: Fixed

2018-07-29 Thread Peter Belkner 
For details refer to 
http://bs1770gain.sourceforge.net/index.html#0.5.0-beta-1


Peter

Bug#810563: bs1770gain: FTBFS with FFmpeg 2.9/3.0 (Werror)

2016-03-06 Thread Peter Belkner 

[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

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner 



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

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner 

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

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

2015-12-19 Thread Peter Belkner 

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.

Bug#797965: BS1770GAIN

2015-09-05 Thread Peter Belkner 

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

Bug#790349: bs1770gain: Fail to build when clock_t is not long int

2015-06-28 Thread Peter Belkner 

Many thanks.

On 28.06.2015 13:23, Petter Reinholdtsen wrote:

Based on the information available from
URL: 
http://stackoverflow.com/questions/1083142/what-s-the-correct-way-to-use-printf-to-print-a-clock-t
 ,
refering to
URL: 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

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-24 Thread 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?


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.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-24 Thread 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.



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.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-24 Thread Peter Belkner 
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-capabilitiesCODEC_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 (0nb_samplesav_frame_get_buffer(frame,0)0) {
DMESSAGE(allocating frame buffer);
goto buffer;
  }

  return 0;
   // cleanup:
   buffer:
  ffsox_frame_cleanup(f);
   frame:
  return -1;
   }

This 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/.

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-24 Thread Peter Belkner 



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;chchannels;++ch) { \
-rp[ch]=(R *)p-fr-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;chchannels;++ch) { \
-rp[ch]=(T *)p-fr-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=1argc?(pull_cb_t)argv[1]:NULL;
 priv-data=2argc?(void *)argv[2]:NULL;

 return SOX_SUCCESS;
   }

I do not quite understand why a char * is used to store a function
pointer, and am thus reluctant to add (void*) until it is analyzed a bit
better.


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.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789250: Generating audio with SoX

2015-06-24 Thread Peter Belkner 

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/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-24 Thread Peter Belkner 
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



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789250: bs1770gain: Fail to build on archs with strict alignment requirements

2015-06-23 Thread Peter Belkner 

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/.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-22 Thread Peter Belkner 

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.

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-22 Thread Peter Belkner 

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

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-22 Thread Peter Belkner 

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;

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-21 Thread Peter Belkner 
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

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-21 Thread Peter Belkner 

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




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-21 Thread Peter Belkner 
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

Bug#789254: This sample seems not to be processable by FFmpeg

2015-06-21 Thread Peter Belkner 
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