Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

> Am 21.07.2019 um 21:58 schrieb Josh Triplett :
> 
>> On July 21, 2019 11:38:03 AM PDT, James Cowgill  wrote:
>> Hi,
>> 
>>> On 12/03/2019 12:44, Reinhard Tartler wrote:
>>> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos >> <mailto:ceffm...@gmail.com>> wrote:
>>> 
>>>Please show the dependencies of (at least) libavutil and
>> libavcodec
>>>with your approach and maybe compare them to what sdl needs:
>> While the
>>>list may become smaller I wonder if it this would really solve
>> the
>>>described issue.
>>> 
>>> Sure thing, please find the full build log attached to this email.
>>> It details the full metadata at the end of the log.
>> 
>> I've been on a rather long haitus from Debian stuff for a while, t I
>> now
>> have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded
>> next
>> (and by the looks of things 4.2 is just around the corner...)
>> 
>> I see a "fix" for this in the git history, but I think it's broken:
>> 
>> * There is an obvious typo in the d/rules file which prevents the
>> option
>> to disable the SDL output device from taking effect. You can see from
>> the build log attached to this bug report that we still have an SDL
>> dependency.
>> 
>> * Even after fixing that, the dependency remains. I think the "opengl"
>> device backend has a dependency on SDL as well. Disabling that is
>> probably a greater loss?
>> 
>> * With the above two changes (disabling both sdl and opengl), I ran the
>> final packages through dose and compared the dependencies. This is the
>> list of transitive dependencies that no longer need installing after
>> this change:
>> 
>> libsdl2-2.0-0
>> libwayland-client0
>> libwayland-cursor0
>> libwayland-egl1
>> libxcursor1
>> libxinerama1
>> libxkbcommon0
>> libxrandr2
>> libxss1
>> xkb-data
>> 
>> Notice that all of OpenGL, all xcb and core x11 libraries are still
>> required.
>> 
>> The total uncompressed size of these packages is around 8M, with
>> libsdl2-2.0-0 and xkb-data being the only significant packages (the
>> rest
>> are < 100k). Note that xkb-data is installed by default so that saving
>> is probably only relevant for stripped down containers. For comparison,
>> if I install ffmpeg in a build chroot, apt says it will use 418M of
>> extra space.
>> 
>> In conclusion, I don't think the savings this change gives us are worth
>> it, and I don't like disabling features in FFmpeg :)
>> 
>> I think what you really want is an "ffmpeg-nox" package containing a
>> build of the frontend ffmpeg tool with libavdevice completely disabled.
>> I haven't run this in dose, but by dropping this dependency I would
>> expect all the GL / X11 / etc dependencies to also go which would give
>> much better space savings. Probably needs a little more thinking about
>> the way this would be implemented though (and it's relationship with
>> the
>> normal ffmpeg package).
> 
> You're right, that's much more what I'm looking for. This is primarily for 
> headless servers, which primarily need the command line tool and a subset of 
> libraries.

I don’t understand: Didn’t you confirm that you tested the committed solution 
and that it works for you?

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-12 18:48 GMT+01:00, Josh Triplett :
> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:

>> I think this should address the issue. Any objections to this approach?
>
> This would work perfectly for me, and I would then avoid installing
> ffplay on my servers.

I was expecting that the ffmpeg package would still pull a large
number of dependencies including X11 with this change but if
there is an improvement for you, all the better!

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-12 13:25 GMT+01:00, Reinhard Tartler :
> In a headless installation that is used for transcoding and streaming,
> such dependencies, like on X11, wayland, etc. may not be desirable.

Funny that you mention X11 and wayland: Both are still dependencies
of FFmpeg after your patch, no?

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

Please show the dependencies of (at least) libavutil and libavcodec
with your approach and maybe compare them to what sdl needs: While the
list may become smaller I wonder if it this would really solve the
described issue.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

> What might work is disabling the avdevice outdev AND
> moving 'ffplay' to its own binary package.

Before suggesting this, I would prefer the OP to test. I
still do not entirely believe that this fixes his issue.

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-10 23:21 GMT+01:00, Reinhard Tartler :
> On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos  wrote:
>
>> Could you test the configure option "--disable-outdev=sdl2"?
>> Your report indicates it should fix your issue, I am not convinced but
>> if it fixes your issue, Debian should consider using it as the device
>> is mostly a (cheap) debug feature.

> Wouldn't that video break playback in 'ffplay'?

Can you elaborate why you think so?

> at the very least, it would break the "SDL2 output device" in libavdevice.

Obviously.

> I'm not sure if I'd agree with that being a "cheap debug [only] feature".

You don't have to.

> Can you elaborate what makes you think so?

Iirc, I was the only one speaking against its removal.

But given that your avconv project never contained an sdl output
device I wonder what your expertise is here?

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

Hi!

Could you test the configure option "--disable-outdev=sdl2"?
Your report indicates it should fix your issue, I am not convinced but
if it fixes your issue, Debian should consider using it as the device
is mostly a (cheap) debug feature.

Please report back, Carl Eugen

Bug#904052: ffmpeg: FTBFS on hurd-i386: wrong value for --target-os at configure

[Carl Eugen Hoyos]

Hi!

I believe the correct fix is to completely remove --target-os from the
configure line, it should only be used for cross-compilation.

Carl Eugen

Bug#493705: FFmpeg uses text relocations on i386

[Carl Eugen Hoyos]

(Since two bugs were reopened and the status was set to "forwarded":)

Note that there will definitely be no "fix" within FFmpeg, simply
because the FFmpeg developers do not believe that there is a bug that
can be fixed.
If Debian believes there is an issue, it can be fixed quickly: Just
add --disable-asm to the configure line. So definitely no need to
"forward" anything. If you decide to not "fix" the issue, please close
the bug reports (again).

Regarding the claim that "it's worth losing 15% of performance for security":
I (strongly) believe it is worth losing 90% of performance for an
actual security issue, so I am not sure I understand the argument. But
I would also suggest you provide some tests to allow us to reproduce
the numbers if you believe they are relevant. (Both "15%" and "lack of
registers problem" are mostly wrong or not the point.)

Carl Eugen

Bug#884232: ffmpeg: CVE-2017-17555

[Carl Eugen Hoyos]

This is not a bug in FFmpeg:
aubio initializes libswresample with 2 channels and then passes data
that contains just one channel.

That cant really work or how could it ?
swresample has no knowledge about what is in the array except what it
is told
There are multiple ways to provide this information to swr

(Answer from Michael on ffmpeg-security)

Carl Eugen

Bug#882384: ffmpeg: Gratuitous valgrind log

[Carl Eugen Hoyos]

2017-11-25 5:41 GMT+01:00 Kingsley G. Morse Jr. :
> Hi Carl,
>
>> Nearly all messages seem to relate to melt, not FFmpeg.
>
> Thanks for your informed thoughts.
>
>> Can you reproduce any issues with ffmpeg (the executable)?
>>
>> The crc issue surprises me a little: Can you produce different
>> output files if you use the valgrind option --malloc-fill?
>
> Sure.
>
> A script is attached.
>
> It uses ffmpeg, without melt.
>
> I also attached two log files from valgrind.
>
> One ran it with --malloc-fill.

What I meant was:
If you call melt (and valgrind) twice to produce two output files
from the same melt options (but different --malloc-fill) options,
are the output files different?
If not, the valgrind warning could be a false positive.

I don't know melt but from the debug output it looks as if your
ffmpeg command does something different (missing -vcodec
huffyuv?), no?

Carl Eugen

Bug#882598: libavutil55: segfault after upgrade

[Carl Eugen Hoyos]

Hi!

I created FFmpeg ticket #6861, thank you for the report!
https://trac.ffmpeg.org/ticket/6861

Carl Eugen

Bug#882384: ffmpeg: Gratuitous valgrind log

[Carl Eugen Hoyos]

Hi!

Nearly all messages seem to relate to melt, not FFmpeg.

Can you reproduce any issues with ffmpeg (the executable)?

The crc issue surprises me a little: Can you produce different
output files if you use the valgrind option --malloc-fill?

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

Michael has committed a patch that is supposed to fix this crash:
http://ffmpeg.org/pipermail/ffmpeg-cvslog/2017-August/108709.html

Thank you for the useful report!

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

I suspect this is a regression since 31326143 (when the function was added).

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

Hi!

Is this issue still reproducible with current FFmpeg git head?

Carl Eugen

Bug#872517: ffmpeg: CVE-2017-7206: heap-based buffer over-read in embed libav

[Carl Eugen Hoyos]

Hi!

> the following vulnerability was published for libav

> (which is embed in ffmpeg).

This is not true.

Please provide valgrind or asan output (both show the 
issue easily for some avconv releases) for any 
affected FFmpeg version or close this issue.

Carl Eugen

Bug#856100: libav-tools : concat Protocol not found

[Carl Eugen Hoyos]

Hi!

Several similar bugs (features missing from avconv in Debian) were closed 
as "fixed" when Debian switched to FFmpeg: How is this report different?

As an alternative, this could be reassigned to "libav-doc".

Thank you, Carl Eugen

Bug#839941: whishlist ffmpeg

[Carl Eugen Hoyos]

Hi!

I wonder if "confirmed" is really the right status:
There is absolutely no way that this can be fixed within 
Debian, the license of the necessary header files is 
certainly not compatible with any open-source license.

I suggest to close as wont-fix or invalid.

Carl Eugen

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Carl Eugen Hoyos]

The relevant lines in the build log are afaict:

src/libavformat/chromaprint.c: In function 'write_packet':
src/libavformat/chromaprint.c:113:1: error: control reaches end of non-void 
function [-Werror=return-type]
 }
 ^

The function looks like this:

static int write_packet(AVFormatContext *s, AVPacket *pkt)
{
ChromaprintMuxContext *cpr = s->priv_data;
return chromaprint_feed(cpr->ctx, pkt->data, pkt->size / 2) ? 0 : 
AVERROR(EINVAL);
}

I guess this is a compiler bug.

Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Hi Bálint!

> I went throught the unclassified bugs and set the 
> proper state to help tracking them.

This bug (#831591) and #832364 contain neither backtrace 
nor bisect. Note that they most likely have to be fixed 
in Kodi, FFmpeg will (afaict) not break ABI once more 
for the 3.1 release series to work-around bugs in other 
projects.
(This analysis may of course be wrong but we cannot 
know better so far.)

Bug #797965 contains no sample, I cannot reproduce.
(Same for #833722 and #797963 which are marked as 
needs-more-info.)

Bug #810224 is invalid: Behaviour is exactly as 
requested by you, my original analysis was wrong.

I do not understand why it makes sense to keep #493705 
and #528080 open: I believe Debian decided many years 
ago that they will not be fixed, FFmpeg has repeated 
its opinion that there is no bug last year (when 
Google stopped allowing such binaries in Android).
(If you want you can fix both bugs anytime by adding 
--disable-asm to the configure options for x86_32.)

I have fixed #785690 upstream today, don't know how 
you proceed with the report here.
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3e886e7

Thank you, Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Hi!

> Knowing what broke could be
> interesting for FFmpeg devs

It would most likely be even more interesting 
for the Kodi developers: We currently assume 
that there is an unknown bug in Kodi...

> > Slightly related: More that half of the open tickets
> > concerning FFmpeg in Debian either contain no samples to
> > reproduce or will not be fixed or were never reproducible.
> > If another FFmpeg developer were interested in fixing
> > bugs reported here it would be very difficult for him to
> > find something useful due to the low snr.
>
> Those can be marked with the moreinfo tag and IMO it is
> OK to close them after a reasonable amount of time if
> the originator is asked to provide a test file but she/he
> did not.

Are five months enough?

Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Hi Bálint!

> I don't have the test file.

In this case I suggest to close the relevant tickets:
We cannot reproduce, there is no backtrace and no bisect.

Since FFmpeg has made three point releases with the ABI 
that is apparently incompatible with (old) Kodi, it is 
very unlikely that it will be changed again (we would 
likely brake mpv that intentionally uses the invalid API).

Slightly related: More that half of the open tickets 
concerning FFmpeg in Debian either contain no samples to 
reproduce or will not be fixed or were never reproducible.
If another FFmpeg developer were interested in fixing 
bugs reported here it would be very difficult for him to 
find something useful due to the low snr.

Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Hi!

> 2016-08-24 22:55 GMT+02:00 Carl Eugen Hoyos :
> >
> > First, please understand that so far, no ABI breakage between
> > FFmpeg 3.0 and FFmpeg 3.1 was found, only the usage of
> > non-public api (that we decided to work-around for 3.1.1).
>
> OK, then assume that Kodi uses non-public API and the rebuild 
> made kodi use the latest ABI.

I don't know!
I just wanted to point out that so far, the "bugs" that were 
worked-around in FFmpeg 3.1.1 were bugs in other applications.

I still do not understand completely: Is the crash still reproducible 
after recompiling Kodi or not?

> Can I somehow find easily the places where the non-public API is used?

I don't know but...

> > Am I correct that no backtrace was provided for this issue?
>
> Yes, AFAIK.

... adding a backtrace should work fast, no?
If another developer looks at the backtrace, he might know what the 
issue is.

> > But even with a backtrace, I fear a bisect may be necessary.

Bisecting FFmpeg takes less than 20 minutes here, I know it would take 
you longer but if the backtrace does not help, this is the only way to 
find out what the issue is.
I can try helping to create a specific configure line to speed up the 
backtrace.

Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Hi!

First, please understand that so far, no ABI breakage between 
FFmpeg 3.0 and FFmpeg 3.1 was found, only the usage of 
non-public api (that we decided to work-around for 3.1.1).

Am I correct that no backtrace was provided for this issue?
But even with a backtrace, I fear a bisect may be necessary.

Sorry, Carl Eugen 

Bug#833722: ffmpeg: can hear music but no sound/dialogs from movie

[Carl Eugen Hoyos]

Hi!

How can the issue you see be reproduced?
Is it a regression?
The console output does not necessarily look FFmpeg-related:
Why do you believe that the issue can be fixed within FFmpeg?

Carl Eugen

Bug#591904: libavcodec52: text relocations on AMD64

[Carl Eugen Hoyos]

Hi!

This bug was fixed upstream some time before the issue was reported to Debian:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3d05c1fb

Please reassign or close, Carl Eugen

Bug#831529: libavcodec57: broken option parsing with LANGs with decimal mark different from .

[Carl Eugen Hoyos]

Hi!

Please someone test attached patch, I cannot reproduce on any of my systems.

Thank you, Carl Eugen
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 979cf37..5bed4e4 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -1323,10 +1323,10 @@ static const AVCodecDefault 
vaapi_encode_h264_defaults[] = {
 { "b",  "0"   },
 { "bf", "2"   },
 { "g",  "120" },
-{ "i_qfactor",  "1.0" },
-{ "i_qoffset",  "0.0" },
-{ "b_qfactor",  "1.2" },
-{ "b_qoffset",  "0.0" },
+{ "i_qfactor",  "1"   },
+{ "i_qoffset",  "0"   },
+{ "b_qfactor",  "6/5" },
+{ "b_qoffset",  "0"   },
 { NULL },
 };
 
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 1ef968c..45f6f6d 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1341,10 +1341,10 @@ static const AVCodecDefault 
vaapi_encode_h265_defaults[] = {
 { "b",  "0"   },
 { "bf", "2"   },
 { "g",  "120" },
-{ "i_qfactor",  "1.0" },
-{ "i_qoffset",  "0.0" },
-{ "b_qfactor",  "1.2" },
-{ "b_qoffset",  "0.0" },
+{ "i_qfactor",  "1"   },
+{ "i_qoffset",  "0"   },
+{ "b_qfactor",  "6/5" },
+{ "b_qoffset",  "0"   },
 { NULL },
 };
 

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Carl Eugen Hoyos]

Thank you for the backtrace!

Could you check if removing some or all entries from 
vaapi_encode_h264_defaults in libavcodec/vaapi_encode_h264.c 
fixes the issue? I was unable to quickly find the vaapi 
source file containing the option strings and I don't 
have a cpu with vaapi capabilities.

Thank you, Carl Eugen

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Carl Eugen Hoyos]

If the issue is reproducible, please someone test if it disappears once you 
recompile GStreamer against the installed libavcodec headers.

Bug#831591: ffmpeg: kodi crash

[Carl Eugen Hoyos]

Kodi reports "FFmpeg version: 3.0.1-3":
Could somebody test if the crash disappears after Kodi gets recompiled against 
current FFmpeg?

Bug#591904: libavcodec52: text relocations on AMD64

[Carl Eugen Hoyos]

Is this still reproducible?
Why is this an issue? I don't remember that this was ever reported upstream 
(text relocations on x86-32 are reported on a regular basis).

Carl Eugen

Bug#493705: ffmpeg-debian: Libraries have text relocations

[Carl Eugen Hoyos]

Same as for #528080: This will not be fixed in FFmpeg upstream, so I suggest 
to close as wont-fix.

Carl Eugen

Bug#528080: ffmpeg-debian: ffmpeg still has shlib-with-non-pic-code lintian errors

[Carl Eugen Hoyos]

Different FFmpeg developers have explained repeatedly (including recently) 
that this will not be fixed within FFmpeg, so I suggest to close this bug 
report as wont-fix.

Carl Eugen

Bug#624436: libavcodec52: Fails to read an ogg video (DRI failure)

[Carl Eugen Hoyos]

This bug report looks incomplete: No backtrace, disassembly and register dump 
and no sample: Please close.

Carl Eugen

Bug#591832: mplayer: hangs on playing ogv (vp3) video with "Invalid frame duration value"

[Carl Eugen Hoyos]

I cannot reproduce this issue with current MPlayer, I suspect this was fixed 
years ago: Please close this ticket.

Carl Eugen

Bug#677035: libavcodec52: SEGV when encoding video

[Carl Eugen Hoyos]

This issue was fixed five years ago in FFmpeg, please close this bug.

Bug#609271: segfault when loading some jpeg files

[Carl Eugen Hoyos]

Please close this ticket as no sample was ever provided.

Carl Eugen

Bug#625944: libavcodec52: JPEG produced with Intel JPEG lib loaded upside-down

[Carl Eugen Hoyos]

This issue was fixed five years ago in FFmpeg, please close.

Carl Eugen

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

[Carl Eugen Hoyos]

Hi!

If you want me to forward this bug to other FFmpeg developers, please:
* Provide sample(s) that allow to reproduce the issue
and
* The ffmpeg command line that allows to reproduce the issue together with 
the complete, uncut console output

and
* explain what is wrong with the output file.

If you cannot (or don't want to) provide all three, I suggest to close 
this bug because I don't see how it can be fixed without it.
(Or at least it wouldn't be known on this bug tracker if the issue ever 
gets fixed.)


If the issue is not reproducible with the ffmpeg command line tool but 
only for an API user, things get more complicated but in this case you 
should try hard to rule out a bug in the tool using the API.


Carl Eugen

Bug#823098: ffmpeg: autopkgtests failing: aac probing failed

[Carl Eugen Hoyos]

Hi!

I sent a patch that probably fixes this issue, very short transport streams 
were never auto-detected by FFmpeg.
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/193698.html

Possible workarounds are to increase the audio length with "sine=d=0.2" or 
to set an explicit audio bitrate of 128k with "-b:a 128k" (this was the 
bitrate in FFmpeg 2.8, when the aac encoder was still experimental) to 
increase the output file size.

Thank you, Carl Eugen

Bug#810224: /usr/bin/avconv: ogg format: unable to use pass and quality? options together

[Carl Eugen Hoyos]

On Friday 26 February 2016 10:42:14 pm you wrote:
> Hi Carl,
>
> On Thu, 25 Feb 2016 13:55:52 +0100 Carl Eugen Hoyos 
>
> wrote:
> > Hi!
> >
> > When encoding with FFmpeg, you can either use fixed quality or fixed
> > bitrate (size), if you decide to use fixed bitrate, two-pass encoding
> > improves the output quality.
> > It makes no sense to use two-pass constant quality encoding, the result
> > of using two contradicting options is undefined.
> >
> > Please close this ticket as invalid.
>
> I think if two options a contradicting then ffmpeg should refuse
> accepting them instead of starting the conversion of the file.
> IMHO this is a valid upstream bug, but upstream can decide to leave it
> unfixed, of course.
>
> What do you think?

That my original comment was simply wrong.

Using two-pass encoding for constant quality is not undefined behaviour, it 
works fine here with all native encoders I tested producing two identical 
output files. I don't think this should be changed: While it makes little 
sense, I don't think it is an issue that FFmpeg accepts two-pass constant 
quality encoding.

When using libtheora, two-pass encoding only accepts constand bitrate, trying 
two-pass encoding with constant quality leads to an error.
I believe this is exactly what you requested.

Carl Eugen

Bug#797963: bs1770gain: support writing Apple SoundCheck tags

[Carl Eugen Hoyos]

Hi!

Please provide a sample so I can open an enhancement request in the FFmpeg bug 
tracker.

Thank you, Carl Eugen

Bug#811519: vlc: avio plugin leaks file content

[Carl Eugen Hoyos]

Can this bug be closed if no additional information gets added?

Thank you, Carl Eugen

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

[Carl Eugen Hoyos]

Hi!

If I understand correctly, no sample and no command line including complete, 
uncut console output was ever provided for this bug report.

If this is correct, please close as needs-more-information.

Thank you, Carl Eugen

Bug#819266: ffmpeg: rtmp is broken

[Carl Eugen Hoyos]

On Friday 25 March 2016 07:19:35 pm you wrote:
> Package: ffmpeg
> Version: 7:2.8.6-1+b2
> Severity: normal

> something about rtmp is broken in ffmpeg as shipped in Debian.
> For example, the Revision RTMP streams
>  do not work in either MPV or VLC.
> However, after building mpv and ffmpeg using mpv-build
> , the streams *do* work -- and
> since MPV and VLC shows the same error, I suspect ffmpeg is the culprit
> here.

Sorry to say but this does not seem like a useful bug report: Did you test 
at all with FFmpeg?

> $ mpv 'rtmp://revision.scenesat.com/live/mainhall'

This url works fine here both with current FFmpeg and FFmpeg 2.8

Carl Eugen

$ ffmpeg -i rtmp://revision.scenesat.com/live/mainhall -qscale 2 out.avi
ffmpeg version N-79134-g4d25172 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil  55. 19.100 / 55. 19.100
  libavcodec 57. 30.100 / 57. 30.100
  libavformat57. 29.101 / 57. 29.101
  libavdevice57.  0.101 / 57.  0.101
  libavfilter 6. 40.102 /  6. 40.102
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
[flv @ 0x20ad3c0] audio stream discovered after head already parsed
Input #0, flv, from 'rtmp://revision.scenesat.com/live/mainhall':
  Metadata:
author  :
copyright   :
description :
keywords:
rating  :
title   :
presetname  : Custom
creationdate: Fri Mar 25 21:25:32 2016
:
videodevice : AVerMedia HD Capture
avclevel: 32
avcprofile  : 77
videokeyframe_frequency: 5
audiodevice : AVerMedia HD Audio Cap (AVerMed
audiochannels   : 2
audioinputvolume: 75
  Duration: N/A, start: 0.00, bitrate: 1328 kb/s
Stream #0:0: Video: h264 (Main), yuv420p(tv), 960x540 [SAR 1:1 DAR 16:9], 
1200 kb/s, 30.30 fps, 29.97 tbr, 1k tbn, 60 tbc
Stream #0:1: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out.avi':
  Metadata:
author  :
ICOP:
description :
keywords:
rating  :
INAM:
presetname  : Custom
creationdate: Fri Mar 25 21:25:32 2016
:
videodevice : AVerMedia HD Capture
avclevel: 32
avcprofile  : 77
videokeyframe_frequency: 5
audiodevice : AVerMedia HD Audio Cap (AVerMed
audiochannels   : 2
audioinputvolume: 75
ISFT: Lavf57.29.101
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 960x540 [SAR 1:1 
DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
  encoder : Lavc57.30.100 mpeg4
Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1
Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 44100 Hz, stereo, fltp, 192 
kb/s
Metadata:
  encoder : Lavc57.30.100 ac3
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg4 (native))
  Stream #0:1 -> #0:1 (mp3 (native) -> ac3 (native))
Press [q] to stop, [?] for help
frame=  606 fps= 31 q=2.0 Lsize=   10002kB time=00:00:20.58 
bitrate=3980.4kbits/s dup=0 drop=140 speed=1.06x
video:9481kB audio:482kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.383157%

Bug#810224: /usr/bin/avconv: ogg format: unable to use pass and quality? options together

[Carl Eugen Hoyos]

Hi!

When encoding with FFmpeg, you can either use fixed quality or fixed bitrate 
(size), if you decide to use fixed bitrate, two-pass encoding improves the 
output quality.
It makes no sense to use two-pass constant quality encoding, the result of 
using two contradicting options is undefined.

Please close this ticket as invalid.

Carl Eugen

Bug#815673: ffmpeg: VP9 seek broken in ffplay

[Carl Eugen Hoyos]

On Tuesday 23 February 2016 03:43:50 pm you wrote:
> I have encoded a video as VP9 using ffmpeg with the following settings
> and I am unable to seek forward in the video (tested with mpv and
> ffplay).

This bug in libvpx is being fixed by setting a more useful default for 
maximum key frame interval:
https://chromium-review.googlesource.com/#/c/329320/

Please reassign this issue to the libvpx package.

Thank you for the report, Carl Eugen

Bug#814807: ffmpeg: FTBFS on mips

[Carl Eugen Hoyos]

Hi!

I am looking at 
http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/tags/n2.8.6 but I 
don't see a commit that may have affected roq audio encoding or muxing.
Are you able to test 2.8.5 with gcc-5_5.3.1-7 or 2.8.6 with gcc-5_5.3.1-6?

Carl Eugen

Bug#809955: mplayer: FTBFS with libpng16

[Carl Eugen Hoyos]

Hi!

Please just remove the build dependency for libpng from MPlayer:
There is no file for which the libpng decoder is used by default 
when running MPlayer and the existing default decoder ffpng is 
supposed to support more files than MPlayer's libpng decoder.

Carl Eugen

Bug#798189: rtmp inside m3u don't supported anymore

[Carl Eugen Hoyos]

Hi!

I believe this is FFmpeg ticket #4797, thank you for the sample CNN.m3u that I 
attached there!
https://trac.ffmpeg.org/ticket/4797
The samples WTV-9.m3u and twIT.m3u work fine here, I cannot reproduce an issue 
for them.

Carl Eugen

Bug#798189: rtmp inside m3u don't supported anymore

[Carl Eugen Hoyos]

Hi!

> I have widely used m3u playlists contained http live streams as well as
> rtmp ones. But after upgrading from 6:11.4-2 to 7:2.7.2-2 version only http
> supported

How can I reproduce this issue?

Carl Eugen

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

[Carl Eugen Hoyos]

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

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.

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

[Carl Eugen Hoyos]

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#692876: Debian bug report 692876

[Carl Eugen Hoyos]

Hi!

On Mon, 18 Mar 2013, Paul Gevers wrote:


On 18-03-13 00:53, Carl Eugen Hoyos wrote:

On 17-03-13 10:33, Carl Eugen Hoyos wrote:

I would like to test, could you provide the sample test.avi ?

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=test.avi;att=1;bug=692876

I tried several (very different) applications, none recognizes the file
type (and I am therefore unable to reproduce your problem).
Could you confirm / Are you sure that the sample you found the original
issue with is the same than the one you uploaded?


I confirm that this is NOT the file that I use to test. Mine is 288476 B
and has md5sum e2118dd2933edaedea4898cd6217e4f6 and is attached to this
message. I have no idea how the file in the bts got corrupted.


Thank you for the updated sample!

It appears that your problem is not reproducible with current FFmpeg, nor 
any releases, see http://ffmpeg.org/download.html


While this issue will certainly be fixed quickly in avconv, please 
remember that this is only one of several hundred known (user-reported) 
regressions in avconv over FFmpeg.


Carl Eugen


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