[FFmpeg-devel] [dan.par...@mail.com: Re: [PATCH] PPC64: The following is probably gratuitous, but after witnessing a couple of months of this type of abrupt interjection ...]
Apparently this mail is meant for anyone in addition to myself, so I'm forwarding to the mailing-list. - Forwarded message from Dan Parrot - Date: Wed, 06 Jul 2016 19:12:54 -0500 From: Dan Parrot To: Clément Bœsch Subject: Re: [FFmpeg-devel] [PATCH] PPC64: The following is probably gratuitous, but after witnessing a couple of months of this type of abrupt interjection ... X-Mailer: Evolution 3.12.9-1+b1 To Clement and anyone that might be similarly inclined to snipe into conversations that had nichts zu tun (or is it keine zu tun) with them: Word to those that will listen: I shall always wield a rhetorical sword a few inches/centimeters longer than that which initiated contact against me. Why? Deterrence. That's why. (As Henry Lapkiss knows now. That's right - the name-mangling is intended disrespectfully.) But, feel free, by any means to challenge me by throwing in non-sequitur comments in the middle of a technical discussion. I promise, I will do my best to send you running with your tail between your legs like I did earlier today with Lapkiss Henry. The purpose of this thread is stated clearly and unambiguously in the subject line of the initial post. I will not tolerate any deviation into human psychology or such like on the thread. If you have legitimate technical criticism - state it as precisely as you can. Otherwise don't say anything or what follows is a taste of what you will get. On Wed, 2016-07-06 at 14:54 +0200, Clément Bœsch wrote: > On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > [...] > > > Also, one further thought: > > > From the commit message, it sounds like you might only be doing this > > > for the bounty in #5570, do you plan to maintain these optimizations > > > in the future? > > > > Unless you are a mind reader, STFU about my motivation in writing code. > > > > It's probably not a good idea for the project to accept a thousand lines > of code for a niche architecture which no one is going to maintain, So what is the magic number? Zero? Two? Because, in the spirit of the International Obfuscated C Code Contest, I will do my utmost to get the number of lines of code down to your divine target value. (Actually, of course I won't. That is sarcasm. This comment is parenthetical since you are unlikely to be a native speaker of English. And yes, I recognize the boundary case of zero.) > that's > why the question was asked. Oh Great. Somebody else who can meta-translate thoughts of others that were not explicitly stated. How can you prove (in the Science/Math sense) that you know what he meant by the question? Your interpretation is no more valid than mine. And since he did not address it to you I assert priority in determining its meaning. I take/took his meaning to be derogatory, and I never take insults quietly. EVER. > swscale might get some improvements in the future, and the people doing > eventual refactorings will probably be blocked into doing it because the > project is known for keeping this kind of stuff in forever. And of course, > they probably won't have an easy way of testing if there is no maintainer > to give them a hand. When/If such hypothetical future changes need to be made, then call me at the phone number which I'm sure to leave at your privileged private email address. I have no doubt that I will drop everything in order to accomodate your requests. > Finally, given the hostile reaction and the very relative speed up, it > doesn't look like this contribution is going to benefit the project. So you get to decide what is beneficial to the project, huh! Who died and made you "Der Kaiser". BTW, what does "relative speed mean"? Relative to what? Relative to a donkey hauling dung? Speed of light? By the way, hostile does not begin to adequately describe the fondness I have for this non-technical commentary. We would all be the poorer if its misbegotten content hadn't sent. Right? > This is my personal opinion, which might not be shared by the other > developers. Don't give one hoot about your personal opinion when I have no idea who you are. There are 7 billion humans on the planet. If you gave each one an audience of 10 seconds, it would be over 2000 years just listening. Then one would have to decide what was important I don't have that kind of time. You might. In which case - good for you. > Regards, No no. The privilege is always mine. (NOT) = NB: And I have not even begun using foul language yet. That would become quite colorful. But for all our sakes, it better not come to that. - End forwarded message - -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] PPC & threats
Hi folks, I think we should reconsider accepting contributions from Dan Parrot. Just received that in my mailbox. - Forwarded message from Dan Parrot - Date: Wed, 06 Jul 2016 19:11:57 -0500 From: Dan Parrot To: Clément Bœsch Subject: keep your opinions to yourself X-Mailer: Evolution 3.12.9-1+b1 this is meant to be insulting. as is the next message you receive. btw i hope you try to prove the authenticity of both messages by posting them to ffmpeg-devel. if you know how the internet works, then you also know you'd need a court order to prove the messages' origin. in which country? good luck dumbass. - End forwarded message - -- 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] [GSoC] MLP/TrueHD encoder
Jai Luthra jailuthra.in> writes: > This is an update for the TrueHD encoder gsoc project. This looks great, congratulations! Not necessarily related: Do you have an idea about how to fix ticket #5039? https://trac.ffmpeg.org/ticket/5039 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
Josh de Kock itanimul.li> writes: > +ret = openmpt_could_open_propability( I don't know anything about openmpt but what was wrong with the original probe function sent by you? Iiuc, this code would slow down probing everything or am I missing something? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PPC & threats
Hi, On Thu, Jul 7, 2016 at 3:14 AM, Clément Bœsch wrote: > Hi folks, > > I think we should reconsider accepting contributions from Dan Parrot. Just > received that in my mailbox. Uhm, yes, I agree this is not acceptable. That went downhill very quickly... :( Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: [...] > > One other thing: why didn't this come up when the earlier patch was > submitted and applied? community patch review is not a reproduceable process, depending on who has time and does the review, different things can be found and pointed out, and people have also different oppinions. Real consistency can possibly only be achived by having an active maintainer that does all review ... To be more precisse the other patch was applied due to this comment IIRC: "If this patch works (FATE passes on ppc64) and is faster than the plain c functions then it can be committed as is" Also i have (too) done consulting jobs where the result was rejected by the community. What to do in that case? well, one is pissed first but one keeps that for oneself because it doesnt help anyone and anything and then either if its possible, economic and or interresting enough do what the community suggests OR if its not possible explain and discuss why the suggestion is not practical / ideal / dooable OR if its not economic and interresting enough accept thats how it is ... I have no idea what weight the bounty has to you if any. But it is certainly desireable to have someone maintain this code in the future or to find out why the speed gain on PPC is alot smaller than x86 from SIMD. How much these matter to the community to accept vs, reject a patch is the communities choice as there is no maintainer for the ppc code. If there was a maintainer then his oppinion would have great weight on what is need to get a patch accepted Either way, please everyone stay polite, calm and friendly, that is certainly the best way to resolve things IF there is a common ground [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Hi, On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer wrote: > On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: > [...] > > > > > One other thing: why didn't this come up when the earlier patch was > > submitted and applied? > > community patch review is not a reproduceable process, depending on > who has time and does the review, different things can be found and > pointed out, and people have also different oppinions. > Real consistency can possibly only be achived by having an active > maintainer that does all review ... > > To be more precisse the other patch was applied due to this comment > IIRC: > "If this patch works (FATE passes on ppc64) and is faster than > the plain c functions then it can be committed as is" How much faster was it? And how does that compare to typical sse2 x86 speedups vs. c? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Thu, Jul 07, 2016 at 07:14:43AM -0400, Ronald S. Bultje wrote: > Hi, > > On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer > wrote: > > > On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > > > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: > > [...] > > > > > > > > One other thing: why didn't this come up when the earlier patch was > > > submitted and applied? > > > > community patch review is not a reproduceable process, depending on > > who has time and does the review, different things can be found and > > pointed out, and people have also different oppinions. > > Real consistency can possibly only be achived by having an active > > maintainer that does all review ... > > > > To be more precisse the other patch was applied due to this comment > > IIRC: > > "If this patch works (FATE passes on ppc64) and is faster than > > the plain c functions then it can be committed as is" > > > How much faster was it? There where several benchmarks posted, one is here: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/196022.html it also contains some arguments why the speedup is less than on x86 > And how does that compare to typical sse2 x86 > speedups vs. c? > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
06.07.2016, 09:20, "Jean-Baptiste Kempf" : > On 06 Jul, Ganesh Ajjanagadde wrote : >> > A custom script is not a common build system tool. >> >> How configure.ac that gets fed into autotools etc is acceptable and >> configure is not is beyond me. >> As for their meaning, I don't know. > > Ask them. But, even if your configure is good, it's not a common tool > for builds (SUGGESTED anyway.) Whatever. I am not going to argue the intent here, and have changed it to "unmet". >> > Not only libavfilter. >> >> So you want me to change from "libavfilter" to "everything except >> libavcodec"? >> Note that it is anyway marked as "not met". > > I'd say so, yes. Changed. >> > Good cryptographic practices, questions 8 and 9 should be "N/A", not >> > "met": you don't store users credential, as you say in the comment. >> >> So you are saying that regarding RNG, Q9 is referring to internal use by >> the project infrastructure? >> Otherwise I don't see how it is "N/A"; it is either met or not. > > No, I am speaking about the 2 questions about storing users credential. > FFmpeg does not do it, because these questions are related to > (web)servers. > > But it seems it was changed already in the meantime. Sorry, I don't understand: I did not change any fields regarding cryptographic practices. > With my kindest regards, > > -- > Jean-Baptiste Kempf > http://www.jbkempf.com/ - +33 672 704 734 > Sent from my Electronic Device > ___ > 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] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Hi, On Thu, Jul 7, 2016 at 7:38 AM, Michael Niedermayer wrote: > On Thu, Jul 07, 2016 at 07:14:43AM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Thu, Jul 7, 2016 at 7:07 AM, Michael Niedermayer > > > wrote: > > > > > On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: > > > > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: > > > [...] > > > > > > > > > > > One other thing: why didn't this come up when the earlier patch was > > > > submitted and applied? > > > > > > community patch review is not a reproduceable process, depending on > > > who has time and does the review, different things can be found and > > > pointed out, and people have also different oppinions. > > > Real consistency can possibly only be achived by having an active > > > maintainer that does all review ... > > > > > > To be more precisse the other patch was applied due to this comment > > > IIRC: > > > "If this patch works (FATE passes on ppc64) and is faster than > > > the plain c functions then it can be committed as is" > > > > > > How much faster was it? > > There where several benchmarks posted, one is here: > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/196022.html > it also contains some arguments why the speedup is less than on x86 I don't think these numbers are very convincing... The arguments, on the other hand, are not facts, they are hunches, so they are essentially meaningless. I would suggest to revert the patch (it really didn't go through any solid review TBH) so that a future contributor that wants to work on #5570 can do it properly and get real gains. If people want to refer to this thread for future directions (I can post this in the trac ticket also): - start with one function. Take a really simple one. Don't do 20 at a time. Especially if this is your first time writing ppc64 assembly. - measure speedups on other archs with similar register width. Best example: measure SSE2 vs. C. - make sure you're measuring scalar C when measuring the base speed, since x86 C vs. SSE2 is also scalar C vs. vector SIMD. There might be other functions being picked up that we don't know about (some altivec is BE-aware; your compiler might be auto-vectorizing C code. - optimize your one function. Start with ideas taken from the x86 SSE2 code. Use all things learned from x86 basics (do aligned loads where possible, limit shuffles/data rearrangements, load constants outside loop, etc.). - measure. Use START/STOP_TIMER, nothing else, around the caller with/without -cpuflags 0 and look only at the last reported cycle count line. - make changes. Measure again. Repeat. Do this with all suggestions from code review also. Your test should be ultra-fast, something that takes 10 seconds but invokes the function millions of times. If unsure, write a test in checkasm, but usually one invocation from a fate test is good enough. - if this is your first time writing assembly, you'll get tons of review comments. This is normal, and we've all been through it. You'll become a better coder for it, so learn from it, deal with it and keep submitting patches until it's done. A few years from now, you'll be the expert reviewer and an ever newer contributor will not yet know that he's about to get learn some extremely important lessons from an experienced expert - you. - once your first few individual functions are in, it may make sense to submit sets of functions that are somehow related. However, this increases review load so only do this once we know that you know what you're doing. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
Hi, On Thu, Jul 7, 2016, at 10:47 AM, Carl Eugen Hoyos wrote: > Josh de Kock itanimul.li> writes: > > > +ret = openmpt_could_open_propability( > > I don't know anything about openmpt but what was > wrong with the original probe function sent by you? It probed one format, and not very well, compared to a lot more formats probed by openmpt's. > Iiuc, this code would slow down probing everything or > am I missing something? At first I couldn't get it to run quickly, but it runs much faster now. It's still not a relatively fast probe, but it does probe quite a few formats, and the demuxer has to be manually enabled, so it's not like most people will experience a significant change. > Thank you, Carl Eugen Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support
On Mon, Jun 27, 2016 at 03:14:34PM +0200, Matthieu Bouron wrote: > On Fri, Jun 24, 2016 at 06:18:02PM +0200, Michael Niedermayer wrote: > > On Fri, Jun 24, 2016 at 11:17:41AM +0200, Matthieu Bouron wrote: > > > On Thu, Apr 07, 2016 at 02:51:44PM +0200, Matthieu Bouron wrote: > > > > On Wed, Mar 23, 2016 at 6:16 PM, Matthieu Bouron > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 22, 2016 at 10:04 AM, Matthieu Bouron < > > > > > matthieu.bou...@gmail.com> wrote: > > > > > > > > > >> > > > > >> > > > > >> On Fri, Mar 18, 2016 at 5:50 PM, Matthieu Bouron < > > > > >> matthieu.bou...@gmail.com> wrote: > > > > >> > > > > >>> From: Matthieu Bouron > > > > >>> > > > > >>> --- > > > > >>> > > > > >>> Hello, > > > > >>> > > > > >>> The following patch add hwaccel support to the mediacodec (h264) > > > > >>> decoder > > > > >>> by allowing > > > > >>> the user to render the output frames directly on a surface. > > > > >>> > > > > >>> In order to do so the user needs to initialize the hwaccel through > > > > >>> the > > > > >>> use of > > > > >>> av_mediacodec_alloc_context and av_mediacodec_default_init > > > > >>> functions. > > > > >>> The later > > > > >>> takes a reference to an android/view/Surface as parameter. > > > > >>> > > > > >>> If the hwaccel successfully initialize, the decoder output frames > > > > >>> pix > > > > >>> fmt will be > > > > >>> AV_PIX_FMT_MEDIACODEC. The following snippet of code demonstrate > > > > >>> how to > > > > >>> render > > > > >>> the frames on the surface: > > > > >>> > > > > >>> AVMediaCodecBuffer *buffer = (AVMediaCodecBuffer > > > > >>> *)frame->data[3]; > > > > >>> av_mediacodec_release_buffer(buffer, 1); > > > > >>> > > > > >>> The last argument of av_mediacodec_release_buffer enable rendering > > > > >>> of the > > > > >>> buffer on the surface (or not if set to 0). > > > > >>> > > > > >>> Regarding the internal changes in the mediacodec decoder: > > > > >>> > > > > >>> MediaCodec.flush() discards both input and output buffers meaning > > > > >>> that if > > > > >>> MediaCodec.flush() is called all output buffers the user has a > > > > >>> reference > > > > >>> on are > > > > >>> now invalid (and cannot be used). > > > > >>> This behaviour does not fit well in the avcodec API. > > > > >>> > > > > >>> When the decoder is configured to output software buffers, there is > > > > >>> no > > > > >>> issue as > > > > >>> the buffers are copied. > > > > >>> > > > > >>> Now when the decoder is configured to output to a surface, the user > > > > >>> might not > > > > >>> want to render all the frames as fast as the decoder can go and > > > > >>> might > > > > >>> want to > > > > >>> control *when* the frame are rendered, so we need to make sure that > > > > >>> the > > > > >>> MediaCodec.flush() call is delayed until all the frames the user > > > > >>> retains > > > > >>> has > > > > >>> been released or rendered. > > > > >>> > > > > >>> Delaying the call to MediaCodec.flush() means buffering any inputs > > > > >>> that > > > > >>> come > > > > >>> the decoder until the user has released/renderer the frame he > > > > >>> retains. > > > > >>> > > > > >>> This is a limitation of this hwaccel implementation, if the user > > > > >>> retains > > > > >>> a > > > > >>> frame (a), then issue a flush command to the decoder, the packets he > > > > >>> feeds to > > > > >>> the decoder at that point will be queued in the internal decoder > > > > >>> packet > > > > >>> queue > > > > >>> (until he releases the frame (a)). This scenario leads to a memory > > > > >>> usage > > > > >>> increase to say the least. > > > > >>> > > > > >>> Currently there is no limitation on the size of the internal decoder > > > > >>> packet > > > > >>> queue but this is something that can be added easily. Then, if the > > > > >>> queue > > > > >>> is > > > > >>> full, what would be the behaviour of the decoder ? Can it block ? Or > > > > >>> should it > > > > >>> returns something like AVERROR(EAGAIN) ? > > > > >>> > > > > >>> About the other internal decoder changes I introduced: > > > > >>> > > > > >>> The MediaCodecDecContext is now refcounted (using the lavu/atomic > > > > >>> api) > > > > >>> since > > > > >>> the (hwaccel) frames can be retained by the user, we need to delay > > > > >>> the > > > > >>> destruction of the codec until the user has released all the frames > > > > >>> he > > > > >>> has a > > > > >>> reference on. > > > > >>> The reference counter of the MediaCodecDecContext is incremented > > > > >>> each > > > > >>> time an > > > > >>> (hwaccel) frame is outputted by the decoder and decremented each > > > > >>> time a > > > > >>> (hwaccel) frame is released. > > > > >>> > > > > >>> Also, when the decoder is configured to output to a surface the pts > > > > >>> that > > > > >>> are > > > > >>> given to the MediaCodec API are now rescaled based on the > > > > >>> codec_timebase > > > > >>> as > > > > >>> those timestamps values are prop
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Thursday, 07 July 2016 at 14:51, Ronald S. Bultje wrote: [...] > - start with one function. Take a really simple one. Don't do 20 at a time. > Especially if this is your first time writing ppc64 assembly. > - measure speedups on other archs with similar register width. Best > example: measure SSE2 vs. C. > - make sure you're measuring scalar C when measuring the base speed, since > x86 C vs. SSE2 is also scalar C vs. vector SIMD. There might be other > functions being picked up that we don't know about (some altivec is > BE-aware; your compiler might be auto-vectorizing C code. > - optimize your one function. Start with ideas taken from the x86 SSE2 > code. Use all things learned from x86 basics (do aligned loads where > possible, limit shuffles/data rearrangements, load constants outside loop, > etc.). > - measure. Use START/STOP_TIMER, nothing else, around the caller > with/without -cpuflags 0 and look only at the last reported cycle count > line. > - make changes. Measure again. Repeat. Do this with all suggestions from > code review also. Your test should be ultra-fast, something that takes 10 > seconds but invokes the function millions of times. If unsure, write a test > in checkasm, but usually one invocation from a fate test is good enough. > - if this is your first time writing assembly, you'll get tons of review > comments. This is normal, and we've all been through it. You'll become a > better coder for it, so learn from it, deal with it and keep submitting > patches until it's done. A few years from now, you'll be the expert > reviewer and an ever newer contributor will not yet know that he's about to > get learn some extremely important lessons from an experienced expert - you. > - once your first few individual functions are in, it may make sense to > submit sets of functions that are somehow related. However, this increases > review load so only do this once we know that you know what you're doing. I think the above is very well written and could actually be used as a guide for new contributors. Thanks, Ronald. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Ronald S. Bultje gmail.com> writes: > - measure. Use START/STOP_TIMER, nothing else, around the > caller with/without -cpuflags 0 and look only at the last > reported cycle count line. If -cpuflags 0 works for the tested case (this wasn't true so far). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
Le primidi 11 messidor, an CCXXIV, Jan Sebechlebsky a écrit : > I don't understand this note - the fifo_format option is used (and seems to > work)? My bad, I did not notice the field had a different name. > Unfortunately :( Do you think cmd muxer initialization could be easily > modified in a way that muxer would also get access to option dictionary? Alas, I do not think so. > Can you specify what could be the problem when the > application does not see the time base of real muxer? I can imagine an application that detects the muxer supports only low frame rates like that an takes measures. But that is rather minor. > I'll add the comment. I've tried to do this without the extra lock at first > by setting error to the thread message queue and adding threadmessage queue > flag which allows the error to be returned immediately, but I think using > this single extra lock is really cleaner solution, I would prefer that. I will see the new code and the comments. Ideally, the thread message queue API should be enough to handle all cases, but it may be too hard to achieve. If the code is simple and robust, then it is good. > This is not yet exposed to the user via cmd options, do you think I should > add this flag to options in option_table.h (for encoding only)? Options are meant for cases where it makes sense to let the user choose. If the user were to enable non-blocking, the application would just treat all the EAGAIN as fatal errors. Blocking or non-blocking is a choice by the application, and is set by setting a flag in an integer field. > Can you please explain little bit more why is this wrong (appart from the > undocumented requirement for the interrupt callback to be thread-safe)? If your worker thread is blocked on an I/O operation when the application tries to close the muxer, it will send the corresponding messages and call pthread_join(). Since the worker thread is still blocked in the I/O operation, it will be stuck like that forever. To avoid that, the main thread needs to arrange for the I/O operation to be cancelled asynchronously, and that is what the interrupt callbeck is for. On the other hand, we do not want to cancel writing the trailer if it is just a little slow, so there must be some kind of timeout. All this non-blocking business is very hard if you delve into the details. 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 1/2] h2645_parse: only read avc length code at the correct position
Reading it from any other position would result in a wrong size being
read, instead fallback to the re-sync mechanic in the else clause.
---
libavcodec/h2645_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 9979b63..09fbc80 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -258,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
int extract_length = 0;
int skip_trailing_zeros = 1;
-if (buf >= next_avc) {
+if (buf == next_avc) {
int i;
for (i = 0; i < nal_length_size; i++)
extract_length = (extract_length << 8) | buf[i];
--
2.9.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] h2645_parse: don't overread AnnexB NALs within an avc stream
We know the maximum size of an AnnexB NAL, signaling it as the maximum
NAL size allows ff_h2645_extract_rbsp to determine the correct size.
---
libavcodec/h2645_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 09fbc80..33eec3d 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -290,7 +290,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
buf += 3;
length-= 3;
-extract_length = length;
+extract_length = FFMIN(length, next_avc - buf);
if (buf >= next_avc) {
/* skip to the start of the next NAL */
--
2.9.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/libvpx: Add VPx alpha decode support
VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
ability to decode such files with alpha channel.
Signed-off-by: Vignesh Venkatasubramanian
---
libavcodec/libvpxdec.c | 111 ---
tests/fate/vpx.mak | 3 +
tests/ref/fate/vp8-alpha-decode | 125
3 files changed, 219 insertions(+), 20 deletions(-)
create mode 100644 tests/ref/fate/vp8-alpha-decode
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index adbc6d0..34378d8 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -29,6 +29,7 @@
#include "libavutil/common.h"
#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
#include "avcodec.h"
#include "internal.h"
#include "libvpx.h"
@@ -36,12 +37,15 @@
typedef struct VP8DecoderContext {
struct vpx_codec_ctx decoder;
+struct vpx_codec_ctx decoder_alpha;
+int has_alpha_channel;
} VP8Context;
-static av_cold int vpx_init(AVCodecContext *avctx,
-const struct vpx_codec_iface *iface)
+static int vpx_codec_dec_init_wrapper(AVCodecContext *avctx,
+ VP8Context *ctx,
+ const struct vpx_codec_iface *iface,
+ int is_alpha_decoder)
{
-VP8Context *ctx = avctx->priv_data;
struct vpx_codec_dec_cfg deccfg = {
/* token partitions+1 would be a decent choice */
.threads = FFMIN(avctx->thread_count, 16)
@@ -50,7 +54,9 @@ static av_cold int vpx_init(AVCodecContext *avctx,
av_log(avctx, AV_LOG_INFO, "%s\n", vpx_codec_version_str());
av_log(avctx, AV_LOG_VERBOSE, "%s\n", vpx_codec_build_config());
-if (vpx_codec_dec_init(&ctx->decoder, iface, &deccfg, 0) != VPX_CODEC_OK) {
+if (vpx_codec_dec_init(
+is_alpha_decoder ? &ctx->decoder_alpha : &ctx->decoder,
+iface, &deccfg, 0) != VPX_CODEC_OK) {
const char *error = vpx_codec_error(&ctx->decoder);
av_log(avctx, AV_LOG_ERROR, "Failed to initialize decoder: %s\n",
error);
@@ -60,8 +66,16 @@ static av_cold int vpx_init(AVCodecContext *avctx,
return 0;
}
+static av_cold int vpx_init(AVCodecContext *avctx,
+const struct vpx_codec_iface *iface)
+{
+VP8Context *ctx = avctx->priv_data;
+return vpx_codec_dec_init_wrapper(avctx, ctx, iface, 0);
+}
+
// returns 0 on success, AVERROR_INVALIDDATA otherwise
-static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img)
+static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img,
+ int has_alpha_channel)
{
#if VPX_IMAGE_ABI_VERSION >= 3
static const enum AVColorSpace colorspaces[8] = {
@@ -82,7 +96,8 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
case VPX_IMG_FMT_I420:
if (avctx->codec_id == AV_CODEC_ID_VP9)
avctx->profile = FF_PROFILE_VP9_0;
-avctx->pix_fmt = AV_PIX_FMT_YUV420P;
+avctx->pix_fmt =
+has_alpha_channel ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
return 0;
#if CONFIG_LIBVPX_VP9_DECODER
case VPX_IMG_FMT_I422:
@@ -168,29 +183,72 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
}
}
+static int vpx_codec_decode_wrapper(AVCodecContext *avctx,
+vpx_codec_ctx_t *decoder, uint8_t *data,
+uint32_t data_sz)
+{
+if (vpx_codec_decode(decoder, data, data_sz, NULL, 0) != VPX_CODEC_OK) {
+const char *error = vpx_codec_error(decoder);
+const char *detail = vpx_codec_error_detail(decoder);
+
+av_log(avctx, AV_LOG_ERROR, "Failed to decode frame: %s\n", error);
+if (detail) {
+av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
+ detail);
+}
+return AVERROR_INVALIDDATA;
+}
+return 0;
+}
+
static int vp8_decode(AVCodecContext *avctx,
void *data, int *got_frame, AVPacket *avpkt)
{
VP8Context *ctx = avctx->priv_data;
AVFrame *picture = data;
const void *iter = NULL;
-struct vpx_image *img;
+const void *iter_alpha = NULL;
+struct vpx_image *img, *img_alpha;
int ret;
+uint8_t *side_data = NULL;
+int side_data_size = 0;
-if (vpx_codec_decode(&ctx->decoder, avpkt->data, avpkt->size, NULL, 0) !=
-VPX_CODEC_OK) {
-const char *error = vpx_codec_error(&ctx->decoder);
-const char *detail = vpx_codec_error_detail(&ctx->decoder);
+ret = vpx_codec_decode_wrapper(avctx, &ctx->decoder, avpkt->data,
+ avpkt->size);
+if (ret)
+return ret;
-av_log(avctx, AV_LOG_ERROR, "Failed to decode frame: %s\n", error);
-if (detail)
-av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
-
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian wrote: > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < >> vigneshv-at-google@ffmpeg.org> wrote: >> >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >>> wrote: >>> > Hi, >>> > >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >>> wrote: >>> > >>> >> Hi, >>> >> >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >>> >> vigneshv-at-google@ffmpeg.org> wrote: >>> >> >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >>> wrote: >>> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: >>> >>> >> Hi, >>> >>> >> >>> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern < >>> >>> jzern-at-google@ffmpeg.org> >>> >>> >> wrote: >>> >>> >> >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >>> ceho...@ag.or.at> >>> >>> >>> wrote: >>> >>> > Do we have decoder support (for either vp8 or vp9) for these >>> files? >>> >>> >>> >>> No, only encoding and muxing. >>> >>> >>> >>> >>> >>> Seems like a feature request, but no reason to block this one if >>> the >>> >>> >>> vp8 one is here. >>> >>> >> >>> >>> >> >>> >>> >> I'm not sure I have an opinion on this... But it feels strange to >>> allow >>> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we >>> recommend >>> >>> >> people handle the files created with this feature, if not by using >>> >>> ffmpeg >>> >>> >> itself? >>> >>> >>> >>> One plausible reason is that Chrome can decode this. So it will be >>> >>> useful for people who already have ffmpeg in their pipelines and want >>> >>> to create such files. And like James Almer mentioned, this isn't a >>> >>> first. VP8 Alpha has been this way too. >>> >> >>> >> >>> >> The fact that something is the way it is, does not prove that it is >>> >> therefore right, or that we should therefore continue doing it that way >>> in >>> >> other cases. >>> >> >>> >> So you're suggesting that it is perfectly fine for people to use Chrome >>> as >>> >> decoder if FFmpeg is the encoder. What if people don't have Chrome >>> >> installed? Or what if they want a way of UI-less batch-processing such >>> >> files, e.g. what if a service like Youtube/Vimeo wants to allow upload >>> of >>> >> vp8a/vp9a files without invoking Chrome for decoding? >>> >> >>> > >>> > Additional evidence in [1], [2]. >>> > >>> > There absolutely seems to be interest in support for vp8a/vp9a decoding >>> > outside Chrome. I'm not saying you should implement it in all multimedia >>> > frameworks ever created in human history, but doing it in one of them >>> (e.g. >>> > ffmpeg, since it already supports encoding) certainly sounds helpful? >>> > >>> >>> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg. >>> I'm just saying that it shouldn't be a reason to block this patch. :) >>> Sorry if i wasn't clear before. >> >> >> I totally understand that you would think that, since it means you don't >> have to do anything :). >> >> But there's an issue with this thinking. We're essentially already the >> dumping ground for anything multimedia-related nowadays. After all, we >> maintain it and keep it working (assuming basic tests), things couldn't get >> much easier than that, right? But is it actually useful to anyone? I mean >> not just useful for you, but useful to a wider set of people, at least in >> theory. >> >> If there's no decoder, I would claim that the wider utility of this thing >> is essentially zero. And that's somewhat of a concern. >> >> So, how do we get a decoder? vp8a suggests that just waiting for one to >> spontaneously combust out of thin air just doesn't work. So I'm suggesting >> you provide us with one. It's ok if it uses libvpx instead of ffvp8/9. >> Since vp8a encoding is already in, I won't ask for a vp8a decoder either. >> I'm just asking for a vp9a decoder. It might even be OK if it's implemented >> on top of ffmpeg instead of inside libavcodec (I'm not sure how others feel >> about this), i.e. just something that invokes libavformat to parse a webm >> file, create two decoders to get the yuv and a planes, and then merge them >> together into a yuva420p picture. I'm just asking for something _small_ and >> _simple_ (i.e. not "Chrome") that we can point users to when they ask "how >> do I decode vp9a files". >> >> I asked on IRC (#ffmpeg-devel) and several people concurred: >> >> jamrial: so … I’m looking for a second opinion here, like, an >> independent one… am I being too hard on these guys for saying “an encoder >> needs a decoder”? >> BBB: I do tend to agree that in general it goes dec->enc, or both at >> the same time. be it a fully lavc decoder or just utilizing a decoder >> library >> BBB: no, you're not being hard >> >> So it seems I'm not entirely alone in this opinion within the ffmpeg >> developer community. >> > > Alright, i have a working patch for the decoder locally (i will push > that to the
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi Vignesh, On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian > wrote: > > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje > wrote: > >> Hi, > >> > >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < > >> vigneshv-at-google@ffmpeg.org> wrote: > >> > >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje > >>> wrote: > >>> > Hi, > >>> > > >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje > > >>> wrote: > >>> > > >>> >> Hi, > >>> >> > >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < > >>> >> vigneshv-at-google@ffmpeg.org> wrote: > >>> >> > >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer > >>> wrote: > >>> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: > >>> >>> >> Hi, > >>> >>> >> > >>> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern < > >>> >>> jzern-at-google@ffmpeg.org> > >>> >>> >> wrote: > >>> >>> >> > >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < > >>> ceho...@ag.or.at> > >>> >>> >>> wrote: > >>> >>> > Do we have decoder support (for either vp8 or vp9) for these > >>> files? > >>> >>> > >>> >>> No, only encoding and muxing. > >>> >>> >>> > >>> >>> >>> Seems like a feature request, but no reason to block this one > if > >>> the > >>> >>> >>> vp8 one is here. > >>> >>> >> > >>> >>> >> > >>> >>> >> I'm not sure I have an opinion on this... But it feels strange > to > >>> allow > >>> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we > >>> recommend > >>> >>> >> people handle the files created with this feature, if not by > using > >>> >>> ffmpeg > >>> >>> >> itself? > >>> >>> > >>> >>> One plausible reason is that Chrome can decode this. So it will be > >>> >>> useful for people who already have ffmpeg in their pipelines and > want > >>> >>> to create such files. And like James Almer mentioned, this isn't a > >>> >>> first. VP8 Alpha has been this way too. > >>> >> > >>> >> > >>> >> The fact that something is the way it is, does not prove that it is > >>> >> therefore right, or that we should therefore continue doing it that > way > >>> in > >>> >> other cases. > >>> >> > >>> >> So you're suggesting that it is perfectly fine for people to use > Chrome > >>> as > >>> >> decoder if FFmpeg is the encoder. What if people don't have Chrome > >>> >> installed? Or what if they want a way of UI-less batch-processing > such > >>> >> files, e.g. what if a service like Youtube/Vimeo wants to allow > upload > >>> of > >>> >> vp8a/vp9a files without invoking Chrome for decoding? > >>> >> > >>> > > >>> > Additional evidence in [1], [2]. > >>> > > >>> > There absolutely seems to be interest in support for vp8a/vp9a > decoding > >>> > outside Chrome. I'm not saying you should implement it in all > multimedia > >>> > frameworks ever created in human history, but doing it in one of them > >>> (e.g. > >>> > ffmpeg, since it already supports encoding) certainly sounds helpful? > >>> > > >>> > >>> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg. > >>> I'm just saying that it shouldn't be a reason to block this patch. :) > >>> Sorry if i wasn't clear before. > >> > >> > >> I totally understand that you would think that, since it means you don't > >> have to do anything :). > >> > >> But there's an issue with this thinking. We're essentially already the > >> dumping ground for anything multimedia-related nowadays. After all, we > >> maintain it and keep it working (assuming basic tests), things couldn't > get > >> much easier than that, right? But is it actually useful to anyone? I > mean > >> not just useful for you, but useful to a wider set of people, at least > in > >> theory. > >> > >> If there's no decoder, I would claim that the wider utility of this > thing > >> is essentially zero. And that's somewhat of a concern. > >> > >> So, how do we get a decoder? vp8a suggests that just waiting for one to > >> spontaneously combust out of thin air just doesn't work. So I'm > suggesting > >> you provide us with one. It's ok if it uses libvpx instead of ffvp8/9. > >> Since vp8a encoding is already in, I won't ask for a vp8a decoder > either. > >> I'm just asking for a vp9a decoder. It might even be OK if it's > implemented > >> on top of ffmpeg instead of inside libavcodec (I'm not sure how others > feel > >> about this), i.e. just something that invokes libavformat to parse a > webm > >> file, create two decoders to get the yuv and a planes, and then merge > them > >> together into a yuva420p picture. I'm just asking for something _small_ > and > >> _simple_ (i.e. not "Chrome") that we can point users to when they ask > "how > >> do I decode vp9a files". > >> > >> I asked on IRC (#ffmpeg-devel) and several people concurred: > >> > >> jamrial: so … I’m looking for a second opinion here, like, an > >> independent one… am I being too hard on these guys for saying “an > encoder > >> nee
Re: [FFmpeg-devel] [GSoC] MLP/TrueHD encoder
On Thu, Jul 7, 2016 at 3:19 PM, Carl Eugen Hoyos wrote: > > Not necessarily related: Do you have an idea about how > to fix ticket #5039? > https://trac.ffmpeg.org/ticket/5039 Hi, Looks like either ffmpeg's decoder is messing up when all samples in a packet are same (likely; this might also explain similar errors in LFE channel with MLP), or that the dolby encoder didn't do lossless encoding (unlikely, but still a possibility). I'll look into it for sure. Cheers, Jai Luthra (darkapex) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/oggenc: fix page duration calculation when granule differs from timestamp
Signed-off-by: James Almer
---
libavformat/oggenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index f998af3..296028e 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -263,10 +263,10 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream
*st,
{
AVStream *st = s->streams[page->stream_index];
-int64_t start = av_rescale_q(page->start_granule, st->time_base,
- AV_TIME_BASE_Q);
-int64_t next = av_rescale_q(page->granule, st->time_base,
- AV_TIME_BASE_Q);
+int64_t start = av_rescale_q(ogg_granule_to_timestamp(oggstream,
page->start_granule),
+ st->time_base, AV_TIME_BASE_Q);
+int64_t next = av_rescale_q(ogg_granule_to_timestamp(oggstream,
page->granule),
+ st->time_base, AV_TIME_BASE_Q);
if (page->segments_count == 255) {
ogg_buffer_page(s, oggstream);
@@ -596,7 +596,7 @@ static int ogg_write_packet_internal(AVFormatContext *s,
AVPacket *pkt)
granule = pkt->pts + pkt->duration;
if (oggstream->page.start_granule == AV_NOPTS_VALUE)
-oggstream->page.start_granule = pkt->pts;
+oggstream->page.start_granule = granule;
ret = ogg_buffer_data(s, st, pkt->data, pkt->size, granule, 0);
if (ret < 0)
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: only read avc length code at the correct position
On Thu, Jul 07, 2016 at 08:21:17PM +0200, Hendrik Leppkes wrote:
> Reading it from any other position would result in a wrong size being
> read, instead fallback to the re-sync mechanic in the else clause.
> ---
> libavcodec/h2645_parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 9979b63..09fbc80 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -258,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
> *buf, int length,
> int extract_length = 0;
> int skip_trailing_zeros = 1;
>
> -if (buf >= next_avc) {
> +if (buf == next_avc) {
> int i;
> for (i = 0; i < nal_length_size; i++)
> extract_length = (extract_length << 8) | buf[i];
the > case should print some warning if it doesnt,
same for the 2nd patch the truncation should show some warning
otherwise patches LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Thu, Jun 30, 2016 at 03:36:31PM +0200, Michael Niedermayer wrote: > On Wed, Jun 29, 2016 at 04:15:12PM +, Dan Parrot wrote: > > This patch addresses Trac ticket #5570. The optimized functions are in file > > libswscale/ppc/input_vsx.c. Each optimized function name is a concatenation > > of the > > corresponding name in libswscale/input.c with suffix _vsx. > > --- > > libswscale/ppc/Makefile | 1 + > > libswscale/ppc/input_vsx.c| 437 > > ++ > > libswscale/swscale.c | 3 + > > libswscale/swscale_internal.h | 1 + > > 4 files changed, 442 insertions(+) > > create mode 100644 libswscale/ppc/input_vsx.c > > patch applied > > Please keep an eye on fate.ffmpeg.org, if it breaks on one of the ppc > machines i will revert the patch According to https://trac.ffmpeg.org/ticket/5570#comment:3 this broke build on some machines [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/oggenc: fix page duration calculation when granule differs from timestamp
On Thu, Jul 07, 2016 at 07:13:47PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
>
> libavformat/oggenc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
> index f998af3..296028e 100644
> --- a/libavformat/oggenc.c
> +++ b/libavformat/oggenc.c
> @@ -263,10 +263,10 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream
> *st,
> {
> AVStream *st = s->streams[page->stream_index];
>
> -int64_t start = av_rescale_q(page->start_granule, st->time_base,
> - AV_TIME_BASE_Q);
> -int64_t next = av_rescale_q(page->granule, st->time_base,
> - AV_TIME_BASE_Q);
> +int64_t start = av_rescale_q(ogg_granule_to_timestamp(oggstream,
> page->start_granule),
> + st->time_base, AV_TIME_BASE_Q);
> +int64_t next = av_rescale_q(ogg_granule_to_timestamp(oggstream,
> page->granule),
> + st->time_base, AV_TIME_BASE_Q);
>
> if (page->segments_count == 255) {
> ogg_buffer_page(s, oggstream);
> @@ -596,7 +596,7 @@ static int ogg_write_packet_internal(AVFormatContext *s,
> AVPacket *pkt)
> granule = pkt->pts + pkt->duration;
>
> if (oggstream->page.start_granule == AV_NOPTS_VALUE)
> -oggstream->page.start_granule = pkt->pts;
> +oggstream->page.start_granule = granule;
>
> ret = ogg_buffer_data(s, st, pkt->data, pkt->size, granule, 0);
> if (ret < 0)
this breaks fate
--- ./tests/ref/lavf/ogg2016-07-04 23:15:26.551386870 +0200
+++ tests/data/fate/lavf-ogg2016-07-08 02:53:19.961122925 +0200
@@ -1,3 +1,3 @@
-81b9366cacb23644c2803585dced9996 *./tests/data/lavf/lavf.ogg
-13516 ./tests/data/lavf/lavf.ogg
+485ac4364e6cd0716ac5a263672f012a *./tests/data/lavf/lavf.ogg
+13517 ./tests/data/lavf/lavf.ogg
./tests/data/lavf/lavf.ogg CRC=0x3a1da17e
Test lavf-ogg failed. Look at tests/data/fate/lavf-ogg.err for details.
make: *** [fate-lavf-ogg] Error 1
--- ./tests/ref/fate/limited_input_seek 2016-07-04 23:15:26.527386870 +0200
+++ tests/data/fate/limited_input_seek 2016-07-08 02:48:50.297117244 +0200
@@ -1 +1 @@
-20a1bb9a1cfb23c1fe86f14e6065cd95
+1d387f44f5f61affe0aafac0aa78549f
Test limited_input_seek failed. Look at tests/data/fate/limited_input_seek.err
for details.
make: *** [fate-limited_input_seek] Error 1
make: *** Waiting for unfinished jobs
--- ./tests/ref/fate/limited_input_seek-copyts 2016-07-04 23:15:26.527386870
+0200
+++ tests/data/fate/limited_input_seek-copyts 2016-07-08 02:48:50.305117245
+0200
@@ -1 +1 @@
-ec3604b1954ed80de364b8ef491771ce
+7444da11963c87bf88a5e8e4bc178f8c
Test limited_input_seek-copyts failed. Look at
tests/data/fate/limited_input_seek-copyts.err for details.
make: *** [fate-limited_input_seek-copyts] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/oggenc: make Vorbis audio the only default for ogg muxer
On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote: > While not enforced, RFC 5334 mentions that the .ogg extension should > be used for Vorbis audio files only. > > Signed-off-by: James Almer > --- > This patch turns the ogg muxer into an audio only muxer to follow > the RFC's recommendation. The next patch in the set adds a new ogv > muxer to properly deal with video files. > > I doubt anyone out there tries to mux theora video using the .ogg > extension (even ffmpeg2theora seems to default to .ogv), so it's > unlikely it will affect people's normal workflow. > But if someone is against it then this patch can either be dropped > or changed to only remove flac from the defaults. That way video > can still be muxed. > > I personally prefer to apply this patch as is, though. > > libavformat/oggenc.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) breaks fate --- ./tests/ref/lavf-fate/ogg_vp3 2016-07-04 23:15:26.551386870 +0200 +++ tests/data/fate/lavf-fate-ogg_vp3 2016-07-08 03:51:46.269196793 +0200 @@ -1,3 +0,0 @@ -4bd51dac3194fa88ae33767c25b4b1e6 *./tests/data/lavf-fate/lavf.ogg -417621 ./tests/data/lavf-fate/lavf.ogg -./tests/data/lavf-fate/lavf.ogg CRC=0x037e3e79 Test lavf-fate-ogg_vp3 failed. Look at tests/data/fate/lavf-fate-ogg_vp3.err for details. make: *** [fate-lavf-fate-ogg_vp3] Error 1 make: *** Waiting for unfinished jobs [...] -- 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
Re: [FFmpeg-devel] [PATCH 3/4] avformat/oggenc: make Vorbis audio the only default for ogg muxer
On 7/7/2016 10:55 PM, Michael Niedermayer wrote: > On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote: >> While not enforced, RFC 5334 mentions that the .ogg extension should >> be used for Vorbis audio files only. >> >> Signed-off-by: James Almer >> --- >> This patch turns the ogg muxer into an audio only muxer to follow >> the RFC's recommendation. The next patch in the set adds a new ogv >> muxer to properly deal with video files. >> >> I doubt anyone out there tries to mux theora video using the .ogg >> extension (even ffmpeg2theora seems to default to .ogv), so it's >> unlikely it will affect people's normal workflow. >> But if someone is against it then this patch can either be dropped >> or changed to only remove flac from the defaults. That way video >> can still be muxed. >> >> I personally prefer to apply this patch as is, though. >> >> libavformat/oggenc.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) > > breaks fate Yes, forgot to run fate for this set. It's caused by the fact the ogg muxer can't mux video streams anymore after this patch. I want to know if the actual change is acceptable first, then I'll resend the set with fate tests updated to use ogv muxer and similar changes. > > --- ./tests/ref/lavf-fate/ogg_vp3 2016-07-04 23:15:26.551386870 +0200 > +++ tests/data/fate/lavf-fate-ogg_vp3 2016-07-08 03:51:46.269196793 +0200 > @@ -1,3 +0,0 @@ > -4bd51dac3194fa88ae33767c25b4b1e6 *./tests/data/lavf-fate/lavf.ogg > -417621 ./tests/data/lavf-fate/lavf.ogg > -./tests/data/lavf-fate/lavf.ogg CRC=0x037e3e79 > Test lavf-fate-ogg_vp3 failed. Look at tests/data/fate/lavf-fate-ogg_vp3.err > for details. > make: *** [fate-lavf-fate-ogg_vp3] Error 1 > make: *** Waiting for unfinished jobs > > [...] > > > > ___ > 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] avformat/oggenc: fix page duration calculation when granule differs from timestamp
On 7/7/2016 9:58 PM, Michael Niedermayer wrote:
> On Thu, Jul 07, 2016 at 07:13:47PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>>
>> libavformat/oggenc.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
>> index f998af3..296028e 100644
>> --- a/libavformat/oggenc.c
>> +++ b/libavformat/oggenc.c
>> @@ -263,10 +263,10 @@ static int ogg_buffer_data(AVFormatContext *s,
>> AVStream *st,
>> {
>> AVStream *st = s->streams[page->stream_index];
>>
>> -int64_t start = av_rescale_q(page->start_granule, st->time_base,
>> - AV_TIME_BASE_Q);
>> -int64_t next = av_rescale_q(page->granule, st->time_base,
>> - AV_TIME_BASE_Q);
>> +int64_t start =
>> av_rescale_q(ogg_granule_to_timestamp(oggstream, page->start_granule),
>> + st->time_base, AV_TIME_BASE_Q);
>> +int64_t next =
>> av_rescale_q(ogg_granule_to_timestamp(oggstream, page->granule),
>> + st->time_base, AV_TIME_BASE_Q);
>>
>> if (page->segments_count == 255) {
>> ogg_buffer_page(s, oggstream);
>> @@ -596,7 +596,7 @@ static int ogg_write_packet_internal(AVFormatContext *s,
>> AVPacket *pkt)
>> granule = pkt->pts + pkt->duration;
>>
>> if (oggstream->page.start_granule == AV_NOPTS_VALUE)
>> -oggstream->page.start_granule = pkt->pts;
>> +oggstream->page.start_granule = granule;
>>
>> ret = ogg_buffer_data(s, st, pkt->data, pkt->size, granule, 0);
>> if (ret < 0)
>
> this breaks fate
Mmh, the granule in ogg_write_packet_internal used for start_granule is
different than pkt->pts for all codecs after being converted into a
timestamp, so that probably changed the calculations for a page's length.
I looked at the output of fate-lavf-ogg and the one created with this
patch had a 0 byte eos packet, which even though valid seems worse than
before the patch.
Here's a version that achieves the same thing (convert granule to ts
before trying to rescale it) while keeping start_granule intact.
>From 7b8d0e5598103cfed0ca37914d1eed933e03d5aa Mon Sep 17 00:00:00 2001
From: James Almer
Date: Thu, 7 Jul 2016 22:41:55 -0300
Subject: [PATCH] avformat/oggenc: fix page duration calculation when granule differs from timestamp
Signed-off-by: James Almer
---
libavformat/oggenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index f998af3..a27e3a7 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -193,7 +193,7 @@ static int ogg_buffer_page(AVFormatContext *s, OGGStreamContext *oggstream)
return AVERROR(ENOMEM);
l->page = oggstream->page;
-oggstream->page.start_granule = oggstream->page.granule;
+oggstream->page.start_granule = ogg_granule_to_timestamp(oggstream, oggstream->page.granule);
oggstream->page_count++;
ogg_reset_cur_page(oggstream);
@@ -265,8 +265,8 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream *st,
int64_t start = av_rescale_q(page->start_granule, st->time_base,
AV_TIME_BASE_Q);
-int64_t next = av_rescale_q(page->granule, st->time_base,
- AV_TIME_BASE_Q);
+int64_t next = av_rescale_q(ogg_granule_to_timestamp(oggstream, page->granule),
+ st->time_base, AV_TIME_BASE_Q);
if (page->segments_count == 255) {
ogg_buffer_page(s, oggstream);
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
