Re: [FFmpeg-devel] [PATCH] Return EOF for ICO when the end is reached
Paul B Mahol gmail.com> writes: > > Attached patch makes the ICO demuxer return EOF instead > > of EIO when the end of the file is reached. Currently, > > if you try to parse an ICO file, it will always result > > in ffmpeg outputting an error because of this. > > lgtm Patch applied. Thank you both, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] compat/w32pthreads: Add return values to match the simulated pthread functions.
Some functions in the native win32 thread wrappers dont return a value. Since the pthread functions they are simulating do return a value (aswell as the equivalent os2 version) this patch updates them accordingly. This makes the win32 variants more compatible with the pthread functions they are emulating and allows them to be used in some instances were previously they were not (such as async). 0001-compat-w32pthreads-Add-return-values-to-match-the-si.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/async: Allow compilation with native threads.
Allows async to be compiled and used when using native win32/os2 threads aswell as pthreads. 0002-avformat-async-Allow-compilation-with-native-threads.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.
Allows the decklink device to be used with native win32/os2 threads instead of just pthreads. Note: I dont have a decklink device to test this but It just allows the use of the already tested win32/os2 pthread simulation functions so there shouldnt be any issues. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] Poll for the community
Hi, I'd like to suggest a poll for the community in order to define some more clear directions for the project. I plan to post the poll on the mailing lists and IRC, people are free to forward them elsewhere. If anyone has a suggestion for a free & simple online poll, I'm listening. A poll system where people can pick the importance of each entry would be perfect. Here is the poll suggestion: Evaluate in the following list what is important and what isn't for you in the FFmpeg project: - More bug fixes (please [+] them in the bug tracker) - More test coverage to prevent regressions - More "simple" features (new demuxers, new options, ...) - More "advanced" features (high level API, scripting language binding, filters rethinking, ...) - More speed optimizations - Better releases (LTS, more backports, ...) - Overall cleanups (merge redundant decoders or dead/clumsy stuff) - More API changes - Less API changes - Better API documentation (please specify) - Better command line documentation (please specify) - Other (please specify) I'd like to submit the poll by the end of next week. Comments on how to improve this list are very welcome, as well as my initial request about a poll system to use. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > Hi Voting Committee > > This mail is an attempt to try out the process described on > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > > This thread is a call for the following people: > Michael Niedermayer > Clément Bœsch > James Almer > Paul B Mahol > Carl Eugen Hoyos > Andreas Cadhalpun > Ronald S. Bultje > wm4 > Lukasz Marek > Rostislav Pehlivanov > Hendrik Leppkes > Christophe Gisquet > Reynaldo H. Verdejo Pinochet > > As a first discussion, I'd like to discuss the introduction of new people to > this list (alphabetical order). > > Nicolas George > Rodger Combs > Stefano Sabatini > Timothy Gu > > I personally would like these people to join the group. > Ping. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Fri, 25 Sep 2015 10:42:18 +0200 Clément Bœsch wrote: > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > > Hi Voting Committee > > > > This mail is an attempt to try out the process described on > > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > > > > This thread is a call for the following people: > > Michael Niedermayer > > Clément Bœsch > > James Almer > > Paul B Mahol > > Carl Eugen Hoyos > > Andreas Cadhalpun > > Ronald S. Bultje > > wm4 > > Lukasz Marek > > Rostislav Pehlivanov > > Hendrik Leppkes > > Christophe Gisquet > > Reynaldo H. Verdejo Pinochet > > > > As a first discussion, I'd like to discuss the introduction of new people to > > this list (alphabetical order). > > > > Nicolas George > > Rodger Combs > > Stefano Sabatini > > Timothy Gu > > > > I personally would like these people to join the group. > > > > Ping. > So if I understand this right, I'm on the voting committee, and I need to give my vote here? If this is the case, I vote "yes" to all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Fri, Sep 25, 2015 at 11:15:20AM +0200, wm4 wrote: > On Fri, 25 Sep 2015 10:42:18 +0200 > Clément Bœsch wrote: > > > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > > > Hi Voting Committee > > > > > > This mail is an attempt to try out the process described on > > > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > > > > > > This thread is a call for the following people: > > > Michael Niedermayer > > > Clément Bœsch > > > James Almer > > > Paul B Mahol > > > Carl Eugen Hoyos > > > Andreas Cadhalpun > > > Ronald S. Bultje > > > wm4 > > > Lukasz Marek > > > Rostislav Pehlivanov > > > Hendrik Leppkes > > > Christophe Gisquet > > > Reynaldo H. Verdejo Pinochet > > > > > > As a first discussion, I'd like to discuss the introduction of new people > > > to > > > this list (alphabetical order). > > > > > > Nicolas George > > > Rodger Combs > > > Stefano Sabatini > > > Timothy Gu > > > > > > I personally would like these people to join the group. > > > > > > > Ping. > > > > So if I understand this right, I'm on the voting committee, and I need > to give my vote here? If this is the case, I vote "yes" to all. Yes, thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On 9/25/15, wm4 wrote: > On Fri, 25 Sep 2015 10:42:18 +0200 > Clément Bœsch wrote: > >> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: >> > Hi Voting Committee >> > >> > This mail is an attempt to try out the process described on >> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html >> > >> > This thread is a call for the following people: >> > Michael Niedermayer >> > Clément Bœsch >> > James Almer >> > Paul B Mahol >> > Carl Eugen Hoyos >> > Andreas Cadhalpun >> > Ronald S. Bultje >> > wm4 >> > Lukasz Marek >> > Rostislav Pehlivanov >> > Hendrik Leppkes >> > Christophe Gisquet >> > Reynaldo H. Verdejo Pinochet >> > >> > As a first discussion, I'd like to discuss the introduction of new >> > people to >> > this list (alphabetical order). >> > >> > Nicolas George >> > Rodger Combs >> > Stefano Sabatini >> > Timothy Gu >> > >> > I personally would like these people to join the group. >> > >> >> Ping. >> > > So if I understand this right, I'm on the voting committee, and I need > to give my vote here? If this is the case, I vote "yes" to all. > Me too. ___ > 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] [RFC] Async M:N asynchronous API model discussion
Hi, With the increasing number of hardware accelerated API, the need for a proper M:N asynchronous API is growing. We've observed that with MMAL and VideoToolBox accelerations typically. Similarly, the incoming MediaCodec hwaccel is going to suffer from the same limitations. Some Libav developers started discussing API evolution in that regard, see https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ A few FFmpeg developers are already interested in cooperating with Libav on that topic. #ffmpeg-devel <@ubitux> just curious, anyone aside from wm4 & myself willing to work with libav for the m:n async api model? BBB maybe (not here :()? <@nevcairiel> i am <@ubitux> any suggestion on how to approach this? <@ubitux> i mean, from the cooperation aspect, not technical one <+wm4> (rcombs also seemed to be interested) <+wm4> ubitux: well, we need to decide on a mailing list? <+wm4> where the discussion happens, and maybe patches <@ubitux> do you think it's possible/overkill to have a temporary 3rd mailing list to avoid butthurts? <@nevcairiel> just use theirs and dont think too much about it <@ubitux> okay <@ubitux> could be nice to send to both though <@ubitux> with the fear that it might degenerate fast <@nevcairiel> that always ends up silly for people that are not subbed to both, since people often forget to hit reply all <+wm4> cross-ML posts are icky <+wm4> they get broken really quick <@saste> ubitux, or you set up a new common mailing-list, but that might now work <@saste> so the safe bet is to use libav-devel <@ubitux> yeah, i can deal with it, but it might be nice to keep ffdev up-to-date; maybe some summaries should be sent on a regular schedule <+wm4> just send a mail to ffmpeg-devel that the new API is discussed on this and that thread <@ubitux> yeah, that was what i had in mind #libav-devel lu_zero: aside from your blog post, what's the state of the m:n async api model? <+nevcairiel> on that note, I'm not convinced using the decoder as the primary loop is the best design, if you consider network sources or some de-coupled models, you might want the demuxer to still push data primarily we have some additional potential hwaccel that would benefit from it typically videotoolbox and incoming mediacodec so a bunch of ppl from ffmpeg are interested in following & helping the design of this api <@lu_zero> nevcairiel: In fact the loop driver must be different depending on the specific purpose <@lu_zero> I was more focused on being able to have the encoder drive the loop but yes, the network would be also a good candidate for other usages <@lu_zero> ubitux: Nice to know, I had been busy with my dayjob for a while but I'll try to get a prototype out soon, I would appreciate having videotoolbox in my tree btw. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/async: Allow compilation with native threads.
2015-09-25 15:56 GMT+08:00 Matt Oliver : > Allows async to be compiled and used when using native win32/os2 threads > aswell as pthreads. LGTM about async. BTW: Attachment of "[PATCH 3/3]" seems missing. Regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
Hi, On Fri, Sep 25, 2015 at 5:15 AM, wm4 wrote: > On Fri, 25 Sep 2015 10:42:18 +0200 > Clément Bœsch wrote: > > > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > > > Hi Voting Committee > > > > > > This mail is an attempt to try out the process described on > > > > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > > > > > > This thread is a call for the following people: > > > Michael Niedermayer > > > Clément Bœsch > > > James Almer > > > Paul B Mahol > > > Carl Eugen Hoyos > > > Andreas Cadhalpun > > > Ronald S. Bultje > > > wm4 > > > Lukasz Marek > > > Rostislav Pehlivanov > > > Hendrik Leppkes > > > Christophe Gisquet > > > Reynaldo H. Verdejo Pinochet > > > > > > As a first discussion, I'd like to discuss the introduction of new > people to > > > this list (alphabetical order). > > > > > > Nicolas George > > > Rodger Combs > > > Stefano Sabatini > > > Timothy Gu > > > > > > I personally would like these people to join the group. > > > > > > > Ping. > > > > So if I understand this right, I'm on the voting committee, and I need > to give my vote here? If this is the case, I vote "yes" to all. +1 for all also. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Async M:N asynchronous API model discussion
Hi, On Fri, Sep 25, 2015 at 6:22 AM, Clément Bœsch wrote: > Hi, > > With the increasing number of hardware accelerated API, the need for a > proper M:N asynchronous API is growing. We've observed that with MMAL and > VideoToolBox accelerations typically. Similarly, the incoming MediaCodec > hwaccel is going to suffer from the same limitations. > > Some Libav developers started discussing API evolution in that regard, see > https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ > > A few FFmpeg developers are already interested in cooperating with Libav on > that topic. > > #ffmpeg-devel > > <@ubitux> just curious, anyone aside from wm4 & myself willing to work > with libav for the m:n async api model? BBB maybe (not here :()? I've had a brief discussion with Luca about it, yes. I'm happy to sit aside and have you guys hash it out, my needs are probably simpler than yours. I'm interested in getting frames from out-of-order-codecs (mpeg, h264, hevc) at the end of GOPs, which such an API would allow. I might even care about getting the frames out-of-order in special situations (e.g. when I know the poc of a dropped packet in h264/hevc). This could be part of such an API, but can be done on top of it also. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.
On 25 September 2015 at 17:58, Matt Oliver wrote: > Allows the decklink device to be used with native win32/os2 threads > instead of just pthreads. > > Note: I dont have a decklink device to test this but It just allows the > use of the already tested win32/os2 pthread simulation functions so there > shouldnt be any issues. > Actually added the patch this time :( 0003-avdevice-decklink-Allow-compilation-with-native-thre.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Poll for the community
On Fri, Sep 25, 2015 at 4:41 AM, Clément Bœsch wrote: > Hi, > > I'd like to suggest a poll for the community in order to define some more > clear directions for the project. I plan to post the poll on the mailing > lists and IRC, people are free to forward them elsewhere. > > If anyone has a suggestion for a free & simple online poll, I'm listening. > A poll system where people can pick the importance of each entry would be > perfect. > > Here is the poll suggestion: > > Evaluate in the following list what is important and what isn't for > you in the FFmpeg project: > > - More bug fixes (please [+] them in the bug tracker) > - More test coverage to prevent regressions > - More "simple" features (new demuxers, new options, ...) > - More "advanced" features (high level API, scripting language > binding, filters rethinking, ...) > - More speed optimizations > - Better releases (LTS, more backports, ...) > - Overall cleanups (merge redundant decoders or dead/clumsy stuff) > - More API changes > - Less API changes > - Better API documentation (please specify) > - Better command line documentation (please specify) > - Other (please specify) > > I'd like to submit the poll by the end of next week. Comments on how to > improve this list are very welcome, as well as my initial request about a > poll system to use. List looks mostly good to me. Here are some suggestions: 1. http://jk.ozlabs.org/projects/patchwork/ - I recall Nicolas mentioning this as possibly useful - many projects (e.g VLC, glibc) use it. I had a look at its use in these projects, and do think it would be useful for FFmpeg. I think it is especially useful for relatively high mailing volume lists like ffmpeg-devel. Patches sometimes get forgotten, sometimes reviews are missing, etc - patchwork helps alleviate such problems without disrupting the current workflow. See for instance the quote on the webpage: "patchwork should supplement mailing lists, not replace them". I suggest creating an "infrastructure" section covering this and other ideas of similar spirit. 2. I don't know whether "more/less API changes" covers the nuances of API changes. There are other questions related to how/when API changes need to be done. Maybe this is useful as a starting point, but I suggest further thought on this. As for the actual polling system, I do not have any ideas. > > Regards, > > -- > Clément B. > > ___ > 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] [RFC] Async M:N asynchronous API model discussion
On Fri, 25 Sep 2015 12:22:51 +0200 Clément Bœsch wrote: > Hi, > > With the increasing number of hardware accelerated API, the need for a > proper M:N asynchronous API is growing. We've observed that with MMAL > and VideoToolBox accelerations typically. Similarly, the incoming > MediaCodec hwaccel is going to suffer from the same limitations. > > Some Libav developers started discussing API evolution in that > regard, see > https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ > > A few FFmpeg developers are already interested in cooperating with > Libav on that topic. Great! This is something I've been lacking recently and had to somewhat emulate with queues and threads. If there's anything I can do to help, I'm interested in participating. After reading Luca's post, I've had a few random and probably naive ideas and comments: - Why not merging AVPacket into AVFrame ? This would restore the symmetry between encoding and decoding. This is actually what V4L does. - Maybe codecs could propose their input buffers, ala get_video_buffer/get_audio_buffer of AVFilterPad. Not sure what HW accel APIs accept random buffers, but some don't and probably some others use background DMAs. E.g., nvenc.c copies the entire raw input into "nvenc memory" before sending them for encoding. It could be a great performance improvement if what produces the input frames could write directly there. Again, V4L does that. - This could go one step further with a lavfi wrapper: demuxers/devices are sources, muxers are sinks, codecs transform AVFrames between coded and decoded content. Best regards, Alexis. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc - fix split function of parser
On 2015-09-01 at 16:27, Rainer Hochecker wrote: > > fix splitting extradata from ts Hi, this commit introduces a regression for me. I'm trying to extract a thumb from the middle of a live TS, containing one HEVC-stream. Unfortunately I'm not sure if I can provide a sample, but before this patch I would always get a good looking thumb, but with this patch I would for the most part get a mostly gray frame. If I generates a few more thumbnails i see that it eventually spits out the same frame that ffmpeg before this patch produced as the first thumb, and it looks OK. However it is much more blocky than what the previous ffmpeg produced: This is the command I want to run: ffmpeg -nostdin -y -an -i hevc_fail.ts -vframes 1 -vf scale=iw*sar:ih thumb%d.jpg -v 100 Before this patch: http://kolbu.ws/~chiller/thumb1.jpg with this patch: http://kolbu.ws/~chiller/thumb1.62bd8deef9005dbc9750e3bdc12fbf9b50392adc.jpg If i let it generates a few more thumbs I end up with a "good" thumb: http://kolbu.ws/~chiller/thumb18.62bd8deef9005dbc9750e3bdc12fbf9b50392adc.jpg However, if you compare the two you will see that even the good thumb with this patch is much more blocky. -- Ståle Kristoffersen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Async M:N asynchronous API model discussion
Le quartidi 4 vendémiaire, an CCXXIV, Alexis Ballier a écrit : > - Why not merging AVPacket into AVFrame ? This would restore the > symmetry between encoding and decoding. This is actually what V4L > does. I would gladly support that. > - This could go one step further with a lavfi wrapper: demuxers/devices > are sources, muxers are sinks, codecs transform AVFrames between coded > and decoded content. I entertained the same idea and raised it during VDD last year, after the FFmpeg/libav discussion (I do not remember exactly who was there, at least Anton), it did not seem to cause a lot of enthusiasm. I still keep it as a distant project though. 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] [RFC] Poll for the community
On Fri, Sep 25, 2015 at 10:41:44AM +0200, Clément Bœsch wrote: > Hi, > > I'd like to suggest a poll for the community in order to define some more > clear directions for the project. I plan to post the poll on the mailing > lists and IRC, people are free to forward them elsewhere. > > If anyone has a suggestion for a free & simple online poll, I'm listening. > A poll system where people can pick the importance of each entry would be > perfect. > > Here is the poll suggestion: > > Evaluate in the following list what is important and what isn't for > you in the FFmpeg project: > > - More bug fixes (please [+] them in the bug tracker) > - More test coverage to prevent regressions > - More "simple" features (new demuxers, new options, ...) > - More "advanced" features (high level API, scripting language > binding, filters rethinking, ...) > - More speed optimizations > - Better releases (LTS, more backports, ...) i am not sure LTS shouldnt be a point of its own > - Overall cleanups (merge redundant decoders or dead/clumsy stuff) > - More API changes > - Less API changes > - Better API documentation (please specify) > - Better command line documentation (please specify) > - Other (please specify) > > I'd like to submit the poll by the end of next week. Comments on how to > improve this list are very welcome, as well as my initial request about a > poll system to use. - Support old API for longer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Poll for the community
On Fri, 25 Sep 2015 10:41:44 +0200 Clément Bœsch wrote: > Hi, > > I'd like to suggest a poll for the community in order to define some more > clear directions for the project. I plan to post the poll on the mailing > lists and IRC, people are free to forward them elsewhere. > > If anyone has a suggestion for a free & simple online poll, I'm listening. > A poll system where people can pick the importance of each entry would be > perfect. > > Here is the poll suggestion: > > Evaluate in the following list what is important and what isn't for > you in the FFmpeg project: > > - More bug fixes (please [+] them in the bug tracker) > - More test coverage to prevent regressions > - More "simple" features (new demuxers, new options, ...) > - More "advanced" features (high level API, scripting language > binding, filters rethinking, ...) > - More speed optimizations > - Better releases (LTS, more backports, ...) > - Overall cleanups (merge redundant decoders or dead/clumsy stuff) > - More API changes > - Less API changes > - Better API documentation (please specify) > - Better command line documentation (please specify) > - Other (please specify) Support old API for shorter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Async M:N asynchronous API model discussion
On Fri, 25 Sep 2015 14:43:37 +0200 Alexis Ballier wrote: > On Fri, 25 Sep 2015 12:22:51 +0200 > Clément Bœsch wrote: > > > Hi, > > > > With the increasing number of hardware accelerated API, the need for a > > proper M:N asynchronous API is growing. We've observed that with MMAL > > and VideoToolBox accelerations typically. Similarly, the incoming > > MediaCodec hwaccel is going to suffer from the same limitations. > > > > Some Libav developers started discussing API evolution in that > > regard, see > > https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ > > > > A few FFmpeg developers are already interested in cooperating with > > Libav on that topic. > > > Great! This is something I've been lacking recently and had to somewhat > emulate with queues and threads. If there's anything I can do to help, > I'm interested in participating. > > After reading Luca's post, I've had a few random and probably naive > ideas and comments: > - Why not merging AVPacket into AVFrame ? This would restore the > symmetry between encoding and decoding. This is actually what V4L > does. > - Maybe codecs could propose their input buffers, ala > get_video_buffer/get_audio_buffer of AVFilterPad. Not sure what HW > accel APIs accept random buffers, but some don't and probably some > others use background DMAs. E.g., nvenc.c copies the entire raw input > into "nvenc memory" before sending them for encoding. It could be a > great performance improvement if what produces the input frames could > write directly there. Again, V4L does that. > - This could go one step further with a lavfi wrapper: demuxers/devices > are sources, muxers are sinks, codecs transform AVFrames between coded > and decoded content. This is really completely orthogonal to what is discussed here and thus offotpic. I agree that graph-based APIs are a good match for multimedia, but putting everything into AVFrame and libavfilter would be a disaster. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, 25 Sep 2015 02:00:29 +
Lucas Andrade wrote:
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index adaa33a..f9f86af 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -525,6 +525,14 @@ static int url_connect(struct playlist *pls,
> AVDictionary *opts, AVDictionary *o
> return ret;
> }
>
> +static void update_options(char **dest, const char *name, void *src)
> +{
> +av_freep(dest);
> +av_opt_get(src, name, 0, (uint8_t**)dest);
> +if (*dest && !strlen(*dest))
> +av_freep(dest);
> +}
> +
> static int open_url(HLSContext *c, URLContext **uc, const char *url,
> AVDictionary *opts)
> {
> AVDictionary *tmp = NULL;
> @@ -534,6 +542,12 @@ static int open_url(HLSContext *c, URLContext **uc,
> const char *url, AVDictionar
> av_dict_copy(&tmp, opts, 0);
>
> ret = ffurl_open(uc, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
> +if( ret >= 0) {
> +// update cookies on http response with setcookies.
> +URLContext *u = *uc;
> +update_options(&c->cookies, "cookies", u->priv_data);
> +av_dict_set(&opts, "cookies", c->cookies, 0);
> +}
>
> av_dict_free(&tmp);
>
> @@ -958,18 +972,9 @@ static void intercept_id3(struct playlist *pls, uint8_t
> *buf,
> pls->is_id3_timestamped = (pls->id3_mpegts_timestamp !=
> AV_NOPTS_VALUE);
> }
>
> -static void update_options(char **dest, const char *name, void *src)
> -{
> -av_freep(dest);
> -av_opt_get(src, name, 0, (uint8_t**)dest);
> -if (*dest && !strlen(*dest))
> -av_freep(dest);
> -}
> -
> static int open_input(HLSContext *c, struct playlist *pls)
> {
> AVDictionary *opts = NULL;
> -AVDictionary *opts2 = NULL;
> int ret;
> struct segment *seg = pls->segments[pls->cur_seq_no - pls->start_seq_no];
>
> @@ -979,9 +984,6 @@ static int open_input(HLSContext *c, struct playlist *pls)
> av_dict_set(&opts, "headers", c->headers, 0);
> av_dict_set(&opts, "seekable", "0", 0);
>
> -// Same opts for key request (ffurl_open mutilates the opts so it cannot
> be used twice)
> -av_dict_copy(&opts2, opts, 0);
> -
> if (seg->size >= 0) {
> /* try to restrict the HTTP request to the part we want
> * (if this is in fact a HTTP request) */
> @@ -999,14 +1001,12 @@ static int open_input(HLSContext *c, struct playlist
> *pls)
> char iv[33], key[33], url[MAX_URL_SIZE];
> if (strcmp(seg->key, pls->key_url)) {
> URLContext *uc;
> -if (open_url(pls->parent->priv_data, &uc, seg->key, opts2) == 0)
> {
> +if (open_url(pls->parent->priv_data, &uc, seg->key, opts) == 0) {
> if (ffurl_read_complete(uc, pls->key, sizeof(pls->key))
> != sizeof(pls->key)) {
> av_log(NULL, AV_LOG_ERROR, "Unable to read key file
> %s\n",
> seg->key);
> }
> -update_options(&c->cookies, "cookies", uc->priv_data);
> -av_dict_set(&opts, "cookies", c->cookies, 0);
> ffurl_close(uc);
> } else {
> av_log(NULL, AV_LOG_ERROR, "Unable to open key file %s\n",
> @@ -1038,7 +1038,7 @@ static int open_input(HLSContext *c, struct playlist
> *pls)
> ret = AVERROR_PATCHWELCOME;
> }
> else
> - ret = AVERROR(ENOSYS);
> +ret = AVERROR(ENOSYS);
>
> /* Seek to the requested position. If this was a HTTP request, the offset
> * should already be where want it to, but this allows e.g. local testing
> @@ -1055,7 +1055,6 @@ static int open_input(HLSContext *c, struct playlist
> *pls)
>
> cleanup:
> av_dict_free(&opts);
> -av_dict_free(&opts2);
> pls->cur_seg_offset = 0;
> return ret;
> }
Looks good. Did you test this successfully? If so, I'll apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Poll for the community
> If anyone has a suggestion for a free & simple online poll, I'm listening. > A poll system where people can pick the importance of each entry would be > perfect. I've used this successfully in the past: https://www.surveymonkey.com/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
I did test with a similar command posted on the tracker, cookies were
updated correctly.
Em sex, 25 de set de 2015 às 10:26, wm4 escreveu:
> On Fri, 25 Sep 2015 02:00:29 +
> Lucas Andrade wrote:
>
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index adaa33a..f9f86af 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -525,6 +525,14 @@ static int url_connect(struct playlist *pls,
> AVDictionary *opts, AVDictionary *o
> > return ret;
> > }
> >
> > +static void update_options(char **dest, const char *name, void *src)
> > +{
> > +av_freep(dest);
> > +av_opt_get(src, name, 0, (uint8_t**)dest);
> > +if (*dest && !strlen(*dest))
> > +av_freep(dest);
> > +}
> > +
> > static int open_url(HLSContext *c, URLContext **uc, const char *url,
> AVDictionary *opts)
> > {
> > AVDictionary *tmp = NULL;
> > @@ -534,6 +542,12 @@ static int open_url(HLSContext *c, URLContext **uc,
> const char *url, AVDictionar
> > av_dict_copy(&tmp, opts, 0);
> >
> > ret = ffurl_open(uc, url, AVIO_FLAG_READ, c->interrupt_callback,
> &tmp);
> > +if( ret >= 0) {
> > +// update cookies on http response with setcookies.
> > +URLContext *u = *uc;
> > +update_options(&c->cookies, "cookies", u->priv_data);
> > +av_dict_set(&opts, "cookies", c->cookies, 0);
> > +}
> >
> > av_dict_free(&tmp);
> >
> > @@ -958,18 +972,9 @@ static void intercept_id3(struct playlist *pls,
> uint8_t *buf,
> > pls->is_id3_timestamped = (pls->id3_mpegts_timestamp !=
> AV_NOPTS_VALUE);
> > }
> >
> > -static void update_options(char **dest, const char *name, void *src)
> > -{
> > -av_freep(dest);
> > -av_opt_get(src, name, 0, (uint8_t**)dest);
> > -if (*dest && !strlen(*dest))
> > -av_freep(dest);
> > -}
> > -
> > static int open_input(HLSContext *c, struct playlist *pls)
> > {
> > AVDictionary *opts = NULL;
> > -AVDictionary *opts2 = NULL;
> > int ret;
> > struct segment *seg = pls->segments[pls->cur_seq_no -
> pls->start_seq_no];
> >
> > @@ -979,9 +984,6 @@ static int open_input(HLSContext *c, struct playlist
> *pls)
> > av_dict_set(&opts, "headers", c->headers, 0);
> > av_dict_set(&opts, "seekable", "0", 0);
> >
> > -// Same opts for key request (ffurl_open mutilates the opts so it
> cannot be used twice)
> > -av_dict_copy(&opts2, opts, 0);
> > -
> > if (seg->size >= 0) {
> > /* try to restrict the HTTP request to the part we want
> > * (if this is in fact a HTTP request) */
> > @@ -999,14 +1001,12 @@ static int open_input(HLSContext *c, struct
> playlist *pls)
> > char iv[33], key[33], url[MAX_URL_SIZE];
> > if (strcmp(seg->key, pls->key_url)) {
> > URLContext *uc;
> > -if (open_url(pls->parent->priv_data, &uc, seg->key, opts2)
> == 0) {
> > +if (open_url(pls->parent->priv_data, &uc, seg->key, opts)
> == 0) {
> > if (ffurl_read_complete(uc, pls->key, sizeof(pls->key))
> > != sizeof(pls->key)) {
> > av_log(NULL, AV_LOG_ERROR, "Unable to read key file
> %s\n",
> > seg->key);
> > }
> > -update_options(&c->cookies, "cookies", uc->priv_data);
> > -av_dict_set(&opts, "cookies", c->cookies, 0);
> > ffurl_close(uc);
> > } else {
> > av_log(NULL, AV_LOG_ERROR, "Unable to open key file
> %s\n",
> > @@ -1038,7 +1038,7 @@ static int open_input(HLSContext *c, struct
> playlist *pls)
> > ret = AVERROR_PATCHWELCOME;
> > }
> > else
> > - ret = AVERROR(ENOSYS);
> > +ret = AVERROR(ENOSYS);
> >
> > /* Seek to the requested position. If this was a HTTP request, the
> offset
> > * should already be where want it to, but this allows e.g. local
> testing
> > @@ -1055,7 +1055,6 @@ static int open_input(HLSContext *c, struct
> playlist *pls)
> >
> > cleanup:
> > av_dict_free(&opts);
> > -av_dict_free(&opts2);
> > pls->cur_seg_offset = 0;
> > return ret;
> > }
>
> Looks good. Did you test this successfully? If so, I'll apply it.
> ___
> 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] [PATCH] Update Cookies on Setcookie playlist response
On Fri, 25 Sep 2015 13:38:20 + Lucas Andrade wrote: > I did test with a similar command posted on the tracker, cookies were > updated correctly. Wanted to apply, but it's only a .diff. Can you send a patch produced with git format-patch? Also, stop https://en.wikipedia.org/wiki/Posting_style#Top-posting ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
Here it is. Also sent as PR on github. Update Cookies Setcookie response.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, 25 Sep 2015 13:50:28 +
Lucas Andrade wrote:
> From 1fd6d3c584678917bd0a262bfbbbfaa7181add08 Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade
> Date: Tue, 22 Sep 2015 00:58:03 -0300
> Subject: [PATCH 1/8] Update Cookies Setcookie response
>
> Update Cookies Setcookie response
> ---
> libavformat/hls.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 82dd744..e5c84e1 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -996,6 +996,8 @@ static int open_input(HLSContext *c, struct playlist *pls)
>
> if (seg->key_type == KEY_NONE) {
> ret = open_url(pls->parent->priv_data, &pls->input, seg->url, opts);
> +update_options(&c->cookies, "cookies", pls->input->priv_data);
> +av_dict_set(&opts, "cookies", c->cookies, 0);
> } else if (seg->key_type == KEY_AES_128) {
> // HLSContext *c = var->parent->priv_data;
> char iv[33], key[33], url[MAX_URL_SIZE];
>
> From d738d7b525eef2fc76b9d13e2b9ca5044d9a46d1 Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade
> Date: Tue, 22 Sep 2015 10:41:31 -0300
> Subject: [PATCH 2/8] Update cookies on http response with setcookies.
>
> If a playlist response sets a cookie, the cookies must be updated for future
> requests.
> ---
> libavformat/hls.c | 27 +++
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index e5c84e1..23e59a6 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -996,8 +996,6 @@ static int open_input(HLSContext *c, struct playlist *pls)
>
> if (seg->key_type == KEY_NONE) {
> ret = open_url(pls->parent->priv_data, &pls->input, seg->url, opts);
> -update_options(&c->cookies, "cookies", pls->input->priv_data);
> -av_dict_set(&opts, "cookies", c->cookies, 0);
> } else if (seg->key_type == KEY_AES_128) {
> // HLSContext *c = var->parent->priv_data;
> char iv[33], key[33], url[MAX_URL_SIZE];
> @@ -1044,16 +1042,21 @@ static int open_input(HLSContext *c, struct playlist
> *pls)
> else
>ret = AVERROR(ENOSYS);
>
> -/* Seek to the requested position. If this was a HTTP request, the offset
> - * should already be where want it to, but this allows e.g. local testing
> - * without a HTTP server. */
> -if (ret == 0 && seg->key_type == KEY_NONE) {
> -int seekret = ffurl_seek(pls->input, seg->url_offset, SEEK_SET);
> -if (seekret < 0) {
> -av_log(pls->parent, AV_LOG_ERROR, "Unable to seek to offset
> %"PRId64" of HLS segment '%s'\n", seg->url_offset, seg->url);
> -ret = seekret;
> -ffurl_close(pls->input);
> -pls->input = NULL;
> +if(ret == 0) {
> +// update cookies on http response with setcookies.
> +update_options(&c->cookies, "cookies", pls->input->priv_data);
> +av_dict_set(&opts, "cookies", c->cookies, 0);
> +/* Seek to the requested position. If this was a HTTP request, the
> offset
> + * should already be where want it to, but this allows e.g. local
> testing
> + * without a HTTP server. */
> +if (seg->key_type == KEY_NONE) {
> +int seekret = ffurl_seek(pls->input, seg->url_offset, SEEK_SET);
> +if (seekret < 0) {
> +av_log(pls->parent, AV_LOG_ERROR, "Unable to seek to offset
> %"PRId64" of HLS segment '%s'\n", seg->url_offset, seg->url);
> +ret = seekret;
> +ffurl_close(pls->input);
> +pls->input = NULL;
> +}
> }
> }
>
>
> From adff5975ac8a34f83ba8d644d6d8ace5d036e01c Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade
> Date: Tue, 22 Sep 2015 13:56:18 -0300
> Subject: [PATCH 3/8] Refactor on cookie update
>
> Removed opts2 as it wasn't needed anymore. Cookies update moved to open_url
> function.
> ---
> libavformat/hls.c | 45 +++--
> 1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 23e59a6..4894e4a 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -535,7 +535,11 @@ static int open_url(HLSContext *c, URLContext **uc,
> const char *url, AVDictionar
> av_dict_copy(&tmp, c->avio_opts, 0);
> av_dict_copy(&tmp, opts, 0);
>
> -ret = ffurl_open(uc, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
> +if(ret = ffurl_open(uc, url, AVIO_FLAG_READ, c->interrupt_callback,
> &tmp) == 0) {
> +// update cookies on http response with setcookies.
> +update_options(&c->cookies, "cookies", uc->priv_data);
> +av_dict_set(&opts, "cookies", c->cookies, 0);
> +}
>
> av_dict_free(&tmp);
>
> @@ -971,7 +975,6 @@ static void update_options(char **dest, const char *name,
> void *src)
> static int open_input(HLSContext *c, struct playlist *pls)
> {
> AVDict
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
Ok, I'll try to merge all those patches at a single one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, 25 Sep 2015 14:23:27 + Lucas Andrade wrote: > Ok, I'll try to merge all those patches at a single one. Should be simple enough... the reason why I want a git format-patch is that you can set your commit message, author name, and email properly. Sorry for not clarifying this earlier. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, Sep 25, 2015 at 9:50 AM, Lucas Andrade wrote: > Here it is. Also sent as PR on github. FYI, we don't do pull requests on github: See "Contributing" at https://github.com/FFmpeg/FFmpeg. > > ___ > 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] [DECISION] Include more developers in the voting committee
On Fri, Sep 25, 2015 at 12:36 PM, Ronald S. Bultje wrote: > Hi, > > On Fri, Sep 25, 2015 at 5:15 AM, wm4 wrote: > >> On Fri, 25 Sep 2015 10:42:18 +0200 >> Clément Bœsch wrote: >> >> > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: >> > > Hi Voting Committee >> > > >> > > This mail is an attempt to try out the process described on >> > > >> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html >> > > >> > > This thread is a call for the following people: >> > > Michael Niedermayer >> > > Clément Bœsch >> > > James Almer >> > > Paul B Mahol >> > > Carl Eugen Hoyos >> > > Andreas Cadhalpun >> > > Ronald S. Bultje >> > > wm4 >> > > Lukasz Marek >> > > Rostislav Pehlivanov >> > > Hendrik Leppkes >> > > Christophe Gisquet >> > > Reynaldo H. Verdejo Pinochet >> > > >> > > As a first discussion, I'd like to discuss the introduction of new >> people to >> > > this list (alphabetical order). >> > > >> > > Nicolas George >> > > Rodger Combs >> > > Stefano Sabatini >> > > Timothy Gu >> > > >> > > I personally would like these people to join the group. >> > > >> > >> > Ping. >> > >> >> So if I understand this right, I'm on the voting committee, and I need >> to give my vote here? If this is the case, I vote "yes" to all. > > > +1 for all also. > Agreed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc - fix split function of parser
On Fri, Sep 25, 2015 at 2:46 PM, Ståle Kristoffersen wrote: > On 2015-09-01 at 16:27, Rainer Hochecker wrote: >> >> fix splitting extradata from ts > > Hi, > this commit introduces a regression for me. > I'm trying to extract a thumb from the middle of a live TS, containing one > HEVC-stream. > Unfortunately I'm not sure if I can provide a sample, but before this patch > I would always get a good looking thumb, but with this patch I would for > the most part get a mostly gray frame. > > If I generates a few more thumbnails i see that it eventually spits out the > same frame that ffmpeg before this patch produced as the first thumb, and > it looks OK. > > However it is much more blocky than what the previous ffmpeg produced: > This is the command I want to run: > > ffmpeg -nostdin -y -an -i hevc_fail.ts -vframes 1 -vf scale=iw*sar:ih > thumb%d.jpg -v 100 > > > Before this patch: > http://kolbu.ws/~chiller/thumb1.jpg > > with this patch: > http://kolbu.ws/~chiller/thumb1.62bd8deef9005dbc9750e3bdc12fbf9b50392adc.jpg > > If i let it generates a few more thumbs I end up with a "good" thumb: > http://kolbu.ws/~chiller/thumb18.62bd8deef9005dbc9750e3bdc12fbf9b50392adc.jpg > > However, if you compare the two you will see that even the good thumb with > this patch is much more blocky. It seems unlikely that this patch is the cause of that, but regardless - please open an issue on Trac, preferably with a small sample and command line to test the difference. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
Ok, I know I did it wrong with the PR. I've used the PR to create the patch. Sorry for trying to help. Anyway, here it is the all-in-one patch. Update Cookies response with Setcookie.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, 25 Sep 2015 15:16:34 + Lucas Andrade wrote: > Ok, I know I did it wrong with the PR. I've used the PR to create the > patch. Sorry for trying to help. > Anyway, here it is the all-in-one patch. Thanks! I applied and pushed it. Sorry for the back and forth. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] checkasm: clip vp9 loopfilter test pixels inside allowed bitdepth range.
---
tests/checkasm/vp9dsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 43fa3a4..692376f 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -370,9 +370,9 @@ static void check_itxfm(void)
#define setpx(a,b,c) \
do { \
if (SIZEOF_PIXEL == 1) { \
-buf0[(a) + (b) * jstride] = c; \
+buf0[(a) + (b) * jstride] = av_clip_uint8(c); \
} else { \
-((uint16_t *)buf0)[(a) + (b) * jstride] = c; \
+((uint16_t *)buf0)[(a) + (b) * jstride] = av_clip_uintp2(c,
bit_depth); \
} \
} while (0)
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 88 +++
libavcodec/x86/vp9lpf_16bpp.asm | 832
3 files changed, 921 insertions(+)
create mode 100644 libavcodec/x86/vp9lpf_16bpp.asm
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index b3cfb0b..9cddaac 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -159,6 +159,7 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
x86/vp9itxfm.o\
x86/vp9lpf.o \
+ x86/vp9lpf_16bpp.o\
x86/vp9mc.o \
x86/vp9mc_16bpp.o
YASM-OBJS-$(CONFIG_WEBP_DECODER) += x86/vp8dsp.o
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index f48225c..0efa9b0 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -65,6 +65,60 @@ filters_8tap_1d_fn2(put, 16, BPC, avx2, 16bpp)
filters_8tap_1d_fn2(avg, 16, BPC, avx2, 16bpp)
#endif
+#define decl_lpf_func(dir, wd, bpp, opt) \
+void ff_loop_filter_##dir##_##wd##_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H)
+
+#define decl_lpf_funcs(dir, wd, bpp) \
+decl_lpf_func(dir, wd, bpp, sse2); \
+decl_lpf_func(dir, wd, bpp, ssse3); \
+decl_lpf_func(dir, wd, bpp, avx)
+
+#define decl_lpf_funcs_wd(dir) \
+decl_lpf_funcs(dir, 4, BPC); \
+decl_lpf_funcs(dir, 8, BPC); \
+decl_lpf_funcs(dir, 16, BPC)
+
+decl_lpf_funcs_wd(h);
+decl_lpf_funcs_wd(v);
+
+#define lpf_16_wrapper(dir, off, bpp, opt) \
+static void loop_filter_##dir##_16_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H) \
+{ \
+ff_loop_filter_##dir##_16_##bpp##_##opt(dst, stride, E, I, H); \
+ff_loop_filter_##dir##_16_##bpp##_##opt(dst + off, stride, E, I, H); \
+}
+
+#define lpf_16_wrappers(bpp, opt) \
+lpf_16_wrapper(h, 8 * stride, bpp, opt); \
+lpf_16_wrapper(v, 16, bpp, opt)
+
+lpf_16_wrappers(BPC, sse2);
+lpf_16_wrappers(BPC, ssse3);
+lpf_16_wrappers(BPC, avx);
+
+#define lpf_mix2_wrapper(dir, off, wd1, wd2, bpp, opt) \
+static void loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt(uint8_t *dst,
ptrdiff_t stride, \
+ int E, int I, int
H) \
+{ \
+ff_loop_filter_##dir##_##wd1##_##bpp##_##opt(dst, stride, E & 0xff,
I & 0xff, H & 0xff); \
+ff_loop_filter_##dir##_##wd2##_##bpp##_##opt(dst + off, stride, E >> 8,
I >> 8, H >> 8); \
+}
+
+#define lpf_mix2_wrappers(wd1, wd2, bpp, opt) \
+lpf_mix2_wrapper(h, 8 * stride, wd1, wd2, bpp, opt); \
+lpf_mix2_wrapper(v, 16, wd1, wd2, bpp, opt)
+
+#define lpf_mix2_wrappers_set(bpp, opt) \
+lpf_mix2_wrappers(4, 4, bpp, opt); \
+lpf_mix2_wrappers(4, 8, bpp, opt); \
+lpf_mix2_wrappers(8, 4, bpp, opt); \
+lpf_mix2_wrappers(8, 8, bpp, opt); \
+
+lpf_mix2_wrappers_set(BPC, sse2);
+lpf_mix2_wrappers_set(BPC, ssse3);
+lpf_mix2_wrappers_set(BPC, avx);
#endif /* HAVE_YASM */
av_cold void INIT_FUNC(VP9DSPContext *dsp)
@@ -72,9 +126,43 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp)
#if HAVE_YASM
int cpu_flags = av_get_cpu_flags();
+#define init_lpf_8_func(idx1, idx2, dir, wd, bpp, opt) \
+dsp->loop_filter_8[idx1][idx2] =
ff_loop_filter_##dir##_##wd##_##bpp##_##opt
+#define init_lpf_16_func(idx, dir, bpp, opt) \
+dsp->loop_filter_16[idx] = loop_filter_##dir##_16_##bpp##_##opt
+#define init_lpf_mix2_func(idx1, idx2, idx3, dir, wd1, wd2, bpp, opt) \
+dsp->loop_filter_mix2[idx1][idx2][idx3] =
loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt
+
+#define init_lpf_funcs(bpp, opt) \
+init_lpf_8_func(0, 0, h, 4, bpp, opt); \
+init_lpf_8_func(0, 1, v, 4, bpp, opt); \
+init_lpf_8_func(1, 0, h, 8, bpp, opt); \
+init_lpf_8_func(1, 1, v, 8, bpp, opt); \
+init_lpf_8_func(2, 0, h, 16, bpp, opt); \
+init_lpf_8_func(2, 1, v, 16, bpp, opt); \
+init_lpf_16_func(0, h, bpp, opt); \
+init_lpf_16_func(1, v, bpp, opt); \
+init_lpf_mix2_func(0, 0, 0, h, 4, 4, bpp, opt); \
+init_lpf_mix2_func(0, 1, 0, h, 4, 8, bpp, opt); \
+init_lpf_mix2_func(1, 0, 0, h, 8, 4, bpp, opt); \
+init_lpf_mix2_func(1, 1, 0, h, 8, 8, bpp, opt); \
+init_lpf_mix2_func(0, 0, 1, v, 4, 4, bpp, opt); \
+init_lpf_mix2_func(0, 1, 1, v, 4, 8, bpp, opt); \
+init_lpf_mix2_func(1, 0, 1, v, 8, 4, bpp, opt); \
+init_lpf_mix2_func(1, 1, 1, v, 8, 8, bpp, opt)
+
if (EXTERNAL_SSE2(cpu_flags)) {
init_subpel3(0, put, BPC, sse2);
init_subpel3(1, avg, BPC, sse2);
+init_lpf_funcs(BPC, sse2)
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, Sep 25, 2015 at 11:23 AM, wm4 wrote: > On Fri, 25 Sep 2015 15:16:34 + > Lucas Andrade wrote: > >> Ok, I know I did it wrong with the PR. I've used the PR to create the >> patch. Sorry for trying to help. >> Anyway, here it is the all-in-one patch. > > Thanks! I applied and pushed it. Sorry for the back and forth. Anyone with write access - please close the github pull request. Thanks. > ___ > 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] [DECISION] Include more developers in the voting committee
As much as I find it gratifying for my ego to see you all welcome us back like that, I must say all your votes are both invalid, and, fortunately, unnecessary. :) Well, this is an unimportant technicality for now, but if we are to use this system, we better understand it correctly. The votes are unnecessary because the motion, if the deadline was before all the answers, would have been validated: it has one supporter (Clément, implicitly), and no opposition: that is 1/0 > 3/2. This kind of vote was meant, in my mind, to validate decisions that have already been discussed and/or for which there is no real doubt about the outcome: make sure nobody's advice has been neglected. Ideally, the call to vote should contain all the votes already. The votes are invalid because they should be direct answer to Clément's call, not to ping nor to each other, and because they are supposed to be motivated, so just "+1" does not count. The requirement to be a direct answer is to avoid votes to be lost: a branch of the thread after the call could devolve into endless bikeshedding, we do not want to re-read all of it to find a vote hidden in it. The requirement that the votes are motivated is to avoid casual opposition or support: at least give it half a minute thought to write a sentence. No such requirement exist for formal votes. I just thought it was best like that. Of course, all of this are just a proposal from me, it can be discussed and changed. I just think people should understand it well before approving it. Also, this is not a normal vote, it is a solemn occasion with symbolic value: validating it with more than silence is nice. But I think we should save that for when the list is really complete. Actually, I was thinking of another way of bootstraping the decision process, but since Clément had already started something I kept quiet. As I am already ranting, here it is, just for entertainment: People who consider themselves active FFmpeg developers should send a patch adding themselves to the list: # Author: Nicolas George # # doc: add myself as FFmpeg developer # # I follow the discussions on the mailing-list, # react to the issues in parts of the code where I am maintainer, # although I have other projects taking my time I produce a few # patches, I intend to contribute more soon. # # --- a/doc/avfilter.txt # +++ b/doc/developers.txt # +Nicolas George (2010-2015) When everybody has done so, we would all approve it, and then squash everything and someone could commit. (Active status could be ensured by a yearly commit to update the year range.) I am confident this would converge and allow unanimity. If Margaret Thatcher were to crawl out of her grave and pretend she's a FFmpeg developer, everybody else would agree that "no, you're not". This is an extreme example, of course, but I believe that if a troll were to try this occasion to get access, there would be easy consensus to reject them, enough to convince the Libre multimedia community. Actually, I would rather fear the opposite: that people would feel shy and not propose themselves, "I have only proposed ten patches in the last four week, I am not active." Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] checkasm: add vp9dsp.itxfm_add tests.
---
tests/checkasm/vp9dsp.c | 275
1 file changed, 275 insertions(+)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index eb9228a..b091905 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -18,12 +18,15 @@
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
+#include
#include
#include "checkasm.h"
+#include "libavcodec/vp9data.h"
#include "libavcodec/vp9dsp.h"
#include "libavutil/common.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
+#include "libavutil/mathematics.h"
static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
@@ -94,6 +97,277 @@ static void check_ipred(void)
#undef randomize_buffers
+#define randomize_buffers() \
+do { \
+uint32_t mask = pixel_mask[(bit_depth - 8) >> 1]; \
+for (y = 0; y < sz; y++) { \
+for (x = 0; x < sz * SIZEOF_PIXEL; x += 4) { \
+uint32_t r = rnd() & mask; \
+AV_WN32A(dst + y * sz * SIZEOF_PIXEL + x, r); \
+AV_WN32A(src + y * sz * SIZEOF_PIXEL + x, rnd() & mask); \
+} \
+for (x = 0; x < sz; x++) { \
+if (bit_depth == 8) { \
+coef[y * sz + x] = src[y * sz + x] - dst[y * sz + x]; \
+} else { \
+((int32_t *) coef)[y * sz + x] = \
+((uint16_t *) src)[y * sz + x] - \
+((uint16_t *) dst)[y * sz + x];\
+} \
+} \
+} \
+} while(0)
+
+// wht function copied from libvpx
+static void fwht_1d(double *out, const double *in, int sz)
+{
+double t0 = in[0] + in[1];
+double t3 = in[3] - in[2];
+double t4 = trunc((t0 - t3) * 0.5);
+double t1 = t4 - in[1];
+double t2 = t4 - in[2];
+
+out[0] = t0 - t2;
+out[1] = t2;
+out[2] = t3 + t1;
+out[3] = t1;
+}
+
+// standard DCT-II
+static void fdct_1d(double *out, const double *in, int sz)
+{
+int k, n;
+
+for (k = 0; k < sz; k++) {
+out[k] = 0.0;
+for (n = 0; n < sz; n++)
+out[k] += in[n] * cos(M_PI * (2 * n + 1) * k / (sz * 2.0));
+}
+out[0] *= M_SQRT1_2;
+}
+
+// see "Towards jointly optimal spatial prediction and adaptive transform in
+// video/image coding", by J. Han, A. Saxena, and K. Rose
+// IEEE Proc. ICASSP, pp. 726-729, Mar. 2010.
+static void fadst4_1d(double *out, const double *in, int sz)
+{
+int k, n;
+
+for (k = 0; k < sz; k++) {
+out[k] = 0.0;
+for (n = 0; n < sz; n++)
+out[k] += in[n] * sin(M_PI * (n + 1) * (2 * k + 1) / (sz * 2.0 +
1.0));
+}
+}
+
+// see "A Butterfly Structured Design of The Hybrid Transform Coding Scheme",
+// by Jingning Han, Yaowu Xu, and Debargha Mukherjee
+//
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41418.pdf
+static void fadst_1d(double *out, const double *in, int sz)
+{
+int k, n;
+
+for (k = 0; k < sz; k++) {
+out[k] = 0.0;
+for (n = 0; n < sz; n++)
+out[k] += in[n] * sin(M_PI * (2 * n + 1) * (2 * k + 1) / (sz *
4.0));
+}
+}
+
+typedef void (*ftx1d_fn)(double *out, const double *in, int sz);
+static void ftx_2d(double *out, const double *in, enum TxfmMode tx,
+ enum TxfmType txtp, int sz)
+{
+static const double scaling_factors[5][4] = {
+{ 4.0, 16.0 * M_SQRT1_2 / 3.0, 16.0 * M_SQRT1_2 / 3.0, 32.0 / 9.0 },
+{ 2.0, 2.0, 2.0, 2.0 },
+{ 1.0, 1.0, 1.0, 1.0 },
+{ 0.25 },
+{ 4.0 }
+};
+static const ftx1d_fn ftx1d_tbl[5][4][2] = {
+{
+{ fdct_1d, fdct_1d },
+{ fadst4_1d, fdct_1d },
+{ fdct_1d, fadst4_1d },
+{ fadst4_1d, fadst4_1d },
+}, {
+{ fdct_1d, fdct_1d },
+{ fadst_1d, fdct_1d },
+{ fdct_1d, fadst_1d },
+{ fadst_1d, fadst_1d },
+}, {
+{ fdct_1d, fdct_1d },
+{ fadst_1d, fdct_1d },
+{ fdct_1d, fadst_1d },
+{ fadst_1d, fadst_1d },
+}, {
+{ fdct_1d, fdct_1d },
+}, {
+{ fwht_1d, fwht_1d },
+},
+};
+double temp[1024];
+double scaling_factor = scaling_factors[tx][txtp];
+int i, j;
+
+// cols
+for (i = 0; i <
Re: [FFmpeg-devel] [RFC][PATCH] ffmpeg: add option to transform metadata using iconv
On 2015-09-24 20:37, Nicolas George wrote:
> Le tridi 3 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I don't know what to say here. I know the encodings needed for iconv
>> because I arrived at them by brute force. I wrote a short Lua script to
>> iterate over a list of encodings supported by my iconv and arrived at
>> this answer. The command line tool called iconv is too clever for this
>> because it returns an error when it can't convert. As for ending in
>> GBK, it is what the script told me.
>
> Could you share the script and enough input to run it and reproduce the
> results?
I can. You should find it attached to this email. I cleaned it up and
put two test cases of data into the file. You will need Lua and the
Lua-iconv module. If your package manager doesn't have that see here:
https://ittner.github.io/lua-iconv/
To run it: lua
>> This feature would not work if there was a misinterpretation in the
>> middle. As you say that would need A->B and C->D where B != C. Perhaps
>> this is why my solution isn't perfect, because there should be an
>> assumption in the middle.
>>
>> I could rework my code to allow for assumptions in the middle. My case
>> would then use "CP1252,UTF-8,UTF-8,GBK" as an argument.
>
> I must say, I do not like your approach very much because it manipulates
> text encoding in the middle of the program. All strings inside the program
> should be in UTF-8.
>
> I can propose this: add an option "metadata_text_encoding" to
> AVFormatContext. If it is set on a demuxer, the demuxing framework uses it
> to convert from it to UTF-8; and similarly, if it is set on a muxer, the
> muxing framework uses it to convert from UTF-8 to it.
>
> Then we can have a special syntax for it to specify bogus conversions.
> Possibly: -metadata_text_encoding "[CP1252>UTF-8]GBK" to specify that the
> text must first be converted from CP1252 to UTF-8 then considered to be GBK
> (and converted to UTF-8). (Well, I consider the feature evil, so I will
> probably not volunteer to implement it, but I will not oppose as long as it
> can not be triggered too easily by an unsuspecting user.
>
> What do you think of it?
As for more special syntax, I'm not a fan of it. Handling this in the
demuxer, somewhere, might be a better idea.
local iconv = require('iconv')
local function canonicalize_list(list)
local tbl = {}
for _,v in ipairs(list) do
local cp = iconv.canonicalize(v)
tbl[cp] = true
end
local ret = {}
for k,_ in pairs(tbl) do
table.insert(ret, k)
end
table.sort(ret)
return ret
end
local function hex_string_to_bytes(str)
local ret = ''
for i in string.gmatch(str, '%x%x') do
ret = ret .. string.char(tonumber(i, 16))
end
return ret
end
-- Moderately slow, ~15sec for 143 encodings.
local function run(encoding_list, mojibake, correct)
for _,a in ipairs(encoding_list) do
for _,b in ipairs(encoding_list) do
for _,c in ipairs(encoding_list) do
local a2b = iconv.new(a, b)
local b2c = iconv.new(b, c)
local str = a2b:iconv(mojibake)
str = b2c:iconv(str)
if string.match(str, correct) then
io.stdout:write(string.format('%s,%s,%s = %s\n', a, b, c,
str))
end
end
end
end
end
-- Very fast, ~0.1sec for 143 encodings.
local function run_assume_middle_utf8(encoding_list, mojibake, correct)
for _,a in ipairs(encoding_list) do
for _,b in ipairs(encoding_list) do
local a2utf = iconv.new(a, 'UTF-8')
local utf2b = iconv.new('UTF-8', b)
local str = a2utf:iconv(mojibake)
str = utf2b:iconv(str)
if string.match(str, correct) then
io.stdout:write(string.format('%s,UTF-8,%s = %s\n', a, b, str))
end
end
end
end
-- Very slow, many minutes for 143 encodings.
local function run_assume_middle_random(encoding_list, mojibake, correct)
for _,a in ipairs(encoding_list) do
for _,b in ipairs(encoding_list) do
for _,c in ipairs(encoding_list) do
for _,d in ipairs(encoding_list) do
local a2b = iconv.new(a, b)
local c2d = iconv.new(c, d)
local str = a2b:iconv(mojibake)
str = c2d:iconv(str)
if string.match(str, correct) then
io.stdout:write(string.format('%s,%s_%s,%s = %s\n', a,
b, c, d, str))
end
end
end
end
end
end
-- Main program
local encoding_list = {}
if true or not iconv.list or not iconv.canonicalize then io.stdout:write(
'The iconv module does not support the list or canonicalize functions so '
.. 'this tool will use an internal list of character encodings.\n')
encoding_list = { "ARMSCII-8", "ATARIST", "BIG5", "BIG5-2003"
[FFmpeg-devel] [PATCH 0/2] dnxhddec: fix DNx100 profiles
There are 2 issues, listed in ticket #4876: - new mb header syntax, where the firt bit indicates mbaff-like handling - incorrectly scanned weight tables Christophe Gisquet (1): dnxhddec: decode and use interlace mb flag Jeremy James (1): dnxhddata: correct weight tables libavcodec/dnxhddata.c | 103 +++-- libavcodec/dnxhddec.c | 15 +-- 2 files changed, 43 insertions(+), 75 deletions(-) -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] dnxhddec: decode and use interlace mb flag
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1. However, reading 11 bits also leads to
obviously incorrect decoding: qscale seems to be 10 bits.
However, as most profiles still have 11bits qscale, the feature is
restricted to the CID1260 profile.
The encoder writes 12 bits of syntax, last and first bits always 0,
which is now somewhat inconsistent with the decoder, but ends up with
the same effect (progressive + reserved bit).
Partially fixes ticket #4876.
---
libavcodec/dnxhddec.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 1034d89..4a42360 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -349,7 +349,12 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx,
AVFrame *frame,
uint8_t *dest_y, *dest_u, *dest_v;
int dct_y_offset, dct_x_offset;
int qscale, i;
+int interlaced_mb = 0;
+if (ctx->cid_table->cid == 1260) {
+interlaced_mb = get_bits1(&ctx->gb);
+qscale = get_bits(&ctx->gb, 10);
+} else
qscale = get_bits(&ctx->gb, 11);
skip_bits1(&ctx->gb);
@@ -386,8 +391,12 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx,
AVFrame *frame,
dest_u += frame->linesize[1];
dest_v += frame->linesize[2];
}
+if (interlaced_mb) {
+dct_linesize_luma <<= 1;
+dct_linesize_chroma <<= 1;
+}
-dct_y_offset = dct_linesize_luma << 3;
+dct_y_offset = interlaced_mb ? frame->linesize[0] : (dct_linesize_luma <<
3);
dct_x_offset = 8 << shift1;
if (!ctx->is_444) {
ctx->idsp.idct_put(dest_y,
dct_linesize_luma, ctx->blocks[0]);
@@ -396,7 +405,7 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx,
AVFrame *frame,
ctx->idsp.idct_put(dest_y + dct_y_offset + dct_x_offset,
dct_linesize_luma, ctx->blocks[5]);
if (!(ctx->avctx->flags & AV_CODEC_FLAG_GRAY)) {
-dct_y_offset = dct_linesize_chroma << 3;
+dct_y_offset = interlaced_mb ? frame->linesize[1] :
(dct_linesize_chroma << 3);
ctx->idsp.idct_put(dest_u,dct_linesize_chroma,
ctx->blocks[2]);
ctx->idsp.idct_put(dest_v,dct_linesize_chroma,
ctx->blocks[3]);
ctx->idsp.idct_put(dest_u + dct_y_offset, dct_linesize_chroma,
ctx->blocks[6]);
@@ -409,7 +418,7 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx,
AVFrame *frame,
ctx->idsp.idct_put(dest_y + dct_y_offset + dct_x_offset,
dct_linesize_luma, ctx->blocks[7]);
if (!(ctx->avctx->flags & AV_CODEC_FLAG_GRAY)) {
-dct_y_offset = dct_linesize_chroma << 3;
+dct_y_offset = interlaced_mb ? frame->linesize[1] :
(dct_linesize_chroma << 3);
ctx->idsp.idct_put(dest_u,
dct_linesize_chroma, ctx->blocks[2]);
ctx->idsp.idct_put(dest_u + dct_x_offset,
dct_linesize_chroma, ctx->blocks[3]);
ctx->idsp.idct_put(dest_u + dct_y_offset,
dct_linesize_chroma, ctx->blocks[8]);
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] dnxhddata: correct weight tables
From: Jeremy James
CID 1260 (as evidenced by incorrect decoding of a sample from ticket
4876) seems to use incorrect weight tables. It appears those tables
were not zigzag-scanned.
Apply zigzag on weight tables for new CIDs 1258, 1259, and 1260, and
fix an incorrect chroma table for CID 1256.
Fixes last issue from ticket #4876.
Found-by: Christophe Gisquet
Signed-off-by: Christophe Gisquet
---
libavcodec/dnxhddata.c | 103 +++--
1 file changed, 31 insertions(+), 72 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 9d2e4e8..cc304e4 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -48,7 +48,7 @@ static const uint8_t dnxhd_1235_chroma_weight[] = {
90, 90, 85, 79, 73, 73, 73, 73,
};
-/* Used in CID 1237, 1253 */
+/* Used in CID 1237, 1253, 1259 */
static const uint8_t dnxhd_1237_luma_weight[] = {
0, 32, 33, 34, 34, 36, 37, 36,
36, 37, 38, 38, 38, 39, 41, 44,
@@ -60,7 +60,7 @@ static const uint8_t dnxhd_1237_luma_weight[] = {
97, 100, 104, 102, 98, 98, 99, 99,
};
-/* Used in CID 1237, 1253 */
+/* Used in CID 1237, 1253, 1259 */
static const uint8_t dnxhd_1237_chroma_weight[] = {
0, 32, 36, 39, 39, 38, 39, 41,
45, 51, 57, 58, 53, 48, 47, 51,
@@ -204,6 +204,7 @@ static const uint8_t dnxhd_1251_chroma_weight[] = {
61, 59, 59, 59, 61, 62, 62, 62,
};
+/* Used in CID 1252, 1258 */
static const uint8_t dnxhd_1252_luma_weight[] = {
0, 32, 34, 35, 36, 36, 36, 37,
36, 37, 39, 40, 41, 40, 40, 40,
@@ -214,6 +215,8 @@ static const uint8_t dnxhd_1252_luma_weight[] = {
71, 82, 90, 90, 88, 87, 90, 95,
100, 107, 103, 97, 95, 93, 99, 99,
};
+
+/* Used in CID 1252, 1258 */
static const uint8_t dnxhd_1252_chroma_weight[] = {
0, 32, 35, 36, 37, 37, 38, 40,
42, 46, 49, 50, 50, 49, 49, 53,
@@ -226,80 +229,36 @@ static const uint8_t dnxhd_1252_chroma_weight[] = {
};
static const uint8_t dnxhd_1256_chroma_weight[] = {
- 0, 32, 32, 32, 32, 32, 32, 33,
-32, 32, 32, 32, 32, 32, 32, 34,
-32, 32, 32, 32, 32, 32, 33, 37,
-32, 32, 32, 32, 32, 32, 36, 39,
-32, 32, 32, 32, 32, 34, 39, 44,
-32, 37, 32, 32, 35, 40, 43, 49,
-32, 33, 36, 36, 40, 43, 50, 60,
-34, 37, 39, 44, 51, 56, 61, 70,
-};
-
-static const uint8_t dnxhd_1258_luma_weight[] = {
- 0, 32, 36, 36, 40, 40, 55, 60,
-34, 36, 37, 40, 41, 48, 57, 82,
-35, 36, 41, 41, 46, 52, 73, 82,
-37, 40, 42, 45, 50, 65, 80, 87,
-39, 41, 44, 49, 62, 78, 88, 90,
-41, 44, 49, 58, 73, 90, 95, 95,
-43, 52, 55, 68, 90, 100, 97, 93,
-52, 53, 71, 82, 107, 103, 99, 99,
-};
-
-static const uint8_t dnxhd_1258_chroma_weight[] = {
- 0, 32, 37, 38, 49, 53, 65, 66,
-35, 37, 40, 49, 56, 64, 65, 82,
-36, 42, 50, 56, 64, 67, 73, 85,
-46, 50, 57, 63, 71, 72, 89, 87,
-49, 58, 65, 72, 78, 88, 88, 90,
-60, 64, 74, 81, 84, 90, 95, 134,
-62, 74, 77, 80, 90, 114, 129, 125,
-74, 74, 90, 100, 128, 125, 116, 116,
-};
-
-static const uint8_t dnxhd_1259_luma_weight[] = {
- 0, 32, 36, 37, 41, 44, 54, 60,
-33, 34, 36, 39, 43, 51, 62, 78,
-34, 36, 38, 41, 49, 59, 73, 79,
-37, 38, 40, 47, 55, 66, 80, 95,
-38, 41, 46, 54, 63, 79, 93, 96,
-46, 47, 56, 64, 78, 90, 97, 98,
-49, 58, 66, 78, 89, 97, 102, 98,
-61, 65, 82, 87, 100, 104, 99, 99,
-};
-
-static const uint8_t dnxhd_1259_chroma_weight[] = {
- 0, 32, 38, 39, 47, 51, 77, 83,
-36, 39, 41, 48, 55, 74, 85, 95,
-39, 45, 53, 58, 72, 83, 105, 89,
-51, 58, 66, 73, 82, 109, 92, 95,
-57, 75, 78, 89, 105, 95, 93, 96,
-81, 82, 99, 99, 94, 90, 97, 98,
-83, 96, 97, 93, 89, 97, 102, 98,
-90, 94, 92, 88, 100, 104, 99, 99,
+ 0, 32, 32, 32, 32, 32, 32, 32,
+32, 32, 32, 32, 32, 32, 32, 32,
+32, 32, 32, 32, 32, 32, 37, 32,
+32, 32, 32, 32, 33, 32, 32, 32,
+32, 32, 33, 34, 37, 36, 32, 32,
+32, 33, 34, 37, 36, 34, 35, 36,
+39, 44, 40, 40, 39, 39, 44, 43,
+43, 51, 56, 50, 49, 60, 61, 70,
};
static const uint8_t dnxhd_1260_luma_weight[] = {
- 0, 32, 37, 37, 40, 41, 52, 53,
-33, 36, 36, 38, 40, 48, 49, 52,
-34, 34, 37, 39, 44, 47, 49, 54,
-33, 35, 38, 40, 45, 46, 54, 51,
-34, 37, 37, 42, 44, 49, 52, 48,
-34, 34, 38, 43, 44, 51, 50, 50,
-33, 36, 41, 44, 51, 52, 50, 54,
-36, 38, 44, 47, 53, 53, 54, 54,
+ 0, 32, 33, 34, 36, 37, 37, 36,
+34, 33, 34, 35, 37, 38, 40, 41,
+40, 39, 38, 37, 34, 33, 34, 37,
+40, 44, 48, 52, 53, 49, 47, 45,
+42, 38, 36, 36, 38, 41, 43, 44,
+46, 49, 52, 54, 54, 49, 44, 44,
+44, 47, 51, 51, 52, 51, 48, 50,
+52, 53, 53, 50, 50, 54, 54, 54,
};
static const uint8_t dnxhd_1260_chroma_weight[] = {
- 0, 32, 40, 38, 42, 40, 45, 45,
-34, 42, 36, 43, 38, 46, 46, 49,
-38, 35, 43, 39, 44, 47, 47, 49,
-35, 42, 43, 42,
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Fri, 25 Sep 2015 10:42:18 +0200 Clément Bœsch wrote: > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > > Hi Voting Committee > > > > This mail is an attempt to try out the process described on > > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > > > > This thread is a call for the following people: > > Michael Niedermayer > > Clément Bœsch > > James Almer > > Paul B Mahol > > Carl Eugen Hoyos > > Andreas Cadhalpun > > Ronald S. Bultje > > wm4 > > Lukasz Marek > > Rostislav Pehlivanov > > Hendrik Leppkes > > Christophe Gisquet > > Reynaldo H. Verdejo Pinochet > > > > As a first discussion, I'd like to discuss the introduction of new > > people to this list (alphabetical order). > > > > Nicolas George > > Rodger Combs > > Stefano Sabatini > > Timothy Gu > > > > I personally would like these people to join the group. what no fabrice on the list? alex b? kieran? whats the reason for not just including anyone who wants to vote on any particular issue again? is this all about just cutting out old devels? how many old devels even still read and reply to the list without committing or developing? zero? iive is still around maintaining xvmc support i guess. not that i really care, just curious. i remember having arpi and gabu on the list really scared some people. even ronald is still talking about them 4 years later. let it g, let it goo (what no llogan or compn on the list either bah) (yes, i still do some trac, patch review on ffmpeg-devel, http://ffmpeg.org/pipermail/ffmpeg-devel/2015-May/172673.html http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177178.html ffmpeg-web commits as well. http://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2015-July/091423.html ) -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Fri, Sep 25, 2015 at 7:06 PM, compn wrote: > On Fri, 25 Sep 2015 10:42:18 +0200 > Clément Bœsch wrote: > >> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: >> > Hi Voting Committee >> > >> > This mail is an attempt to try out the process described on >> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html >> > >> > This thread is a call for the following people: >> > Michael Niedermayer >> > Clément Bœsch >> > James Almer >> > Paul B Mahol >> > Carl Eugen Hoyos >> > Andreas Cadhalpun >> > Ronald S. Bultje >> > wm4 >> > Lukasz Marek >> > Rostislav Pehlivanov >> > Hendrik Leppkes >> > Christophe Gisquet >> > Reynaldo H. Verdejo Pinochet >> > >> > As a first discussion, I'd like to discuss the introduction of new >> > people to this list (alphabetical order). >> > >> > Nicolas George >> > Rodger Combs >> > Stefano Sabatini >> > Timothy Gu >> > >> > I personally would like these people to join the group. > > > what no fabrice on the list? alex b? kieran? > > whats the reason for not just including anyone who wants to vote on any > particular issue again? > > is this all about just cutting out old devels? how many old devels even > still read and reply to the list without committing or developing? > zero? iive is still around maintaining xvmc support i guess. > > not that i really care, just curious. You should've joined the meeting, or read the meeting transcription if you want to know how this list was created. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers
Hi All,
currently, select option of tee pseudo muxer may contain only one stream
specifier. Sometimes I need to use more than one stream specifier.
So I made the following patch. It makes possible to put multiple stream
specifier into select option separated by comma.
eg. select=\'a:0,v\'
(I choose the comma character as separator because it is similar to
tee's bsf option separator. bsf option allows multiple value separated
by comma)
Please consider that put this patch into the official ffmpeg source tree.
thank you,
Bela Bodecs
p.s.:the documentation/web also should alter by this, but I do not know
where to send this:
select
Select the streams that should be mapped to the slave output,
specified by a stream specifier. If not specified, this defaults to
all the input streams.
+++
You may use multiple stream specifiers separated by commas (,)
eg.: a:0,v
Patch description:
diff -u tee.c.orig tee.c
--- tee.c.orig 2015-07-09 22:22:27.0 +0200
+++ tee.c 2015-09-25 13:15:15.763273903 +0200
@@ -47,6 +47,7 @@
static const char *const slave_opt_close = "]";
static const char *const slave_opt_delim = ":]"; /* must have the
close too */
static const char *const slave_bsfs_spec_sep = "/";
+static const char *const slave_select_sep = ",";
static const AVClass tee_muxer_class = {
.class_name = "Tee muxer",
@@ -142,7 +143,9 @@
AVFormatContext *avf2 = NULL;
AVStream *st, *st2;
int stream_count;
-
+int fullret;
+char *subselect = NULL, *next_subselect = NULL, *first_subselect;
+
if ((ret = parse_slave_options(avf, slave, &options, &filename)) < 0)
return ret;
@@ -172,15 +175,26 @@
for (i = 0; i < avf->nb_streams; i++) {
st = avf->streams[i];
if (select) {
-ret = avformat_match_stream_specifier(avf, avf->streams[i],
select);
-if (ret < 0) {
-av_log(avf, AV_LOG_ERROR,
- "Invalid stream specifier '%s' for output '%s'\n",
- select, slave);
-goto end;
-}
+fullret = 0;
+first_subselect = select;
+next_subselect = NULL;
+while (subselect = strtok_r(first_subselect,
slave_select_sep, &next_subselect)) {
+first_subselect = NULL;
+
+ret = avformat_match_stream_specifier(avf,
avf->streams[i], subselect);
+if (ret < 0) {
+av_log(avf, AV_LOG_ERROR,
+"Invalid stream specifier '%s' for output '%s'\n",
+subselect, slave);
+goto end;
+}
+if (ret != 0) {
+fullret = 1; // match
+break;
+}
-if (ret == 0) { /* no match */
+}
+if (fullret == 0) { /* no match */
tee_slave->stream_map[i] = -1;
continue;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee
On Fri, 25 Sep 2015 19:08:57 +0200 Hendrik Leppkes wrote: > On Fri, Sep 25, 2015 at 7:06 PM, compn wrote: > > On Fri, 25 Sep 2015 10:42:18 +0200 > > Clément Bœsch wrote: > > > >> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote: > >> > Hi Voting Committee > >> > > >> > This mail is an attempt to try out the process described on > >> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html > >> > > >> > This thread is a call for the following people: > >> > Michael Niedermayer > >> > Clément Bœsch > >> > James Almer > >> > Paul B Mahol > >> > Carl Eugen Hoyos > >> > Andreas Cadhalpun > >> > Ronald S. Bultje > >> > wm4 > >> > Lukasz Marek > >> > Rostislav Pehlivanov > >> > Hendrik Leppkes > >> > Christophe Gisquet > >> > Reynaldo H. Verdejo Pinochet > >> > > >> > As a first discussion, I'd like to discuss the introduction of > >> > new people to this list (alphabetical order). > >> > > >> > Nicolas George > >> > Rodger Combs > >> > Stefano Sabatini > >> > Timothy Gu > >> > > >> > I personally would like these people to join the group. > > > > > > what no fabrice on the list? alex b? kieran? > > > > whats the reason for not just including anyone who wants to vote on > > any particular issue again? > > > > is this all about just cutting out old devels? how many old devels > > even still read and reply to the list without committing or > > developing? zero? iive is still around maintaining xvmc support i > > guess. > > > > not that i really care, just curious. > > You should've joined the meeting, or read the meeting transcription if > you want to know how this list was created. i was there (well, i read the threads here and i was at vdd) i know how the list was created. i just dont know why the list criteria was chosen. which is why i asked. "is this all about cutting out old devels?" yes? no? thx, bai -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/apedec: fix undefined left shifts of negative numbers
On Sat, Sep 19, 2015 at 10:18 PM, Ganesh Ajjanagadde wrote: > This fixes -Wshift-negative-value reported with clang 3.7+, e.g > http://fate.ffmpeg.org/log.cgi?time=20150919172459&log=compile&slot=x86_64-darwin-clang-polly-notiling-3.7. > Note that the patch crucially depends on int >= 32 bits, > an assumption made in many places in the codebase. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavcodec/apedec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c > index 5536e0f..7b34d26 100644 > --- a/libavcodec/apedec.c > +++ b/libavcodec/apedec.c > @@ -1281,7 +1281,7 @@ static void do_apply_filter(APEContext *ctx, int > version, APEFilter *f, > /* Update the adaption coefficients */ > absres = FFABS(res); > if (absres) > -*f->adaptcoeffs = ((res & (-1<<31)) ^ (-1<<30)) >> > +*f->adaptcoeffs = ((res & (-(1<<31))) ^ (-(1<<30))) >> >(25 + (absres <= f->avg*3) + (absres <= > f->avg*4/3)); > else > *f->adaptcoeffs = 0; > -- > 2.5.2 > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings
On Fri, Sep 18, 2015 at 5:15 PM, Ganesh Ajjanagadde
wrote:
> This patch results in identical behavior of movenc, and suppresses
> -Wstrict-overflow
> warnings observed in GCC 5.2.
> I have manually checked that all usages are safe, and overflow possibility
> does
> not exist with this expression rewrite.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index af03d1e..6e4a1a6 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track, int
> cluster_idx)
> {
> int64_t next_dts;
>
> -if (cluster_idx >= track->entry)
> +if (cluster_idx - track->entry >= 0)
> return 0;
>
> if (cluster_idx + 1 == track->entry)
> --
> 2.5.2
>
ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.
On Fri, Sep 25, 2015 at 09:41:59PM +1000, Matt Oliver wrote:
> On 25 September 2015 at 17:58, Matt Oliver wrote:
>
> > Allows the decklink device to be used with native win32/os2 threads
> > instead of just pthreads.
> >
> > Note: I dont have a decklink device to test this but It just allows the
> > use of the already tested win32/os2 pthread simulation functions so there
> > shouldnt be any issues.
> >
>
> Actually added the patch this time :(
> configure |4 ++--
> libavdevice/decklink_common.cpp |2 +-
> libavdevice/decklink_dec.cpp|2 +-
> libavdevice/decklink_enc.cpp|2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
> 4aa7edd4948d914a5f8f580bda23c9edb931f860
> 0003-avdevice-decklink-Allow-compilation-with-native-thre.patch
> From 13c98e75292284a8b9e17c3a459208c1c06c10cb Mon Sep 17 00:00:00 2001
> From: Matt Oliver
> Date: Fri, 25 Sep 2015 17:52:57 +1000
> Subject: [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.
>
> ---
> configure | 4 ++--
> libavdevice/decklink_common.cpp | 2 +-
> libavdevice/decklink_dec.cpp| 2 +-
> libavdevice/decklink_enc.cpp| 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/configure b/configure
> index e21820a..58865d9 100755
> --- a/configure
> +++ b/configure
> @@ -2652,9 +2652,9 @@ avfoundation_indev_extralibs="-framework CoreVideo
> -framework Foundation -framew
> avfoundation_indev_select="avfoundation"
> bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h
> dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
> caca_outdev_deps="libcaca"
> -decklink_outdev_deps="decklink pthreads"
> +decklink_outdev_deps="decklink threads"
> decklink_outdev_extralibs="-lstdc++"
> -decklink_indev_deps="decklink pthreads"
> +decklink_indev_deps="decklink threads"
> decklink_indev_extralibs="-lstdc++"
> dshow_indev_deps="IBaseFilter"
> dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
> -lshlwapi"
> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
> index ac7964c..476315f 100644
> --- a/libavdevice/decklink_common.cpp
> +++ b/libavdevice/decklink_common.cpp
> @@ -26,7 +26,7 @@
> #include
> #endif
>
> -#include
> +#include "libavutil/thread.h"
> #include
>
> extern "C" {
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 747f47e..5c86d94 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -21,7 +21,7 @@
>
> #include
>
> -#include
> +#include "libavutil/thread.h"
> #include
>
> extern "C" {
> diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
> index 6c5450f..1c9f728 100644
> --- a/libavdevice/decklink_enc.cpp
> +++ b/libavdevice/decklink_enc.cpp
> @@ -21,7 +21,7 @@
>
> #include
>
> -#include
> +#include "libavutil/thread.h"
> #include
>
> extern "C" {
i have no means to test either but
shouldnt libavutil/*.h be under extern "C" { ?
[...]
--
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] [PATCH 1/2] dnxhddec: decode and use interlace mb flag
On Fri, Sep 25, 2015 at 06:57:17PM +0200, Christophe Gisquet wrote: > This bit is 1 in some samples, and seems to coincide with interlaced > mbs and CID1260. 2008 specs do not know about it, and maintain qscale > is 11 bits. This looks oversized, but may help larger bitdepths. > > Currently, it leads to an obviously incorrect qscale value, meaning > its syntax is shifted by 1. However, reading 11 bits also leads to > obviously incorrect decoding: qscale seems to be 10 bits. > > However, as most profiles still have 11bits qscale, the feature is > restricted to the CID1260 profile. > > The encoder writes 12 bits of syntax, last and first bits always 0, > which is now somewhat inconsistent with the decoder, but ends up with > the same effect (progressive + reserved bit). > > Partially fixes ticket #4876. > --- > libavcodec/dnxhddec.c | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] dnxhddata: correct weight tables
On Fri, Sep 25, 2015 at 06:57:18PM +0200, Christophe Gisquet wrote: > From: Jeremy James > > CID 1260 (as evidenced by incorrect decoding of a sample from ticket > 4876) seems to use incorrect weight tables. It appears those tables > were not zigzag-scanned. > > Apply zigzag on weight tables for new CIDs 1258, 1259, and 1260, and > fix an incorrect chroma table for CID 1256. > > Fixes last issue from ticket #4876. > > Found-by: Christophe Gisquet > Signed-off-by: Christophe Gisquet > --- > libavcodec/dnxhddata.c | 103 > +++-- > 1 file changed, 31 insertions(+), 72 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] checkasm: Use a self-balancing tree
Tested functions are internally kept in a binary search tree for efficient
lookups. The downside of the current implementation is that the tree quickly
becomes unbalanced which causes an unneccessary amount of comparisons between
nodes. Improve this by changing the tree into a self-balancing left-leaning
red-black tree with a worst case lookup/insertion time complexity of O(log n).
Significantly reduces the recursion depth and makes the tests run around 10%
faster overall. The relative performance improvement compared to the existing
non-balanced tree will also most likely increase as more tests are added.
---
tests/checkasm/checkasm.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 2bfa9d4..2f967e3 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -134,6 +134,7 @@ typedef struct CheckasmFuncVersion {
typedef struct CheckasmFunc {
struct CheckasmFunc *child[2];
CheckasmFuncVersion versions;
+uint8_t color; /* 0 = red, 1 = black */
char name[1];
} CheckasmFunc;
@@ -296,24 +297,57 @@ static int cmp_func_names(const char *a, const char *b)
return (digit_diff = av_isdigit(*a) - av_isdigit(*b)) ? digit_diff :
ascii_diff;
}
+/* Perform a tree rotation in the specified direction and return the new root
*/
+static CheckasmFunc *rotate_tree(CheckasmFunc *f, int dir)
+{
+CheckasmFunc *r = f->child[dir^1];
+f->child[dir^1] = r->child[dir];
+r->child[dir] = f;
+r->color = f->color;
+f->color = 0;
+return r;
+}
+
+#define is_red(f) ((f) && !(f)->color)
+
+/* Balance a left-leaning red-black tree at the specified node */
+static void balance_tree(CheckasmFunc **root)
+{
+CheckasmFunc *f = *root;
+
+if (is_red(f->child[0]) && is_red(f->child[1])) {
+f->color ^= 1;
+f->child[0]->color = f->child[1]->color = 1;
+}
+
+if (!is_red(f->child[0]) && is_red(f->child[1]))
+*root = rotate_tree(f, 0); /* Rotate left */
+else if (is_red(f->child[0]) && is_red(f->child[0]->child[0]))
+*root = rotate_tree(f, 1); /* Rotate right */
+}
+
/* Get a node with the specified name, creating it if it doesn't exist */
-static CheckasmFunc *get_func(const char *name, int length)
+static CheckasmFunc *get_func(CheckasmFunc **root, const char *name)
{
-CheckasmFunc *f, **f_ptr = &state.funcs;
+CheckasmFunc *f = *root;
-/* Search the tree for a matching node */
-while ((f = *f_ptr)) {
+if (f) {
+/* Search the tree for a matching node */
int cmp = cmp_func_names(name, f->name);
-if (!cmp)
-return f;
+if (cmp) {
+f = get_func(&f->child[cmp > 0], name);
-f_ptr = &f->child[(cmp > 0)];
+/* Rebalance the tree on the way up if a new node was inserted */
+if (!f->versions.func)
+balance_tree(root);
+}
+} else {
+/* Allocate and insert a new node into the tree */
+int name_length = strlen(name);
+f = *root = checkasm_malloc(sizeof(CheckasmFunc) + name_length);
+memcpy(f->name, name, name_length + 1);
}
-/* Allocate and insert a new node into the tree */
-f = *f_ptr = checkasm_malloc(sizeof(CheckasmFunc) + length);
-memcpy(f->name, name, length+1);
-
return f;
}
@@ -414,7 +448,8 @@ void *checkasm_check_func(void *func, const char *name, ...)
if (!func || name_length <= 0 || name_length >= sizeof(name_buf))
return NULL;
-state.current_func = get_func(name_buf, name_length);
+state.current_func = get_func(&state.funcs, name_buf);
+state.funcs->color = 1;
v = &state.current_func->versions;
if (v->func) {
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: Use a self-balancing tree
On Fri, Sep 25, 2015 at 09:28:26PM +0200, Henrik Gramner wrote: > Tested functions are internally kept in a binary search tree for efficient > lookups. The downside of the current implementation is that the tree quickly > becomes unbalanced which causes an unneccessary amount of comparisons between > nodes. Improve this by changing the tree into a self-balancing left-leaning > red-black tree with a worst case lookup/insertion time complexity of O(log n). > > Significantly reduces the recursion depth and makes the tests run around 10% > faster overall. The relative performance improvement compared to the existing > non-balanced tree will also most likely increase as more tests are added. > --- > tests/checkasm/checkasm.c | 59 > +-- > 1 file changed, 47 insertions(+), 12 deletions(-) is there any reason why this doesnt use libavutil/tree.* ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: Use a self-balancing tree
On Fri, Sep 25, 2015 at 9:57 PM, Michael Niedermayer wrote: > is there any reason why this doesnt use > libavutil/tree.* ? Two reasons basically. First, the glue code required to use a generic tree implementation instead of one customized for this use case would be as large as the implementation of the tree itself. Second, my intention is to port it back to x264 at some point so I don't want to rely too much on libavutil features unless there's a large benefit of doing so. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 2 +
libavcodec/x86/constants.h | 1 +
libavcodec/x86/vp9dsp_init.h| 23 +
libavcodec/x86/vp9dsp_init_16bpp.c | 15 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 7 +
libavcodec/x86/vp9intrapred_16bpp.asm | 672
libavcodec/x86/vp9lpf_16bpp.asm | 2 +-
libavcodec/x86/vp9mc_16bpp.asm | 2 +-
9 files changed, 723 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/x86/vp9intrapred_16bpp.asm
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 9cddaac..44bf342 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -157,6 +157,7 @@ YASM-OBJS-$(CONFIG_VC1_DECODER)+= x86/vc1dsp.o
YASM-OBJS-$(CONFIG_VORBIS_DECODER) += x86/vorbisdsp.o
YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
+ x86/vp9intrapred_16bpp.o \
x86/vp9itxfm.o\
x86/vp9lpf.o \
x86/vp9lpf_16bpp.o\
diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 553dd49..9f3c8b4 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -55,6 +55,8 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1024) = {
0x0400040004000400ULL, 0x040
0x0400040004000400ULL,
0x0400040004000400ULL};
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_2048) = { 0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4095) = { 0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL,
+0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4096) = { 0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_8192) = { 0x2000200020002000ULL,
0x2000200020002000ULL,
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index 33dbb65..37a1869 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -47,6 +47,7 @@ extern const ymm_reg ff_pw_512;
extern const ymm_reg ff_pw_1023;
extern const ymm_reg ff_pw_1024;
extern const ymm_reg ff_pw_2048;
+extern const ymm_reg ff_pw_4095;
extern const ymm_reg ff_pw_4096;
extern const ymm_reg ff_pw_8192;
extern const ymm_reg ff_pw_m1;
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index d1a9514..47d2246 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -41,6 +41,18 @@ decl_mc_func(avg, sz, h, opt, type, fsz, bpp); \
decl_mc_func(put, sz, v, opt, type, fsz, bpp); \
decl_mc_func(avg, sz, v, opt, type, fsz, bpp)
+#define decl_ipred_fn(type, sz, bpp, opt) \
+void ff_vp9_ipred_##type##_##sz##x##sz##_##bpp##_##opt(uint8_t *dst, \
+ ptrdiff_t stride, \
+ const uint8_t *l, \
+ const uint8_t *a)
+
+#define decl_ipred_fns(type, bpp, opt4, opt8_16_32) \
+decl_ipred_fn(type, 4, bpp, opt4); \
+decl_ipred_fn(type, 8, bpp, opt8_16_32); \
+decl_ipred_fn(type, 16, bpp, opt8_16_32); \
+decl_ipred_fn(type, 32, bpp, opt8_16_32)
+
#define mc_rep_func(avg, sz, hsz, hszb, dir, opt, type, f_sz, bpp) \
static av_always_inline void \
ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##bpp##_##opt(uint8_t *dst, ptrdiff_t
dst_stride, \
@@ -142,6 +154,17 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
init_subpel3_8to64(idx, type, bpp, opt); \
init_subpel2(4, idx, 4, type, bpp, opt)
+#define cat(a, bpp, b) a##bpp##b
+
+#define init_ipred_func(type, enum, sz, bpp, opt) \
+dsp->intra_pred[TX_##sz##X##sz][enum##_PRED] = \
+cat(ff_vp9_ipred_##type##_##sz##x##sz##_, bpp, _##opt)
+
+#define init_8_16_32_ipred_funcs(type, enum, bpp, opt) \
+init_ipred_func(type, enum, 8, bpp, opt); \
+init_ipred_func(type, enum, 16, bpp, opt); \
+init_ipred_func(type, enum, 32, bpp, opt)
+
void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp);
diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
b/libavcodec/x86/vp9dsp_init_16bpp.c
index bd61e24..f4a4a5d 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp.c
@@ -46,6 +46,11 @@ decl_fpel_func(avg, 32, _16, avx2);
decl_fpel_func(avg,
[FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option
Signed-off-by: Kyle Swanson
---
doc/filters.texi| 9 +
libavfilter/f_ebur128.c | 22 ++
2 files changed, 31 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 044876c..e63311a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12642,6 +12642,15 @@ stream for better peak accuracy. It logs a message for
true-peak.
This mode requires a build with @code{libswresample}.
@end table
+@item dualmono
+Treat mono input files as 'dual mono.' If a mono file is intended for playback
+on a stereo system, its EBU R128 measurement will be perceptually incorrect.
+If set to @code{true}, this option will compensate for this effect.
+Multi-channel input files are not effected by this option.
+
+@item panlaw
+Set a specific pan law to be used for the measurement of dual mono files.
+This parameter is optional, and has a default value of -3.01dB.
@end table
@subsection Examples
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 1d5c8fd..906c9d7 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -139,6 +139,8 @@ typedef struct {
/* misc */
int loglevel; ///< log level for frame logging
int metadata; ///< whether or not to inject loudness
results in frames
+int dual_mono; ///< whether or not to treat single
channel input files as dual-mono
+double pan_law; ///< pan law value used to calulate
dual-mono measurements
} EBUR128Context;
enum {
@@ -163,6 +165,8 @@ static const AVOption ebur128_options[] = {
{ "none", "disable any peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_NONE}, INT_MIN, INT_MAX, A|F, "mode" },
{ "sample", "enable peak-sample mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_SAMPLES_PEAKS}, INT_MIN, INT_MAX, A|F, "mode" },
{ "true", "enable true-peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_TRUE_PEAKS},INT_MIN, INT_MAX, A|F, "mode" },
+{ "dualmono", "treat mono input files as dual-mono", OFFSET(dual_mono),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, A|V|F },
+{ "panlaw", "set a specific pan law for dual-mono files", OFFSET(pan_law),
AV_OPT_TYPE_DOUBLE, {.dbl = -3.01029995663978}, -10.0, 0.0, A|V|F },
{ NULL },
};
@@ -661,6 +665,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
}
if (nb_integrated)
ebur128->integrated_loudness = LOUDNESS(integrated_sum /
nb_integrated);
+/* dual-mono correction */
+if (nb_channels == 1 && ebur128->dual_mono) {
+ebur128->integrated_loudness -= ebur128->pan_law;
+}
}
/* LRA */
@@ -707,6 +715,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
}
}
+/* dual-mono correction */
+if (nb_channels == 1 && ebur128->dual_mono) {
+loudness_400 -= ebur128->pan_law;
+loudness_3000 -= ebur128->pan_law;
+}
+
#define LOG_FMT "M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f LU"
/* push one video frame */
@@ -855,6 +869,14 @@ static av_cold void uninit(AVFilterContext *ctx)
int i;
EBUR128Context *ebur128 = ctx->priv;
+/* dual-mono correction */
+if (ebur128->nb_channels == 1 && ebur128->dual_mono) {
+ebur128->i400.rel_threshold -= ebur128->pan_law;
+ebur128->i3000.rel_threshold -= ebur128->pan_law;
+ebur128->lra_low -= ebur128->pan_law;
+ebur128->lra_high -= ebur128->pan_law;
+}
+
av_log(ctx, AV_LOG_INFO, "Summary:\n\n"
" Integrated loudness:\n"
"I: %5.1f LUFS\n"
--
1.8.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
Hi, 2015-09-25 22:36 GMT+02:00 Ronald S. Bultje : > +pd_16: times 8 dd 16 In h264_intrapred_10bit.asm > +pd_32: times 8 dd 32 In h264_idct_10bit.asm And that's about anything remotely useful I have to say, as you were careful about those duplications. > +pmaxsw m0, m4 > +pmaxsw m1, m4 > +pmaxsw m2, m4 > +pmaxsw m3, m4 > +pminsw m0, m5 > +pminsw m1, m5 > +pminsw m2, m5 > +pminsw m3, m5 That was the only thing that surprised me, but then again I didn't look much at the tm mode. So, fine for me. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
Hi, On Fri, Sep 25, 2015 at 5:09 PM, Christophe Gisquet < christophe.gisq...@gmail.com> wrote: > Hi, > > 2015-09-25 22:36 GMT+02:00 Ronald S. Bultje : > > +pd_16: times 8 dd 16 > > In h264_intrapred_10bit.asm > > > +pd_32: times 8 dd 32 > > In h264_idct_10bit.asm > > And that's about anything remotely useful I have to say, as you were > careful about those duplications. Will move into constants.c, thanks for noticing. > +pmaxsw m0, m4 > > +pmaxsw m1, m4 > > +pmaxsw m2, m4 > > +pmaxsw m3, m4 > > +pminsw m0, m5 > > +pminsw m1, m5 > > +pminsw m2, m5 > > +pminsw m3, m5 > > That was the only thing that surprised me, but then again I didn't > look much at the tm mode. Hm, right, so the reason tm needs to clip (and others don't) is because this is the only one applying a non-positive filter. Most other filters (like in directional intra pred, but also dc) are a+b*2+c+2>>2 or a+b+1>>1 or just simple pixel copies (like v/h), but this one is a+b-c, so it can flip out of the allowed bitrange and thus needs clipping. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 6 +
libavcodec/x86/constants.h | 3 +
libavcodec/x86/h264_idct_10bit.asm | 5 +-
libavcodec/x86/h264_intrapred_10bit.asm | 2 +-
libavcodec/x86/vp9dsp_init.h| 23 +
libavcodec/x86/vp9dsp_init_16bpp.c | 15 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 7 +
libavcodec/x86/vp9intrapred_16bpp.asm | 671
libavcodec/x86/vp9lpf_16bpp.asm | 2 +-
libavcodec/x86/vp9mc_16bpp.asm | 2 +-
11 files changed, 730 insertions(+), 7 deletions(-)
create mode 100644 libavcodec/x86/vp9intrapred_16bpp.asm
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 9cddaac..44bf342 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -157,6 +157,7 @@ YASM-OBJS-$(CONFIG_VC1_DECODER)+= x86/vc1dsp.o
YASM-OBJS-$(CONFIG_VORBIS_DECODER) += x86/vorbisdsp.o
YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
+ x86/vp9intrapred_16bpp.o \
x86/vp9itxfm.o\
x86/vp9lpf.o \
x86/vp9lpf_16bpp.o\
diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 553dd49..19345f5 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -55,6 +55,8 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1024) = {
0x0400040004000400ULL, 0x040
0x0400040004000400ULL,
0x0400040004000400ULL};
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_2048) = { 0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4095) = { 0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL,
+0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4096) = { 0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_8192) = { 0x2000200020002000ULL,
0x2000200020002000ULL,
@@ -79,3 +81,7 @@ DECLARE_ALIGNED(16, const xmm_reg, ff_ps_neg) = {
0x80008000ULL, 0x800
DECLARE_ALIGNED(32, const ymm_reg, ff_pd_1)= { 0x00010001ULL,
0x00010001ULL,
0x00010001ULL,
0x00010001ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pd_16) = { 0x00100010ULL,
0x00100010ULL,
+0x00100010ULL,
0x00100010ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pd_32) = { 0x00200020ULL,
0x00200020ULL,
+0x00200020ULL,
0x00200020ULL };
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index 33dbb65..4a2451d 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -47,6 +47,7 @@ extern const ymm_reg ff_pw_512;
extern const ymm_reg ff_pw_1023;
extern const ymm_reg ff_pw_1024;
extern const ymm_reg ff_pw_2048;
+extern const ymm_reg ff_pw_4095;
extern const ymm_reg ff_pw_4096;
extern const ymm_reg ff_pw_8192;
extern const ymm_reg ff_pw_m1;
@@ -62,5 +63,7 @@ extern const uint64_t ff_pb_FC;
extern const xmm_reg ff_ps_neg;
extern const ymm_reg ff_pd_1;
+extern const ymm_reg ff_pd_16;
+extern const ymm_reg ff_pd_32;
#endif /* AVCODEC_X86_CONSTANTS_H */
diff --git a/libavcodec/x86/h264_idct_10bit.asm
b/libavcodec/x86/h264_idct_10bit.asm
index cc115b0..f1c2c81 100644
--- a/libavcodec/x86/h264_idct_10bit.asm
+++ b/libavcodec/x86/h264_idct_10bit.asm
@@ -24,14 +24,11 @@
%include "libavutil/x86/x86util.asm"
-SECTION_RODATA
-
-pd_32:times 4 dd 32
-
SECTION .text
cextern pw_1023
%define pw_pixel_max pw_1023
+cextern pd_32
;-
; void ff_h264_idct_add_10(pixel *dst, int16_t *block, int stride)
diff --git a/libavcodec/x86/h264_intrapred_10bit.asm
b/libavcodec/x86/h264_intrapred_10bit.asm
index 9aeb702..9e40cfe 100644
--- a/libavcodec/x86/h264_intrapred_10bit.asm
+++ b/libavcodec/x86/h264_intrapred_10bit.asm
@@ -34,11 +34,11 @@ cextern pw_8
cextern pw_4
cextern pw_2
cextern pw_1
+cextern pd_16
pw_m32101234: dw -3, -2, -1, 0, 1, 2, 3, 4
pw_m3:times 8 dw -3
pd_17:times 4 dd 17
-pd_16:times 4 dd 16
SECTION .text
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index d1a9514..47
[FFmpeg-devel] [PATCH 0/4] Misc dnxhd patches
The ones I'm not very pleased with are the first and last ones. I don't understand in the first one why I have to special case frame-threading to not run execute2. But I'm discovering the API. The last one feels like incomplete work. I do have a working patch to implement the feature, but until there's actually change in the flag value, it is useless. It raises again the question of colorspace conversion in a codec when various libraries exist. Christophe Gisquet (4): dnxhddec: implement slice multithreading dnxhddec: indicate colorspace dnxhddec: proper rule for interlaced mb flag dnxhddec: parse and print adaptive color transform libavcodec/dnxhddec.c | 245 +++--- 1 file changed, 155 insertions(+), 90 deletions(-) -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading
Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
---
libavcodec/dnxhddec.c | 221 ++
1 file changed, 133 insertions(+), 88 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 4a42360..d9762e4 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -32,10 +32,20 @@
#include "internal.h"
#include "thread.h"
+typedef struct RowContext {
+DECLARE_ALIGNED(16, int16_t, blocks)[12][64];
+int luma_scale[64];
+int chroma_scale[64];
+GetBitContext gb;
+int last_dc[3];
+int last_qscale;
+} RowContext;
+
typedef struct DNXHDContext {
AVCodecContext *avctx;
-GetBitContext gb;
BlockDSPContext bdsp;
+const uint8_t* buf;
+int buf_size;
int64_t cid;///< compression id
unsigned int width, height;
enum AVPixelFormat pix_fmt;
@@ -43,28 +53,27 @@ typedef struct DNXHDContext {
uint32_t mb_scan_index[68]; /* max for 1080p */
int cur_field; ///< current interlaced field
VLC ac_vlc, dc_vlc, run_vlc;
-int last_dc[3];
IDCTDSPContext idsp;
-DECLARE_ALIGNED(16, int16_t, blocks)[12][64];
ScanTable scantable;
const CIDEntry *cid_table;
int bit_depth; // 8, 10 or 0 if not initialized at all.
int is_444;
-void (*decode_dct_block)(struct DNXHDContext *ctx, int16_t *block,
+void (*decode_dct_block)(const struct DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
int n, int qscale);
-int last_qscale;
-int luma_scale[64];
-int chroma_scale[64];
} DNXHDContext;
#define DNXHD_VLC_BITS 9
#define DNXHD_DC_VLC_BITS 7
-static void dnxhd_decode_dct_block_8(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_8(const DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
int n, int qscale);
-static void dnxhd_decode_dct_block_10(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
int n, int qscale);
-static void dnxhd_decode_dct_block_10_444(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
int n, int qscale);
static av_cold int dnxhd_decode_init(AVCodecContext *avctx)
@@ -215,12 +224,13 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
}
for (i = 0; i < ctx->mb_height; i++) {
-ctx->mb_scan_index[i] = AV_RB32(buf + 0x170 + (i << 2));
-ff_dlog(ctx->avctx, "mb scan index %d\n", ctx->mb_scan_index[i]);
-if (buf_size < ctx->mb_scan_index[i] + 0x280LL) {
+uint32_t index = AV_RB32(buf + 0x170 + (i << 2));
+ctx->mb_scan_index[i] = index;
+ff_dlog(ctx->avctx, "mb scan index %d\n", index);
+if (buf_size < index + 0x280LL) {
av_log(ctx->avctx, AV_LOG_ERROR,
"invalid mb scan index (%d < %d).\n",
- buf_size, ctx->mb_scan_index[i] + 0x280);
+ buf_size, index + 0x280);
return AVERROR_INVALIDDATA;
}
}
@@ -228,7 +238,8 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
return 0;
}
-static av_always_inline void dnxhd_decode_dct_block(DNXHDContext *ctx,
+static av_always_inline void dnxhd_decode_dct_block(const DNXHDContext *ctx,
+RowContext *row,
int16_t *block, int n,
int qscale,
int index_bits,
@@ -242,61 +253,61 @@ static av_always_inline void
dnxhd_decode_dct_block(DNXHDContext *ctx,
const uint8_t *ac_level = ctx->cid_table->ac_level;
const uint8_t *ac_flags = ctx->cid_table->ac_flags;
const int eob_index = ctx->cid_table->eob_index;
-OPEN_READER(bs, &ctx->gb);
+OPEN_READER(bs, &row->gb);
if (!ctx->is_444) {
if (n & 2) {
component = 1 + (n & 1);
-scale = ctx->chroma_scale;
+scale = row->chroma_scale;
weight_matrix = ctx->cid_table->chroma_weight;
} else {
component = 0;
-scale = ctx->luma_scale;
+scale = row->luma_scale;
weight_matrix = ctx->cid_table->luma_weight;
}
} else {
component = (n >> 1) % 3;
if (component) {
-scale = ctx->chroma_scale;
+scale = row->chroma_scale;
weight_matrix = ctx->cid_tab
[FFmpeg-devel] [PATCH 2/4] dnxhddec: indicate colorspace
It is supposed to only old BT.709 colorspaces. --- libavcodec/dnxhddec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index d9762e4..0722aa0 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -82,6 +82,7 @@ static av_cold int dnxhd_decode_init(AVCodecContext *avctx) ctx->avctx = avctx; ctx->cid = -1; +avctx->colorspace = AVCOL_SPC_BT709; return 0; } -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] dnxhddec: proper rule for interlaced mb flag
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
---
libavcodec/dnxhddec.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 0722aa0..82a0d3c 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -58,6 +58,7 @@ typedef struct DNXHDContext {
const CIDEntry *cid_table;
int bit_depth; // 8, 10 or 0 if not initialized at all.
int is_444;
+int mbaff;
void (*decode_dct_block)(const struct DNXHDContext *ctx,
RowContext *row, int16_t *block,
int n, int qscale);
@@ -153,6 +154,7 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
} else {
ctx->cur_field = 0;
}
+ctx->mbaff = buf[0x6] & 32;
ctx->height = AV_RB16(buf + 0x18);
ctx->width = AV_RB16(buf + 0x1a);
@@ -192,6 +194,9 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
if ((ret = dnxhd_init_vlc(ctx, cid)) < 0)
return ret;
+if (ctx->mbaff && ctx->cid_table->cid != 1260)
+av_log(ctx->avctx, AV_LOG_WARNING,
+ "Adaptive MB interlace flag in an unsupported profile.\n");
// make sure profile size constraints are respected
// DNx100 allows 1920->1440 and 1280->960 subsampling
@@ -366,7 +371,7 @@ static int dnxhd_decode_macroblock(const DNXHDContext *ctx,
RowContext *row,
int qscale, i;
int interlaced_mb = 0;
-if (ctx->cid_table->cid == 1260) {
+if (ctx->mbaff) {
interlaced_mb = get_bits1(&row->gb);
qscale = get_bits(&row->gb, 10);
} else
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option
On Fri, Sep 25, 2015 at 4:04 PM, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson
> ---
> doc/filters.texi| 9 +
> libavfilter/f_ebur128.c | 22 ++
> 2 files changed, 31 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 044876c..e63311a 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -12642,6 +12642,15 @@ stream for better peak accuracy. It logs a message
> for true-peak.
> This mode requires a build with @code{libswresample}.
> @end table
>
> +@item dualmono
> +Treat mono input files as 'dual mono.' If a mono file is intended for
> playback
> +on a stereo system, its EBU R128 measurement will be perceptually incorrect.
> +If set to @code{true}, this option will compensate for this effect.
> +Multi-channel input files are not effected by this option.
> +
> +@item panlaw
> +Set a specific pan law to be used for the measurement of dual mono files.
> +This parameter is optional, and has a default value of -3.01dB.
> @end table
>
> @subsection Examples
> diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
> index 1d5c8fd..906c9d7 100644
> --- a/libavfilter/f_ebur128.c
> +++ b/libavfilter/f_ebur128.c
> @@ -139,6 +139,8 @@ typedef struct {
> /* misc */
> int loglevel; ///< log level for frame logging
> int metadata; ///< whether or not to inject loudness
> results in frames
> +int dual_mono; ///< whether or not to treat single
> channel input files as dual-mono
> +double pan_law; ///< pan law value used to calulate
> dual-mono measurements
> } EBUR128Context;
>
> enum {
> @@ -163,6 +165,8 @@ static const AVOption ebur128_options[] = {
> { "none", "disable any peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
> PEAK_MODE_NONE}, INT_MIN, INT_MAX, A|F, "mode" },
> { "sample", "enable peak-sample mode", 0, AV_OPT_TYPE_CONST, {.i64 =
> PEAK_MODE_SAMPLES_PEAKS}, INT_MIN, INT_MAX, A|F, "mode" },
> { "true", "enable true-peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
> PEAK_MODE_TRUE_PEAKS},INT_MIN, INT_MAX, A|F, "mode" },
> +{ "dualmono", "treat mono input files as dual-mono", OFFSET(dual_mono),
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, A|V|F },
> +{ "panlaw", "set a specific pan law for dual-mono files",
> OFFSET(pan_law), AV_OPT_TYPE_DOUBLE, {.dbl = -3.01029995663978}, -10.0, 0.0,
> A|V|F },
> { NULL },
> };
>
> @@ -661,6 +665,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> }
> if (nb_integrated)
> ebur128->integrated_loudness = LOUDNESS(integrated_sum /
> nb_integrated);
> +/* dual-mono correction */
> +if (nb_channels == 1 && ebur128->dual_mono) {
> +ebur128->integrated_loudness -= ebur128->pan_law;
> +}
> }
>
> /* LRA */
> @@ -707,6 +715,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> }
> }
>
> +/* dual-mono correction */
> +if (nb_channels == 1 && ebur128->dual_mono) {
> +loudness_400 -= ebur128->pan_law;
> +loudness_3000 -= ebur128->pan_law;
> +}
> +
> #define LOG_FMT "M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f LU"
>
> /* push one video frame */
> @@ -855,6 +869,14 @@ static av_cold void uninit(AVFilterContext *ctx)
> int i;
> EBUR128Context *ebur128 = ctx->priv;
>
> +/* dual-mono correction */
> +if (ebur128->nb_channels == 1 && ebur128->dual_mono) {
> +ebur128->i400.rel_threshold -= ebur128->pan_law;
> +ebur128->i3000.rel_threshold -= ebur128->pan_law;
> +ebur128->lra_low -= ebur128->pan_law;
> +ebur128->lra_high -= ebur128->pan_law;
> +}
> +
> av_log(ctx, AV_LOG_INFO, "Summary:\n\n"
> " Integrated loudness:\n"
> "I: %5.1f LUFS\n"
> --
> 1.8.4
>
This is a feature supported by many other loudness scanners. In the
United States, this filter is used to measure loudness for much of our
distributed public radio content. Our current workaround is to first
determine channel count, and then alter our calls to FFmpeg
accordingly. This is a simple, but quite useful feature to have.
Compare the output of the following commands. The first is our
workaround, and the second is an equivalent command which also
provides an accurate measurement. The advantage to having this built
in is that the same call can be used for multi-channel inputs as well.
ffmpeg -nostats -i mono.wav -filter_complex
"[0:0][0:0]amerge=inputs=2[aout];[aout]ebur128=framelog=verbose:peak=sample+true"
-f null -
ffmpeg -nostats -i mono.wav -filter_complex ebur128=dualmono=true
ebur128 -f null -
See also: https://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/139910.html
Also see this blo
[FFmpeg-devel] [PATCH 4/4] dnxhddec: parse and print adaptive color transform
Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.
Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the output format to decide what to do of it.
---
libavcodec/dnxhddec.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 82a0d3c..7570a9a 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -59,6 +59,7 @@ typedef struct DNXHDContext {
int bit_depth; // 8, 10 or 0 if not initialized at all.
int is_444;
int mbaff;
+int act;
void (*decode_dct_block)(const struct DNXHDContext *ctx,
RowContext *row, int16_t *block,
int n, int qscale);
@@ -198,6 +199,11 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
av_log(ctx->avctx, AV_LOG_WARNING,
"Adaptive MB interlace flag in an unsupported profile.\n");
+ctx->act = buf[0x2C] & 7;
+if (ctx->act && ctx->cid_table->cid != 1256)
+av_log(ctx->avctx, AV_LOG_WARNING,
+ "Adaptive color transform in an unsupported profile.\n");
+
// make sure profile size constraints are respected
// DNx100 allows 1920->1440 and 1280->960 subsampling
if (ctx->width != ctx->cid_table->width) {
@@ -368,7 +374,7 @@ static int dnxhd_decode_macroblock(const DNXHDContext *ctx,
RowContext *row,
int dct_linesize_chroma = frame->linesize[1];
uint8_t *dest_y, *dest_u, *dest_v;
int dct_y_offset, dct_x_offset;
-int qscale, i;
+int qscale, i, act;
int interlaced_mb = 0;
if (ctx->mbaff) {
@@ -376,7 +382,15 @@ static int dnxhd_decode_macroblock(const DNXHDContext
*ctx, RowContext *row,
qscale = get_bits(&row->gb, 10);
} else
qscale = get_bits(&row->gb, 11);
-skip_bits1(&row->gb);
+act = get_bits1(&row->gb);
+if (act) {
+static int warned = 0;
+if (!warned) {
+warned = 1;
+av_log(ctx->avctx, AV_LOG_ERROR,
+ "Unsupported adaptive color transform, patch welcome.\n");
+}
+}
if (qscale != row->last_qscale) {
for (i = 0; i < 64; i++) {
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: Use a self-balancing tree
On Fri, Sep 25, 2015 at 10:06:41PM +0200, Henrik Gramner wrote: > On Fri, Sep 25, 2015 at 9:57 PM, Michael Niedermayer wrote: > > is there any reason why this doesnt use > > libavutil/tree.* ? > > Two reasons basically. > > First, the glue code required to use a generic tree implementation > instead of one customized for this use case would be as large as the > implementation of the tree itself. > > Second, my intention is to port it back to x264 at some point so I > don't want to rely too much on libavutil features unless there's a > large benefit of doing so. ahh, ok, no objection from me then [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] checkasm: clip vp9 loopfilter test pixels inside allowed bitdepth range.
On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje wrote: > --- > tests/checkasm/vp9dsp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Ok as long as it doesn't skew the range distribution so much that you'll end up with the same max clipped value all the time. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] checkasm: clip vp9 loopfilter test pixels inside allowed bitdepth range.
Hi, On Fri, Sep 25, 2015 at 6:42 PM, Henrik Gramner wrote: > On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje > wrote: > > --- > > tests/checkasm/vp9dsp.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Ok as long as it doesn't skew the range distribution so much that > you'll end up with the same max clipped value all the time. We basically fill pixels with base+/-range, so it clips at worst in one direction, and only for a few seed values where base happens to be very low or high. So it should be OK. Thanks, Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source
Assumes 'GA94' format (ATSC standard)
Signed-off-by: DHE
---
doc/encoders.texi| 5 +
libavcodec/libx264.c | 37 +
2 files changed, 42 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..8e3770b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with
@command{ffmpeg}:
ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an
out.mkv
@end example
+@item a53cc
+Import closed captions (which must be ATSC compatible format) into output.
+At this time only the mpeg2 decoder provides these. Default is 0 (off).
+
+
@item x264-params (N.A.)
Override the x264 configuration using a :-separated list of key=value
parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..4227bcc 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
int avcintra_class;
int motion_est;
int forced_idr;
+int a53_cc;
char *x264_params;
} X264Context;
@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
int nnal, i, ret;
x264_picture_t pic_out = {0};
int pict_type;
+AVFrameSideData *side_data;
x264_picture_init( &x4->pic );
x4->pic.img.i_csp = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
X264_TYPE_AUTO;
reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads =
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[0].payload_size = side_data->size +
11;
+x4->pic.extra_sei.payloads[0].payload =
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
+x4->pic.extra_sei.payloads[0].payload_type = 4;
+memcpy(x4->pic.extra_sei.payloads[0].payload + 10,
side_data->data, side_data->size);
+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, but hard
coding
+ * this style may not be the right thing to do -- other formats
+ * do exist. This information is not available in the side_data
+ * so we are going with this right now.
+ */
+x4->pic.extra_sei.payloads[0].payload[3] = 'G';
+x4->pic.extra_sei.payloads[0].payload[4] = 'A';
+x4->pic.extra_sei.payloads[0].payload[5] = '9';
+x4->pic.extra_sei.payloads[0].payload[6] = '4';
+x4->pic.extra_sei.payloads[0].payload[7] = 3;
+x4->pic.extra_sei.payloads[0].payload[8] =
+ ((side_data->size/3) & 0x1f) | 0x40;
+x4->pic.extra_sei.payloads[0].payload[9] = 0;
+x4->pic.extra_sei.payloads[0].payload[side_data->size+10] =
255;
+}
+}
+
}
do {
if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL,
&pic_out) < 0)
@@ -821,6 +857,7 @@ static const AVOption options[] = {
{"level", "Specify level (as defined by Annex A)", OFFSET(level),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
{"passlogfile", "Filename for 2 pass stats", OFFSET(stats),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
{"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
+{"a53cc", "Use A53 Closed Captions (if available)",
OFFSET(a53_cc),AV_OPT_TYPE_INT,
{.i64 = 0}, 0, 1, VE},
{"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING,
{.str=NULL}, 0, 0, VE},
{ "crf", "Select the quality for constant quality mode",
OFFSET(crf), AV_OPT_TYPE_FLOAT,
{.dbl = -1 }, -1, FLT_MAX, VE },
{ "crf_max", "In CRF mode, prevents VBV from lowering quality beyond
this point.",OFFSET(crf_max),
AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE },
--
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dnxhddec: indicate colorspace
On Fri, Sep 25, 2015 at 11:25:07PM +0200, Christophe Gisquet wrote: > It is supposed to only old BT.709 colorspaces. > --- > libavcodec/dnxhddec.c | 1 + > 1 file changed, 1 insertion(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source
DeHackEd dehacked.net> writes: > + item a53cc > +Import closed captions (which must be ATSC compatible format) into output. > +At this time only the mpeg2 decoder provides these. I thought the h264 decoder also provides them, no? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading
On Fri, Sep 25, 2015 at 11:25:06PM +0200, Christophe Gisquet wrote: > Around 3x speedup with 4 threads. Maybe more mb lines should be > batched per thread, but that's good enough for a first try. > --- > libavcodec/dnxhddec.c | 221 > ++ > 1 file changed, 133 insertions(+), 88 deletions(-) This segfaults with http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov [Switching to Thread 0x7fffddc35700 (LWP 26013)] 0x00745550 in get_bits (s=0x7fffddc34470, n=11) at libavcodec/get_bits.h:265 265 UPDATE_CACHE(re, s); (gdb) bt #0 0x00745550 in get_bits (s=0x7fffddc34470, n=11) at libavcodec/get_bits.h:265 #1 0x00746a59 in dnxhd_decode_macroblock (ctx=0x1cb7be0, row=0x7fffddc33c70, frame=0x1ce4080, x=0, y=0) at libavcodec/dnxhddec.c:373 #2 0x007471c6 in dnxhd_decode_row (avctx=0x1ce34e0, data=0x1ce4080, jobnr=0, threadnr=0) at libavcodec/dnxhddec.c:466 #3 0x00af53fd in avcodec_default_execute2 (c=0x1ce34e0, func=0x7470e6 , arg=0x1ce4080, ret=0x0, count=68) at libavcodec/utils.c:959 #4 0x00747284 in dnxhd_decode_macroblocks (ctx=0x1ce42c0, frame=0x1ce4080, buf=0x7fffeae11290 "", buf_size=1834368) at libavcodec/dnxhddec.c:480 #5 0x007475da in dnxhd_decode_frame (avctx=0x1ce3c00, data=0x1ce4080, got_frame=0x1ce22f0, avpkt=0x1ce2298) at libavcodec/dnxhddec.c:541 #6 0x00a3bc76 in frame_worker_thread (arg=0x1ce2198) at libavcodec/pthread_frame.c:154 #7 0x7fffef83ee9a in start_thread (arg=0x7fffddc35700) at pthread_create.c:308 #8 0x7fffef56c38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x in ?? () [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH][RFC] tests/checkasm/checkasm: remove use of deprecated av_set_cpu_flags_mask()
This patch completes the removal of all uses of av_set_cpu_flags_mask, so the
deprecated function can be removed in a future version bump.
Signed-off-by: Ganesh Ajjanagadde
---
tests/checkasm/checkasm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 2bfa9d4..5981040 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -323,7 +323,8 @@ static void check_cpu_flag(const char *name, int flag)
int old_cpu_flag = state.cpu_flag;
flag |= old_cpu_flag;
-av_set_cpu_flags_mask(flag);
+flag &= av_get_cpu_flags();
+av_force_cpu_flags(flag);
state.cpu_flag = av_get_cpu_flags();
if (!flag || state.cpu_flag != old_cpu_flag) {
--
2.5.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source
On 09/25/2015 07:45 PM, Carl Eugen Hoyos wrote: > DeHackEd dehacked.net> writes: > >> + item a53cc >> +Import closed captions (which must be ATSC compatible format) into output. >> +At this time only the mpeg2 decoder provides these. > > I thought the h264 decoder also provides them, no? Indeed, you are correct. Not sure how I missed that. A quick test (using my own output) came up positive so I'll just update the docs. > > Carl Eugen > > ___ > 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] [PATCH] libx264: copy A53 closed captions from source
Assumes 'GA94' format (ATSC standard)
Signed-off-by: DHE
---
doc/encoders.texi| 5 +
libavcodec/libx264.c | 37 +
2 files changed, 42 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..bb16dea 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with
@command{ffmpeg}:
ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an
out.mkv
@end example
+@item a53cc
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
+
+
@item x264-params (N.A.)
Override the x264 configuration using a :-separated list of key=value
parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..4227bcc 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
int avcintra_class;
int motion_est;
int forced_idr;
+int a53_cc;
char *x264_params;
} X264Context;
@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
int nnal, i, ret;
x264_picture_t pic_out = {0};
int pict_type;
+AVFrameSideData *side_data;
x264_picture_init( &x4->pic );
x4->pic.img.i_csp = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
X264_TYPE_AUTO;
reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads =
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[0].payload_size = side_data->size +
11;
+x4->pic.extra_sei.payloads[0].payload =
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
+x4->pic.extra_sei.payloads[0].payload_type = 4;
+memcpy(x4->pic.extra_sei.payloads[0].payload + 10,
side_data->data, side_data->size);
+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, but hard
coding
+ * this style may not be the right thing to do -- other formats
+ * do exist. This information is not available in the side_data
+ * so we are going with this right now.
+ */
+x4->pic.extra_sei.payloads[0].payload[3] = 'G';
+x4->pic.extra_sei.payloads[0].payload[4] = 'A';
+x4->pic.extra_sei.payloads[0].payload[5] = '9';
+x4->pic.extra_sei.payloads[0].payload[6] = '4';
+x4->pic.extra_sei.payloads[0].payload[7] = 3;
+x4->pic.extra_sei.payloads[0].payload[8] =
+ ((side_data->size/3) & 0x1f) | 0x40;
+x4->pic.extra_sei.payloads[0].payload[9] = 0;
+x4->pic.extra_sei.payloads[0].payload[side_data->size+10] =
255;
+}
+}
+
}
do {
if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL,
&pic_out) < 0)
@@ -821,6 +857,7 @@ static const AVOption options[] = {
{"level", "Specify level (as defined by Annex A)", OFFSET(level),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
{"passlogfile", "Filename for 2 pass stats", OFFSET(stats),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
{"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
+{"a53cc", "Use A53 Closed Captions (if available)",
OFFSET(a53_cc),AV_OPT_TYPE_INT,
{.i64 = 0}, 0, 1, VE},
{"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING,
{.str=NULL}, 0, 0, VE},
{ "crf", "Select the quality for constant quality mode",
OFFSET(crf), AV_OPT_TYPE_FLOAT,
{.dbl = -1 }, -1, FLT_MAX, VE },
{ "crf_max", "In CRF mode, prevents VBV from lowering quality beyond
this point.",OFFSET(crf_max),
AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE },
--
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/opt: add flag to return NULL when applicable in av_opt_get
On Mon, Sep 21, 2015 at 01:25:15PM -0500, Rodger Combs wrote: > --- > libavutil/opt.c | 12 ++-- > libavutil/opt.h | 10 ++ > libavutil/version.h | 2 +- > 3 files changed, 21 insertions(+), 3 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/audio_convert: fix clobbering of xmm registers
Signed-off-by: James Almer --- libswresample/x86/audio_convert.asm | 122 ++-- 1 file changed, 61 insertions(+), 61 deletions(-) diff --git a/libswresample/x86/audio_convert.asm b/libswresample/x86/audio_convert.asm index e9a9acf..d441636 100644 --- a/libswresample/x86/audio_convert.asm +++ b/libswresample/x86/audio_convert.asm @@ -202,8 +202,8 @@ cglobal %2_to_%1_%3, 3, 3, 6, dst, src, len %endif %endmacro -%macro PACK_6CH 5-7 -cglobal pack_6ch_%2_to_%1_%3, 2,8,7, dst, src, src1, src2, src3, src4, src5, len +%macro PACK_6CH 8 +cglobal pack_6ch_%2_to_%1_%3, 2, 8, %6, dst, src, src1, src2, src3, src4, src5, len %if ARCH_X86_64 mov lend, r2d %else @@ -239,7 +239,7 @@ pack_6ch_%2_to_%1_u_int %+ SUFFIX: subsrc3q, srcq subsrc4q, srcq subsrc5q, srcq -%7 x,x,x,x,m7,x +%8 x,x,x,x,m7,x .loop: mov%3 m0, [srcq ] mov%3 m1, [srcq+src1q] @@ -271,9 +271,9 @@ pack_6ch_%2_to_%1_u_int %+ SUFFIX: movlhps m1, m3 movhlps m5, m3 -%6 m0,m6,x,x,m7,m3 -%6 m4,m1,x,x,m7,m3 -%6 m2,m5,x,x,m7,m3 +%7 m0,m6,x,x,m7,m3 +%7 m4,m1,x,x,m7,m3 +%7 m2,m5,x,x,m7,m3 mov %+ %3 %+ ps [dstq ], m0 mov %+ %3 %+ ps [dstq+16], m6 @@ -305,8 +305,8 @@ pack_6ch_%2_to_%1_u_int %+ SUFFIX: %endif %endmacro -%macro UNPACK_6CH 5-7 -cglobal unpack_6ch_%2_to_%1_%3, 2, 8, 8, dst, src, dst1, dst2, dst3, dst4, dst5, len +%macro UNPACK_6CH 8 +cglobal unpack_6ch_%2_to_%1_%3, 2, 8, %6, dst, src, dst1, dst2, dst3, dst4, dst5, len %if ARCH_X86_64 mov lend, r2d %else @@ -342,7 +342,7 @@ unpack_6ch_%2_to_%1_u_int %+ SUFFIX: subdst3q, dstq subdst4q, dstq subdst5q, dstq -%7 x,x,x,x,m7,x +%8 x,x,x,x,m7,x .loop: mov%3 m0, [srcq ] mov%3 m1, [srcq+16] @@ -360,9 +360,9 @@ unpack_6ch_%2_to_%1_u_int %+ SUFFIX: SWAP 1, 4 SWAP 2, 3 -%6 m0,m1,x,x,m7,m6 -%6 m2,m3,x,x,m7,m6 -%6 m4,m5,x,x,m7,m6 +%7 m0,m1,x,x,m7,m6 +%7 m2,m3,x,x,m7,m6 +%7 m4,m5,x,x,m7,m6 mov %+ %3 %+ ps [dstq ], m0 mov %+ %3 %+ ps [dstq+dst1q], m1 @@ -380,8 +380,8 @@ unpack_6ch_%2_to_%1_u_int %+ SUFFIX: %define PACK_8CH_GPRS (10 * ARCH_X86_64) + ((6 + HAVE_ALIGNED_STACK) * ARCH_X86_32) -%macro PACK_8CH 5-7 -cglobal pack_8ch_%2_to_%1_%3, 2,PACK_8CH_GPRS,10, ARCH_X86_32*48, dst, src, len, src1, src2, src3, src4, src5, src6, src7 +%macro PACK_8CH 8 +cglobal pack_8ch_%2_to_%1_%3, 2, PACK_8CH_GPRS, %6, ARCH_X86_32*48, dst, src, len, src1, src2, src3, src4, src5, src6, src7 mov dstq, [dstq] %if ARCH_X86_32 DEFINE_ARGS dst, src, src2, src3, src4, src5, src6 @@ -463,7 +463,7 @@ pack_8ch_%2_to_%1_u_int %+ SUFFIX: %endif %if ARCH_X86_64 -%7 x,x,x,x,m9,x +%8 x,x,x,x,m9,x %elifidn %1, int32 %define m9 [flt2p31] %else @@ -489,10 +489,10 @@ pack_8ch_%2_to_%1_u_int %+ SUFFIX: %if ARCH_X86_64 TRANSPOSE8x4D 0, 1, 2, 3, 4, 5, 6, 7, 8 -%6 m0,m1,x,x,m9,m8 -%6 m2,m3,x,x,m9,m8 -%6 m4,m5,x,x,m9,m8 -%6 m6,m7,x,x,m9,m8 +%7 m0,m1,x,x,m9,m8 +%7 m2,m3,x,x,m9,m8 +%7 m4,m5,x,x,m9,m8 +%7 m6,m7,x,x,m9,m8 mov%3 [dstq], m0 %else @@ -500,12 +500,12 @@ pack_8ch_%2_to_%1_u_int %+ SUFFIX: TRANSPOSE8x4D 0, 1, 2, 3, 4, 5, 6, 7, [rsp], [rsp+16], 1 -%6 m0,m1,x,x,m9,m2 +%7 m0,m1,x,x,m9,m2 mova m2, [rsp] mov%3 [dstq], m0 -%6 m2,m3,x,x,m9,m0 -%6 m4,m5,x,x,m9,m0 -%6 m6,m7,x,x,m9,m0 +%7 m2,m3,x,x,m9,m0 +%7 m4,m5,x,x,m9,m0 +%7 m6,m7,x,x,m9,m0 %endif @@ -614,15 +614,15 @@ CONV int32, int16, a, 2, 1, INT16_TO_INT32_N, NOP_N CONV int16, int32, u, 1, 2, INT32_TO_INT16_N, NOP_N CONV int16, int32, a, 1, 2, INT32_TO_INT16_N, NOP_N -PACK_6CH float, float, u, 2, 2, NOP_N, NOP_N -PACK_6CH float, float, a, 2, 2, NOP_N, NOP_N +PACK_6CH float, float, u, 2, 2, 0, NOP_N, NOP_N +PACK_6CH float, float, a, 2, 2, 0, NOP_N, NOP_N INIT_XMM sse -PACK_6CH float, float, u, 2, 2, NOP_N, NOP_N -PACK_6CH float, float, a, 2, 2, NOP_N, NOP_N +PACK_6CH float, float, u, 2, 2, 7, NOP_N, NOP_N +PACK_6CH float, float, a, 2, 2, 7, NOP_N, NOP_N -UNPACK_6CH float, float, u, 2, 2, NOP_N, NOP_N -UNPACK_6CH float, float, a, 2, 2, NOP_N, NOP_N +UNPACK_6CH float, float, u, 2, 2, 7, NOP_N, NOP_N +UNPACK_6CH float, float, a, 2, 2, 7, NOP_N, NOP_N INIT_XMM sse2 CONV int32, int16, u, 2, 1, INT16_TO_INT32_N, NOP_N @@ -675,23 +675,23 @@ UNPACK_2CH float, int16, a, 2, 1, INT16_TO_FLOAT_N, INT16_TO_FLOAT_INIT UNPACK_2CH int16, float, u, 1, 2, FLOAT_TO_INT16_N, FLOAT_TO_INT16_INIT UNPACK_2CH int16, float, a, 1, 2, FLOAT_TO_INT16_N, FLOAT_TO_INT16_INIT -PACK_6CH float, int32, u, 2, 2, INT32_TO_FLOAT_N, INT32_TO_FLOAT_INIT -PACK_6CH float, int32, a, 2, 2, INT32_TO_FLOAT_N, INT32_TO_FLOAT_INIT -PACK_6CH int32, float, u, 2, 2, FLOAT_TO_INT32_N, FLOAT_TO_INT32_INIT -PACK_6CH int32, float, a, 2, 2, FLOAT_TO_INT32_N, FLOAT_TO_INT32_INIT +PACK_6CH float, int32, u, 2, 2, 8, I
Re: [FFmpeg-devel] [PATCH 1/3] tests/checkasm: make randomize_buffers a function for easier debugging
On Tue, Sep 22, 2015 at 03:45:59PM +0200, Ronald S. Bultje wrote: > Hi, > > On Mon, Sep 21, 2015 at 4:55 AM, Rodger Combs > wrote: > > > --- > > tests/checkasm/vp9dsp.c | 108 > > +--- > > 1 file changed, 57 insertions(+), 51 deletions(-) > > > LGTM. Sorry for the initial long macro, that was kind of ugly, yes. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] AAC encoder: tweak PNS usage to be more aggressive
> ffmpeg | branch: master | Claudio Freire | Fri > Sep 25 03:56:32 2015 -0300| [9458a62decfcaa1313b1ba69276466de536d0768] | > committer: Claudio Freire > > AAC encoder: tweak PNS usage to be more aggressive > > This patch tweaks search_for_pns to be both more > aggressive and more careful when applying PNS. On > the one side, it will again try to use PNS on zero > (or effectively zero) bands. For this, both zeroes > and band_type have to be checked (some ZERO bands > aren't marked in zeroes). On the other side, a more > accurate rate-distortion measure avoids using PNS > where it would cause audible distortion. > > Also fixed a small bug in the computation of freq > that caused PNS usage on low-frequency bands during > 8-short windows. This allows re-enabling PNS during > 8-short. Clang and gcc's address sanitizer complain about this change http://fate.ffmpeg.org/report.cgi?time=20150925234050&slot=x86_64-archlinux-gcc-asan http://fate.ffmpeg.org/report.cgi?time=20150925220641&slot=x86_64-debian-asan-144800 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: Combine dynamicbase and nxcompat checks
They were added to binutils in the same version so it's safe to combine. Signed-off-by: Alex Smith --- configure | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configure b/configure index 3339126..b572d59 100755 --- a/configure +++ b/configure @@ -4367,8 +4367,6 @@ case $target_os in LIBTARGET=arm-wince fi enabled shared && ! enabled small && check_cmd $windres --version && enable gnu_windres -check_ldflags -Wl,--nxcompat -check_ldflags -Wl,--dynamicbase enabled x86_32 && check_ldflags -Wl,--large-address-aware shlibdir_default="$bindir_default" SLIBPREF="" @@ -4392,6 +4390,7 @@ case $target_os in objformat="win32" ranlib=: enable dos_paths +check_ldflags -Wl,--nxcompat,--dynamicbase # Lets work around some stupidity in binutils. # ld will strip relocations from executables even though we need them # for dynamicbase (ASLR). Using -pie does retain the reloc section -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading
Hi, 2015-09-26 1:52 GMT+02:00 Michael Niedermayer : > This segfaults with > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov Can't reproduce with frame or slice threading or no threading. What was the command-line? > #3 0x00af53fd in avcodec_default_execute2 (c=0x1ce34e0, func=0x7470e6 [...] > #6 0x00a3bc76 in frame_worker_thread (arg=0x1ce2198) at > libavcodec/pthread_frame.c:154 Indicates maybe frame+slice, but that brings me to the point: why is it crashing at all? Is it something that should be avoidable through my code? It seems I should just avoid running the slice-threading code in the frame threading case. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3 v2] configure: Support for HEASLR on mingw targets
From: Alex Smith The appropriate flag for HEASLR (--high-entropy-va) was added in binutils 2.25. Also set the image base >4GB so higher entropy gets applied to image base randomization when used with HEASLR (8 -> 17 bits of randomization). Windows does this for compatibility because of "latent pointer truncation issues". Signed-off-by: Alex Smith --- configure | 4 1 file changed, 4 insertions(+) diff --git a/configure b/configure index f6bc622..0a4b4ed 100755 --- a/configure +++ b/configure @@ -4401,6 +4401,10 @@ case $target_os in add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup elif enabled x86_64; then add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup +check_ldflags -Wl,--high-entropy-va # binutils 2.25 +# Set image base >4GB for extra entropy with HEASLR +add_ldexeflags -Wl,--image-base,0x14000 +append SHFLAGS -Wl,--image-base,0x18000 fi ;; win32|win64) -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
