<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 22.06.2015 09:55, Petter Reinholdtsen wrote:<br>
<blockquote cite="mid:2fl1th4fa8x.fsf@diskless.uio.no" type="cite">
<pre wrap="">[Peter Belkner]
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Aha.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">The (previous) patch solves the first issue. The idea is to throw away
packages FFmpeg cannot deal with.
</pre>
</blockquote>
<pre wrap="">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.</pre>
</blockquote>
<br>
The FFmpeg example "ffmpeg/doc/examples/decoding_encoding.c" aborts
in such a case:
<blockquote>
<pre>len = avcodec_decode_audio4(c, decoded_frame, &got_frame, &avpkt);
if (len < 0) {
fprintf(stderr, "Error while decoding\n");
exit(1);
}</pre>
</blockquote>
On the other hand the FFmpeg program silently deals with the file.<br>
<br>
I don't think that it is a good idea to let BS1770GAIN re-implemet
large portions of FFmpeg.<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:2fl1th4fa8x.fsf@diskless.uio.no" type="cite">
<pre wrap="">
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?
</pre>
<blockquote type="cite">
<pre wrap="">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.000000000 +0200
--- ./bs1770gain-0.4.4-beta3/libffsox-2/ffsox_frame_writer.c 2015-06-22 09:12:36.000000000 +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.
</pre>
</blockquote>
<pre wrap="">I tested and this solve the stuttering for me too, but I have no idea
about the mathematics involved here.
</pre>
</blockquote>
<br>
</body>
</html>