Re: [FFmpeg-devel] [PATCH] avdevice/decklink: adjust for timecode lag
On 31-08-2019 04:14 AM, Marton Balint wrote: On Fri, 30 Aug 2019, Gyan wrote: On 22-08-2019 01:10 AM, Marton Balint wrote: On Tue, 20 Aug 2019, Devin Heitmueller wrote: A couple of follow-up Qs: Is auto-detection available for all Decklink devices? No, but AFAIK it is for all devices which support SDI. Generally it's the older analog capture devices which don't support it. For those for which it is available, are there any edge cases in which it sets inaccurate mode? I don't trust the existing detection code enough to use it in production. It often fails to detect and thus ffmpeg will exit at startup. Can this be fixed by simply increasing the timeout from 1 sec to 2 seconds? Also, there are cases where it will misdetect 1080i59 as 1080p30 depending on the card. It's been on my TODO list for a while to make that code more robust (I believe I know what most of the issues are), but it hasn't been critical for any of my use cases. Hmm, interesting... When you say the issue is card-dependant, does this mean card _model_ dependant or that the issue can affect one card and not the other with of the same model/fw? If an user can't or won't use format auto detection, then there is no way to reliably obtain the correct timecode without this patch or some similar hack. Maybe the offset-related ops could be guarded by a check for auto detection, even though the patch won't hurt even if it was used in that case. I am still not liking this too much because we are guessing some timecode which we never actually saw, and the guessing is based on the number of the VideoFrameArrived callbacks. Yes, usually it is called once for every frame, but some frames might not contain audio, also there are some examples in the SDK docs where only an audio frame (and no video frame) is available in the callback. Yes, that's why there is a new counter, incremented only upon getting a video frame and reset until the demuxer successfully queues the packet of the first video frame. I just noticed an issue with it, but I can change that. So it is up to the receiving application to do something to keep audio and video in sync, it either drops/duplicates video or audio. If it drops/dups video then our guessed start timecode can be wrong even if we were only counting the video frames. By receiving app, do you mean the Decklink driver or decklink_dec/ffmpeg.c? So I think that if a workaround/hack is needed, we should do that differently. One idea is to introduce an option which makes the code drop video till the first valid video frame, or the first valid timecode. But if autodetection works (or it can be fixed), then I just don't see too much use even for this. As Ilinca's tests showed, without auto format detection, the stored timecode is *wrong*. That's a bug so some change is *required*. Gyan ___ 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 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Thursday, August 1, 2019 22:51 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Michael Niedermayer > > Sent: Wednesday, July 31, 2019 14:04 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > > On Tue, Jul 30, 2019 at 10:27:10AM -0300, James Almer wrote: > > > On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote: > > > > Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie > : > > > >> > > > >>> -Original Message- > > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] > On > > Behalf > > > >>> Of Carl Eugen Hoyos > > > >>> Sent: Tuesday, July 30, 2019 16:06 > > > >>> To: FFmpeg development discussions and patches > > >>> de...@ffmpeg.org> > > > >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > > > >>> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > >>> > > > >>> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu > > : > > > > > > Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate > > > whether encoder supports variable dimension encoding. > > > >>> > > > >>> Isn't this about variable (or "changing") "resolutions" instead of > > dimensions? > > > >>> > > > >> > > > >> Comment is welcome and "variable resolutions" is good. > > > > > > > >> But is "dimension" not quite suitable for the meaning of "variable > > > >> size"? > > > > > > > > It took me some time to understand that "dimension" implies > resolution, > > > > especially since the FFmpeg documentation mentions resolution iirc. > > > > > > > > Carl Eugen > > > > > > We have a AV_SIDE_DATA_PARAM_CHANGE_DIMENSIONS flag to signal > > resolution > > > changes, so both words seem to be used interchangeably. > > > > > > > > This also makes me think that the existing > > AV_CODEC_CAP_PARAM_CHANGE > > > codec cap can be used for this already, without the need for a new one. > > > It should a matter of using AV_PKT_DATA_PARAM_CHANGE packet side > > data > > > afterwards in some form. > > > > if AV_PKT_DATA_PARAM_CHANGE is used then other parameters would > > need to > > be handled too i think. > > For example pixel format changes alongside width and height. > > And it leaves some areas of uncertanity which may require more flags > > like does a aspect ratio change or a change of one of the colorspace > > parameters need a encoder "flush/restart". (the flush is done from > > outside the encoder in the patch so the code would need to know) > > > > Also for symmetry, if AV_PKT_DATA_PARAM_CHANGE expects sidedata > on > > the input side of the decoder, something should produce matching > > side data on the encoder side. > > > > encoder -> decoder should continue working. So only a demuxer > > generating the side data could be a problem. > > Sounds like a new flag will be more robust? Ping for this patch set? https://patchwork.ffmpeg.org/patch/14122/ https://patchwork.ffmpeg.org/patch/14139/ https://patchwork.ffmpeg.org/patch/14140/ ___ 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] lavu/pixfmt: add AYUV pixel format
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Friday, August 30, 2019 00:12 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie : > > > Thus AYUV will make more sense. > > If your hardware decoding does not produce valid alpha data (0xFF > for opaque, 0x00 for completely transparent), you cannot use an > FFmpeg pix_fmt that defines alpha for decoding. > If you define a pix_fmt that does not contain alpha information (as > needed for your hardware decoder), please do not use "A" in its > name. The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). Apart from Y/U/V channel, there is an additional need for a channel to store the zero byte in surfaces(nb_components = 4). And it is designed in hardware/driver for VA_FourCC_AYUV and AYUV format. It's not quite proper to use something like "0YUV" directly which indicates that there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = 3). "0YUV": YUV0/YUV0/... "RGB0":RGB/RGB/... It's true that we could only map Y/U/V data from surface to frame in ffmpeg and use a 3-components pixel format like "0YUV", but IMHO it's kind of improper because the output from hardware/driver is forced changed in Application level even if user didn't call for a CSC: - hardware/driver output (in AYUV): YUV0/YUV0/... - ffmpeg output (in 0YUV): YUV/YUV/... Please feel free to offer your opinions on this question(AYUV or 0YUV) and let me know how to push it step-further. Thanks, Linjie ___ 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 v4] Add ZeroMQ as protocol option
On Sat, 31 Aug 2019, Marton Balint wrote: On Fri, 30 Aug 2019, Andriy Gelman wrote: On Thu, 29. Aug 21:01, Marton Balint wrote: On Thu, 29 Aug 2019, Andriy Gelman wrote: > Changes in v4: > - Use polling instead of non-blocking option for socket >read/write operations. > - Added pkt_size, timeout_send, timeout_recv options. >Updated documentation for new options. No, timeout_send and timeout_recv is not needed. The URL context has a timeout parameter. Please see how unix.c or tcp.c does the polling: They both use a helper funciton called ff_network_wait_fd_timeout (implemented in network.c) which does polling in a loop with small timeouts in order to be able to check the interrupt callback. After successful polling you can call the actual transfer function. You should do something similar, copy ff_network_wait_fd_timeout, replace the file descriptor polling with zmq polling and you should be good to go. Thanks Marton, I've added these changes. I'll send the updated patch shortly. When working on this new version, I first tried to use the AVIO_FLAG_NONBLOCK flag to decide whether to go into a blocking or non-blocking mode. My intention was to return AVERROR(EAGAIN) when in the non-blocking mode if read/write is not available. But avio exits with "Resource temporarily unavailable" when AVIO_FLAG_NONBLOCK flag is set and AVERROR(EAGAIN) is returned. So probably I've misunderstood the meaning of AVIO_FLAG_NONBLOCK. The updated patch is not using this flag. AVIO_FLAG_NONBLOCK is not heavily used or tested. You can still add support for it, (if the flag is set then you skip the code where you poll and if the transfer function returns EAGAIN then you return that as a special case). I am not sure how you can test it actually. Another point: the documentation in url.h says: " * In non-blocking mode, return AVERROR(EAGAIN) immediately. * In blocking mode, wait for data/EOF/error with a short timeout (0.1s), * and return AVERROR(EAGAIN) on timeout." But the function ff_network_wait_fd_timeout returns AVERROR(ETIMEDOUT) on timeout (causing the code to exit) in blocking mode. It seems to me that either the documentation or the return value should be updated. Should I submit a separate patch on this? Yeah, the docs seems inaccurate. I guess the idea was that common code in avio.c:retry_transfer_wrapper should handle the retries but the common code has to differentiate between EAGAIN which should be retried immediately and EAGAIN which should be retried after sleeping a bit. Maybe we should simply return EINTR for the immediate retry case, because that already means an immediate retry in retry_transfer_wrapper. Ok, this won't work out of the box, because for EINTR we will not check if rw_timeout is elapsed... So I guess the docs should be changed to that (yes, submit a separate patch), and existing protocols should be fixed to return EINTR when the poll() times out instead of EAGAIN. This way we can reduce the duplicated code from the protocols. And of course this also means that the zmq protocol can return EINTR on poll timeout and you can call ff_zmq_wait instead of ff_zmq_wait_timeout. Keep the zmq patch as is then, we can remove the extra waiter loop function once the API is cleaned up... Thanks, Marton ___ 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 v5] Add ZeroMQ as protocol option
On Fri, 30 Aug 2019, Andriy Gelman wrote: Changes in v5: - Use polling in a loop to check interrupt callback. - Remove timeout_send/timeout_recv options and update documentation. Thanks, two comments: I noticed that you created a version requirement: libzmq >= 4.3.1. That is a bit new. Are you actually using API which is not available or broken in older releases? If yes, then OK. If not, then I'd relax this to 4.2.0 or something around that release. The other issue I can see is that you are using function names like ff_zmq_*. That is a bit misleading, because in ffmpeg libraries ff_* functions are common functions used from multiple C files. This is not the case here, so please change the ff prefix of the static functions to something else (e.g: zmq or zmqproto to not clash with real zmq library function names). Thanks, Marton ___ 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 3/3] avformat/mov: Check for EOF in mov_read_meta()
On 8/30/2019 8:25 PM, Michael Niedermayer wrote:
> Fixes: Timeout (195sec -> 2ms)
> Fixes:
> 16735/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5090676403863552
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 675b915906..46c544b61f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4419,7 +4419,10 @@ static int mov_read_custom(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> while (atom.size > 8) {
> -uint32_t tag = avio_rl32(pb);
> +uint32_t tag;
> +if (avio_feof(pb))
> +return AVERROR_EOF;
> +tag = avio_rl32(pb);
> atom.size -= 4;
> if (tag == MKTAG('h','d','l','r')) {
> avio_seek(pb, -8, SEEK_CUR);
Maybe do something like "while (atom.size > 8 && !avio_feof(pb))"
instead, which is similar to the loop in mov_read_default.
___
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/3] tools/target_dec_fuzzer: Init parsepkt
On 8/30/2019 8:25 PM, Michael Niedermayer wrote:
> Fixes: memory corruption
> Fixes:
> 16702/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PNG_fuzzer-5768418552184832
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> tools/target_dec_fuzzer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> index e22a0c5c34..901dbca385 100644
> --- a/tools/target_dec_fuzzer.c
> +++ b/tools/target_dec_fuzzer.c
> @@ -194,6 +194,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> size) {
> // Read very simple container
> AVPacket avpkt, parsepkt;
> av_init_packet();
> +av_init_packet();
> while (data < end && it < maxiteration) {
> // Search for the TAG
> while (data + sizeof(fuzz_tag) < end) {
>
LGTM.
___
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 v4] Add ZeroMQ as protocol option
On Fri, 30 Aug 2019, Andriy Gelman wrote: On Thu, 29. Aug 21:01, Marton Balint wrote: On Thu, 29 Aug 2019, Andriy Gelman wrote: > Changes in v4: > - Use polling instead of non-blocking option for socket >read/write operations. > - Added pkt_size, timeout_send, timeout_recv options. >Updated documentation for new options. No, timeout_send and timeout_recv is not needed. The URL context has a timeout parameter. Please see how unix.c or tcp.c does the polling: They both use a helper funciton called ff_network_wait_fd_timeout (implemented in network.c) which does polling in a loop with small timeouts in order to be able to check the interrupt callback. After successful polling you can call the actual transfer function. You should do something similar, copy ff_network_wait_fd_timeout, replace the file descriptor polling with zmq polling and you should be good to go. Thanks Marton, I've added these changes. I'll send the updated patch shortly. When working on this new version, I first tried to use the AVIO_FLAG_NONBLOCK flag to decide whether to go into a blocking or non-blocking mode. My intention was to return AVERROR(EAGAIN) when in the non-blocking mode if read/write is not available. But avio exits with "Resource temporarily unavailable" when AVIO_FLAG_NONBLOCK flag is set and AVERROR(EAGAIN) is returned. So probably I've misunderstood the meaning of AVIO_FLAG_NONBLOCK. The updated patch is not using this flag. AVIO_FLAG_NONBLOCK is not heavily used or tested. You can still add support for it, (if the flag is set then you skip the code where you poll and if the transfer function returns EAGAIN then you return that as a special case). I am not sure how you can test it actually. Another point: the documentation in url.h says: " * In non-blocking mode, return AVERROR(EAGAIN) immediately. * In blocking mode, wait for data/EOF/error with a short timeout (0.1s), * and return AVERROR(EAGAIN) on timeout." But the function ff_network_wait_fd_timeout returns AVERROR(ETIMEDOUT) on timeout (causing the code to exit) in blocking mode. It seems to me that either the documentation or the return value should be updated. Should I submit a separate patch on this? Yeah, the docs seems inaccurate. I guess the idea was that common code in avio.c:retry_transfer_wrapper should handle the retries but the common code has to differentiate between EAGAIN which should be retried immediately and EAGAIN which should be retried after sleeping a bit. Maybe we should simply return EINTR for the immediate retry case, because that already means an immediate retry in retry_transfer_wrapper. So I guess the docs should be changed to that (yes, submit a separate patch), and existing protocols should be fixed to return EINTR when the poll() times out instead of EAGAIN. This way we can reduce the duplicated code from the protocols. And of course this also means that the zmq protocol can return EINTR on poll timeout and you can call ff_zmq_wait instead of ff_zmq_wait_timeout. Regards, Marton ___ 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 2/3] avformat/cdxl: Fix integer overflow in intermediate
Fixes: signed integer overflow: 65535 * 65312 cannot be represented in type 'int' Fixes: 16704/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6294115603447808 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/cdxl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/cdxl.c b/libavformat/cdxl.c index 9aacaddb40..e675b2c8f1 100644 --- a/libavformat/cdxl.c +++ b/libavformat/cdxl.c @@ -131,7 +131,8 @@ static int cdxl_read_packet(AVFormatContext *s, AVPacket *pkt) height = AV_RB16(>header[16]); palette_size = AV_RB16(>header[20]); audio_size = AV_RB16(>header[22]); -if (FFALIGN(width, 16) * (uint64_t)height * cdxl->header[19] > INT_MAX) +if (cdxl->header[19] == 0 || +FFALIGN(width, 16) * (uint64_t)height * cdxl->header[19] > INT_MAX) return AVERROR_INVALIDDATA; if (format == 0x20) image_size = width * height * cdxl->header[19] / 8; -- 2.23.0 ___ 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 1/3] tools/target_dec_fuzzer: Init parsepkt
Fixes: memory corruption
Fixes:
16702/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PNG_fuzzer-5768418552184832
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e22a0c5c34..901dbca385 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -194,6 +194,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
// Read very simple container
AVPacket avpkt, parsepkt;
av_init_packet();
+av_init_packet();
while (data < end && it < maxiteration) {
// Search for the TAG
while (data + sizeof(fuzz_tag) < end) {
--
2.23.0
___
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 3/3] avformat/mov: Check for EOF in mov_read_meta()
Fixes: Timeout (195sec -> 2ms)
Fixes:
16735/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5090676403863552
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 675b915906..46c544b61f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4419,7 +4419,10 @@ static int mov_read_custom(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
while (atom.size > 8) {
-uint32_t tag = avio_rl32(pb);
+uint32_t tag;
+if (avio_feof(pb))
+return AVERROR_EOF;
+tag = avio_rl32(pb);
atom.size -= 4;
if (tag == MKTAG('h','d','l','r')) {
avio_seek(pb, -8, SEEK_CUR);
--
2.23.0
___
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] avdevice/decklink: adjust for timecode lag
On Fri, 30 Aug 2019, Gyan wrote: On 22-08-2019 01:10 AM, Marton Balint wrote: On Tue, 20 Aug 2019, Devin Heitmueller wrote: A couple of follow-up Qs: Is auto-detection available for all Decklink devices? No, but AFAIK it is for all devices which support SDI. Generally it's the older analog capture devices which don't support it. For those for which it is available, are there any edge cases in which it sets inaccurate mode? I don't trust the existing detection code enough to use it in production. It often fails to detect and thus ffmpeg will exit at startup. Can this be fixed by simply increasing the timeout from 1 sec to 2 seconds? Also, there are cases where it will misdetect 1080i59 as 1080p30 depending on the card. It's been on my TODO list for a while to make that code more robust (I believe I know what most of the issues are), but it hasn't been critical for any of my use cases. Hmm, interesting... When you say the issue is card-dependant, does this mean card _model_ dependant or that the issue can affect one card and not the other with of the same model/fw? If an user can't or won't use format auto detection, then there is no way to reliably obtain the correct timecode without this patch or some similar hack. Maybe the offset-related ops could be guarded by a check for auto detection, even though the patch won't hurt even if it was used in that case. I am still not liking this too much because we are guessing some timecode which we never actually saw, and the guessing is based on the number of the VideoFrameArrived callbacks. Yes, usually it is called once for every frame, but some frames might not contain audio, also there are some examples in the SDK docs where only an audio frame (and no video frame) is available in the callback. So it is up to the receiving application to do something to keep audio and video in sync, it either drops/duplicates video or audio. If it drops/dups video then our guessed start timecode can be wrong even if we were only counting the video frames. So I think that if a workaround/hack is needed, we should do that differently. One idea is to introduce an option which makes the code drop video till the first valid video frame, or the first valid timecode. But if autodetection works (or it can be fixed), then I just don't see too much use even for this. Regards, Marton ___ 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 4/4] avcodec/vorbisdec: Check get_vlc2() failure
On Mon, Jul 08, 2019 at 01:18:05AM +0200, Michael Niedermayer wrote: > No testcase Testcase found by ossfuzz will apply [...] -- 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: 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".
[FFmpeg-devel] [PATCH] avcodec/decode: add a parameter to ff_reget_buffer() to request a writable buffer
Some decoders may not need a writable buffer in some specific cases, but only
a reference to the existing buffer with updated frame properties instead, for
the purpose of returning duplicate frames.
Signed-off-by: James Almer
---
libavcodec/aasc.c | 2 +-
libavcodec/anm.c | 2 +-
libavcodec/ansi.c | 2 +-
libavcodec/avs.c | 2 +-
libavcodec/bethsoftvideo.c | 2 +-
libavcodec/bink.c | 2 +-
libavcodec/c93.c | 2 +-
libavcodec/cdgraphics.c| 2 +-
libavcodec/cinepak.c | 2 +-
libavcodec/clearvideo.c| 4 ++--
libavcodec/cpia.c | 2 +-
libavcodec/cscd.c | 2 +-
libavcodec/decode.c| 8
libavcodec/dsicinvideo.c | 2 +-
libavcodec/fic.c | 4 ++--
libavcodec/flashsv.c | 2 +-
libavcodec/flicvideo.c | 6 +++---
libavcodec/gifdec.c| 2 +-
libavcodec/indeo2.c| 2 +-
libavcodec/internal.h | 6 +++---
libavcodec/jvdec.c | 2 +-
libavcodec/mmvideo.c | 2 +-
libavcodec/motionpixels.c | 2 +-
libavcodec/msrle.c | 2 +-
libavcodec/mss1.c | 2 +-
libavcodec/mss2.c | 2 +-
libavcodec/mss3.c | 2 +-
libavcodec/mss4.c | 2 +-
libavcodec/msvideo1.c | 2 +-
libavcodec/nuv.c | 2 +-
libavcodec/pafvideo.c | 2 +-
libavcodec/qtrle.c | 2 +-
libavcodec/roqvideodec.c | 2 +-
libavcodec/rpza.c | 2 +-
libavcodec/rscc.c | 2 +-
libavcodec/scpr.c | 2 +-
libavcodec/screenpresso.c | 2 +-
libavcodec/smacker.c | 2 +-
libavcodec/smc.c | 2 +-
libavcodec/tiertexseqv.c | 2 +-
libavcodec/truemotion1.c | 2 +-
libavcodec/truemotion2.c | 2 +-
libavcodec/tscc.c | 2 +-
libavcodec/tscc2.c | 2 +-
libavcodec/ulti.c | 2 +-
libavcodec/vmnc.c | 2 +-
libavcodec/xxan.c | 2 +-
libavcodec/yop.c | 2 +-
48 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/libavcodec/aasc.c b/libavcodec/aasc.c
index 58cc3c85ba..9974297ce2 100644
--- a/libavcodec/aasc.c
+++ b/libavcodec/aasc.c
@@ -91,7 +91,7 @@ static int aasc_decode_frame(AVCodecContext *avctx,
return AVERROR_INVALIDDATA;
}
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+if ((ret = ff_reget_buffer(avctx, s->frame, 1)) < 0)
return ret;
compr = AV_RL32(buf);
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index 778f38413e..97534ffd04 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -122,7 +122,7 @@ static int decode_frame(AVCodecContext *avctx,
if (buf_size < 7)
return AVERROR_INVALIDDATA;
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+if ((ret = ff_reget_buffer(avctx, s->frame, 1)) < 0)
return ret;
dst = s->frame->data[0];
dst_end = s->frame->data[0] + s->frame->linesize[0]*avctx->height;
diff --git a/libavcodec/ansi.c b/libavcodec/ansi.c
index f1fafab771..cde7e28a11 100644
--- a/libavcodec/ansi.c
+++ b/libavcodec/ansi.c
@@ -362,7 +362,7 @@ static int decode_frame(AVCodecContext *avctx,
const uint8_t *buf_end = buf+buf_size;
int ret, i, count;
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+if ((ret = ff_reget_buffer(avctx, s->frame, 1)) < 0)
return ret;
if (!avctx->frame_number) {
for (i=0; iheight; i++)
diff --git a/libavcodec/avs.c b/libavcodec/avs.c
index 66724d47b7..dac1c16ca5 100644
--- a/libavcodec/avs.c
+++ b/libavcodec/avs.c
@@ -59,7 +59,7 @@ avs_decode_frame(AVCodecContext * avctx,
AvsBlockType type;
GetBitContext change_map = {0}; //init to silence warning
-if ((ret = ff_reget_buffer(avctx, p)) < 0)
+if ((ret = ff_reget_buffer(avctx, p, 1)) < 0)
return ret;
p->pict_type = AV_PICTURE_TYPE_P;
p->key_frame = 0;
diff --git a/libavcodec/bethsoftvideo.c b/libavcodec/bethsoftvideo.c
index e5a73f55a1..d056e673df 100644
--- a/libavcodec/bethsoftvideo.c
+++ b/libavcodec/bethsoftvideo.c
@@ -79,7 +79,7 @@ static int bethsoftvid_decode_frame(AVCodecContext *avctx,
int code, ret;
int yoffset;
-if ((ret = ff_reget_buffer(avctx, vid->frame)) < 0)
+if ((ret = ff_reget_buffer(avctx, vid->frame, 1)) < 0)
return ret;
wrap_to_next_line = vid->frame->linesize[0] - avctx->width;
diff --git a/libavcodec/bink.c b/libavcodec/bink.c
index 5bb3955f93..16dc20a362 100644
--- a/libavcodec/bink.c
+++ b/libavcodec/bink.c
@@ -1261,7 +1261,7 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame, AVPac
if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
return ret;
} else {
-if ((ret = ff_reget_buffer(avctx, c->last)) < 0)
+if ((ret = ff_reget_buffer(avctx, c->last, 1)) < 0)
return ret;
if ((ret = av_frame_ref(frame, c->last)) < 0)
return ret;
diff --git a/libavcodec/c93.c b/libavcodec/c93.c
index b708659cca..53ba401e33 100644
---
Re: [FFmpeg-devel] [PATCH] avcodec/wcmv: use ff_reget_buffer()
On 8/30/19, James Almer wrote:
> On 8/30/2019 3:45 AM, Paul B Mahol wrote:
>> Here is sample: https://0x0.st/z49v.avi
>
> Thanks. Can you make a fate test for it?
Here is much smaller file.
https://0x0.st/z4f5.avi
>
>>
>> On 8/30/19, Paul B Mahol wrote:
>>> It still exits early when no blocks are encoded.
>>>
>>> On 8/30/19, James Almer wrote:
Signed-off-by: James Almer
---
Untested. There doesn't seem to be a fate test, and i have no samples
at hand.
libavcodec/wcmv.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
index 0d60b9fe1f..68142b45fd 100644
--- a/libavcodec/wcmv.c
+++ b/libavcodec/wcmv.c
@@ -60,7 +60,7 @@ static int decode_frame(AVCodecContext *avctx,
if (!blocks)
return avpkt->size;
-if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) <
0)
+if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
return ret;
if (blocks > 5) {
@@ -157,13 +157,9 @@ static int decode_frame(AVCodecContext *avctx,
if (bytestream2_get_bytes_left() < 8LL * blocks)
return AVERROR_INVALIDDATA;
-if (s->prev_frame->data[0]) {
-ret = av_frame_copy(frame, s->prev_frame);
-if (ret < 0)
-return ret;
-} else {
-ptrdiff_t linesize[4] = { frame->linesize[0], 0, 0, 0 };
-av_image_fill_black(frame->data, linesize, avctx->pix_fmt, 0,
+if (!avctx->frame_number) {
+ptrdiff_t linesize[4] = { s->prev_frame->linesize[0], 0, 0, 0
};
+av_image_fill_black(s->prev_frame->data, linesize,
avctx->pix_fmt,
0,
avctx->width, avctx->height);
}
@@ -184,7 +180,7 @@ static int decode_frame(AVCodecContext *avctx,
if (w > avctx->width || h > avctx->height)
return AVERROR_INVALIDDATA;
-dst = frame->data[0] + (avctx->height - y - 1) *
frame->linesize[0]
+ x * bpp;
+dst = s->prev_frame->data[0] + (avctx->height - y - 1) *
s->prev_frame->linesize[0] + x * bpp;
for (int i = 0; i < h; i++) {
s->zstream.next_out = dst;
s->zstream.avail_out = w * bpp;
@@ -196,15 +192,14 @@ static int decode_frame(AVCodecContext *avctx,
return AVERROR_INVALIDDATA;
}
-dst -= frame->linesize[0];
+dst -= s->prev_frame->linesize[0];
}
}
-frame->key_frame = intra;
-frame->pict_type = intra ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
+s->prev_frame->key_frame = intra;
+s->prev_frame->pict_type = intra ? AV_PICTURE_TYPE_I :
AV_PICTURE_TYPE_P;
-av_frame_unref(s->prev_frame);
-if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
+if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
return ret;
*got_frame = 1;
--
2.22.0
___
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 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 1/5] avcodec/vaapi_encode: Simplify code with av_clip_int8()
On Thu, Aug 29, 2019 at 12:18:03AM +, Li, Zhong wrote: > > From: ffmpeg-devel On Behalf Of Michael > > Niedermayer > > Sent: Thursday, August 29, 2019 1:27 AM > > To: FFmpeg development discussions and patches > > Subject: [FFmpeg-devel] [PATCH 1/5] avcodec/vaapi_encode: Simplify code with > > av_clip_int8() > > > > Only build tested > > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/vaapi_encode.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index > > 2fb43cf1a4..3be9159d37 100644 > > --- a/libavcodec/vaapi_encode.c > > +++ b/libavcodec/vaapi_encode.c > > @@ -480,7 +480,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx, > > .width = roi->right - roi->left, > > .height = roi->bottom - roi->top, > > }, > > -.roi_value = av_clip_c(v, INT8_MIN, INT8_MAX), > > +.roi_value = av_clip_int8(v), > > }; > > } > > > > -- > > 2.23.0 > > LGTM will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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 2/2] avcodec/arbc: Use ff_reget_buffer()
On Fri, Aug 30, 2019 at 11:15:21AM -0300, James Almer wrote:
> On 8/29/2019 4:33 PM, James Almer wrote:
> > On 8/29/2019 4:04 PM, Michael Niedermayer wrote:
> >> Fixes: Timeout (20sec -> 0.5sec)
> >> Fixes:
> >> 16404/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARBC_fuzzer-5660216355454976
> >>
> >> Found-by: continuous fuzzing process
> >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavcodec/arbc.c | 21 +++--
> >> 1 file changed, 7 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
> >> index 06970f140b..f0de50e243 100644
> >> --- a/libavcodec/arbc.c
> >> +++ b/libavcodec/arbc.c
> >> @@ -136,15 +136,9 @@ static int decode_frame(AVCodecContext *avctx, void
> >> *data,
> >> if (7 * nb_segments > bytestream2_get_bytes_left(>gb))
> >> return AVERROR_INVALIDDATA;
> >>
> >> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
> >> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
> >> return ret;
> >>
> >> -if (s->prev_frame->data[0]) {
> >> -ret = av_frame_copy(frame, s->prev_frame);
> >> -if (ret < 0)
> >> -return ret;
> >> -}
> >> -
> >> for (int i = 0; i < nb_segments; i++) {
> >> int resolution_flag;
> >> int fill;
> >> @@ -161,19 +155,18 @@ static int decode_frame(AVCodecContext *avctx, void
> >> *data,
> >> resolution_flag = bytestream2_get_byte(>gb);
> >>
> >> if (resolution_flag & 0x10)
> >> -prev_pixels -= fill_tileX(avctx, 1024, 1024, fill, frame);
> >> +prev_pixels -= fill_tileX(avctx, 1024, 1024, fill,
> >> s->prev_frame);
> >> if (resolution_flag & 0x08)
> >> -prev_pixels -= fill_tileX(avctx, 256, 256, fill, frame);
> >> +prev_pixels -= fill_tileX(avctx, 256, 256, fill,
> >> s->prev_frame);
> >> if (resolution_flag & 0x04)
> >> -prev_pixels -= fill_tileX(avctx, 64, 64, fill, frame);
> >> +prev_pixels -= fill_tileX(avctx, 64, 64, fill, s->prev_frame);
> >> if (resolution_flag & 0x02)
> >> -prev_pixels -= fill_tileX(avctx, 16, 16, fill, frame);
> >> +prev_pixels -= fill_tileX(avctx, 16, 16, fill, s->prev_frame);
> >> if (resolution_flag & 0x01)
> >> -prev_pixels -= fill_tile4(avctx, fill, frame);
> >> +prev_pixels -= fill_tile4(avctx, fill, s->prev_frame);
> >> }
> >>
> >> -av_frame_unref(s->prev_frame);
> >> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
> >> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
> >> return ret;
> >>
> >> frame->pict_type = prev_pixels <= 0 ? AV_PICTURE_TYPE_I :
> >> AV_PICTURE_TYPE_P;
> >
> > You could while at it revert 8b10f09fd53, then implement d70bbdc5fa for
> > this decoder as part of this patch.
>
> Or maybe we should do what you suggested and simplify things by either
> adding a new reget function, or changing the current one to take a new
> argument to request a writable buffer.
> The latter sounds better, IMO, and I can look into implementing it.
sure, ok
thx
[...]
--
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: 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 v1 3/5] avcodec/v210enc: define DEFINE_V210_PLANAR_FUNC to remove duplicate function
On Wed, Aug 28, 2019 at 11:45:14PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v210enc.c | 43 ---
> 1 file changed, 16 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
> index 69a2efe..716544a 100644
> --- a/libavcodec/v210enc.c
> +++ b/libavcodec/v210enc.c
> @@ -36,35 +36,24 @@
> dst += 4; \
> } while (0)
>
> -static void v210_planar_pack_8_c(const uint8_t *y, const uint8_t *u,
> - const uint8_t *v, uint8_t *dst,
> - ptrdiff_t width)
> -{
> -uint32_t val;
> -int i;
> -
> -for (i = 0; i < width - 5; i += 6) {
> -WRITE_PIXELS(u, y, v, 8);
> -WRITE_PIXELS(y, u, y, 8);
> -WRITE_PIXELS(v, y, u, 8);
> -WRITE_PIXELS(y, v, y, 8);
> -}
> +#define DEFINE_V210_PLANAR_FUNC(nbits, depth)\
> +static void v210_planar_pack_##depth##_c(const uint##nbits##_t *y, \
> +const uint##nbits##_t *u, const uint##nbits##_t *v, \
> +uint8_t *dst, ptrdiff_t width) \
> +{\
> +uint32_t val;\
> +int i; \
> + \
> +for (i = 0; i < width - 5; i += 6) { \
> +WRITE_PIXELS(u, y, v, depth);\
> +WRITE_PIXELS(y, u, y, depth);\
> +WRITE_PIXELS(v, y, u, depth);\
> +WRITE_PIXELS(y, v, y, depth);\
> +}\
> }
>
> -static void v210_planar_pack_10_c(const uint16_t *y, const uint16_t *u,
> - const uint16_t *v, uint8_t *dst,
> - ptrdiff_t width)
> -{
> -uint32_t val;
> -int i;
> -
> -for (i = 0; i < width - 5; i += 6) {
> -WRITE_PIXELS(u, y, v, 10);
> -WRITE_PIXELS(y, u, y, 10);
> -WRITE_PIXELS(v, y, u, 10);
> -WRITE_PIXELS(y, v, y, 10);
> -}
> -}
> +DEFINE_V210_PLANAR_FUNC(8, 8);
> +DEFINE_V210_PLANAR_FUNC(16, 10);
same as with the other per depth functions, i think this might be cleaner
in a seperate "template" file
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
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 v1 4/5] avcodec/v210enc: make 8bit and 10bit process consistent
On Wed, Aug 28, 2019 at 11:45:15PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/v210enc.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) the commit message should say "why" (for code factorization in the next commit) i presume thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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 v1 5/5] avcodec/v210enc: define DEFINE_V210_ENCODE_FUNC to remove duplicate code
On Wed, Aug 28, 2019 at 11:45:16PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/v210enc.c | 171 > +-- > 1 file changed, 69 insertions(+), 102 deletions(-) > > diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c > index 2400538..b40c7ae 100644 > --- a/libavcodec/v210enc.c > +++ b/libavcodec/v210enc.c > @@ -89,15 +89,77 @@ FF_ENABLE_DEPRECATION_WARNINGS > return 0; > } > > +#define DEFINE_V210_ENCODE_FUNC(nbits, depth) > \ > +static void v210_enc_##depth(AVCodecContext *avctx, > \ > +uint8_t *dst, const AVFrame *pic) > \ puting this in a seperate file which is included twice would avoid the rather large mutiline macro also that would match how such functions for multiple depths are handled in other codecs thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand 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".
[FFmpeg-devel] [PATCH v5] Add ZeroMQ as protocol option
Changes in v5:
- Use polling in a loop to check interrupt callback.
- Remove timeout_send/timeout_recv options and update
documentation.
Thanks,
Andriy
>From a0c642f59c314c7ae53917f2b0d02bc6779009c2 Mon Sep 17 00:00:00 2001
From: Andriy Gelman
Date: Tue, 30 Jul 2019 14:39:32 -0400
Subject: [PATCH] libavformat: Add ZeroMQ as a protocol option
Currently multiple clients are only supported by using a multicast
destination address. An alternative is to stream to a server which
re-distributes the content. This commit adds ZeroMQ as a protocol
option, which allows multiple clients to connect to a single ffmpeg
instance.
---
Changelog | 1 +
configure | 4 +-
doc/general.texi| 1 +
doc/protocols.texi | 42 +
libavformat/Makefile| 1 +
libavformat/libzmq.c| 199
libavformat/protocols.c | 1 +
libavformat/version.h | 2 +-
8 files changed, 249 insertions(+), 2 deletions(-)
create mode 100644 libavformat/libzmq.c
diff --git a/Changelog b/Changelog
index 20e42964da..4b29e015a0 100644
--- a/Changelog
+++ b/Changelog
@@ -8,6 +8,7 @@ version :
- support for TrueHD in mp4
- Supoort AMD AMF encoder on Linux (via Vulkan)
- IMM5 video decoder
+- ZeroMQ protocol
version 4.2:
diff --git a/configure b/configure
index 08a54a7e9f..bde2bcc004 100755
--- a/configure
+++ b/configure
@@ -3414,6 +3414,8 @@ libsrt_protocol_deps="libsrt"
libsrt_protocol_select="network"
libssh_protocol_deps="libssh"
libtls_conflict="openssl gnutls mbedtls"
+libzmq_protocol_deps="libzmq"
+libzmq_protocol_select="network"
# filters
afftdn_filter_deps="avcodec"
@@ -6324,7 +6326,7 @@ enabled libxavs && require libxavs "stdint.h
xavs.h" xavs_encoder_enco
enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0"
"stdint.h xavs2.h" xavs2_api_get
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.7.0" zimg.h
zimg_get_api_version
-enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
+enabled libzmq&& require_pkg_config libzmq "libzmq >= 4.3.1" zmq.h
zmq_ctx_new
enabled libzvbi && require_pkg_config libzvbi zvbi-0.2 libzvbi.h
vbi_decoder_new &&
{ test_cpp_condition libzvbi.h "VBI_VERSION_MAJOR
> 0 || VBI_VERSION_MINOR > 2 || VBI_VERSION_MINOR == 2 && VBI_VERSION_MICRO >=
28" ||
enabled gpl || die "ERROR: libzvbi requires
version 0.2.28 or --enable-gpl."; }
diff --git a/doc/general.texi b/doc/general.texi
index d0c3525e02..2744c238cf 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1339,6 +1339,7 @@ performance on systems without hardware floating point
support).
@item TCP @tab X
@item TLS @tab X
@item UDP @tab X
+@item ZMQ @tab E
@end multitable
@code{X} means that the protocol is supported.
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 3e4e7af3d4..32a89c2fe5 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1728,4 +1728,46 @@ Timeout in ms.
Create the Unix socket in listening mode.
@end table
+@section libzmq
+
+ZeroMQ asynchronous messaging library.
+
+This library supports unicast streaming to multiple clients without relying on
+an external server.
+
+The required syntax for streaming or connecting to a stream is:
+@example
+zmq:tcp://ip-address:port
+@end example
+
+Example:
+Create a localhost stream on port :
+@example
+ffmpeg -re -i input -f mpegts zmq:tcp://127.0.0.1:
+@end example
+
+Multiple clients may connect to the stream using:
+@example
+ffplay zmq:tcp://127.0.0.1:
+@end example
+
+Streaming to multiple clients is implemented using a ZeroMQ Pub-Sub pattern.
+The server side binds to a port and publishes data. Clients connect to the
+server (via IP address/port) and subscribe to the stream. The order in which
+the server and client start generally does not matter.
+
+ffmpeg must be compiled with the --enable-libzmq option to support
+this protocol.
+
+Options can be set on the @command{ffmpeg}/@command{ffplay} command
+line. The following options are supported:
+
+@table @option
+
+@item pkt_size
+Forces the maximum packet size for sending/receiving data. The default value
is 32,768 bytes. On the server side, this sets the maximum size of sent packets
via ZeroMQ. On the clients, it sets an internal buffer size for receiving
packets. Note that pkt_size on the clients should be equal to or greater than
pkt_size on the server. Otherwise the received message may be truncated causing
decoding errors.
+
+@end table
+
+
@c man end PROTOCOLS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a434b005a4..efa3a112ae 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
Re: [FFmpeg-devel] [PATCH v4] Add ZeroMQ as protocol option
On Thu, 29. Aug 21:01, Marton Balint wrote: > > > On Thu, 29 Aug 2019, Andriy Gelman wrote: > > > Changes in v4: > > - Use polling instead of non-blocking option for socket > >read/write operations. > > - Added pkt_size, timeout_send, timeout_recv options. > >Updated documentation for new options. > > No, timeout_send and timeout_recv is not needed. The URL context has a > timeout parameter. > > Please see how unix.c or tcp.c does the polling: They both use a helper > funciton called ff_network_wait_fd_timeout (implemented in network.c) which > does polling in a loop with small timeouts in order to be able to check the > interrupt callback. After successful polling you can call the actual > transfer function. > > You should do something similar, copy ff_network_wait_fd_timeout, replace > the file descriptor polling with zmq polling and you should be good to go. Thanks Marton, I've added these changes. I'll send the updated patch shortly. When working on this new version, I first tried to use the AVIO_FLAG_NONBLOCK flag to decide whether to go into a blocking or non-blocking mode. My intention was to return AVERROR(EAGAIN) when in the non-blocking mode if read/write is not available. But avio exits with "Resource temporarily unavailable" when AVIO_FLAG_NONBLOCK flag is set and AVERROR(EAGAIN) is returned. So probably I've misunderstood the meaning of AVIO_FLAG_NONBLOCK. The updated patch is not using this flag. Another point: the documentation in url.h says: " * In non-blocking mode, return AVERROR(EAGAIN) immediately. * In blocking mode, wait for data/EOF/error with a short timeout (0.1s), * and return AVERROR(EAGAIN) on timeout." But the function ff_network_wait_fd_timeout returns AVERROR(ETIMEDOUT) on timeout (causing the code to exit) in blocking mode. It seems to me that either the documentation or the return value should be updated. Should I submit a separate patch on this? Thanks, Andriy ___ 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 v3] Allow 'concat' filter to support inputs with different frame rates
Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.
If a later input is higher framerate, this results in dropped frames; if
a later input is lower framerate it might cause judder.
This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".
A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
---
Updated version of
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/208251.html
Fixes the missing concat-vfr filtergraph for tests, and adds a newline
to the end of the log message.
libavfilter/avf_concat.c | 15 ++-
tests/fate/filter-video.mak | 4 +-
tests/filtergraphs/concat-vfr| 8 ++
tests/ref/fate/filter-concat-vfr | 224 +++
4 files changed, 249 insertions(+), 2 deletions(-)
create mode 100644 tests/filtergraphs/concat-vfr
create mode 100644 tests/ref/fate/filter-concat-vfr
diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 1d0c2de290..2791859d8f 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -131,8 +131,21 @@ static int config_output(AVFilterLink *outlink)
outlink->h = inlink->h;
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->format = inlink->format;
+outlink->frame_rate = inlink->frame_rate;
+
+for (seg = 1; seg < cat->nb_segments; seg++) {
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
+if (outlink->frame_rate.num != inlink->frame_rate.num ||
+outlink->frame_rate.den != outlink->frame_rate.den) {
+av_log(ctx, AV_LOG_VERBOSE,
+"Video inputs have different frame rates, output will be
VFR\n");
+outlink->frame_rate = av_make_q(1, 0);
+break;
+}
+}
+
for (seg = 1; seg < cat->nb_segments; seg++) {
-inlink = ctx->inputs[in_no += ctx->nb_outputs];
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
if (!outlink->sample_aspect_ratio.num)
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
/* possible enhancement: unsafe mode, do not check */
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 60c6be143b..0c6ee72432 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -424,9 +424,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, VMD_DEMUXER
VMDVIDEO_DECODER FORMAT_FILTER PE
fate-filter-gradfun-sample: tests/data/filtergraphs/gradfun
fate-filter-gradfun-sample: CMD = framecrc -i $(TARGET_SAMPLES)/vmd/12.vmd
-filter_script $(TARGET_PATH)/tests/data/filtergraphs/gradfun -an -frames:v 20
-FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat
+FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) +=
fate-filter-concat fate-filter-concat-vfr
fate-filter-concat: tests/data/filtergraphs/concat
fate-filter-concat: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat
+fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
+fate-filter-concat-vfr: CMD = framecrc -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) +=
fate-filter-mpdecimate
fate-filter-mpdecimate: CMD = framecrc -lavfi
testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p
diff --git a/tests/filtergraphs/concat-vfr b/tests/filtergraphs/concat-vfr
new file mode 100644
index 00..e15cb96845
--- /dev/null
+++ b/tests/filtergraphs/concat-vfr
@@ -0,0 +1,8 @@
+testsrc=r=5:n=1:d=2 [v1];
+sine=440:b=2:d=1 [a1];
+testsrc=r=15:n=1:d=1 [v2];
+sine=622:b=2:d=2 [a2];
+testsrc=r=8:n=1:d=1 [v3];
+sine=880:b=2:d=1 [a3];
+
+[v1][a1][v2][a2][v3][a3] concat=v=1:a=1:n=3
diff --git a/tests/ref/fate/filter-concat-vfr b/tests/ref/fate/filter-concat-vfr
new file mode 100644
index 00..0dece67a07
--- /dev/null
+++ b/tests/ref/fate/filter-concat-vfr
@@ -0,0 +1,224 @@
+#tb 0: 1/100
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+#tb 1: 1/44100
+#media_type 1: audio
+#codec_id 1: pcm_s16le
+#sample_rate 1: 44100
+#channel_layout 1: 4
+#channel_layout_name 1: mono
+0, 0, 0,0, 230400, 0x88c4d19a
+1, 0, 0, 1024, 2048, 0xb3f10192
+1, 1024, 1024, 1024, 2048, 0xb340fe4e
+1, 2048, 2048, 1024, 2048, 0x0a5f0111
+1, 3072, 3072, 1024, 2048, 0x51be06b8
+1, 4096, 4096, 1024, 2048, 0x71a1ffcb
+1, 5120, 5120, 1024, 2048, 0x7f64f50f
+1, 6144, 6144, 1024, 2048, 0x70a8fa17
+1,
[FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: add support to fuzz bitstream filters
Signed-off-by: James Almer
---
Untested. I'm also not sure how to add the FFMPEG_BSF define to tools/Makefile,
and have it coexist with FFMPEG_DECODER. Assuming it's needed.
tools/target_dec_fuzzer.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 0d10503cfb..b8fe1f2aa1 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -65,6 +65,8 @@ static void error(const char *err)
}
static AVCodec *c = NULL;
+static AVBitStreamFilter *f = NULL;
+
static AVCodec *AVCodecInitialize(enum AVCodecID codec_id)
{
AVCodec *res;
@@ -102,6 +104,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
int *got_picture_ptr,
const AVPacket *avpkt) = NULL;
AVCodecParserContext *parser = NULL;
+AVBSFContext *bsf = NULL;
if (!c) {
@@ -120,6 +123,27 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
av_log_set_level(AV_LOG_PANIC);
}
+if (!f) {
+#ifdef FFMPEG_BSF
+#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
+#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
+extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
+f = _SYMBOL(FFMPEG_BSF);
+
+if (f->codec_ids) {
+const enum AVCodecID *ids;
+for (ids = f->codec_ids; *ids != AV_CODEC_ID_NONE; ids++)
+if (*ids == c->id)
+break;
+if (ids == AV_CODEC_ID_NONE)
+error("Invalid bsf");
+}
+#else
+extern AVBitStreamFilter ff_null_bsf;
+f = _null_bsf;
+#endif
+}
+
switch (c->type) {
case AVMEDIA_TYPE_AUDIO : decode_handler = avcodec_decode_audio4; break;
case AVMEDIA_TYPE_VIDEO : decode_handler = avcodec_decode_video2; break;
@@ -181,6 +205,18 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
}
parser_avctx->codec_id = ctx->codec_id;
+res = av_bsf_alloc(f, );
+if (res < 0)
+error("Failed memory allocation");
+
+res = avcodec_parameters_from_context(bsf->par_in, ctx);
+if (res < 0)
+error("Failed memory allocation");
+
+res = av_bsf_init(bsf);
+if (res < 0)
+return 0; // Failure of av_bsf_init() does not imply that a issue was
found
+
int got_frame;
AVFrame *frame = av_frame_alloc();
if (!frame)
@@ -237,6 +273,11 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
}
// Iterate through all data
+ res = av_bsf_send_packet(bsf, );
+ while (res >= 0) {
+res = av_bsf_receive_packet(bsf, );
+if (res < 0)
+break;
while (avpkt.size > 0 && it++ < maxiteration) {
av_frame_unref(frame);
int ret = decode_handler(ctx, frame, _frame, );
@@ -255,6 +296,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
avpkt.size -= ret;
}
av_packet_unref();
+ }
}
av_packet_unref();
}
@@ -270,6 +312,7 @@ maximums_reached:
fprintf(stderr, "pixels decoded: %"PRId64", iterations: %d\n", ec_pixels,
it);
+av_bsf_free();
av_frame_free();
avcodec_free_context();
avcodec_free_context(_avctx);
--
2.22.0
___
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 v1 1/2] avcodec/v410dec: add the slice threading support
All this patches are missing number showing speedup gains.
On 8/30/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v410dec.c | 77
> ++--
> 1 file changed, 57 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
> index 48fab68..a9b17a0 100644
> --- a/libavcodec/v410dec.c
> +++ b/libavcodec/v410dec.c
> @@ -24,6 +24,14 @@
> #include "libavutil/intreadwrite.h"
> #include "avcodec.h"
> #include "internal.h"
> +#include "thread.h"
> +
> +#define MAX_SLICES 32
> +typedef struct ThreadData {
> +AVFrame *frame;
> +uint8_t *buf;
> +int stride;
> +} ThreadData;
>
> static av_cold int v410_decode_init(AVCodecContext *avctx)
> {
> @@ -42,31 +50,30 @@ static av_cold int v410_decode_init(AVCodecContext
> *avctx)
> return 0;
> }
>
> -static int v410_decode_frame(AVCodecContext *avctx, void *data,
> - int *got_frame, AVPacket *avpkt)
> +static int v410_decode_slice(AVCodecContext *avctx, void *arg, int jobnr,
> int nb_jobs)
> {
> -AVFrame *pic = data;
> -uint8_t *src = avpkt->data;
> +ThreadData *td = arg;
> +AVFrame *pic = td->frame;
> +int stride = td->stride;
> +int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> +int slice_h = avctx->height / thread_count;
> +int slice_m = avctx->height % thread_count;
> +int slice_start = jobnr * slice_h;
> +int slice_end = slice_start + slice_h;
> +const uint8_t *src = td->buf + stride * slice_start;
> uint16_t *y, *u, *v;
> uint32_t val;
> -int i, j, ret;
> -
> -if (avpkt->size < 4 * avctx->height * avctx->width) {
> -av_log(avctx, AV_LOG_ERROR, "Insufficient input data.\n");
> -return AVERROR(EINVAL);
> -}
> +int i, j;
>
> -if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
> -return ret;
> + /* add the remaining slice for the last job */
> +if (jobnr == thread_count - 1)
> +slice_end += slice_m;
>
> -pic->key_frame = 1;
> -pic->pict_type = AV_PICTURE_TYPE_I;
> +y = (uint16_t*)pic->data[0] + slice_start * (pic->linesize[0] >> 1);
> +u = (uint16_t*)pic->data[1] + slice_start * (pic->linesize[1] >> 1);
> +v = (uint16_t*)pic->data[2] + slice_start * (pic->linesize[2] >> 1);
>
> -y = (uint16_t *)pic->data[0];
> -u = (uint16_t *)pic->data[1];
> -v = (uint16_t *)pic->data[2];
> -
> -for (i = 0; i < avctx->height; i++) {
> +for (i = slice_start; i < avctx->height; i++) {
> for (j = 0; j < avctx->width; j++) {
> val = AV_RL32(src);
>
> @@ -82,6 +89,34 @@ static int v410_decode_frame(AVCodecContext *avctx, void
> *data,
> v += pic->linesize[2] >> 1;
> }
>
> +return 0;
> +}
> +
> +static int v410_decode_frame(AVCodecContext *avctx, void *data,
> + int *got_frame, AVPacket *avpkt)
> +{
> +ThreadData td;
> +AVFrame *pic = data;
> +uint8_t *src = avpkt->data;
> +int ret;
> +int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> +
> +td.stride = avctx->width * 4;
> +if (avpkt->size < 4 * avctx->height * avctx->width) {
> +av_log(avctx, AV_LOG_ERROR, "Insufficient input data.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
> +return ret;
> +
> +pic->key_frame = 1;
> +pic->pict_type = AV_PICTURE_TYPE_I;
> +
> +td.buf = src;
> +td.frame = pic;
> +avctx->execute2(avctx, v410_decode_slice, , NULL, thread_count);
> +
> *got_frame = 1;
>
> return avpkt->size;
> @@ -94,5 +129,7 @@ AVCodec ff_v410_decoder = {
> .id = AV_CODEC_ID_V410,
> .init = v410_decode_init,
> .decode = v410_decode_frame,
> -.capabilities = AV_CODEC_CAP_DR1,
> +.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SLICE_THREADS,
> +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> + FF_CODEC_CAP_INIT_CLEANUP,
> };
> --
> 2.6.4
>
> ___
> 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] Change libvpx-vpx default to crf=32.
On Thu, Aug 29, 2019 at 10:14 AM Jan Ekström wrote: > > On Thu, Aug 29, 2019 at 7:17 PM Carl Eugen Hoyos wrote: > > > > Am Do., 29. Aug. 2019 um 18:12 Uhr schrieb Elliott Karpilovsky > > : > > > > > > On Wed, Aug 28, 2019 at 3:11 PM Carl Eugen Hoyos > > > wrote: > > > > > > > > Am Mi., 28. Aug. 2019 um 23:26 Uhr schrieb Elliott Karpilovsky > > > > : > > > > > > > > > > Current default is 200kbps, which produces inconsistent > > > > > results (too high for low-res, too low for hi-res). Use > > > > > CRF instead, which will adapt. Affects vp8/vp9. Also > > > > > have VP8 use a default bitrate of 256kbps. > > > > > > > > Would it simplify the patch if -crf 0 would indicate lossless encoding? > > > > > I do not believe so. I believe that there would be more code changes > > > to switch the checks from ctx->lossless to ctx->crf, > > > > Of course but that wasn't my question. > > I believe it is a horrible bug that x264 uses crf 0 for lossless encoding, > > while libvpx uses another option. If fixing this bug simplifies your > > patch, I believe it is worth the effort. > > > > Just for the record, libx264 only does lossless for CRF=0 for 8bit > coding. The quantizer range for CRF was expanded downwards for higher > bit depths since the results were similar for lossy coding. In that > case you either have to poke the right negative value, or set > quantizer to zero - which is the option that works for all bit depths > with libx264. > > That said, I do not have heavy objections one way or another regarding > how the libvpx wrapper defines CRF (as I think the definition for VP8 > and VP9 is already in general different from what libx264 does - like > bit rate being required for VP8 etc). Just wanted to refresh people's > minds regarding libx264's CRF behavior with lossless coding. > > Best regards, > Jan Thanks for the context. My preference is to keep this patch about changing the default behavior. I would not oppose someone else writing another patch to change CRF=0 to lossless, but it feels like these two should be separate. ___ 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 v1 1/2] avcodec/v410dec: add the slice threading support
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/v410dec.c | 77 ++--
1 file changed, 57 insertions(+), 20 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index 48fab68..a9b17a0 100644
--- a/libavcodec/v410dec.c
+++ b/libavcodec/v410dec.c
@@ -24,6 +24,14 @@
#include "libavutil/intreadwrite.h"
#include "avcodec.h"
#include "internal.h"
+#include "thread.h"
+
+#define MAX_SLICES 32
+typedef struct ThreadData {
+AVFrame *frame;
+uint8_t *buf;
+int stride;
+} ThreadData;
static av_cold int v410_decode_init(AVCodecContext *avctx)
{
@@ -42,31 +50,30 @@ static av_cold int v410_decode_init(AVCodecContext *avctx)
return 0;
}
-static int v410_decode_frame(AVCodecContext *avctx, void *data,
- int *got_frame, AVPacket *avpkt)
+static int v410_decode_slice(AVCodecContext *avctx, void *arg, int jobnr, int
nb_jobs)
{
-AVFrame *pic = data;
-uint8_t *src = avpkt->data;
+ThreadData *td = arg;
+AVFrame *pic = td->frame;
+int stride = td->stride;
+int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
+int slice_h = avctx->height / thread_count;
+int slice_m = avctx->height % thread_count;
+int slice_start = jobnr * slice_h;
+int slice_end = slice_start + slice_h;
+const uint8_t *src = td->buf + stride * slice_start;
uint16_t *y, *u, *v;
uint32_t val;
-int i, j, ret;
-
-if (avpkt->size < 4 * avctx->height * avctx->width) {
-av_log(avctx, AV_LOG_ERROR, "Insufficient input data.\n");
-return AVERROR(EINVAL);
-}
+int i, j;
-if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
-return ret;
+ /* add the remaining slice for the last job */
+if (jobnr == thread_count - 1)
+slice_end += slice_m;
-pic->key_frame = 1;
-pic->pict_type = AV_PICTURE_TYPE_I;
+y = (uint16_t*)pic->data[0] + slice_start * (pic->linesize[0] >> 1);
+u = (uint16_t*)pic->data[1] + slice_start * (pic->linesize[1] >> 1);
+v = (uint16_t*)pic->data[2] + slice_start * (pic->linesize[2] >> 1);
-y = (uint16_t *)pic->data[0];
-u = (uint16_t *)pic->data[1];
-v = (uint16_t *)pic->data[2];
-
-for (i = 0; i < avctx->height; i++) {
+for (i = slice_start; i < avctx->height; i++) {
for (j = 0; j < avctx->width; j++) {
val = AV_RL32(src);
@@ -82,6 +89,34 @@ static int v410_decode_frame(AVCodecContext *avctx, void
*data,
v += pic->linesize[2] >> 1;
}
+return 0;
+}
+
+static int v410_decode_frame(AVCodecContext *avctx, void *data,
+ int *got_frame, AVPacket *avpkt)
+{
+ThreadData td;
+AVFrame *pic = data;
+uint8_t *src = avpkt->data;
+int ret;
+int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
+
+td.stride = avctx->width * 4;
+if (avpkt->size < 4 * avctx->height * avctx->width) {
+av_log(avctx, AV_LOG_ERROR, "Insufficient input data.\n");
+return AVERROR(EINVAL);
+}
+
+if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
+return ret;
+
+pic->key_frame = 1;
+pic->pict_type = AV_PICTURE_TYPE_I;
+
+td.buf = src;
+td.frame = pic;
+avctx->execute2(avctx, v410_decode_slice, , NULL, thread_count);
+
*got_frame = 1;
return avpkt->size;
@@ -94,5 +129,7 @@ AVCodec ff_v410_decoder = {
.id = AV_CODEC_ID_V410,
.init = v410_decode_init,
.decode = v410_decode_frame,
-.capabilities = AV_CODEC_CAP_DR1,
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SLICE_THREADS,
+.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
+ FF_CODEC_CAP_INIT_CLEANUP,
};
--
2.6.4
___
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 v1 2/2] avcodec/v308dec: add the slice threading support
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/v308dec.c | 74 ++--
1 file changed, 55 insertions(+), 19 deletions(-)
diff --git a/libavcodec/v308dec.c b/libavcodec/v308dec.c
index dd53fbd..07e5e24 100644
--- a/libavcodec/v308dec.c
+++ b/libavcodec/v308dec.c
@@ -22,6 +22,13 @@
#include "avcodec.h"
#include "internal.h"
+#define MAX_SLICES 32
+typedef struct ThreadData {
+AVFrame *frame;
+uint8_t *buf;
+int stride;
+} ThreadData;
+
static av_cold int v308_decode_init(AVCodecContext *avctx)
{
avctx->pix_fmt = AV_PIX_FMT_YUV444P;
@@ -32,14 +39,53 @@ static av_cold int v308_decode_init(AVCodecContext *avctx)
return 0;
}
+static int v308_decode_slice(AVCodecContext *avctx, void *arg, int jobnr, int
nb_jobs)
+{
+ThreadData *td = arg;
+AVFrame *pic = td->frame;
+int stride = td->stride;
+int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
+int slice_h = avctx->height / thread_count;
+int slice_m = avctx->height % thread_count;
+int slice_start = jobnr * slice_h;
+int slice_end = slice_start + slice_h;
+const uint8_t *src = td->buf + stride * slice_start;
+uint8_t *y, *u, *v;
+int i, j;
+
+ /* add the remaining slice for the last job */
+if (jobnr == thread_count - 1)
+slice_end += slice_m;
+
+y = pic->data[0] + slice_start * pic->linesize[0];
+u = pic->data[1] + slice_start * pic->linesize[1];
+v = pic->data[2] + slice_start * pic->linesize[2];
+
+for (i = slice_start; i < avctx->height; i++) {
+for (j = 0; j < avctx->width; j++) {
+v[j] = *src++;
+y[j] = *src++;
+u[j] = *src++;
+}
+
+y += pic->linesize[0];
+u += pic->linesize[1];
+v += pic->linesize[2];
+}
+
+return 0;
+}
+
static int v308_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame, AVPacket *avpkt)
{
+ThreadData td;
AVFrame *pic = data;
-const uint8_t *src = avpkt->data;
-uint8_t *y, *u, *v;
-int i, j, ret;
+uint8_t *src = avpkt->data;
+int ret;
+int thread_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
+td.stride = avctx->width * 3;
if (avpkt->size < 3 * avctx->height * avctx->width) {
av_log(avctx, AV_LOG_ERROR, "Insufficient input data.\n");
return AVERROR(EINVAL);
@@ -51,21 +97,9 @@ static int v308_decode_frame(AVCodecContext *avctx, void
*data,
pic->key_frame = 1;
pic->pict_type = AV_PICTURE_TYPE_I;
-y = pic->data[0];
-u = pic->data[1];
-v = pic->data[2];
-
-for (i = 0; i < avctx->height; i++) {
-for (j = 0; j < avctx->width; j++) {
-v[j] = *src++;
-y[j] = *src++;
-u[j] = *src++;
-}
-
-y += pic->linesize[0];
-u += pic->linesize[1];
-v += pic->linesize[2];
-}
+td.buf = src;
+td.frame = pic;
+avctx->execute2(avctx, v308_decode_slice, , NULL, thread_count);
*got_frame = 1;
@@ -79,5 +113,7 @@ AVCodec ff_v308_decoder = {
.id = AV_CODEC_ID_V308,
.init = v308_decode_init,
.decode = v308_decode_frame,
-.capabilities = AV_CODEC_CAP_DR1,
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SLICE_THREADS,
+.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
+ FF_CODEC_CAP_INIT_CLEANUP,
};
--
2.6.4
___
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] avcodec/omx: fix xFramerate calculation
On Thu, Aug 29, 2019 at 10:30 PM Nicolas George wrote: > Aman Gupta (12019-08-29): > > > > -in_port_params.format.video.xFramerate = (1 << 16) * > > > avctx->framerate.num / avctx->framerate.den; > > > > +in_port_params.format.video.xFramerate = (int64_t)(1 << 16) > * > > > avctx->framerate.num / avctx->framerate.den; > > > > > > change 1 > 1LL is more simple to solve the overflow. > > > > Great, thank you for the tip! Updated my local patch accordingly. > > This remark looks weird: using long long directly is almost never > correct code. > > And in this particular case, av_rescale_q() seems the correct choice. > The OMX spec requires xFramerate in Q16 format, which is basically (framerate<<16) I'm not sure how I would use av_rescale_q to achieve this. > > Regards, > > -- > Nicolas George > ___ > 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] avdevice/decklink: adjust for timecode lag
On 22-08-2019 01:10 AM, Marton Balint wrote: On Tue, 20 Aug 2019, Devin Heitmueller wrote: A couple of follow-up Qs: Is auto-detection available for all Decklink devices? No, but AFAIK it is for all devices which support SDI. Generally it's the older analog capture devices which don't support it. For those for which it is available, are there any edge cases in which it sets inaccurate mode? I don't trust the existing detection code enough to use it in production. It often fails to detect and thus ffmpeg will exit at startup. Can this be fixed by simply increasing the timeout from 1 sec to 2 seconds? Also, there are cases where it will misdetect 1080i59 as 1080p30 depending on the card. It's been on my TODO list for a while to make that code more robust (I believe I know what most of the issues are), but it hasn't been critical for any of my use cases. Hmm, interesting... When you say the issue is card-dependant, does this mean card _model_ dependant or that the issue can affect one card and not the other with of the same model/fw? If an user can't or won't use format auto detection, then there is no way to reliably obtain the correct timecode without this patch or some similar hack. Maybe the offset-related ops could be guarded by a check for auto detection, even though the patch won't hurt even if it was used in that case. Gyan ___ 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 3/3] dnn: export operand info in python script and load in c code
Em qui, 29 de ago de 2019 às 02:42, Guo, Yejun escreveu:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Pedro Arthur
> > Sent: Tuesday, August 27, 2019 10:46 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] dnn: export operand info in python
> > script and load in c code
> >
> > hi,
> >
> > Em ter, 20 de ago de 2019 às 05:54, Guo, Yejun
> > escreveu:
> > >
> > > Signed-off-by: Guo, Yejun
> > > ---
> > > libavfilter/dnn/dnn_backend_native.c| 49 +++---
> > > libavfilter/dnn/dnn_backend_native.h| 2 +-
> > > libavfilter/dnn_interface.h | 2 +-
> > > tools/python/convert_from_tensorflow.py | 111
> > +---
> > > 4 files changed, 142 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/libavfilter/dnn/dnn_backend_native.c
> > b/libavfilter/dnn/dnn_backend_native.c
> > > index 0ba4e44..eeae711 100644
> > > --- a/libavfilter/dnn/dnn_backend_native.c
> > > +++ b/libavfilter/dnn/dnn_backend_native.c
> > > @@ -72,7 +72,6 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > > ConvolutionalParams *conv_params;
> > > DepthToSpaceParams *depth_to_space_params;
> > > LayerPadParams *pad_params;
> > > -int32_t operand_index = 0;
> > >
> > > model = av_malloc(sizeof(DNNModel));
> > > if (!model){
> > > @@ -93,9 +92,10 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > > }
> > > model->model = (void *)network;
> > >
> > > -avio_seek(model_file_context, file_size - 4, SEEK_SET);
> > > +avio_seek(model_file_context, file_size - 8, SEEK_SET);
> > > network->layers_num = (int32_t)avio_rl32(model_file_context);
> > > -dnn_size = 4;
> > > +network->operands_num = (int32_t)avio_rl32(model_file_context);
> > > +dnn_size = 8;
> > > avio_seek(model_file_context, 0, SEEK_SET);
> > >
> > I think it is worth adding some means to assert the input file is
> > indeed a dnn file, the code as is may alloc an undefined amout of
> > memory if the file passed is malformed or corrupted.
> > Maybe adding a magic number + the file size (or something else) at the
> > beginning of the file and early skip parsing it if it does not match?
> > however it may require two passes to generate the file which goes
> > against your previous patch.
> >
> > Otherwise I can push it as is, as this behavior was already there
> > before the patch.
>
> good point, how about add "FFMPEGDNNNATIVE" + version_number at the beginning
> of the file,
> or we can use another magic number instead of "FFMPEGDNNNATIVE". Once we
> change the model file
> format, the version_number should be increased. I can send a new patch after
> this patch set is pushed.
>
I was thinking of using a single dword but anything will do.
Patch pushed, thanks!
> I think it doesn't matter to put the info at the beginning or at the end of
> the file, avio_seek
> does not alloc memory. And the layers_num and operands_num take similar
> effect of file_size.
>
> >
> > > network->layers = av_mallocz(network->layers_num * sizeof(Layer));
> > > @@ -105,11 +105,6 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > > return NULL;
> > > }
> ___
> 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 V2 1/3] dnn: introduce dnn operand (in c code) to hold operand infos within network
Em qui, 29 de ago de 2019 às 02:57, Guo, Yejun escreveu:
>
> the info can be saved in dnn operand object without regenerating again and
> again,
> and it is also needed for layer split/merge, and for memory reuse.
>
> to make things step by step, this patch just focuses on c code,
> the change within python script will be added later.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn/dnn_backend_native.c | 226
> -
> libavfilter/dnn/dnn_backend_native.h | 54 +-
> libavfilter/dnn/dnn_backend_native_layer_pad.c | 24 ++-
> libavfilter/dnn/dnn_backend_native_layer_pad.h | 4 +-
> tests/dnn/Makefile | 2 +-
> tests/dnn/dnn-layer-pad-test.c | 60 +--
> 6 files changed, 236 insertions(+), 134 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index d52abc6..daa4f50 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -30,77 +30,30 @@
> static DNNReturnType set_input_output_native(void *model, DNNInputData
> *input, const char *input_name, const char **output_names, uint32_t nb_output)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> -InputParams *input_params;
> -ConvolutionalParams *conv_params;
> -DepthToSpaceParams *depth_to_space_params;
> -LayerPadParams *pad_params;
> -int cur_width, cur_height, cur_channels;
> -int32_t layer;
>
> -if (network->layers_num <= 0 || network->layers[0].type != INPUT){
> +if (network->layers_num <= 0 || network->operands_num <= 0)
> return DNN_ERROR;
> -}
> -else{
> -input_params = (InputParams *)network->layers[0].params;
> -input_params->width = cur_width = input->width;
> -input_params->height = cur_height = input->height;
> -input_params->channels = cur_channels = input->channels;
> -if (input->data){
> -av_freep(>data);
> -}
> -av_assert0(input->dt == DNN_FLOAT);
> -network->layers[0].output = input->data = av_malloc(cur_height *
> cur_width * cur_channels * sizeof(float));
> -if (!network->layers[0].output){
> -return DNN_ERROR;
> -}
> -}
> -
> -for (layer = 1; layer < network->layers_num; ++layer){
> -switch (network->layers[layer].type){
> -case CONV:
> -conv_params = (ConvolutionalParams
> *)network->layers[layer].params;
> -if (conv_params->input_num != cur_channels){
> -return DNN_ERROR;
> -}
> -cur_channels = conv_params->output_num;
> -
> -if (conv_params->padding_method == VALID) {
> -int pad_size = (conv_params->kernel_size - 1) *
> conv_params->dilation;
> -cur_height -= pad_size;
> -cur_width -= pad_size;
> -}
> -break;
> -case DEPTH_TO_SPACE:
> -depth_to_space_params = (DepthToSpaceParams
> *)network->layers[layer].params;
> -if (cur_channels % (depth_to_space_params->block_size *
> depth_to_space_params->block_size) != 0){
> -return DNN_ERROR;
> -}
> -cur_channels = cur_channels / (depth_to_space_params->block_size
> * depth_to_space_params->block_size);
> -cur_height *= depth_to_space_params->block_size;
> -cur_width *= depth_to_space_params->block_size;
> -break;
> -case MIRROR_PAD:
> -pad_params = (LayerPadParams *)network->layers[layer].params;
> -cur_height = cur_height + pad_params->paddings[1][0] +
> pad_params->paddings[1][1];
> -cur_width = cur_width + pad_params->paddings[2][0] +
> pad_params->paddings[2][1];
> -cur_channels = cur_channels + pad_params->paddings[3][0] +
> pad_params->paddings[3][1];
> -break;
> -default:
> -return DNN_ERROR;
> -}
> -if (network->layers[layer].output){
> -av_freep(>layers[layer].output);
> -}
> -
> -if (cur_height <= 0 || cur_width <= 0)
> -return DNN_ERROR;
>
> -network->layers[layer].output = av_malloc(cur_height * cur_width *
> cur_channels * sizeof(float));
> -if (!network->layers[layer].output){
> -return DNN_ERROR;
> -}
> -}
> +av_assert0(input->dt == DNN_FLOAT);
> +
> +/**
> + * as the first step, suppose network->operands[0] is the input operand.
> + */
> +network->operands[0].dims[0] = 1;
> +network->operands[0].dims[1] = input->height;
> +network->operands[0].dims[2] = input->width;
> +network->operands[0].dims[3] = input->channels;
> +network->operands[0].type = DOT_INPUT;
> +network->operands[0].data_type = DNN_FLOAT;
> +network->operands[0].isNHWC = 1;
> +
> +av_freep(>operands[0].data);
> +
Re: [FFmpeg-devel] [PATCH V2 2/3] dnn: change .model file format to put layer number at the end of file
Em qui, 29 de ago de 2019 às 02:58, Guo, Yejun escreveu:
>
> currently, the layer number is at the beginning of the .model file,
> so we have to scan twice in python script, the first scan to get the
> layer number. Only one scan needed after put the layer number at the
> end of .model file.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn/dnn_backend_native.c| 2 ++
> tools/python/convert_from_tensorflow.py | 12 +---
> 2 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index daa4f50..5d39353 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -93,8 +93,10 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
> }
> model->model = (void *)network;
>
> +avio_seek(model_file_context, file_size - 4, SEEK_SET);
> network->layers_num = (int32_t)avio_rl32(model_file_context);
> dnn_size = 4;
> +avio_seek(model_file_context, 0, SEEK_SET);
>
> network->layers = av_mallocz(network->layers_num * sizeof(Layer));
> if (!network->layers){
> diff --git a/tools/python/convert_from_tensorflow.py
> b/tools/python/convert_from_tensorflow.py
> index 34454b8..cbc76a9 100644
> --- a/tools/python/convert_from_tensorflow.py
> +++ b/tools/python/convert_from_tensorflow.py
> @@ -129,15 +129,6 @@ class TFConverter:
> self.converted_nodes.add(node.name)
>
>
> -def generate_layer_number(self):
> -# in current hard code implementation, the layer number is the first
> data written to the native model file
> -# it is not easy to know it at the beginning time in the general
> converter, so first do a dry run for compatibility
> -# will be refined later.
> -with open('/tmp/tmp.model', 'wb') as f:
> -self.dump_layers_to_file(f)
> -self.converted_nodes.clear()
> -
> -
> def dump_layers_to_file(self, f):
> for node in self.nodes:
> if node.name in self.converted_nodes:
> @@ -157,10 +148,9 @@ class TFConverter:
>
>
> def dump_to_file(self):
> -self.generate_layer_number()
> with open(self.outfile, 'wb') as f:
> -np.array([self.layer_number], dtype=np.uint32).tofile(f)
> self.dump_layers_to_file(f)
> +np.array([self.layer_number], dtype=np.uint32).tofile(f)
>
>
> def generate_name_node_dict(self):
> --
> 2.7.4
Pushed, thanks!
>
> ___
> 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 2/2] avcodec/arbc: Use ff_reget_buffer()
On 8/29/2019 4:33 PM, James Almer wrote:
> On 8/29/2019 4:04 PM, Michael Niedermayer wrote:
>> Fixes: Timeout (20sec -> 0.5sec)
>> Fixes:
>> 16404/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARBC_fuzzer-5660216355454976
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/arbc.c | 21 +++--
>> 1 file changed, 7 insertions(+), 14 deletions(-)
>>
>> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
>> index 06970f140b..f0de50e243 100644
>> --- a/libavcodec/arbc.c
>> +++ b/libavcodec/arbc.c
>> @@ -136,15 +136,9 @@ static int decode_frame(AVCodecContext *avctx, void
>> *data,
>> if (7 * nb_segments > bytestream2_get_bytes_left(>gb))
>> return AVERROR_INVALIDDATA;
>>
>> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
>> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
>> return ret;
>>
>> -if (s->prev_frame->data[0]) {
>> -ret = av_frame_copy(frame, s->prev_frame);
>> -if (ret < 0)
>> -return ret;
>> -}
>> -
>> for (int i = 0; i < nb_segments; i++) {
>> int resolution_flag;
>> int fill;
>> @@ -161,19 +155,18 @@ static int decode_frame(AVCodecContext *avctx, void
>> *data,
>> resolution_flag = bytestream2_get_byte(>gb);
>>
>> if (resolution_flag & 0x10)
>> -prev_pixels -= fill_tileX(avctx, 1024, 1024, fill, frame);
>> +prev_pixels -= fill_tileX(avctx, 1024, 1024, fill,
>> s->prev_frame);
>> if (resolution_flag & 0x08)
>> -prev_pixels -= fill_tileX(avctx, 256, 256, fill, frame);
>> +prev_pixels -= fill_tileX(avctx, 256, 256, fill, s->prev_frame);
>> if (resolution_flag & 0x04)
>> -prev_pixels -= fill_tileX(avctx, 64, 64, fill, frame);
>> +prev_pixels -= fill_tileX(avctx, 64, 64, fill, s->prev_frame);
>> if (resolution_flag & 0x02)
>> -prev_pixels -= fill_tileX(avctx, 16, 16, fill, frame);
>> +prev_pixels -= fill_tileX(avctx, 16, 16, fill, s->prev_frame);
>> if (resolution_flag & 0x01)
>> -prev_pixels -= fill_tile4(avctx, fill, frame);
>> +prev_pixels -= fill_tile4(avctx, fill, s->prev_frame);
>> }
>>
>> -av_frame_unref(s->prev_frame);
>> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
>> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
>> return ret;
>>
>> frame->pict_type = prev_pixels <= 0 ? AV_PICTURE_TYPE_I :
>> AV_PICTURE_TYPE_P;
>
> You could while at it revert 8b10f09fd53, then implement d70bbdc5fa for
> this decoder as part of this patch.
Or maybe we should do what you suggested and simplify things by either
adding a new reget function, or changing the current one to take a new
argument to request a writable buffer.
The latter sounds better, IMO, and I can look into implementing 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] avcodec/wcmv: use ff_reget_buffer()
On 8/30/2019 3:45 AM, Paul B Mahol wrote:
> Here is sample: https://0x0.st/z49v.avi
Thanks. Can you make a fate test for it?
>
> On 8/30/19, Paul B Mahol wrote:
>> It still exits early when no blocks are encoded.
>>
>> On 8/30/19, James Almer wrote:
>>> Signed-off-by: James Almer
>>> ---
>>> Untested. There doesn't seem to be a fate test, and i have no samples
>>> at hand.
>>>
>>> libavcodec/wcmv.c | 23 +--
>>> 1 file changed, 9 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
>>> index 0d60b9fe1f..68142b45fd 100644
>>> --- a/libavcodec/wcmv.c
>>> +++ b/libavcodec/wcmv.c
>>> @@ -60,7 +60,7 @@ static int decode_frame(AVCodecContext *avctx,
>>> if (!blocks)
>>> return avpkt->size;
>>>
>>> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
>>> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
>>> return ret;
>>>
>>> if (blocks > 5) {
>>> @@ -157,13 +157,9 @@ static int decode_frame(AVCodecContext *avctx,
>>> if (bytestream2_get_bytes_left() < 8LL * blocks)
>>> return AVERROR_INVALIDDATA;
>>>
>>> -if (s->prev_frame->data[0]) {
>>> -ret = av_frame_copy(frame, s->prev_frame);
>>> -if (ret < 0)
>>> -return ret;
>>> -} else {
>>> -ptrdiff_t linesize[4] = { frame->linesize[0], 0, 0, 0 };
>>> -av_image_fill_black(frame->data, linesize, avctx->pix_fmt, 0,
>>> +if (!avctx->frame_number) {
>>> +ptrdiff_t linesize[4] = { s->prev_frame->linesize[0], 0, 0, 0 };
>>> +av_image_fill_black(s->prev_frame->data, linesize,
>>> avctx->pix_fmt,
>>> 0,
>>> avctx->width, avctx->height);
>>> }
>>>
>>> @@ -184,7 +180,7 @@ static int decode_frame(AVCodecContext *avctx,
>>> if (w > avctx->width || h > avctx->height)
>>> return AVERROR_INVALIDDATA;
>>>
>>> -dst = frame->data[0] + (avctx->height - y - 1) *
>>> frame->linesize[0]
>>> + x * bpp;
>>> +dst = s->prev_frame->data[0] + (avctx->height - y - 1) *
>>> s->prev_frame->linesize[0] + x * bpp;
>>> for (int i = 0; i < h; i++) {
>>> s->zstream.next_out = dst;
>>> s->zstream.avail_out = w * bpp;
>>> @@ -196,15 +192,14 @@ static int decode_frame(AVCodecContext *avctx,
>>> return AVERROR_INVALIDDATA;
>>> }
>>>
>>> -dst -= frame->linesize[0];
>>> +dst -= s->prev_frame->linesize[0];
>>> }
>>> }
>>>
>>> -frame->key_frame = intra;
>>> -frame->pict_type = intra ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
>>> +s->prev_frame->key_frame = intra;
>>> +s->prev_frame->pict_type = intra ? AV_PICTURE_TYPE_I :
>>> AV_PICTURE_TYPE_P;
>>>
>>> -av_frame_unref(s->prev_frame);
>>> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
>>> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
>>> return ret;
>>>
>>> *got_frame = 1;
>>> --
>>> 2.22.0
>>>
>>> ___
>>> 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 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] avcodec/wcmv: use ff_reget_buffer()
On 8/30/2019 3:26 AM, Paul B Mahol wrote:
> It still exits early when no blocks are encoded.
That's unrelated to this patch. I can look into reverting 976dae8b32 and
preventing data copying when the frame doesn't change in a separate
patchset.
>
> On 8/30/19, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Untested. There doesn't seem to be a fate test, and i have no samples
>> at hand.
>>
>> libavcodec/wcmv.c | 23 +--
>> 1 file changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
>> index 0d60b9fe1f..68142b45fd 100644
>> --- a/libavcodec/wcmv.c
>> +++ b/libavcodec/wcmv.c
>> @@ -60,7 +60,7 @@ static int decode_frame(AVCodecContext *avctx,
>> if (!blocks)
>> return avpkt->size;
>>
>> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
>> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
>> return ret;
>>
>> if (blocks > 5) {
>> @@ -157,13 +157,9 @@ static int decode_frame(AVCodecContext *avctx,
>> if (bytestream2_get_bytes_left() < 8LL * blocks)
>> return AVERROR_INVALIDDATA;
>>
>> -if (s->prev_frame->data[0]) {
>> -ret = av_frame_copy(frame, s->prev_frame);
>> -if (ret < 0)
>> -return ret;
>> -} else {
>> -ptrdiff_t linesize[4] = { frame->linesize[0], 0, 0, 0 };
>> -av_image_fill_black(frame->data, linesize, avctx->pix_fmt, 0,
>> +if (!avctx->frame_number) {
>> +ptrdiff_t linesize[4] = { s->prev_frame->linesize[0], 0, 0, 0 };
>> +av_image_fill_black(s->prev_frame->data, linesize, avctx->pix_fmt,
>> 0,
>> avctx->width, avctx->height);
>> }
>>
>> @@ -184,7 +180,7 @@ static int decode_frame(AVCodecContext *avctx,
>> if (w > avctx->width || h > avctx->height)
>> return AVERROR_INVALIDDATA;
>>
>> -dst = frame->data[0] + (avctx->height - y - 1) * frame->linesize[0]
>> + x * bpp;
>> +dst = s->prev_frame->data[0] + (avctx->height - y - 1) *
>> s->prev_frame->linesize[0] + x * bpp;
>> for (int i = 0; i < h; i++) {
>> s->zstream.next_out = dst;
>> s->zstream.avail_out = w * bpp;
>> @@ -196,15 +192,14 @@ static int decode_frame(AVCodecContext *avctx,
>> return AVERROR_INVALIDDATA;
>> }
>>
>> -dst -= frame->linesize[0];
>> +dst -= s->prev_frame->linesize[0];
>> }
>> }
>>
>> -frame->key_frame = intra;
>> -frame->pict_type = intra ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
>> +s->prev_frame->key_frame = intra;
>> +s->prev_frame->pict_type = intra ? AV_PICTURE_TYPE_I :
>> AV_PICTURE_TYPE_P;
>>
>> -av_frame_unref(s->prev_frame);
>> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
>> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
>> return ret;
>>
>> *got_frame = 1;
>> --
>> 2.22.0
>>
>> ___
>> 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 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] ffmpeg version differences
Mehta, Krishnakant wrote: >Kindly let us know what are major differences in ffmpeg ver 4.2 >and 2.8.11 Please check the informations available on the homepage: https://ffmpeg.org/ You should post such questions on the FFmpeg user mailing list, not the developer's one. Hope this helps! Reto ___ 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] ffmpeg version differences
Hi, We are using 'ffmpeg version 2.8.11' library for one of our medical application running on Cent OS (linux) to convert audio/video streams. We want to migrate to latest ffmpeg version 4.2 on RHEL8 linux platform. Kindly let us know what are major differences in ffmpeg ver 4.2 and 2.8.11 Thanks in advance, Regards, Krishnakant Mehta CapGemini This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ 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 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, August 9, 2019 19:47
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Hendrik Leppkes
> > Sent: Friday, August 9, 2019 17:40
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx for vp9 without destroy va_context
> >
> > On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie wrote:
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > > Of Hendrik Leppkes
> > > > Sent: Tuesday, August 6, 2019 16:27
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > recreate
> > > > hw_frames_ctx for vp9 without destroy va_context
> > > >
> > > > On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu wrote:
> > > > >
> > > > > VP9 allows resolution changes per frame. Currently in VAAPI,
> resolution
> > > > > changes leads to va context destroy and reinit. This will cause
> > > > > reference frame surface lost and produce garbage.
> > > > >
> > > > > Though refs surface id could be passed to media driver and found in
> > > > > RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> > > > > new created VaContext could only got an empty RefList.
> > > > >
> > > > > As libva allows re-create surface separately without changing the
> > > > > context, this issue could be handled by only recreating
> hw_frames_ctx.
> > > > >
> > > > > Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > > > > hw_frame_ctx when dynamic resolution changing happens.
> > > > >
> > > > > Could be verified by:
> > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > > > ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
> > > > > vaapi.yuv
> > > > >
> > > > > Signed-off-by: Linjie Fu
> > > > > ---
> > > > > libavcodec/decode.c| 10 +-
> > > > > libavcodec/internal.h | 1 +
> > > > > libavcodec/pthread_frame.c | 2 ++
> > > > > libavcodec/vaapi_decode.c | 40 ++-
> --
> > -
> > > > --
> > > > > libavcodec/vaapi_vp9.c | 4
> > > > > 5 files changed, 34 insertions(+), 23 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > > > index 0863b82..7b15fa5 100644
> > > > > --- a/libavcodec/decode.c
> > > > > +++ b/libavcodec/decode.c
> > > > > @@ -1254,7 +1254,6 @@ int
> > > > ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > > > >
> > > > > frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
> >data;
> > > > >
> > > > > -
> > > > > if (frames_ctx->initial_pool_size) {
> > > > > // We guarantee 4 base work surfaces. The function above
> > guarantees
> > > > 1
> > > > > // (the absolute minimum), so add the missing count.
> > > >
> > > > Unrelated whitespace change
> > >
> > > There is a redundant whitespace here, so I removed it within this patch.
> > >
> > > > > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext
> > *avctx,
> > > > > return AVERROR_PATCHWELCOME;
> > > > > }
> > > > >
> > > > > -if (hwaccel->priv_data_size) {
> > > > > +if (hwaccel->priv_data_size && !avctx->internal-
> > >hwaccel_priv_data) {
> > > > > avctx->internal->hwaccel_priv_data =
> > > > > av_mallocz(hwaccel->priv_data_size);
> > > > > if (!avctx->internal->hwaccel_priv_data)
> > > > > @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext *avctx,
> > > > const enum AVPixelFormat *fmt)
> > > > > memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> > > > >
> > > > > for (;;) {
> > > > > -// Remove the previous hwaccel, if there was one.
> > > > > -hwaccel_uninit(avctx);
> > > > > -
> > > > > +// Remove the previous hwaccel, if there was one,
> > > > > +// and no need for keeping.
> > > > > +if (!avctx->internal->hwaccel_priv_data_keeping)
> > > > > +hwaccel_uninit(avctx);
> > > > > user_choice = avctx->get_format(avctx, choices);
> > > > > if (user_choice == AV_PIX_FMT_NONE) {
> > > > > // Explicitly chose nothing, give up.
> > > >
> > > > There could be a dozen special cases how stuff can go wrong here.
> What
> > > > if get_format actually returns a different format then the one
> > > > currently in use? Or a software format?
> > > > Just removing this alone is not safe.
> > >
> > > Didn't quite get your point.
> > > IMHO, avctx->internal->hwaccel_priv_data_keeping won't be
Re: [FFmpeg-devel] [PATCH V1] avutil/file: always set *size to zero if *bufptr is NULL
On 8/30/19, myp...@gmail.com wrote: > On Thu, Aug 29, 2019 at 9:07 PM Michael Niedermayer > wrote: >> >> On Thu, Aug 29, 2019 at 01:04:43AM +0800, Jun Zhao wrote: >> > From: Jun Zhao >> > >> > Always set *size to zero if *bufptr is NULL, it's more make sence. >> > >> > fix #8095 >> > >> > Signed-off-by: Jun Zhao >> > --- >> > libavutil/file.c |7 ++- >> > 1 files changed, 6 insertions(+), 1 deletions(-) >> >> probably ok >> >> maybe the av_file_unmap and av_file_map changes could be in seperate >> patches >> >> thx >> >> [...] > Thanks, will split the patch Please refrain from applying patches that have typos in logs. ___ 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] avcodec/wcmv: use ff_reget_buffer()
Here is sample: https://0x0.st/z49v.avi
On 8/30/19, Paul B Mahol wrote:
> It still exits early when no blocks are encoded.
>
> On 8/30/19, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Untested. There doesn't seem to be a fate test, and i have no samples
>> at hand.
>>
>> libavcodec/wcmv.c | 23 +--
>> 1 file changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
>> index 0d60b9fe1f..68142b45fd 100644
>> --- a/libavcodec/wcmv.c
>> +++ b/libavcodec/wcmv.c
>> @@ -60,7 +60,7 @@ static int decode_frame(AVCodecContext *avctx,
>> if (!blocks)
>> return avpkt->size;
>>
>> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
>> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
>> return ret;
>>
>> if (blocks > 5) {
>> @@ -157,13 +157,9 @@ static int decode_frame(AVCodecContext *avctx,
>> if (bytestream2_get_bytes_left() < 8LL * blocks)
>> return AVERROR_INVALIDDATA;
>>
>> -if (s->prev_frame->data[0]) {
>> -ret = av_frame_copy(frame, s->prev_frame);
>> -if (ret < 0)
>> -return ret;
>> -} else {
>> -ptrdiff_t linesize[4] = { frame->linesize[0], 0, 0, 0 };
>> -av_image_fill_black(frame->data, linesize, avctx->pix_fmt, 0,
>> +if (!avctx->frame_number) {
>> +ptrdiff_t linesize[4] = { s->prev_frame->linesize[0], 0, 0, 0 };
>> +av_image_fill_black(s->prev_frame->data, linesize,
>> avctx->pix_fmt,
>> 0,
>> avctx->width, avctx->height);
>> }
>>
>> @@ -184,7 +180,7 @@ static int decode_frame(AVCodecContext *avctx,
>> if (w > avctx->width || h > avctx->height)
>> return AVERROR_INVALIDDATA;
>>
>> -dst = frame->data[0] + (avctx->height - y - 1) *
>> frame->linesize[0]
>> + x * bpp;
>> +dst = s->prev_frame->data[0] + (avctx->height - y - 1) *
>> s->prev_frame->linesize[0] + x * bpp;
>> for (int i = 0; i < h; i++) {
>> s->zstream.next_out = dst;
>> s->zstream.avail_out = w * bpp;
>> @@ -196,15 +192,14 @@ static int decode_frame(AVCodecContext *avctx,
>> return AVERROR_INVALIDDATA;
>> }
>>
>> -dst -= frame->linesize[0];
>> +dst -= s->prev_frame->linesize[0];
>> }
>> }
>>
>> -frame->key_frame = intra;
>> -frame->pict_type = intra ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
>> +s->prev_frame->key_frame = intra;
>> +s->prev_frame->pict_type = intra ? AV_PICTURE_TYPE_I :
>> AV_PICTURE_TYPE_P;
>>
>> -av_frame_unref(s->prev_frame);
>> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
>> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
>> return ret;
>>
>> *got_frame = 1;
>> --
>> 2.22.0
>>
>> ___
>> 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 v2] avformat/mxfenc: fix warning: unused function 'klv_ber_length' [-Wunused-function]
tor 2019-08-29 klockan 16:44 +0800 skrev lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/mxfenc.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 8b3d599a6f..aa23ee3947 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -553,15 +553,14 @@ static int klv_ber_length(uint64_t len)
> static int klv_encode_ber_length(AVIOContext *pb, uint64_t len)
> {
> // Determine the best BER size
> -int size;
> -if (len < 128) {
> +int size = klv_ber_length(len);
> +if (size == 1) {
> //short form
> avio_w8(pb, len);
> return 1;
> }
>
> -size = (av_log2(len) >> 3) + 1;
> -
> +size --;
Looks good to me. I'll push some time this weekend unless someone
objects
/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] avcodec/wcmv: use ff_reget_buffer()
It still exits early when no blocks are encoded.
On 8/30/19, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Untested. There doesn't seem to be a fate test, and i have no samples
> at hand.
>
> libavcodec/wcmv.c | 23 +--
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
> index 0d60b9fe1f..68142b45fd 100644
> --- a/libavcodec/wcmv.c
> +++ b/libavcodec/wcmv.c
> @@ -60,7 +60,7 @@ static int decode_frame(AVCodecContext *avctx,
> if (!blocks)
> return avpkt->size;
>
> -if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
> +if ((ret = ff_reget_buffer(avctx, s->prev_frame)) < 0)
> return ret;
>
> if (blocks > 5) {
> @@ -157,13 +157,9 @@ static int decode_frame(AVCodecContext *avctx,
> if (bytestream2_get_bytes_left() < 8LL * blocks)
> return AVERROR_INVALIDDATA;
>
> -if (s->prev_frame->data[0]) {
> -ret = av_frame_copy(frame, s->prev_frame);
> -if (ret < 0)
> -return ret;
> -} else {
> -ptrdiff_t linesize[4] = { frame->linesize[0], 0, 0, 0 };
> -av_image_fill_black(frame->data, linesize, avctx->pix_fmt, 0,
> +if (!avctx->frame_number) {
> +ptrdiff_t linesize[4] = { s->prev_frame->linesize[0], 0, 0, 0 };
> +av_image_fill_black(s->prev_frame->data, linesize, avctx->pix_fmt,
> 0,
> avctx->width, avctx->height);
> }
>
> @@ -184,7 +180,7 @@ static int decode_frame(AVCodecContext *avctx,
> if (w > avctx->width || h > avctx->height)
> return AVERROR_INVALIDDATA;
>
> -dst = frame->data[0] + (avctx->height - y - 1) * frame->linesize[0]
> + x * bpp;
> +dst = s->prev_frame->data[0] + (avctx->height - y - 1) *
> s->prev_frame->linesize[0] + x * bpp;
> for (int i = 0; i < h; i++) {
> s->zstream.next_out = dst;
> s->zstream.avail_out = w * bpp;
> @@ -196,15 +192,14 @@ static int decode_frame(AVCodecContext *avctx,
> return AVERROR_INVALIDDATA;
> }
>
> -dst -= frame->linesize[0];
> +dst -= s->prev_frame->linesize[0];
> }
> }
>
> -frame->key_frame = intra;
> -frame->pict_type = intra ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
> +s->prev_frame->key_frame = intra;
> +s->prev_frame->pict_type = intra ? AV_PICTURE_TYPE_I :
> AV_PICTURE_TYPE_P;
>
> -av_frame_unref(s->prev_frame);
> -if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
> +if ((ret = av_frame_ref(frame, s->prev_frame)) < 0)
> return ret;
>
> *got_frame = 1;
> --
> 2.22.0
>
> ___
> 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".
