Re: [FFmpeg-devel] how to flush audio delayed frames
On 30.07.2015, at 13:49, qw wrote: > avcodec_encode_audio() is used to encode audio frame. How to flush audio > delayed frames in audio encoder? This is the wrong list for that kind of question. But look for "flushing" in the avcodec_encode_audio2 documentation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015, at 17:05, Andreas Cadhalpun wrote: > Hi, > > On 28.07.2015 15:36, Vittorio Giovara wrote: >> This set contains the removal of all deprecated features marked as >> such until 2012/early 2013. This was announced several times in the >> past months and agreed at several meetings (since fosdem and recently >> at the sprint). >> >> With more than two year span, downstream users should have had enough >> time to update their API usage (or comment otherwise). > > Unfortunately this is just wishful thinking. > As it is, your proposed removal of deprecated features is going to break > about three quarters of all packages using the libav* libraries in Debian: > > FF_API_PIX_FMT: 57 > amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch > ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils > gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid > hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265 > libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 opal > openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg sflphone > strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av > zoneminder > > FF_API_AVFRAME_LAVC: 19 > acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo > goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek > squeezelite vcmi vlc xine-lib-1.2 > > FF_API_AUDIOCONVERT: 5 > alsa-plugins cantata ffdiaporama moc mpv > > FF_API_DESTRUCT_PACKET: 1 > openmw > > FF_API_AVFILTERBUFFER: 1 > pianobar > > Note that this is only counting one API per packet. Hm, so all those PIX_FMT cases might hide a lot of other issues? I think that one isn't a real issue as it hardly has any maintenance cost (I think I fixed MPlayer now though). Can we potentially get lists for each, to see if we can put pressure on certain projects so we can get rid of the worst? > Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC > still is, it might make sense to delay their removal. If the list was complete, I wouldn't say AVFRAME is that widespread, a bit of pushing might work still... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavformat/dsfdec: Error dsf_read_header fixed.
01.08.2015 у 05:42 Ganesh Ajjanagadde напісаў:
On Fri, Jul 31, 2015 at 9:29 PM, Peter Ross wrote:
On Fri, Jul 31, 2015 at 08:56:49PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
wrote:
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk wrote:
Sample rate is written "as is" in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
st->codec->channels = avio_rl32(pb);
-st->codec->sample_rate = avio_rl32(pb) / 8;
+st->codec->sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st->codec->codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
I really need to stop trusting these spec files that much,
they are often incomplete as in this case. Ironically,
wikipedia here gives a much better description of the format:
https://en.wikipedia.org/wiki/Direct_Stream_Digital,
where they mention that essentially this signal is oversampled by a factor of 8.
As the wiki entry indicates, max frequency of PCM is 352.8 kHz.
In fact, I think previous patch should be reverted:
the wikipedia article says that newer format is called "DSD-wide" and
uses 8-bit word length.
ffprobe yields the downsampled frequency of 352.8 kHz which is what
actually gets used when one demuxes/
operates on the data per wikipedia.
Thus, I believe previous behavior was correct.
converting between DSD->PCM reduces the sample rate by 8.
at present, the DSD->PCM conversion happens libavcodec/dsddec.c.
however, a 'codec' cannot change sample_rate, so the divide by 8 is performed
earlier in libavformat.
yes, this is a hack.
i have a patch set that moves DSD->PCM conversion into swresample, where it
belongs,
along with adding a DST decoder and support for additional file formats.
If anyone is interested, I can repost.
Was there a reason why previous patch set was ignored or not applied?
(Relevant mailing list link would help to get a sense for it).
At the minimum though, this hack should have relevant comments for it
in the source code.
This would have removed some of the confusion.
Peter, thank you for your reply. Now I understand why you have to
divided it by 8. However, upon your message problem still remains.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: Add myself as maintainer for dxva2 and Windows/MSVC
I have been (partially) taking care of these for a while now, so might as well formalize it. --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c14a199..89083bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -300,7 +300,7 @@ Codecs: Hardware acceleration: crystalhd.c Philip Langdale - dxva2*Laurent Aimar + dxva2*Hendrik Leppkes, Laurent Aimar libstagefright.cppMohamed Naufal vaapi*Gwenole Beauchesne vda* Sebastien Zwickert @@ -550,7 +550,7 @@ Amiga / PowerPC Colin Ward Linux / PowerPC Luca Barbato Windows MinGW Alex Beregszaszi, Ramiro Polla Windows Cygwin Victor Paesa -Windows MSVCMatthew Oliver +Windows MSVCMatthew Oliver, Hendrik Leppkes Windows ICL Matthew Oliver ADI/Blackfin DSPMarc Hoffman Sparc Roman Shaposhnik -- 1.9.5.msysgit.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
Hi folks, Since Michael decided to step down as a leader, the question of reunification with Libav came up once more naturally. Before negotiations start again, I think it's important if we can all individually start thinking about what are our conditions or expectations from a potential reunification, and what we are willing to concede in the process. The purpose of the operation is to start a debate with a very good overview for everyone about what is still going wrong and what are the priorities in solving the matter. The Libav project has been encouraged to do the same by Jean-Baptiste Kempf and myself, and at least some of the developers seem to be willing to play the game. The VDD are coming soon¹, and while I personally hate these real life meetings more than probably most of the people here on this mailing list, I think with recent the events (Michael leadership, but also stuff like FFmpeg being back as default in all the distributions) and the help of this "mental preparation" (or whatever you want to call it), we finally have a great opportunity to put an end to this extremely toxic environment for our common users and developers from both projects. So I'd call for everyone to come, even though I have many doubts about this. In order to illustrate what I'm selfishly expecting from this operation, I'll start here with my own list. Keep in mind that it's not so much for discussing it right now, and certain points are meant to be very personal and in disagreement with probably a number of current FFmpeg developers. We are just setting up pieces on the board for a future discussion. Highest: - Using the current FFmpeg source code as the code base for the common project. This is the most important point. There are many arguments toward this, but I think the main one is that we do not want to loose anything of the last years of development from many FFmpeg developers. The amount of work done by everyone is surreal, and it would be a huge mistake to think that we can re-do all of this based on a old code base or on Libav code without losing code history, gaining regressions, and losing people because they won't work on an incomplete codebase for a very long time. Which leads me to my next point: - After we come to an agreement, both FFmpeg and Libav must freeze their respective repository. That way, everyone is forced to work on a common project, or has to fork properly in case of a disagreement (by changing not only the project name but also the library names etc). This will prevent losing something from the past years for both projects. Medium: - While I have no real opinion on whether a leader is needed, I think it really helps when you don't have a process that prevent any development dead lock. The decision machine must not stop. Since we all agree there is no one currently that can take the position of a leader in FFmpeg, and there isn't really any on Libav, creating a working development process looks like a priority to me. I do not believe at all in review blocking in the current Libav state for several reasons, and I don't think FFmpeg is perfect in that regard, especially with no more decision maker. So there is room for discussion here. A middle ground between the two would involve talking about maintainership areas, and common sense about trust and power on these areas. Typically, I would like to avoid having to wait for a meaningless review on a patch for code only I know. Again, I'm fine doing concessions here but I think the terms need to be discussed. - 2011 is our Godwin point. It needs to stop being mentioned for the sanity of everyone, so developers of the new project would need to stand against other developers and users to stop the discussion ASAP when it appears. - One of the main collateral damage for the FFmpeg codebase is the duplicated features (prores, avr/swr, and more), and I'm willing to make this a priority on my TODO list for the sake of the new project, but I would like to see more people standing here, especially when they are concerned by these areas. - Redefine how we make evolution on the API: while there are indeed very different approaches to how API evolve in both projects, I think it is really mainly a consequence of politics (for compatibility FFmpeg had many trouble engaging in API evolution for instance), and I think we can come up with new methods and how to deal with that. So basically, this is a touchy topic, but it is because even our users disagree with this (some want to trash many stuff, and some want to keep them forever) more than a disagreement between FFmpeg and Libav developers. I'm looking forward many benefits in this reunification, such as finally being able to end my long struggle with the subtitles API that I couldn't really change for years. - We should probably keep our bug tracker since it reflects bugs on the FFmpeg code base. Pr
Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
On Sat, Aug 1, 2015 at 11:18 AM, Clément Bœsch wrote: > Hi folks, > > Since Michael decided to step down as a leader, the question of > reunification with Libav came up once more naturally. Before negotiations > start again, I think it's important if we can all individually start > thinking about what are our conditions or expectations from a potential > reunification, and what we are willing to concede in the process. > > The purpose of the operation is to start a debate with a very good > overview for everyone about what is still going wrong and what are the > priorities in solving the matter. The Libav project has been encouraged to > do the same by Jean-Baptiste Kempf and myself, and at least some of the > developers seem to be willing to play the game. > > The VDD are coming soon¹, and while I personally hate these real life > meetings more than probably most of the people here on this mailing list, > I think with recent the events (Michael leadership, but also stuff like > FFmpeg being back as default in all the distributions) and the help of > this "mental preparation" (or whatever you want to call it), we finally > have a great opportunity to put an end to this extremely toxic environment > for our common users and developers from both projects. So I'd call for > everyone to come, even though I have many doubts about this. > > In order to illustrate what I'm selfishly expecting from this operation, > I'll start here with my own list. Keep in mind that it's not so much for > discussing it right now, and certain points are meant to be very personal > and in disagreement with probably a number of current FFmpeg developers. > We are just setting up pieces on the board for a future discussion. > > > Highest: > > - Using the current FFmpeg source code as the code base for the common > project. > > This is the most important point. There are many arguments toward this, > but I think the main one is that we do not want to loose anything of the > last years of development from many FFmpeg developers. The amount of > work done by everyone is surreal, and it would be a huge mistake to > think that we can re-do all of this based on a old code base or on Libav > code without losing code history, gaining regressions, and losing people > because they won't work on an incomplete codebase for a very long time. > Which leads me to my next point: > > - After we come to an agreement, both FFmpeg and Libav must freeze their > respective repository. > > That way, everyone is forced to work on a common project, or has to fork > properly in case of a disagreement (by changing not only the project > name but also the library names etc). This will prevent losing something > from the past years for both projects. > > > Medium: > > - While I have no real opinion on whether a leader is needed, I think it > really helps when you don't have a process that prevent any development > dead lock. The decision machine must not stop. > > Since we all agree there is no one currently that can take the position > of a leader in FFmpeg, and there isn't really any on Libav, creating a > working development process looks like a priority to me. > > I do not believe at all in review blocking in the current Libav state > for several reasons, and I don't think FFmpeg is perfect in that regard, > especially with no more decision maker. So there is room for discussion > here. > > A middle ground between the two would involve talking about > maintainership areas, and common sense about trust and power on these > areas. Typically, I would like to avoid having to wait for a meaningless > review on a patch for code only I know. Again, I'm fine doing > concessions here but I think the terms need to be discussed. > > - 2011 is our Godwin point. It needs to stop being mentioned for the > sanity of everyone, so developers of the new project would need to stand > against other developers and users to stop the discussion ASAP when it > appears. > > - One of the main collateral damage for the FFmpeg codebase is the > duplicated features (prores, avr/swr, and more), and I'm willing to make > this a priority on my TODO list for the sake of the new project, but I > would like to see more people standing here, especially when they are > concerned by these areas. > > - Redefine how we make evolution on the API: while there are indeed very > different approaches to how API evolve in both projects, I think it is > really mainly a consequence of politics (for compatibility FFmpeg had > many trouble engaging in API evolution for instance), and I think we can > come up with new methods and how to deal with that. So basically, this > is a touchy topic, but it is because even our users disagree with this > (some want to trash many stuff, and some want to keep them forever) more > than a disagreement between FFmpeg and Libav developers. I'm looking > forward many benefits in this reuni
Re: [FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
Le quartidi 14 thermidor, an CCXXIII, Reimar Döffinger a écrit : > If the goal is consistency, wouldn't an API like av_hash be the better > solution? Hear, hear! (Actually, when reading that discussion for the first time, I had not noticed it was about ciphers and not hashes, and my first reaction was "there is an unified API already".) > And yes, on-stack allocations were desired, even though they make changes > to the structs hard... Pointing the obvious: I very much doubt we ever need to change the struct used just for the implementation of a 30-years-old block cipher. This should be the guiding question: weight the potential hassle of a change in the struct versus the practical hassle of heap allocations. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add myself as maintainer for dxva2 and Windows/MSVC
Hi, On Sat, Aug 1, 2015 at 5:13 AM, Hendrik Leppkes wrote: > I have been (partially) taking care of these for a while now, so might > as well formalize it. > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c14a199..89083bd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -300,7 +300,7 @@ Codecs: > > Hardware acceleration: >crystalhd.c Philip Langdale > - dxva2*Laurent Aimar > + dxva2*Hendrik Leppkes, Laurent Aimar >libstagefright.cppMohamed Naufal >vaapi*Gwenole Beauchesne >vda* Sebastien Zwickert > @@ -550,7 +550,7 @@ Amiga / PowerPC Colin Ward > Linux / PowerPC Luca Barbato > Windows MinGW Alex Beregszaszi, Ramiro Polla > Windows Cygwin Victor Paesa > -Windows MSVCMatthew Oliver > +Windows MSVCMatthew Oliver, Hendrik Leppkes > Windows ICL Matthew Oliver > ADI/Blackfin DSPMarc Hoffman > Sparc Roman Shaposhnik > -- > 1.9.5.msysgit.1 > lgtm. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit : > > ffmpeg -lavfi testsrc -f framecrc | head > Thats interresting, i tried this and it did not trash my terminal > also ive almost never seen ffmpeg trash my terminal with the current > code. No matter how i run it As Ganesh noticed, I forgot the output "-" in my example, but you probably noticed that on your own, and that is not the issue. I just ran some tests and it appears that bash restores the tty state if the command was killed by a signal but not if it exited normally. Therefore, "ffmpeg ... - | head" will have the tty restored because ffmpeg dies by SIGPIPE, but "strace ffmpeg ... - | head" will trash the tty state because bash does not know of the SIGPIPE. The same goes for anything that runs ffmpeg as a sub-process, from "sh -c ..." to the FATE harness. Well, bash does part of its job, but I consider it should do more: leaving the tty trashed just because you inserted strace in front of the command is bad policy. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
Hi, On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch wrote: > - One of the main collateral damage for the FFmpeg codebase is the > duplicated features (prores, avr/swr, and more), and I'm willing to make > this a priority on my TODO list for the sake of the new project, but I > would like to see more people standing here, especially when they are > concerned by these areas. I've worked on both, so I can find some time and merge each, when a reunification happens based on our codebase. The outcome will be one prores enc/dec and one resampling library, which is a superset (in terms of features and performance) of the individual components. The alternates will exist under an ifdef for a while, while they undergo the deprecation process as is usual. Eventually they disappear. If the point of deduplication or merging of the two codebases overall comes up (basically similar to the above, comparing the two codebases for various modules and deciding if features/sections need (re-)merging), I'm happy to be one of the people involved in the process. An example could be re-splitting ffvp9 in multiple source files. As for merge conditions, I'm open-minded and think it'll benefit both projects, as well as our end users. I'll write down more details sometime later. I'm willing to add sweeteners (like: set aside time to write particular features) as a bonus if a merge happens based on our codebase. An examples would be to merge all openhevc optimizations (properly rewritten in yasm) in ffhevc, or something like that. This is a huge project (ask James/Christophe), so don't take this lightly. :) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
On Sat, Aug 1, 2015 at 6:54 AM, Nicolas George wrote: > Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit : >> > ffmpeg -lavfi testsrc -f framecrc | head >> Thats interresting, i tried this and it did not trash my terminal >> also ive almost never seen ffmpeg trash my terminal with the current >> code. No matter how i run it > > As Ganesh noticed, I forgot the output "-" in my example, but you probably > noticed that on your own, and that is not the issue. Interesting. Doing a ttyctl -u (in zsh) and testing without the patch does give this as an issue. > > I just ran some tests and it appears that bash restores the tty state if the > command was killed by a signal but not if it exited normally. > > Therefore, "ffmpeg ... - | head" will have the tty restored because ffmpeg > dies by SIGPIPE, but "strace ffmpeg ... - | head" will trash the tty state > because bash does not know of the SIGPIPE. The same goes for anything that > runs ffmpeg as a sub-process, from "sh -c ..." to the FATE harness. > > Well, bash does part of its job, but I consider it should do more: leaving > the tty trashed just because you inserted strace in front of the command is > bad policy. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
Hey, I've offered on IRC already, but I figured doing it formally on the ML is probably best. I would be willing to take over doing the merges from Libav for the time being, until we decide otherwise, and on top I can probably spare some time reviewing and handling patches submitted to the ML as the need arises. I've been developing with and for FFmpeg for many years, and I feel confident I'm up to the task, and should just step up and do it. Just let me know, or share any objections. I've already been granted access, however I didn't want to start without giving a chance to comment. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
On Sat, Aug 01, 2015 at 07:05:21AM -0400, Ronald S. Bultje wrote: > Hi, > > On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch wrote: > > > - One of the main collateral damage for the FFmpeg codebase is the > > duplicated features (prores, avr/swr, and more), and I'm willing to make > > this a priority on my TODO list for the sake of the new project, but I > > would like to see more people standing here, especially when they are > > concerned by these areas. > > > I've worked on both, so I can find some time and merge each, when a > reunification happens based on our codebase. The outcome will be one prores > enc/dec and one resampling library, which is a superset (in terms of > features and performance) of the individual components. The alternates will > exist under an ifdef for a while, while they undergo the deprecation > process as is usual. Eventually they disappear. If people want, i can help with merging duplicated features i did the j2k/jpeg2000 decoder merge which IIRC also found its way into Libav But i am also happy to stay out of this if people think that would be better [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
Dana 1. 8. 2015. 17:08 osoba "Hendrik Leppkes" napisala je: > > Hey, > > I've offered on IRC already, but I figured doing it formally on the ML > is probably best. > > I would be willing to take over doing the merges from Libav for the > time being, until we decide otherwise, and on top I can probably spare > some time reviewing and handling patches submitted to the ML as the > need arises. > > I've been developing with and for FFmpeg for many years, and I feel > confident I'm up to the task, and should just step up and do it. > > Just let me know, or share any objections. > I've already been granted access, however I didn't want to start > without giving a chance to comment. > Feel free to do it. > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
On 8/1/2015 4:07 PM, Hendrik Leppkes wrote: > Hey, > > I've offered on IRC already, but I figured doing it formally on the ML > is probably best. > > I would be willing to take over doing the merges from Libav for the > time being, until we decide otherwise, and on top I can probably spare > some time reviewing and handling patches submitted to the ML as the > need arises. > > I've been developing with and for FFmpeg for many years, and I feel > confident I'm up to the task, and should just step up and do it. I can fill in if you are e.g. on vacation. Not sure how much the community at large trusts me, however. ;) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
On 01/08/15 7:15 AM, Nicolas George wrote: > Le quartidi 14 thermidor, an CCXXIII, Reimar Döffinger a écrit : >> If the goal is consistency, wouldn't an API like av_hash be the better >> solution? > > Hear, hear! > > (Actually, when reading that discussion for the first time, I had not > noticed it was about ciphers and not hashes, and my first reaction was > "there is an unified API already".) > >> And yes, on-stack allocations were desired, even though they make changes >> to the structs hard... > > Pointing the obvious: I very much doubt we ever need to change the struct > used just for the implementation of a 30-years-old block cipher. One example i can give that took advantage of the hidden nature of the struct is ripemd. See aa70801aaf4038faaf673558c241fa19d5dcd181. Admittedly one could blame this on my original design decision to reduce code duplication (The object size grew considerably after that change), but in any case had the struct not been opaque we would be stuck with a useless element and its relevant ugly deprecation code for the next year or so, not to mention how to handle the transform() function pointer. Also, rc4 currently can't encrypt, only decrypt. No idea if adding encryption functionality will require changes to the struct. In any case, I have no preferences. I can push the alloc() function without the deprecation code, or push both and decide later if the deprecation code is kept or not. Which do you prefer? > > This should be the guiding question: weight the potential hassle of a change > in the struct versus the practical hassle of heap allocations. > > Regards, > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
Hi Hendrik, On Sat, Aug 1, 2015 at 11:07 AM, Hendrik Leppkes wrote: > Hey, > > I've offered on IRC already, but I figured doing it formally on the ML > is probably best. > > I would be willing to take over doing the merges from Libav for the > time being, until we decide otherwise, and on top I can probably spare > some time reviewing and handling patches submitted to the ML as the > need arises. > > I've been developing with and for FFmpeg for many years, and I feel > confident I'm up to the task, and should just step up and do it. > > Just let me know, or share any objections. > I've already been granted access, however I didn't want to start > without giving a chance to comment. No objections, and much appreciated. Thank you. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/mov: Support alac extradata in wave atom
Hi!
Attached patch fixes ticket #4747 for me, I don't know how to
detect that the wave atom contains no frma / alac atom...
Please comment, Carl Eugendiff --git a/libavformat/mov.c b/libavformat/mov.c
index fdba34c..dd48957 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1434,6 +1434,17 @@ static int mov_read_wave(MOVContext *c, AVIOContext *pb, MOVAtom atom)
ret = ff_get_extradata(st->codec, pb, atom.size);
if (ret < 0)
return ret;
+} else if ( st->codec->codec_id == AV_CODEC_ID_ALAC
+ && atom.size >= 256
+ && !st->codec->extradata_size) {
+#define ALAC_EXTRADATA_SIZE 36
+st->codec->extradata = av_mallocz(ALAC_EXTRADATA_SIZE + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!st->codec->extradata)
+return AVERROR(ENOMEM);
+st->codec->extradata_size = ALAC_EXTRADATA_SIZE;
+AV_WB32(st->codec->extradata, ALAC_EXTRADATA_SIZE);
+AV_WB32(st->codec->extradata + 4, MKTAG('a','l','a','c'));
+avio_read(pb, st->codec->extradata + 12, 24);
} else if (atom.size > 8) { /* to read frma, esds atoms */
if ((ret = mov_read_default(c, pb, atom)) < 0)
return ret;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
On 01/08/15 1:31 PM, James Almer wrote: > Also, rc4 currently can't encrypt, only decrypt. No idea if adding encryption > functionality will require changes to the struct. Whoops. Apparently that's not the case. Next time I'll read how a given algorithm works before commenting on an implementation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
Hi Hendrik! On 2015-08-01 17:07 +0200, Hendrik Leppkes wrote: > I've offered on IRC already, but I figured doing it formally on the ML > is probably best. > > I would be willing to take over doing the merges from Libav for the > time being, until we decide otherwise, and on top I can probably spare > some time reviewing and handling patches submitted to the ML as the > need arises. Good to hear. > I've been developing with and for FFmpeg for many years, and I feel > confident I'm up to the task, and should just step up and do it. > > Just let me know, or share any objections. > I've already been granted access, however I didn't want to start > without giving a chance to comment. You are a user of ffmpeg's libs since some years now. So I expect you to handle (API) compatibility with care. I have no objections and very much welcome your offer. Thank you for stepping up, Alexander pgpYzs5oxGJQI.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] aacenc: remove redundant argument from coder functions
On Fri, Jul 31, 2015 at 9:56 PM, Michael Niedermayer wrote: > > Rostislav, Claudio > please both of you send me your public SSH keys, i think you both > should have git write access Sent mine on a private email. Let me know if you didn't get it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
On 2015-08-01 11:48 +0200, Hendrik Leppkes wrote: [...] > I don't have a very strong opinion on the bug tracker, I've seen > better and worse systems than trac, but keeping the existing issues is > probably a good idea - even if a lot of them are user support > questions and not actual issues. Just curious. Why do you think that many of the issues are user support? I am following all changes to the bug tracker and I do not have that impression. More the opposite, clear support questions are closed quickly and the reporter is pointed at the -user ML. Having said that, I think we should always give the reporter the benefit of doubt. That's how it is done mostly. Usually reporters are asked if doing X resolves their problem and if yes the issue is closed. Often in the progress bugs and usability issues are found and fixed. I think it's very important after all. Anyway, this is really getting off-topic, so maybe a new thread should be started if you have serious concerns. [...] Alexander pgp36SKgZrBkP.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.
Also I can check if the stream duration values are sane, by checking that
they are less than the total duration of the file.
On Fri, Jul 31, 2015 at 3:56 PM, Sasi Inguva wrote:
> The syntax is the normal syntax HH:MM:SS used everywhere.
> av_parse_time can parse both [-]HH:MM:SS[.m...]]] and [-]S+[.m...]
> syntax for duration. So if mkvmerge outputs 1200.00 secs in duration it
> would be able to parse that also .
>
> On Fri, Jul 31, 2015 at 3:31 PM, wm4 wrote:
>
>> On Fri, 31 Jul 2015 13:00:02 -0700
>> Sasi Inguva wrote:
>>
>> > Signed-off-by: Sasi Inguva
>> > ---
>> > libavformat/matroskadec.c | 20 ++--
>> > 1 file changed, 18 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> > index 1807cae..03b564e 100644
>> > --- a/libavformat/matroskadec.c
>> > +++ b/libavformat/matroskadec.c
>> > @@ -41,6 +41,7 @@
>> > #include "libavutil/lzo.h"
>> > #include "libavutil/mathematics.h"
>> > #include "libavutil/opt.h"
>> > +#include "libavutil/parseutils.h"
>> > #include "libavutil/time_internal.h"
>> >
>> > #include "libavcodec/bytestream.h"
>> > @@ -1418,10 +1419,25 @@ static void
>> matroska_convert_tags(AVFormatContext *s)
>> >
>> &chapter[j].chapter->metadata, NULL);
>> > } else if (tags[i].target.trackuid) {
>> > MatroskaTrack *track = matroska->tracks.elem;
>> > -for (j = 0; j < matroska->tracks.nb_elem; j++)
>> > -if (track[j].uid == tags[i].target.trackuid &&
>> track[j].stream)
>> > +for (j = 0; j < matroska->tracks.nb_elem; j++) {
>> > +if (track[j].uid == tags[i].target.trackuid &&
>> track[j].stream) {
>>
>> Adding the { and } seems redundant, but personally I don't mind.
>>
>> > +MatroskaTag *track_tags = tags[i].tag.elem;
>> > +int64_t track_duration_ms;
>> > +for (int ind = 0; ind < tags[i].tag.nb_elem;
>> ++ind) {
>> > +if (track_tags[ind].name &&
>> > +!av_strcasecmp(track_tags[ind].name,
>> "duration") &&
>> > +track_tags[ind].string &&
>> > +(av_parse_time(&track_duration_ms,
>> track_tags[ind].string, 1) == 0)) {
>>
>> Who says the syntax mkvmerge writes and the syntax av_parse_time() will
>> always be the same? I'm not sure if we should rely on this.
>>
>> > +track[j].stream->duration =
>> av_rescale_q(track_duration_ms,
>> > +
>> (AVRational){ 1, 100 },
>> > +
>> track[j].stream->time_base);
>> > +}
>> > +}
>> > +
>> > matroska_convert_tag(s, &tags[i].tag,
>> > &track[j].stream->metadata,
>> NULL);
>> > +}
>> > +}
>> > } else {
>> > matroska_convert_tag(s, &tags[i].tag, &s->metadata,
>> > tags[i].target.type);
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Message to the community
Hello, Following some discussions on IRC a number of us wrote this message for ffmpeg.org: https://etherpad.mozilla.org/Cem9NXUdZw If anyone had any comments/objections etc they would be appreciated. I plan to send a patch for the website if there are no changes. It's much better that there is a proper response from the community instead of bits and pieces on IRC, Hacker News, Reddit etc. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.
On Sat, 1 Aug 2015 11:11:14 -0700 Sasi Inguva wrote: > Also I can check if the stream duration values are sane, by checking that > they are less than the total duration of the file. Wouldn't change much - they could be too short too, and we couldn't detect this situation. This is simply an unreliable value. (I'm not even sure if we should export it as stream duration at all, but on the other hand the file duration can be unreliable anyway.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix regression in processing .aax files
01.08.2015, 03:43, "Michael Niedermayer" :
> On Fri, Jul 31, 2015 at 01:36:58PM +0300, Vesselin Bontchev wrote:
>> mov.c | 8
>>
>> From 418d573659dd011de503e45622307974cf437df5 Mon Sep 17 00:00:00 2001
>> From: Vesselin Bontchev
>>
>> /* verify activation data */
>> if (!activation_bytes || c->activation_bytes_size != 4) {
>
> not part of this patch but
> both check for c->activation_bytes_size != 4
> is this intended? isn't the 2nd unreachable that way?
Good catch, this is not intended at all!
>> - av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes option is
>> missing!\n");
>> - ret = AVERROR(EINVAL);
>> + av_log(c->fc, AV_LOG_WARNING, "[aax] activation_bytes option is
>> missing!\n");
>> + ret = 0; /* allow ffprobe to continue working on .aax files */
>> goto fail;
>> }
>
>> if (c->activation_bytes_size != 4) {
>> - av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes value needs to be 4
>> bytes!\n");
>> - ret = AVERROR(EINVAL);
>> + av_log(c->fc, AV_LOG_WARNING, "[aax] activation_bytes value needs to be 4
>> bytes!\n");
>> + ret = 0; /* allow ffprobe to continue working on .aax files */
>> goto fail;
>> }
>
> are both needed for ffprobe ?
> wouldn't ffprobe simply have it not set and take the first if() always
You are absolutely right. I am attaching a new fixed revision of the patch.
VesselinFrom 3710003b6f44dda82fce2eb2c166214f6842c677 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Fri, 31 Jul 2015 12:16:08 +0200
Subject: [PATCH] avformat/mov: fix regression in processing .aax files
Commit 0a551cbe introduced "activation_bytes" option, and not specifying
this option (while calling ffmpeg / ffprobe) causes the program to quit
early. Before this commit, ffprobe was capable of processing metadata in
.aax files.
---
libavformat/mov.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index fdba34c..154d2f8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -848,9 +848,9 @@ static int mov_read_adrm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
av_log(c->fc, AV_LOG_INFO, "\n");
/* verify activation data */
-if (!activation_bytes || c->activation_bytes_size != 4) {
-av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes option is missing!\n");
-ret = AVERROR(EINVAL);
+if (!activation_bytes) {
+av_log(c->fc, AV_LOG_WARNING, "[aax] activation_bytes option is missing!\n");
+ret = 0; /* allow ffprobe to continue working on .aax files */
goto fail;
}
if (c->activation_bytes_size != 4) {
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6] Add support for Audible AA files
30.07.2015, 13:48, "Vesselin Bontchev" : > Please review. > > Thanks, > Vesselin Hi! Is this patch in good enough shape to be merged? Or is there something more I can do to get this patch merged upstream? Thanks, Vesselin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] news: submit reworded announcement
From: Kieran Kunhya Signed-off-by: Clément Bœsch --- src/index | 39 +++ 1 file changed, 39 insertions(+) diff --git a/src/index b/src/index index 8d7fe33..bc0ba45 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,45 @@ News + August 1st, 2015, A message from the FFmpeg project + +Dear multimedia community, + + +As some of you may already know, http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html";>Michael +Niedermayer recently resigned as the leader of the project. He has been +doing an outstanding work for many years, and the project is now facing +another crisis in its history. Nevertheless, the community will continue +to contribute to the project and will try to satisfy as much as possible +the expectations of everyone. + + +To illustrate this, we are in the process of a reconciliation with the +Libav project. This is a tedious and sensitive operation, that will be +notably discussed in our communities online over the coming weeks, and in +person at the https://www.videolan.org/videolan/events/vdd15/";>VideoLAN Developer +Days in Paris in September: a neutral venue for the entire open source +multimedia community. + + +We don't really know yet if this is going to result in anything, but in the +meantime we urge our common users to avoid making any loud statements and +assumption regarding both sides. + + +The last four years have not been easy on our multimedia community, for +both contributors and users. The current situation gives us an opportunity +to find solutions to these issues, and to have reconciliation between the +forks, which have split the community for so long. + + +Unfortunately, much of the disagreement has taken place in inappropriate +venues so far, which has made finding common ground and solutions +difficult. We aim to discuss this. + + July 4th, 2015, FFmpeg needs a new host After graciously hosting our projects (http://www.ffmpeg.org";>FFmpeg, http://www.mplayerhq.hu";>MPlayer -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: submit reworded announcement
On Sun, 2 Aug 2015 00:50:23 +0200 Clément Bœsch wrote: > From: Kieran Kunhya > > Signed-off-by: Clément Bœsch > --- > src/index | 39 +++ > 1 file changed, 39 insertions(+) > > diff --git a/src/index b/src/index > index 8d7fe33..bc0ba45 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,45 @@ > News > > > + August 1st, 2015, A message from the FFmpeg > project > + > +Dear multimedia community, > + > + > +As some of you may already know, + > href="http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html";>Michael > +Niedermayer recently resigned as the leader of the project. He has > been > +doing an outstanding work for many years, and the project is now facing > +another crisis in its history. Nevertheless, the community will continue > +to contribute to the project and will try to satisfy as much as possible > +the expectations of everyone. > + > + > +To illustrate this, we are in the process of a reconciliation with the > +Libav project. This is a tedious and sensitive operation, that will be Sounds offensive. How would you like if someone says that talking to you is tedious? Yes, I know, the reconcillation talks _are_ tedious for all of us, but the formulation sounds a bit ambiguous. > +notably discussed in our communities online over the coming weeks, and in > +person at the +href="https://www.videolan.org/videolan/events/vdd15/";>VideoLAN Developer > +Days in Paris in September: a neutral venue for the entire open > source > +multimedia community. > + > + > +We don't really know yet if this is going to result in anything, but in > the > +meantime we urge our common users to avoid making any loud statements and > +assumption regarding both sides. > + > + > +The last four years have not been easy on our multimedia community, for > +both contributors and users. The current situation gives us an > opportunity > +to find solutions to these issues, and to have reconciliation between the > +forks, which have split the community for so long. > + > + > +Unfortunately, much of the disagreement has taken place in inappropriate > +venues so far, which has made finding common ground and solutions > +difficult. We aim to discuss this. > + This is a bit too long and redundant with the new paragraphs added. I don't understand why you felt the need to redo this at all (including reverting the already pushed announcement). > + >July 4th, 2015, FFmpeg needs a new host > > After graciously hosting our projects ( href="http://www.ffmpeg.org";>FFmpeg, href="http://www.mplayerhq.hu";>MPlayer ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: submit reworded announcement
On Sun, Aug 02, 2015 at 12:53:59AM +0200, wm4 wrote: [...] > This is a bit too long and redundant with the new paragraphs added. I > don't understand why you felt the need to redo this at all (including > reverting the already pushed announcement). > It was committed without review from the ffmpeg team, and raised objections from at least 4 persons in the next minutes. As a result, it was reverted so we could take more time to think about it. Most of the authors were unknown, and the other rage quitted. It was done in order to prevent the flame to heat up. I know my English is bad and maybe too direct (and it was done in a hurry in order to calm down angry spirits that left), so the original wording is currently reworked by Lydia (thank you) and a proper review will be done. Regards, -- Clément B. pgpA1rHsnFQn5.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: submit reworded announcement
On 2 August 2015 at 00:02, Clément Bœsch wrote: > On Sun, Aug 02, 2015 at 12:53:59AM +0200, wm4 wrote: > [...] >> This is a bit too long and redundant with the new paragraphs added. I >> don't understand why you felt the need to redo this at all (including >> reverting the already pushed announcement). >> I asked a lot of people who I have on email saying it was fine. It was only after it was committed were there "new" objections from people who'd already said it was fine. The authors were not unknown if you look at etherpad there is a full history: kierank rcombs wm4 Pavel Koshevoy dericed ..and others Please remove my name from this patch, the wording is terrible. Every single time I kid myself that there's an inclination that the two forks will act like adults, and every time you prove that you are unable to act like adults. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] news: submit reworded announcement
From: Kieran Kunhya Signed-off-by: Lydia Pintscher --- src/index | 30 ++ 1 file changed, 30 insertions(+) diff --git a/src/index b/src/index index 8d7fe33..a93f060 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,36 @@ News + August 1st, 2015, A message from the FFmpeg project + +Dear multimedia community, + + +The resignation of Michael Niedermayer as leader of FFmpeg yesterday has +come by surprise. He has worked tirelessly on the FFmpeg project for many +years and we must thank him for the work that he has done. We hope that in +the future he will continue to contribute to the project. In the coming +weeks, the FFmpeg project is managed by the active contributors. + + +The last four years have not been easy for our multimedia community - both +contributors and users. We should now look to the future, try to find +solutions to these issues, and to have reconciliation between the forks, +which have split the community for so long. + + +Unfortunately, much of the disagreement has taken place in inappropriate +venues so far, which has made finding common ground and solutions +difficult. We aim to discuss this in our communities online over the coming +weeks, and in person at the https://www.videolan.org/videolan/events/vdd15/";>VideoLAN Developer +Days in Paris in September: a neutral venue for the entire open source +multimedia community. + + +The FFmpeg project. + + July 4th, 2015, FFmpeg needs a new host After graciously hosting our projects (http://www.ffmpeg.org";>FFmpeg, http://www.mplayerhq.hu";>MPlayer -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: submit reworded announcement
On 2 August 2015 at 00:11, Clément Bœsch wrote: > From: Kieran Kunhya > > Signed-off-by: Lydia Pintscher > --- > src/index | 30 ++ > 1 file changed, 30 insertions(+) Apologies for my previous outburst - this version is fine. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: submit reworded announcement
On Sun, 2 Aug 2015 01:11:17 +0200 Clément Bœsch wrote: > From: Kieran Kunhya > > Signed-off-by: Lydia Pintscher > --- > src/index | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/src/index b/src/index > index 8d7fe33..a93f060 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,36 @@ > News > > > + August 1st, 2015, A message from the FFmpeg > project > + > +Dear multimedia community, > + > + > +The resignation of Michael Niedermayer as leader of FFmpeg yesterday has > +come by surprise. He has worked tirelessly on the FFmpeg project for many > +years and we must thank him for the work that he has done. We hope that > in > +the future he will continue to contribute to the project. In the coming > +weeks, the FFmpeg project is managed by the active contributors. > + > + > +The last four years have not been easy for our multimedia community - > both > +contributors and users. We should now look to the future, try to find > +solutions to these issues, and to have reconciliation between the forks, > +which have split the community for so long. > + > + > +Unfortunately, much of the disagreement has taken place in inappropriate > +venues so far, which has made finding common ground and solutions > +difficult. We aim to discuss this in our communities online over the > coming > +weeks, and in person at the +href="https://www.videolan.org/videolan/events/vdd15/";>VideoLAN Developer > +Days in Paris in September: a neutral venue for the entire open > source > +multimedia community. > + > + > +The FFmpeg project. > + > + >July 4th, 2015, FFmpeg needs a new host > > After graciously hosting our projects ( href="http://www.ffmpeg.org";>FFmpeg, href="http://www.mplayerhq.hu";>MPlayer Seems fine now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Update about servers
From: Michael Niedermayer Signed-off-by: Michael Niedermayer --- src/index |1 + 1 file changed, 1 insertion(+) diff --git a/src/index b/src/index index 884edfd..d43658c 100644 --- a/src/index +++ b/src/index @@ -79,6 +79,7 @@ We use about 4TB of storage and at least 4TB of bandwidth / month for various mailing lists, http://trac.ffmpeg.org";>trac, http://samples.ffmpeg.org";>samples repo, svn, etc. + UPDATE: We have received more than 7 offers for hosting and servers, thanks alot to everyone! March 16, 2015, FFmpeg 2.6.1 -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update about servers
On 01/08/15 8:40 PM, Michael Niedermayer wrote: > From: Michael Niedermayer > > Signed-off-by: Michael Niedermayer > --- > src/index |1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/index b/src/index > index 884edfd..d43658c 100644 > --- a/src/index > +++ b/src/index > @@ -79,6 +79,7 @@ > > We use about 4TB of storage and at least 4TB of bandwidth / month for > various mailing lists, http://trac.ffmpeg.org";>trac, href="http://samples.ffmpeg.org";>samples repo, svn, etc. > > + UPDATE: We have received more than 7 offers for hosting and > servers, thanks alot to everyone! "a lot". And as Plorkyeran on IRC said, this should be at the top of the entry and not at the bottom. Sorry for originally suggesting the latter. LGTM otherwise, thanks. > >March 16, 2015, FFmpeg 2.6.1 > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update about servers
On Sat, Aug 01, 2015 at 08:45:19PM -0300, James Almer wrote: > On 01/08/15 8:40 PM, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > Signed-off-by: Michael Niedermayer > > --- > > src/index |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/index b/src/index > > index 884edfd..d43658c 100644 > > --- a/src/index > > +++ b/src/index > > @@ -79,6 +79,7 @@ > > > > We use about 4TB of storage and at least 4TB of bandwidth / month for > > various mailing lists, http://trac.ffmpeg.org";>trac, > href="http://samples.ffmpeg.org";>samples repo, svn, etc. > > > > + UPDATE: We have received more than 7 offers for hosting and > > servers, thanks alot to everyone! > > "a lot". > > And as Plorkyeran on IRC said, this should be at the top of the entry and not > at the bottom. > Sorry for originally suggesting the latter. > > LGTM otherwise, thanks. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
On Sat, 1 Aug 2015 17:07:58 +0200 Hendrik Leppkes wrote: > Just let me know, or share any objections. > I've already been granted access, however I didn't want to start > without giving a chance to comment. assuming everyone still wants merges, sounds good to me. thanks -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] New Server
Hi On Fri, Jul 31, 2015 at 07:03:37PM +0200, Antonio Guillermo Martínez Largo wrote: > Hi All, > > We're the proposer of the OVH option. > > Of course the project people should select the best options but for me is > difficult to argue that the option we propose is not one of the best. > > Our offer is a 2 years prepaid high end server under the administrative > and tech management of the ffmpeg community (the contact for the server > will be person you decide, with no relation with our company except 3.000 > euros prepaid transfer we'll do). The server would be hosted in a top 5 > provider in europe (may be top 1/2 for dedicated servers, nº 3 hosting > provider in the world according netcraft in Jan 2014, 700.000 customers > today) with 100% uptime for their site since two years (0 outages since > April 2013). > > For us is difficult to understand it's discarded based on some > not-so-conclusive test (also not applied over the other options in the > same way). > > In any case, our offer is still alive next week if you think it twice. I just picked the 2 which had noone saying anything against, we had several more offers than what we need. And several more great offers than what we need. but maybe theres a way to still make everyone happy ? If you wish to help/contribute, you could donate to FFmpeg,MPlayer, RTMPDump or DVDNav and the specific project could setup a sponsor page or something maybe reynaldo (in cc) i think wanted to suggest such a sponsor page for FFmpeg in a different context already ... or maybe someone of the admins sees a use for another server ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Offering to help out - keeping the merges going and ML patch handling
On Sat, Aug 01, 2015 at 05:07:58PM +0200, Hendrik Leppkes wrote: > Hey, > > I've offered on IRC already, but I figured doing it formally on the ML > is probably best. > > I would be willing to take over doing the merges from Libav for the > time being, until we decide otherwise, and on top I can probably spare > some time reviewing and handling patches submitted to the ML as the > need arises. > > I've been developing with and for FFmpeg for many years, and I feel > confident I'm up to the task, and should just step up and do it. Thanks alot ! Also a technical comment, about fate suite, i never bothered waiting for it to sync before merging a commit. I dont think that extra constraint is important. almost all fate clients we have can handle 0-latency fate suite updates, aka they will update git and rsync at the same time. The very few which dont would have a new test or 2 fail for a round, this is in practice basically irrelevant. One can clearly see that the failures are due to a missing file and so noone should be confused or waste time on them [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
On 01/08/15 1:03 PM, Michael Niedermayer wrote: > On Sat, Aug 01, 2015 at 07:05:21AM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch wrote: >> >>> - One of the main collateral damage for the FFmpeg codebase is the >>> duplicated features (prores, avr/swr, and more), and I'm willing to make >>> this a priority on my TODO list for the sake of the new project, but I >>> would like to see more people standing here, especially when they are >>> concerned by these areas. >> >> >> I've worked on both, so I can find some time and merge each, when a >> reunification happens based on our codebase. The outcome will be one prores >> enc/dec and one resampling library, which is a superset (in terms of >> features and performance) of the individual components. The alternates will >> exist under an ifdef for a while, while they undergo the deprecation >> process as is usual. Eventually they disappear. > > If people want, i can help with merging duplicated features > i did the j2k/jpeg2000 decoder merge which IIRC also found its way > into Libav I doubt anyone would reject your help, really. Your work with bug fixing has been outstanding, and I'm sure you enjoy working on things like j2k, swr, h264, hevc and such much more than doing daily merges. > But i am also happy to stay out of this if people think that would be > better I want to believe that wouldn't be necessary. One would hope stepping down from the leader position should be enough to start talks about a project reunification, but in any case the following weeks will tell. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix regression in processing .aax files
On Sun, Aug 02, 2015 at 12:04:13AM +0300, Vesselin Bontchev wrote:
> 01.08.2015, 03:43, "Michael Niedermayer" :
> > On Fri, Jul 31, 2015 at 01:36:58PM +0300, Vesselin Bontchev wrote:
> >> mov.c | 8
> >>
> >> From 418d573659dd011de503e45622307974cf437df5 Mon Sep 17 00:00:00 2001
> >> From: Vesselin Bontchev
> >>
> >> /* verify activation data */
> >> if (!activation_bytes || c->activation_bytes_size != 4) {
> >
> > not part of this patch but
> > both check for c->activation_bytes_size != 4
> > is this intended? isn't the 2nd unreachable that way?
>
> Good catch, this is not intended at all!
>
> >> - av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes option is
> >> missing!\n");
> >> - ret = AVERROR(EINVAL);
> >> + av_log(c->fc, AV_LOG_WARNING, "[aax] activation_bytes option is
> >> missing!\n");
> >> + ret = 0; /* allow ffprobe to continue working on .aax files */
> >> goto fail;
> >> }
> >
> >> if (c->activation_bytes_size != 4) {
> >> - av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes value needs to be 4
> >> bytes!\n");
> >> - ret = AVERROR(EINVAL);
> >> + av_log(c->fc, AV_LOG_WARNING, "[aax] activation_bytes value needs to be
> >> 4 bytes!\n");
> >> + ret = 0; /* allow ffprobe to continue working on .aax files */
> >> goto fail;
> >> }
> >
> > are both needed for ffprobe ?
> > wouldn't ffprobe simply have it not set and take the first if() always
>
> You are absolutely right. I am attaching a new fixed revision of the patch.
>
> Vesselin
> mov.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 23b48c80cfd1bb5e216abf4c78dd42cd6b152c7c
> 0001-avformat-mov-fix-regression-in-processing-.aax-files.patch
> From 3710003b6f44dda82fce2eb2c166214f6842c677 Mon Sep 17 00:00:00 2001
> From: Vesselin Bontchev
> Date: Fri, 31 Jul 2015 12:16:08 +0200
> Subject: [PATCH] avformat/mov: fix regression in processing .aax files
>
> Commit 0a551cbe introduced "activation_bytes" option, and not specifying
> this option (while calling ffmpeg / ffprobe) causes the program to quit
> early. Before this commit, ffprobe was capable of processing metadata in
> .aax files.
> ---
> libavformat/mov.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Hosting
Hello, I would like to offer hosting for FFmpeg and its repos, etc I can provide a dedicated server with 3 2TB drives for storage and 1 1TB HDD for the OS, 24 GB of RAM, 12 Cores/24 Threads and a 1 Gbps up & down link with 20 TB of bandwidth, for $179 a month. Now for Software, What software needs to run on this server? I can set it all up (if I need help I can Ask the community). Right Now we cant afford to pay for all of the expenses but we could host it with donations and when we can afford to we would be happy to host it for free. If you would like more information, please contact me. Thank you for your time and consideration. Respectfully, Zachariah Moss iPlex Web Hosting and Design (iPlex.org) Owner ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, Jul 30, 2015 at 6:10 PM, Andreas Cadhalpun wrote: > Removing these APIs causes compile failures, which are more severe than > occasional runtime failures. It means people have to use old versions of > the libav* libraries. I disagree as well, it's true that noone likes code failing to compile, but a runtime misbehaviour is several orders of magnitude worse. Also, in my opinion, if maintainers or the community don't upgrade their code (or code they care about) when APIs change, it's not a good sign of a healthy, engaged environment, where code can be left bitrotting. >> I actually did fix a huge number of packages during the last two API >> breaks. But it's not really reasonable to expect me to do it all the >> time. > > Certainly. But someone has to do the work, if you want to remove widely > used APIs. "widely used APIs" that were marked deprecated two years ago. That someone is the downstream project maintainer. Exactly like there is a "promise" that API won't be broken (unless necessary) between minor releases, by using libav APIs you "agree" that there can be breakage between major, and for good reasons too. The "announcement" is in the form of warnings when you try to use the API. Not removing deprecated APIs when the time is due would mean that no deprecation would be taken seriously, thus neutering the whole concept of deprecating code. Also please kindly stop saying "you should do this" or "you should do that", noone is asking you to do anything, so don't try to impose additional expectations on libav maintainers. Finally there is still time before distributions pick up candidates for new releases, both of the library and of the downstream project, so I don't really see any use of complaining now (two years *after* the deprecation was announced). Cheers -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] hls merge cleanup
I've been watching an encrypted stream for the past 20 minutes and everything seems to be working fine. On Thu, Jul 30, 2015 at 1:10 PM, Michael Niedermayer wrote: > On Thu, Jul 30, 2015 at 12:39:53PM -0400, Micah Galizia wrote: >> Cookies and user agent stuff all look the same to me (I'll test with >> an encrypted stream this weekend). > > the Cookies & user agent stuff is still the code as it was previously > > best to look at the diff of the new code > git show 0c73a5a53cc97f4291bbe9e1e68226edf6161744 > and what was actually changed > git diff ba12ba859aabfa7153ba397d869db13acdaba340^ > ba12ba859aabfa7153ba397d869db13acdaba340 > > > and thanks alot for looking into this > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The misfortune of the wise is better than the prosperity of the fool. > -- Epicurus -- "The mark of an immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one." --W. Stekel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6] Add support for Audible AA files
On 30/07/15 7:46 AM, Vesselin Bontchev wrote:
> From 06b0c0013404a67c72ea14a3c90730c0c4bd5b9a Mon Sep 17 00:00:00 2001
> From: Vesselin Bontchev
> Date: Sun, 19 Jul 2015 23:16:36 +0200
> Subject: [PATCH] Add support for Audible AA files
>
> https://en.wikipedia.org/wiki/Audible.com#Quality
> ---
> doc/demuxers.texi| 6 +
> doc/general.texi | 2 +
> libavformat/Makefile | 1 +
> libavformat/aadec.c | 325
> +++
> libavformat/allformats.c | 1 +
> 5 files changed, 335 insertions(+)
> create mode 100644 libavformat/aadec.c
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index e45e1af..c86e8a4 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -18,6 +18,12 @@ enabled demuxers.
>
> The description of some of the currently available demuxers follows.
>
> +@section aa
> +
> +Audible Format 2, 3, and 4 demuxer.
> +
> +This demuxer is used to demux Audible Format 2, 3, and 4 (.aa) files.
> +
> @section applehttp
>
> Apple HTTP Live Streaming demuxer.
> diff --git a/doc/general.texi b/doc/general.texi
> index a260e79..2b782e0 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -228,6 +228,8 @@ library:
> @item 8088flex TMV @tab @tab X
> @item AAX @tab @tab X
> @tab Audible Enhanced Audio format, used in audiobooks.
> +@item AA@tab @tab X
> +@tab Audible Format 2, 3, and 4, used in audiobooks.
> @item ACT Voice @tab @tab X
> @tab contains G.729 audio
> @item Adobe Filmstrip @tab X @tab X
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index cc73fd8..466da51 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -59,6 +59,7 @@ OBJS-$(CONFIG_SHARED)+= log2_tab.o
> golomb_tab.o
>
> # muxers/demuxers
> OBJS-$(CONFIG_A64_MUXER) += a64.o rawenc.o
> +OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
> OBJS-$(CONFIG_AAC_DEMUXER) += aacdec.o apetag.o img2.o rawdec.o
> OBJS-$(CONFIG_AC3_DEMUXER) += ac3dec.o rawdec.o
> OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
> new file mode 100644
> index 000..771bcfd
> --- /dev/null
> +++ b/libavformat/aadec.c
> @@ -0,0 +1,325 @@
> +/*
> + * Audible AA demuxer
> + * Copyright (c) 2015 Vesselin Bontchev
> + *
> + * Header parsing is borrowed from https://github.com/jteeuwen/audible
> project.
> + * Copyright (c) 2001-2014, Jim Teeuwen
> + *
> + * Redistribution and use in source and binary forms, with or without
> modification,
> + * are permitted provided that the following conditions are met:
> + *
> + * 1. Redistributions of source code must retain the above copyright notice,
> this
> + *list of conditions and the following disclaimer.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS" AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> LIABLE FOR
> + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include "avformat.h"
> +#include "internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/tea.h"
> +#include "libavutil/opt.h"
> +
> +#define AA_MAGIC 1469084982 /* this identifies an audible .aa file */
> +#define MAX_CODEC_SECOND_SIZE 3982
> +#define MAX_TOC_ENTRIES 16
> +#define MAX_DICTIONARY_ENTRIES 128
> +#define TEA_BLOCK_SIZE 8
> +
> +typedef struct AADemuxContext {
> +AVClass *class;
> +void *aa_fixed_key;
char
> +int aa_fixed_key_size;
> +int32_t codec_second_size;
> +struct AVTEA *tea_ctx;
> +uint8_t file_key[16];
> +int64_t current_chapter_size;
> +int64_t current_codec_second_size;
> +int chapter_idx;
> +} AADemuxContext;
> +
> +static int32_t get_second_size(char *codec_name)
> +{
> +int32_t result = -1;
> +
> +if (!strcmp(codec_name, "mp332")) {
> +result = 3982;
> +} else if (!strcmp(codec_name, "acelp16")) {
> +result = 2000;
> +} else if (!strcmp(codec_name, "acelp85")) {
> +result = 1045;
> +}
> +
> +return result;
> +}
> +
> +static int aa_read_header(AVFormatContext *s)
> +{
> +int i, j, idx;
> +uint32_t nkey;
> +uint32_t nval;
> +char key[128];
> +char val[128];
> +
