Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext
Hi, On 2022-08-02 16:19, Anton Khirnov wrote: Why are you not resubmitting your original patch that stops copying hwaccel_priv_data to the user-facing context? It seemed more correct to me, since the user-facing context should never see any hwaccel data. Or does it not fix the issue fully? The original patch is not fixing it properly. With that patch and avcodec-threads > 1, the uninit of the hardware decoder is not called anymore. So it will replace a crash fix with a (big) resource leak. For reference, this it the patch we're talking about https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg94274.html For a more proper fix, we probably want to bundle hwaccel+state+uninit to a single refcounted thing. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] sws: Don't compile yuv2yuvX for mmx
--- libswscale/x86/yuv2yuvX.asm | 2 -- 1 file changed, 2 deletions(-) diff --git a/libswscale/x86/yuv2yuvX.asm b/libswscale/x86/yuv2yuvX.asm index b6294cb919..d5b03495fd 100644 --- a/libswscale/x86/yuv2yuvX.asm +++ b/libswscale/x86/yuv2yuvX.asm @@ -124,8 +124,6 @@ cglobal yuv2yuvX, 7, 7, 8, filter, filterSize, src, dest, dstW, dither, offset REP_RET %endmacro -INIT_MMX mmx -YUV2YUVX_FUNC INIT_MMX mmxext YUV2YUVX_FUNC INIT_XMM sse3 -- 2.37.2.609.g9ff673ca1a-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] sws: Don't compile yuv2yuvX for mmx
Alan Kelly: > --- > libswscale/x86/yuv2yuvX.asm | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/libswscale/x86/yuv2yuvX.asm b/libswscale/x86/yuv2yuvX.asm > index b6294cb919..d5b03495fd 100644 > --- a/libswscale/x86/yuv2yuvX.asm > +++ b/libswscale/x86/yuv2yuvX.asm > @@ -124,8 +124,6 @@ cglobal yuv2yuvX, 7, 7, 8, filter, filterSize, src, dest, > dstW, dither, offset > REP_RET > %endmacro > > -INIT_MMX mmx > -YUV2YUVX_FUNC > INIT_MMX mmxext > YUV2YUVX_FUNC > INIT_XMM sse3 Already sent exactly the same patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300247.html (I wanted to remove this function in a05f22eaf393177b94432431c145cbc5ba10390a, but noticed that you used it for unaligned data and tail processing and I did not know whether this was intentional or not.) - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
tor 2022-08-18 klockan 16:31 +0200 skrev Michael Niedermayer: > On Wed, Aug 17, 2022 at 05:03:56PM +0200, Tomas Härdin wrote: > > tor 2022-08-11 klockan 19:35 +0200 skrev Timo Rothenpieler: > > > On 11.08.2022 19:21, Mark Gaiser wrote: > > > > > > > > Here's the conversation requesting this very feature: > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html > > > > > > I generally agree with the points brought up there. > > > But my conclusion very much is not "just put a somewhat random > > > default > > > into the code". > > > Even a list of defaults is not Okay. > > > We can't hardcode "magic servers". > > > > > > If it's not possible to make the protocol work without them, it > > > likely > > > shouldn't have been merged in the first place. > > > Why can't it access the files directly, but only via some magic > > > http > > > gateway? > > > Why does it need special code in ffmpeg in the first place, if > > > you > > > can > > > just access it via that http proxy-gateway anyway? > > > > I raised this very point several times when IPFS support was first > > suggested, and raised that ipfsgateway.c amounts to business logic > > that > > does not belong in lavf. I see now hat others in this thread, like > > Derek, agree with me on this, which is nice. IIRC I even suggested > > that > > users should solve this in bash, a suggestion that was shouted down > > as > > being "insecure". > > you cannot do it in bash Is bash not Turing complete? > filter="ipfs://..." > on the command line is translated or not ? > if its drawtext showing the user on screen a URL it must not be > OTOH if the filter reads from the URL it has to be > this just isnt going to work at the bash command line level besides > bash is > not even a dependancy of FFmpeg > not to mention that a ipfs:// link from one container to another > container > would never show up on the command line The point is that this is business logic that belongs elsewhere. > > > > I also suggested we should actually implement ipfs or link to a > > library > > that implements it rather than shoving more string mangling crap > > into > > for reference, mark replied in that thread: > > A "proper" implementation is unfeasible for ffmpeg purposes > because a > proper implementation would act as an IPFS node. > That means it would: > - spin up > - do it's bootstrapping > - connect to nodes and find new nodes to connect to > - find the CID on the network > - etc... > > This all adds a lot of startup time making it very unfriendly to > users. > In this scenario it could take up to minutes before your video > starts > playing if it doesn't time out. Yes that is what implementing ipfs: entails. But ipfsgateway.c is not actually ipfs: now is it? This would be like gopher.c using overbite as a gateway instead of actually implementing gopher: We don't need to shovel everything into this project. We can actually rely on users being smart. For example vlc could do the business logic of dealing with IPFS. Or, better yet, the OS. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] checkasm: sw_scale: Produce more realistic test filter coefficients for yuv2yuvX
On Thu, 18 Aug 2022, Alan Kelly wrote: Thanks Martin for doing this. On Thu, Aug 18, 2022 at 10:16 AM Martin Storsjö wrote: This avoids triggering overflows in the filters, and avoids stray test failures in the approximate functions on x86; due to rounding differences, one implementation might overflow while another one doesn't. Signed-off-by: Martin Storsjö --- FWIW, this modification runs successfully with over 1000 different seeds in checkasm. --- tests/checkasm/sw_scale.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) I'll go ahead and push this patch later today, if there's no opposition, as it fixes spurious fate failures. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] sws: Don't compile yuv2yuvX for mmx
Thanks for doing this! On Fri, Aug 19, 2022 at 10:53 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Alan Kelly: > > --- > > libswscale/x86/yuv2yuvX.asm | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/libswscale/x86/yuv2yuvX.asm b/libswscale/x86/yuv2yuvX.asm > > index b6294cb919..d5b03495fd 100644 > > --- a/libswscale/x86/yuv2yuvX.asm > > +++ b/libswscale/x86/yuv2yuvX.asm > > @@ -124,8 +124,6 @@ cglobal yuv2yuvX, 7, 7, 8, filter, filterSize, src, > dest, dstW, dither, offset > > REP_RET > > %endmacro > > > > -INIT_MMX mmx > > -YUV2YUVX_FUNC > > INIT_MMX mmxext > > YUV2YUVX_FUNC > > INIT_XMM sse3 > > Already sent exactly the same patch: > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300247.html > (I wanted to remove this function in > a05f22eaf393177b94432431c145cbc5ba10390a, but noticed that you used it > for unaligned data and tail processing and I did not know whether this > was intentional or not.) > > - Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Fri, Aug 19, 2022 at 11:15 AM Tomas Härdin wrote: > tor 2022-08-18 klockan 16:31 +0200 skrev Michael Niedermayer: > > On Wed, Aug 17, 2022 at 05:03:56PM +0200, Tomas Härdin wrote: > > > tor 2022-08-11 klockan 19:35 +0200 skrev Timo Rothenpieler: > > > > On 11.08.2022 19:21, Mark Gaiser wrote: > > > > > > > > > > Here's the conversation requesting this very feature: > > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html > > > > > > > > I generally agree with the points brought up there. > > > > But my conclusion very much is not "just put a somewhat random > > > > default > > > > into the code". > > > > Even a list of defaults is not Okay. > > > > We can't hardcode "magic servers". > > > > > > > > If it's not possible to make the protocol work without them, it > > > > likely > > > > shouldn't have been merged in the first place. > > > > Why can't it access the files directly, but only via some magic > > > > http > > > > gateway? > > > > Why does it need special code in ffmpeg in the first place, if > > > > you > > > > can > > > > just access it via that http proxy-gateway anyway? > > > > > > I raised this very point several times when IPFS support was first > > > suggested, and raised that ipfsgateway.c amounts to business logic > > > that > > > does not belong in lavf. I see now hat others in this thread, like > > > Derek, agree with me on this, which is nice. IIRC I even suggested > > > that > > > users should solve this in bash, a suggestion that was shouted down > > > as > > > being "insecure". > > > > you cannot do it in bash > > Is bash not Turing complete? > I believe we went over this in detail during those patch rounds when this was brought up (by you?). I didn't go back in the archives to find it, but some reasons that come to mind: - just handing the mere edge cases would make that bash script complex - potentially involving regex - add in gateway detection logic and you'll have a bash script that's likely more complex than the current ipfsgateway.c code. - not cross platform by any means This would require the manual step of installing such a script to get "ffplay ipfs://" to work. Worst of all, it would not be usable for applications building on top of ffmpeg (vlc, mpv, kodi) and would not be cross platform at all. > > filter="ipfs://..." > > on the command line is translated or not ? > > if its drawtext showing the user on screen a URL it must not be > > OTOH if the filter reads from the URL it has to be > > this just isnt going to work at the bash command line level besides > > bash is > > not even a dependancy of FFmpeg > > not to mention that a ipfs:// link from one container to another > > container > > would never show up on the command line > > The point is that this is business logic that belongs elsewhere. > > > > > > > I also suggested we should actually implement ipfs or link to a > > > library > > > that implements it rather than shoving more string mangling crap > > > into > > > > for reference, mark replied in that thread: > > > > A "proper" implementation is unfeasible for ffmpeg purposes > > because a > > proper implementation would act as an IPFS node. > > That means it would: > > - spin up > > - do it's bootstrapping > > - connect to nodes and find new nodes to connect to > > - find the CID on the network > > - etc... > > > > This all adds a lot of startup time making it very unfriendly to > > users. > > In this scenario it could take up to minutes before your video > > starts > > playing if it doesn't time out. > > Yes that is what implementing ipfs: entails. But ipfsgateway.c is not > actually ipfs: now is it? This would be like gopher.c using overbite as > a gateway instead of actually implementing gopher: > > We don't need to shovel everything into this project. We can actually > rely on users being smart. For example vlc could do the business logic > of dealing with IPFS. Or, better yet, the OS. > .. we should probably fork this out into its own thread, but i do like to have this discussion! .. What you describe here is an opinion I hear all too often. 9 out of 10 times the gut reaction for "implementing IPFS support" is any of the above suggestions you make. Very understandable for someone with technical skills and just a surface level overview of what ipfs support means. Heck, I too would give that response and thought that way when I just discovered IPFS! But when you dive deep into this you'll find out that there are no easy solutions. Bear in mind, any solution where you'd need an ipfs implementation like ffmpeg has now in each application is just not scalable. I wanted to add IPFS support in ffmpeg because it allows for far easier IPFS usage in anything that uses IPFS. But is that ideal? Depends on the alternatives. Is it the best achievable at the moment? Probably yes. I don't understand the argument of "ipfsgateway.c amounts to business logic that does not belong in lavf". Earlier argumen
Re: [FFmpeg-devel] [PATCH v2] avcodec/audiotoolboxenc: return external error if encode failed
On 6/24/2022 4:05 AM, Steven Liu wrote:
"zhilizhao(赵志立)" 于2022年6月24日周五 14:59写道：
On Jun 24, 2022, at 1:59 PM, Steven Liu wrote:
because the AudioConverterFillComplexBuffer can return 0 or 1 if
success.
so set the ret to 0 it AudioConverterFillComplexBuffer success and
return ret value for success or return AVERROR_EXTERNAL when
AudioConverterFillComplexBuffer failed.
BTW change the error message log level from warning to error.
Signed-off-by: Steven Liu
---
libavcodec/audiotoolboxenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index f8305ab89b..00293154bf 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -554,11 +554,13 @@ static int ffat_encode(AVCodecContext *avctx, AVPacket
*avpkt,
avctx->frame_size,
&avpkt->pts,
&avpkt->duration);
+ret = 0;
} else if (ret && ret != 1) {
-av_log(avctx, AV_LOG_WARNING, "Encode error: %i\n", ret);
+av_log(avctx, AV_LOG_ERROR, "Encode error: %i\n", ret);
+ret = AVERROR_EXTERNAL;
}
-return 0;
+return ret;
}
LGTM.
Applied, Thanks
This is probably the source of the regression described in
https://trac.ffmpeg.org/ticket/9866
Can you look at it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects
Jean-Baptiste Kempf (12022-08-18): > Those plans files become outdated very quickly and are often not maintained. > Or they become infinite unicorn-wishlist things. > Or they become a blocking task for the project. Or I might be hit by a bus. Or I might decide to try heroin and overdose because it was cut with fentanyl. Or… If we always focus on the worst-case scenario, we never go forward. Worst case scenario here? It becomes blocking, we discuss to remove it, wasted a little time. Less worst case scenario: it becomes an unicorn-wishlist, somebody finds something doable in it and starts contributing to the project. Anyway… > I have NO opinion on AVWriter, but just show the API and documentation before > implementing it. > Once people agree on the API need and form, just implement it, I don't see > the need for a plans.md file for that. Hum, I like that idea. For AVWriter, much of the API itself is macros and inline functions, but it is a minor issue that I can work around. “Once people agree” means applying it; I hope nobody will bikeshed the idea of pushing a .h file with no implementation I insist that I am not doing this to “preemptively shield [my] code from criticism”, like Anton disingenuously said. If that was the case, I would not have written “The resulting patches will be subject to technical review like any other patches”. What I am trying to do is to find a way to discuss broad strokes before investing time in details, because without it the project is condemned to immobility because of naysayers. It is not specific to AVWriter, it is not specific to me. If we had that procedure at the time the new channel layout API was implemented, then we could have discussed it to take into account the needs of users, filters, advanced formats and devices and now have a great channel layout API. Instead, we had to salvage one that was not designed with these considerations in mind, but because it was a series of 279 patches, nobody dared send it back for complete redesign as we should have. I find this borderline dishonest. Depending on the responses to this mail, I will send a patch to add avwriter.h and doc/avwriter.md and start the actual discussion. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects
On Fri, 19 Aug 2022, at 18:01, Nicolas George wrote: > Or I might be hit by a bus. Or I might decide to try heroin and overdose > because it was cut with fentanyl. Or… If we always focus on the Exactly. This is called the bus-factor and is important in all volunteers open source communities. Which is why the norm is "show us the code" and not wait for future things. Because as we are volunteers working when we can, shit happens in real life, so you cannot block a project with future plans until they are done. Because maybe it's a 6months time or a 2 years time, or never. And then you never ship your software. For the same reason, something "ready to merge, not optimal but better than the current state" is Always better than "I'll do an optimal solution in 3 years". Especially since the first solution does not block the latter one. Therefore, I don't think those plans documents are useful: "show us the code!". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx
On 8/17/2022 11:29 AM, Zhao Zhili wrote: >> This seems like it should be in a separate patch, though - it is >> changing a different >> behavior than what this patch does. > > OK. Will send a 2nd patch with this in the next few days. >> I did look at that, but I do not think it can be. >> >> get_stream_info_time is not equivalent to what is here. >> get_stream_info_time will >> eventually fall back to frag_stream_info->tfdt_dts, where as this >> code falls back >> to frag_stream_info->sidx_pts even if it is AV_NOPTS_VALUE. It would >> be a behavior >> change do use get_stream_info_time here. > > OK, it make sense together with `if (sc->has_sidx)`. > > No more comments from me. Applied. Thank you for your reviews :). - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] API enhancements / broken promises
On Thu, Aug 18, 2022 at 07:19:07PM +0200, Jean-Baptiste Kempf wrote: > On Wed, 17 Aug 2022, at 19:21, Michael Niedermayer wrote: > > a unwise choice. But if someone is against very basic xml or json parsers > > please speak up now and here because its still better to say "no" now than > > after nicolas did the work. > > Absolutely against this idea. > > Both JSON and XML are very very very difficult to parse in a secure manner. > > Doing a simple XML parser and a simple JSON parser might be simple tasks for > any decent programmer, doing those parsers is extremely difficult because > there are a lot of complex corners cases, even if you take a subset of XML. > Unicode, encoding, entities decoding, binary data, languages are not > something you can skip, even if you take a subset of XML. > > Once you add document validation and DTD, namespaces, recursive XML or > XPath/XQuery this makes it a project as big as the whole FFmpeg, and that's > why libxml2 is so big. > If you just want DASH and TTML (and maybe fontconfig), you still have to do a > large set of features. > > And then you need to care about security. It's a difficult problem to fix, > and seeing the track record of the security of open source multimedia > projects, we should focus on our issues, not adding new ones. > > > If you believe that you can do a better job than thousands of people paid > large amounts of money who spent decades on this problem, then, please do a > separate project, host it on git.ffmpeg.org, git.videolan.org or github, and > give us a fast streaming API. Please be sure that you validate most > test-suites and cornercases too. And fuzz it. > > Managing to do that would be an impact probably much bigger than FFmpeg, so > don't hesitate. And then FFmpeg will be able to use it, and other projects > too. > > But for me, until this is ready and battle-tested, it's a hard no.. ok but just to clarify what i meant / was thinking of was a simple key / value style parser no features beyond that. just enough so we can use it to read our own generated xml from some object serialization. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] API enhancements / broken promises
On 19.08.2022 20:30, Michael Niedermayer wrote: ok but just to clarify what i meant / was thinking of was a simple key / value style parser no features beyond that. just enough so we can use it to read our own generated xml from some object serialization. One can hardly call that XML then. For something like that, it's much better to just use libxml2, if you really want to use XML, or just use another, super trivial format, like .ini or something. XML, JSON, YAML and friends all have a massive amount of complexity attached to them. Any kind of parser we add for them would almost inevitably grow over time, as people add more and more features to them. "Just one more simple patch". I'd rather not open that can of worms. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Keep data_partitioning in sync between threads
Andreas Rheinhardt: > Fixes frame-threaded decoding of samples created by concatting > a video with data partitioning and a video not using it. > (Only the MPEG-4 decoder sets this, so it is synced in > mpeg4_update_thread_context() despite being a MpegEncContext-field.) > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/mpeg4videodec.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c > index bfebc3806c..d89adf8d63 100644 > --- a/libavcodec/mpeg4videodec.c > +++ b/libavcodec/mpeg4videodec.c > @@ -3534,6 +3534,7 @@ static int mpeg4_update_thread_context(AVCodecContext > *dst, > s->vol_sprite_usage = s1->vol_sprite_usage; > s->sprite_brightness_change = s1->sprite_brightness_change; > s->num_sprite_warping_points = s1->num_sprite_warping_points; > +s->m.data_partitioning = s1->m.data_partitioning; > s->rvlc = s1->rvlc; > s->resync_marker = s1->resync_marker; > s->t_frame = s1->t_frame; Will apply the remaining two patches of this patchset tomorrow unless there are exceptions. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/7] avutil: move half-precision float helper to avutil
On 18.08.2022 17:37, Timo Rothenpieler wrote: I plan to push this soon. The half2float.o entry has been moved to the correct Makefile, otherwise nothing else changed in the meantime. applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] libswscale: add support for VUYX format
On 8/19/2022 10:24 PM, Philip Langdale wrote: As we already have support for VUYA, I figured I should do the small amount of work to support VUYX as well. That means a little refactoring to share code. Signed-off-by: Philip Langdale --- libswscale/input.c | 10 --- libswscale/output.c | 35 +--- libswscale/utils.c | 1 + tests/ref/fate/filter-pixdesc-vuyx | 1 + tests/ref/fate/filter-pixfmts-copy | 1 + tests/ref/fate/filter-pixfmts-crop | 1 + tests/ref/fate/filter-pixfmts-field | 1 + tests/ref/fate/filter-pixfmts-fieldorder | 1 + tests/ref/fate/filter-pixfmts-hflip | 1 + tests/ref/fate/filter-pixfmts-il | 1 + tests/ref/fate/filter-pixfmts-null | 1 + tests/ref/fate/filter-pixfmts-pad| 1 + tests/ref/fate/filter-pixfmts-scale | 1 + tests/ref/fate/filter-pixfmts-transpose | 1 + tests/ref/fate/filter-pixfmts-vflip | 1 + tests/ref/fate/pixfmt_best | 2 +- 16 files changed, 51 insertions(+), 9 deletions(-) create mode 100644 tests/ref/fate/filter-pixdesc-vuyx [...] diff --git a/tests/ref/fate/pixfmt_best b/tests/ref/fate/pixfmt_best index 1da1846275..783c5fe640 100644 --- a/tests/ref/fate/pixfmt_best +++ b/tests/ref/fate/pixfmt_best @@ -1 +1 @@ -74 tests passed, 0 tests failed. +75 tests passed, 0 tests failed. Shouldn't this be in patch 1/3? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
