Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file
On Thu, 6 Dec 2018 21:47:18 +0100 Michael Niedermayer wrote: > On Tue, Dec 04, 2018 at 02:27:22PM +0100, Michael Niedermayer wrote: > > > > > On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote: > > > > > > Also ping on "swscale/output: VSX-optimize > > > > > > nbps yuv2plane1". > > > > > > > > > > This IIUC has not been tested on BE yet > > > > > > > > > > my ppc emulation setup is a bit broken and my ppc hw ive not tried > > > > > using > > > > > since years and it was not in good shape last i used it. > > > > > So i cant just quickly test this ... > > these are more suggestions than i expected :) > > but i just got cross build working again and i also just eliminated a > > mysterious ld.so related segfault > > ATM iam re rerunning fate with a freshly rebuilt qemu > > (the past one had an issue with altivec) > > i have cross build with ppc and qemu partly working > but it appears gcc or something is just buggy Hi, Carl Eugen Hoyos reported that it builds fine on BE, the guards being in correct place not to affect BE. How are things on your side? - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom
On 12/11/18, 9:07 AM, "Ronak" wrote: > >> On Dec 6, 2018, at 4:47 AM, Tobias Rapp wrote: >> >> On 06.12.2018 08:28, Karthick J wrote: >>> --- >>> [...] >> >> Looks OK now, no more comments from my side. > >I actually was going to submit a patch that would remove sidx atoms being >written out for any non-video content. > >Is that now unnecessary because of your changes here? > >So adding -movflags skip_sidx for our audio only fmp4 files would allow us to >skip the sidx atoms? Yes > >Ronak > >> >> Regards, >> Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/dashenc: Used the movenc option skip_sidx instead of global_sidx
On 12/5/18, 11:49 AM, "Karthick J" wrote: > >Anyways the intended behaviour was to disable SIDX atom. >--- > libavformat/dashenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > [...] Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom
On 12/6/18, 3:18 PM, "Tobias Rapp" wrote: > >On 06.12.2018 08:28, Karthick J wrote: >> --- >> doc/muxers.texi | 4 >> libavformat/movenc.c | 12 ++-- >> libavformat/movenc.h | 1 + >> 3 files changed, 15 insertions(+), 2 deletions(-) >> >> [...] > >Looks OK now, no more comments from my side. Pushed. Regards, Karthick > >Regards, >Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom
> On Dec 6, 2018, at 4:47 AM, Tobias Rapp wrote: > > On 06.12.2018 08:28, Karthick J wrote: >> --- >> doc/muxers.texi | 4 >> libavformat/movenc.c | 12 ++-- >> libavformat/movenc.h | 1 + >> 3 files changed, 15 insertions(+), 2 deletions(-) >> [...] > > Looks OK now, no more comments from my side. I actually was going to submit a patch that would remove sidx atoms being written out for any non-video content. Is that now unnecessary because of your changes here? So adding -movflags skip_sidx for our audio only fmp4 files would allow us to skip the sidx atoms? Ronak > > Regards, > Tobias > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vividas demuxer
On 12/10/2018 9:05 AM, Paul B Mahol wrote:
> +static uint32_t get_v(uint8_t *p)
> +{
> +uint32_t v = 0;
> +
> +do {
> +v <<= 7;
> +v += *p & 0x7f;
> +} while (*p++ & 0x80);
> +
> +return v;
> +}
More than four or so iterations will overflow uint32_t.
> +AVInputFormat ff_vividas_demuxer = {
> +.name = "vividas",
> +.long_name = NULL_IF_CONFIG_SMALL("Vividas VIV"),
> +.priv_data_size = sizeof(VividasDemuxContext),
> +.read_probe = viv_probe,
> +.read_header= viv_read_header,
> +.read_packet= viv_read_packet,
> +.read_close = viv_read_close,
> +.read_seek = viv_read_seek,
> +.flags = AVFMT_GLOBALHEADER,
Afaics, this is a muxer only flag.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
2018-12-10 23:41 GMT+01:00, Mark Thompson :
> On 09/12/2018 14:21, Mark Thompson wrote:
>> On 09/12/2018 13:54, Paul B Mahol wrote:
>>> On 12/9/18, Mark Thompson wrote:
On 09/12/2018 08:52, Paul B Mahol wrote:
> On 12/7/18, Paul B Mahol wrote:
>> On 12/7/18, Michael Niedermayer wrote:
>>> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
>>> This recovers state with #7374 linked sample.
>>>
>>> Work funded by Open Broadcast Systems.
>>>
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> libavcodec/h264_refs.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
>>> index eaf965e43d..5645a203a7 100644
>>> --- a/libavcodec/h264_refs.c
>>> +++ b/libavcodec/h264_refs.c
>>> @@ -718,6 +718,7 @@ int
>>> ff_h264_execute_ref_pic_marking(H264Context
>>> *h)
>>> }
>>> break;
>>> case MMCO_RESET:
>>> +default:
>>> while (h->short_ref_count) {
>>> remove_short(h, h->short_ref[0]->frame_num, 0);
>>> }
>>> @@ -730,7 +731,6 @@ int
>>> ff_h264_execute_ref_pic_marking(H264Context
>>> *h)
>>> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>>> h->last_pocs[j] = INT_MIN;
>>> break;
>>> -default: assert(0);
>>> }
>>> }
>>
>> mmco[i].opcode should not be invalid, its checked around the point
>> where
>> this
>> array is filled.
>> unless there is something iam missing
>
> Yes, you are missing big time.
> If you think by "checked" about those nice asserts they are not
> enabled
> at
> all.
>
There is check for invalid opcode, but stored invalid opcode is not
changed.
>>>
>>> Theres no question that we end with a invalid value in the struct,
>>> but
>>> that
>>> is not intended to be in there. You can see that this is not intended
>>> by
>>> simply looking at the variable that holds the number of entries, it
>>> is
>>> not written at all in this case.
>>>
>>> So for example if this code stores 5 correct looking mmcos and the
>>> 6th
>>> is
>>> invalid, 6 are in the array but the number of entries is just left
>>> where
>>> it
>>> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the
>>> invalid
>>> value
>>> later doesnt feel ideal.
>>
>> Nope, mmco state is left in inconsistent state, and my patch fix it.
>> As
>> you
>> provided nothing valuable to consider as alternative I will apply it.
>>
>
> What about converting any invalid mmco opcode to mmco reset and
> updating mmco size too?
> Currently mmco size is left in previous state.
Don't invent a new RESET (= 5) operation - that type is special and its
presence implies other constraints which we probably don't want to think
about here (around frame_num in particular).
I think END / truncating the list would be best option?
>>>
>>> Nope, that would still put it into bad state. With your approach decoder
>>> does
>>> not recover from artifacts. Try sample from bug report #7374.
>>
>> Adding a spurious reset here throws away all previous reference frames,
>> which will break the stream where it wouldn't otherwise be if the
>> corrupted frame would have been bypassed for referencing. For example, in
>> real-time cases with feedback a stream which has encountered errors can be
>> recovered without an intra frame by referring to an older frame which
>> still exists in the DPB.
>
> Sample: . The bad frame
> here has frame_num 24, but we already hit an error before that point and the
> feedback about that makes frame_num 25 refer to LTRF 1 such that 24 is never
> used. (From a simulator rather than a real capture, because random bit
> errors are never where you want them.)
>
> It doesn't exactly hit the original issue because the leftover MMCO count
> from the previous slice is not large enough. With:
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 5645a203a7..977b4ed12f 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -875,6 +875,7 @@ int ff_h264_decode_ref_pic_marking(H264SliceContext *sl,
> GetBitContext *gb,
> av_log(logctx, AV_LOG_ERROR,
> "illegal memory management control operation
>
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
2018-12-10 17:55 GMT+01:00, Kevin Wheatley : > I came across a similar discussion here: > > https://github.com/OpenImageIO/oiio/pull/1412 So the solution is: We don't fix it because it is broken elsewhere? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavfi/signalstats: Cast AV_RN16() output to int.
Hi! I suspect attached patch fixes a bug on some platforms, silences a warning. Please comment, Carl Eugen From cfc9e3fd1e24d108581bad096a4de987069b2c49 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Tue, 11 Dec 2018 03:12:49 +0100 Subject: [PATCH] lavfi/signalstats: Cast the return value of AV_RN16() to int. It is unsigned at least on arm, fixes the following warnings: libavfilter/vf_signalstats.c:833:21: warning: taking the absolute value of unsigned type 'unsigned int' has no effect dify += abs(yuv - AV_RN16(prev->data[0] + pw + i * 2)); --- libavfilter/vf_signalstats.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c index 298881b..2b8c0de 100644 --- a/libavfilter/vf_signalstats.c +++ b/libavfilter/vf_signalstats.c @@ -830,7 +830,7 @@ static int filter_frame16(AVFilterLink *link, AVFrame *in) masky |= yuv; histy[yuv]++; -dify += abs(yuv - AV_RN16(prev->data[0] + pw + i * 2)); +dify += abs(yuv - (int)AV_RN16(prev->data[0] + pw + i * 2)); } w += in->linesize[0]; pw += prev->linesize[0]; @@ -848,9 +848,9 @@ static int filter_frame16(AVFilterLink *link, AVFrame *in) masku |= yuvu; maskv |= yuvv; histu[yuvu]++; -difu += abs(yuvu - AV_RN16(prev->data[1] + cpw + i * 2)); +difu += abs(yuvu - (int)AV_RN16(prev->data[1] + cpw + i * 2)); histv[yuvv]++; -difv += abs(yuvv - AV_RN16(prev->data[2] + cpw + i * 2)); +difv += abs(yuvv - (int)AV_RN16(prev->data[2] + cpw + i * 2)); histsat[p_sat[i]]++; histhue[((int16_t*)p_hue)[i]]++; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vividas demuxer
On Mon, Dec 10, 2018 at 01:05:05PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/vividas.c| 708 +++
> 3 files changed, 710 insertions(+)
> create mode 100644 libavformat/vividas.c
[...]
> +}
> +
> +static int viv_read_packet(AVFormatContext *s,
> + AVPacket *pkt)
> +{
> +VividasDemuxContext *viv = s->priv_data;
> +AVIOContext *pb;
> +int64_t off;
> +
> +if (avio_feof(viv->sb_pb))
> +return AVERROR_EOF;
> +
> +if (viv->current_audio_subpacket < viv->n_audio_subpackets) {
> +AVStream *astream;
> +int size =
> viv->audio_subpackets[viv->current_audio_subpacket+1].start -
> viv->audio_subpackets[viv->current_audio_subpacket].start;
> +pb = viv->sb_pb;
> +av_get_packet(pb, pkt, size);
missing failure check
> +pkt->pos += viv->sb_offset +
> viv->sb_blocks[viv->current_sb].byte_offset;
> +
> +pkt->stream_index = 1;
> +astream = s->streams[pkt->stream_index];
> +
> +pkt->pts = av_rescale(viv->audio_sample, astream->time_base.den,
> astream->time_base.num) / astream->codecpar->sample_rate;
> +viv->audio_sample +=
> viv->audio_subpackets[viv->current_audio_subpacket].pcm_bytes / 2 /
> astream->codecpar->channels;
> +pkt->flags |= AV_PKT_FLAG_KEY;
> +viv->current_audio_subpacket++;
> +return 0;
> +}
> +
> +if (viv->current_sb_entry >= viv->n_sb_entries) {
> +if (viv->current_sb+1 >= viv->n_sb_blocks)
> +return AVERROR(EIO);
> +viv->current_sb++;
> +
> +load_sb_block(s, viv, 0);
> +viv->current_sb_entry = 0;
> +}
> +
> +pb = viv->sb_pb;
> +off = avio_tell(pb);
> +off += viv->sb_entries[viv->current_sb_entry].size;
> +
> +if (viv->sb_entries[viv->current_sb_entry].flag == 0) {
> +int i, v_size = ffio_read_varlen(pb);
> +ffio_read_varlen(pb);
> +av_get_packet(pb, pkt, v_size);
missing failure check
> +pkt->pos += viv->sb_offset +
> viv->sb_blocks[viv->current_sb].byte_offset;
> +
> +pkt->pts = viv->sb_blocks[viv->current_sb].packet_offset +
> viv->current_sb_entry;
> +pkt->flags |= (pkt->data[0]&0x80)?0:AV_PKT_FLAG_KEY;
> +pkt->stream_index = 0;
> +
> +for (i = 0; i < MAX_AUDIO_SUBPACKETS - 1; i++) {
> +int start, pcm_bytes;
> +start = ffio_read_varlen(pb);
> +pcm_bytes = ffio_read_varlen(pb);
> +
> +if (i > 0 && start == 0)
> +break;
> +
> +viv->n_audio_subpackets = i+1;
> +viv->audio_subpackets[i].start = start;
> +viv->audio_subpackets[i].pcm_bytes = pcm_bytes;
> +}
> +viv->audio_subpackets[viv->n_audio_subpackets].start = (int)(off -
> avio_tell(pb));
> +viv->current_audio_subpacket = 0;
> +//viv->n_audio_subpackets = 0;
> +//avio_seek(pb, off, SEEK_SET);
is that intended to be here ?
> +
> +} else {
> +int v_size = ffio_read_varlen(pb);
> +av_get_packet(pb, pkt, v_size);
missing error check
[...]
> +static int viv_read_seek(AVFormatContext *s, int stream_index, int64_t
> timestamp, int flags)
> +{
> +VividasDemuxContext *viv = s->priv_data;
> +int frame = 0;
> +int i;
> +
> +if (stream_index == 0)
> +frame = (int)timestamp;
> +else
> +frame = (int)timestamp * s->streams[stream_index]->time_base.den *
> s->streams[0]->time_base.num / s->streams[stream_index]->time_base.num /
> s->streams[0]->time_base.den;
timestamp is truncated which would lead to incorrect results if a timestamp
outside the int range is used
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix leak of yuv_line in TiffContext.
2018-12-11 0:52 GMT+01:00, Carl Hetherington : > Please review... I have used FFmpeg a lot but never suggested a patch > before :) Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Default to clang for Android
2018-12-10 3:13 GMT+01:00, Carl Eugen Hoyos : > 2018-12-07 3:06 GMT+01:00, Carl Eugen Hoyos : > >> I believe the Android documentation indicates that gcc will be >> removed from ndk. Attached patch changes the default to >> "clang" for --target-os=android. >> >> Now with patch. > > Any comments? I'll push this if there are no objections. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use ioctl(..., "int request" ) on Android
2018-12-10 23:47 GMT+01:00, Mark Thompson :
> On 10/12/2018 00:47, Carl Eugen Hoyos wrote:
>> 2018-12-09 18:50 GMT+01:00, Mark Thompson :
>>> On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes building with new Android toolchain, used to be a
warning.
Please comment, Carl Eugen
From d366c948af086520bfb2a4048e76f8d117690776 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 6 Dec 2018 23:34:54 +0100
Subject: [PATCH] lavd/v4l2: Use "int request" as second parameter for
ioctl()
on Android.
Fixes build with new Android toolchain.
---
libavdevice/v4l2.c |4
1 file changed, 4 insertions(+)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 10a0ff0..aa7c052 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -95,7 +95,11 @@ struct video_data {
int (*open_f)(const char *file, int oflag, ...);
int (*close_f)(int fd);
int (*dup_f)(int fd);
+#ifdef __ANDROID__
+int (*ioctl_f)(int fd, int request, ...);
+#else
int (*ioctl_f)(int fd, unsigned long int request, ...);
+#endif
ssize_t (*read_f)(int fd, void *buffer, size_t n);
void *(*mmap_f)(void *start, size_t length, int prot, int flags,
int
fd, int64_t offset);
int (*munmap_f)(void *_start, size_t length);
--
1.7.10.4
>>>
>>> LGTM on its own, but should this perhaps be "#ifndef (glibc something)"
>>> for
>>> the first case? Looking at possible V4L2-hosting libcs, only glibc has
>>> the
>>> nonstandard* "unsigned long" rather than "int" as the request argument,
>>> so I
>>> expect we're going to hit this in more cases (e.g. musl) if compilers are
>>> now complaining about it.
>>
>> Is videodev2.h a Linux header as opposed to a c-library header or am I
>> completely misunderstanding?
>
> I'm not quite sure what you're asking, so I'll try to explain all of that
> more carefully:
>
> videodev2.h is a Linux header, but it only defines the types and values to
> call ioctl() with so is mostly orthogonal to this discussion.
I had not thought about this, you are of course right.
> ioctl() itself is a C library call, but since V4L2 is almost always used with
> glibc
> the prototype here has ended up matching that rather than the standard POSIX
> one.
>
> Android follows the POSIX prototype, so your patch is correct. However, so
> do other standard C libraries such as Musl, and therefore I expect we will
> hit the same problem with other C libraries in the not-too-distant future.
> My suggestion, then, is to guard the change with "#ifdef __GLIBC__
> #else #endif", rather than fixing it
> only for Android as you have here.
Applied with your suggestion, thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix leak of yuv_line in TiffContext.
Please review... I have used FFmpeg a lot but never suggested a patch before :) Signed-off-by: Carl Hetherington --- libavcodec/tiff.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index 751f23ef33..f71885d156 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1550,6 +1550,8 @@ static av_cold int tiff_end(AVCodecContext *avctx) ff_lzw_decode_close(>lzw); av_freep(>deinvert_buf); s->deinvert_buf_size = 0; +av_freep(>yuv_line); +s->yuv_line_size = 0; av_freep(>fax_buffer); s->fax_buffer_size = 0; return 0; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Do not use strncat() to limit copying a one-char constant
2018-12-10 23:53 GMT+01:00, Mark Thompson :
> On 10/12/2018 00:57, Carl Eugen Hoyos wrote:
>> 2018-12-09 19:03 GMT+01:00, Mark Thompson :
>>> On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
Hi!
Attached patch silences a new gcc warning, alternative would be to
disable the warning.
Please comment, Carl Eugen
From dd49cddc6fad136222d4a168301059d55fea4a4c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 6 Dec 2018 23:23:12 +0100
Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying
a
one-char constant.
Silences a warning:
libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
equals source length [-Wstringop-overflow=]
strncat(buf, ",", 1);
^~~~
---
libavformat/matroskadec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2daa1db..df820b4 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3944,7 +3944,7 @@ static int webm_dash_manifest_cues(AVFormatContext
*s, int64_t init_range)
}
end += ret;
if (i != s->streams[0]->nb_index_entries - 1) {
-strncat(buf, ",", 1);
+strcat(buf, ",");
end++;
}
}
--
1.7.10.4
>>>
>>> LGTM.
>>>
>>> (Optional: perhaps nicer to remove that code fragment with the str(n?)cat
>>> completely by including the comma in the snprintf above, as '"%s", i !=
>>> s->streams[0]->nb_index_entries - 1 ? "," : ""'?)
>>
>> New patch attached.
>>
>> Please review, Carl Eugen
>>
>>
>> From 082bce9706a4c326187ae543d8b8aa93424c48b0 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Mon, 10 Dec 2018 01:55:15 +0100
>> Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
>> one-char constant.
>>
>> Instead add the character to the snprintf above as suggested by Mark.
>>
>> Silences a warning:
>> libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
>> libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
>> equals source length [-Wstringop-overflow=]
>> strncat(buf, ",", 1);
>> ^~~~
>> ---
>> libavformat/matroskadec.c |7 ++-
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 2daa1db..4ad99db 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -3936,17 +3936,14 @@ static int webm_dash_manifest_cues(AVFormatContext
>> *s, int64_t init_range)
>> strcpy(buf, "");
>> for (i = 0; i < s->streams[0]->nb_index_entries; i++) {
>> int ret = snprintf(buf + end, 20,
>> - "%" PRId64,
>> s->streams[0]->index_entries[i].timestamp);
>> + "%" PRId64"%s",
>> s->streams[0]->index_entries[i].timestamp,
>> + i != s->streams[0]->nb_index_entries - 1 ? ","
>> : "");
>> if (ret <= 0 || (ret == 20 && i ==
>> s->streams[0]->nb_index_entries - 1)) {
>> av_log(s, AV_LOG_ERROR, "timestamp too long.\n");
>> av_free(buf);
>> return AVERROR_INVALIDDATA;
>> }
>> end += ret;
>> -if (i != s->streams[0]->nb_index_entries - 1) {
>> -strncat(buf, ",", 1);
>> -end++;
>> -}
>> }
>> av_dict_set(>streams[0]->metadata, CUE_TIMESTAMPS, buf, 0);
>> av_free(buf);
>> --
>> 1.7.10.4
>
> Yep, LGTM.
Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V1 2/2] lavc/vaapi_encode: fix slices number check.
On 10/12/2018 01:56, myp...@gmail.com wrote:
> On Mon, Dec 10, 2018 at 2:08 AM Mark Thompson wrote:
>>
>> On 06/12/2018 10:39, Jun Zhao wrote:
>>> Fix slice number check logic. Only when the user setting slices
>>> number more than the driver constraints dump the rounded up warning
>>> message.
>>>
>>> Signed-off-by: Jun Zhao
>>> ---
>>> libavcodec/vaapi_encode.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>> index eda8a36..3c8a33d 100644
>>> --- a/libavcodec/vaapi_encode.c
>>> +++ b/libavcodec/vaapi_encode.c
>>> @@ -1572,7 +1572,7 @@ static av_cold int
>>> vaapi_encode_init_slice_structure(AVCodecContext *avctx)
>>> , tnereturn AVERROR(EINVAL);
>>> }
>>>
>>> -if (ctx->nb_slices > avctx->slices) {
>>> +if (ctx->nb_slices < avctx->slices) {
>>> av_log(avctx, AV_LOG_WARNING, "Slice count rounded up to "
>>> "%d (from %d) due to driver constraints on slice "
>>> "structure.\n", ctx->nb_slices, avctx->slices);
>>>
>>
>> No? The existing check looks right to me - we warn if the number got
>> increased over what the user specified due to driver constraints. (We don't
>> allow it to decrease unless the supplied number is larger than the number of
>> rows, which gets warned about above there.)
>>
> I think avctx->slices is user setting value and ctx->nb_slices is the
> driver constraints,
This is correct.
> so I think we need to check avctx->slices >
> ctx->nb_slices, then give a rounded up warning. :)
avctx->slice > ctx->nb_slices would mean that the driver constraint number is
/less/ than number the user set; that would be rounding down. This case isn't
allowed by the code above except for the degenerate example where the user
setting is greater than the number of rows, which is already warned about.
What we are actually checking for here is the driver constraint number being
/greater/ than the number the user set (that is, that ctx->nb_slices >
avctx->slices), and then warning the user that their supplied number has been
rounded up to the next available possibility and that the output stream will
therefore contain more slices than expected.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Do not use strncat() to limit copying a one-char constant
On 10/12/2018 00:57, Carl Eugen Hoyos wrote:
> 2018-12-09 19:03 GMT+01:00, Mark Thompson :
>> On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch silences a new gcc warning, alternative would be to
>>> disable the warning.
>>>
>>> Please comment, Carl Eugen
>>>
>>>
>>> From dd49cddc6fad136222d4a168301059d55fea4a4c Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos
>>> Date: Thu, 6 Dec 2018 23:23:12 +0100
>>> Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
>>> one-char constant.
>>>
>>> Silences a warning:
>>> libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
>>> libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
>>> equals source length [-Wstringop-overflow=]
>>> strncat(buf, ",", 1);
>>> ^~~~
>>> ---
>>> libavformat/matroskadec.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>>> index 2daa1db..df820b4 100644
>>> --- a/libavformat/matroskadec.c
>>> +++ b/libavformat/matroskadec.c
>>> @@ -3944,7 +3944,7 @@ static int webm_dash_manifest_cues(AVFormatContext
>>> *s, int64_t init_range)
>>> }
>>> end += ret;
>>> if (i != s->streams[0]->nb_index_entries - 1) {
>>> -strncat(buf, ",", 1);
>>> +strcat(buf, ",");
>>> end++;
>>> }
>>> }
>>> --
>>> 1.7.10.4
>>>
>>
>> LGTM.
>>
>> (Optional: perhaps nicer to remove that code fragment with the str(n?)cat
>> completely by including the comma in the snprintf above, as '"%s", i !=
>> s->streams[0]->nb_index_entries - 1 ? "," : ""'?)
>
> New patch attached.
>
> Please review, Carl Eugen
>
>
> From 082bce9706a4c326187ae543d8b8aa93424c48b0 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Mon, 10 Dec 2018 01:55:15 +0100
> Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
> one-char constant.
>
> Instead add the character to the snprintf above as suggested by Mark.
>
> Silences a warning:
> libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
> libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
> equals source length [-Wstringop-overflow=]
> strncat(buf, ",", 1);
> ^~~~
> ---
> libavformat/matroskadec.c |7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 2daa1db..4ad99db 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3936,17 +3936,14 @@ static int webm_dash_manifest_cues(AVFormatContext
> *s, int64_t init_range)
> strcpy(buf, "");
> for (i = 0; i < s->streams[0]->nb_index_entries; i++) {
> int ret = snprintf(buf + end, 20,
> - "%" PRId64,
> s->streams[0]->index_entries[i].timestamp);
> + "%" PRId64"%s",
> s->streams[0]->index_entries[i].timestamp,
> + i != s->streams[0]->nb_index_entries - 1 ? "," :
> "");
> if (ret <= 0 || (ret == 20 && i == s->streams[0]->nb_index_entries
> - 1)) {
> av_log(s, AV_LOG_ERROR, "timestamp too long.\n");
> av_free(buf);
> return AVERROR_INVALIDDATA;
> }
> end += ret;
> -if (i != s->streams[0]->nb_index_entries - 1) {
> -strncat(buf, ",", 1);
> -end++;
> -}
> }
> av_dict_set(>streams[0]->metadata, CUE_TIMESTAMPS, buf, 0);
> av_free(buf);
> --
> 1.7.10.4
Yep, LGTM.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use ioctl(..., "int request" ) on Android
On 10/12/2018 00:47, Carl Eugen Hoyos wrote:
> 2018-12-09 18:50 GMT+01:00, Mark Thompson :
>> On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch fixes building with new Android toolchain, used to be a
>>> warning.
>>>
>>> Please comment, Carl Eugen
>>>
>>> From d366c948af086520bfb2a4048e76f8d117690776 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos
>>> Date: Thu, 6 Dec 2018 23:34:54 +0100
>>> Subject: [PATCH] lavd/v4l2: Use "int request" as second parameter for
>>> ioctl()
>>> on Android.
>>>
>>> Fixes build with new Android toolchain.
>>> ---
>>> libavdevice/v4l2.c |4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
>>> index 10a0ff0..aa7c052 100644
>>> --- a/libavdevice/v4l2.c
>>> +++ b/libavdevice/v4l2.c
>>> @@ -95,7 +95,11 @@ struct video_data {
>>> int (*open_f)(const char *file, int oflag, ...);
>>> int (*close_f)(int fd);
>>> int (*dup_f)(int fd);
>>> +#ifdef __ANDROID__
>>> +int (*ioctl_f)(int fd, int request, ...);
>>> +#else
>>> int (*ioctl_f)(int fd, unsigned long int request, ...);
>>> +#endif
>>> ssize_t (*read_f)(int fd, void *buffer, size_t n);
>>> void *(*mmap_f)(void *start, size_t length, int prot, int flags, int
>>> fd, int64_t offset);
>>> int (*munmap_f)(void *_start, size_t length);
>>> --
>>> 1.7.10.4
>>>
>>
>> LGTM on its own, but should this perhaps be "#ifndef (glibc something)" for
>> the first case? Looking at possible V4L2-hosting libcs, only glibc has the
>> nonstandard* "unsigned long" rather than "int" as the request argument, so I
>> expect we're going to hit this in more cases (e.g. musl) if compilers are
>> now complaining about it.
>
> Is videodev2.h a Linux header as opposed to a c-library header or am I
> completely misunderstanding?
I'm not quite sure what you're asking, so I'll try to explain all of that more
carefully:
videodev2.h is a Linux header, but it only defines the types and values to call
ioctl() with so is mostly orthogonal to this discussion. ioctl() itself is a C
library call, but since V4L2 is almost always used with glibc the prototype
here has ended up matching that rather than the standard POSIX one.
Android follows the POSIX prototype, so your patch is correct. However, so do
other standard C libraries such as Musl, and therefore I expect we will hit the
same problem with other C libraries in the not-too-distant future. My
suggestion, then, is to guard the change with "#ifdef __GLIBC__
#else #endif", rather than fixing it only
for Android as you have here.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 09/12/2018 14:21, Mark Thompson wrote:
> On 09/12/2018 13:54, Paul B Mahol wrote:
>> On 12/9/18, Mark Thompson wrote:
>>> On 09/12/2018 08:52, Paul B Mahol wrote:
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
>>> On 12/7/18, Paul B Mahol wrote:
On 12/7/18, Michael Niedermayer wrote:
> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
>> This recovers state with #7374 linked sample.
>>
>> Work funded by Open Broadcast Systems.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/h264_refs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
>> index eaf965e43d..5645a203a7 100644
>> --- a/libavcodec/h264_refs.c
>> +++ b/libavcodec/h264_refs.c
>> @@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context
>> *h)
>> }
>> break;
>> case MMCO_RESET:
>> +default:
>> while (h->short_ref_count) {
>> remove_short(h, h->short_ref[0]->frame_num, 0);
>> }
>> @@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context
>> *h)
>> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>> h->last_pocs[j] = INT_MIN;
>> break;
>> -default: assert(0);
>> }
>> }
>
> mmco[i].opcode should not be invalid, its checked around the point
> where
> this
> array is filled.
> unless there is something iam missing
Yes, you are missing big time.
If you think by "checked" about those nice asserts they are not
enabled
at
all.
>>>
>>> There is check for invalid opcode, but stored invalid opcode is not
>>> changed.
>>
>> Theres no question that we end with a invalid value in the struct, but
>> that
>> is not intended to be in there. You can see that this is not intended by
>> simply looking at the variable that holds the number of entries, it is
>> not written at all in this case.
>>
>> So for example if this code stores 5 correct looking mmcos and the 6th
>> is
>> invalid, 6 are in the array but the number of entries is just left where
>> it
>> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the invalid
>> value
>> later doesnt feel ideal.
>
> Nope, mmco state is left in inconsistent state, and my patch fix it. As
> you
> provided nothing valuable to consider as alternative I will apply it.
>
What about converting any invalid mmco opcode to mmco reset and
updating mmco size too?
Currently mmco size is left in previous state.
>>>
>>> Don't invent a new RESET (= 5) operation - that type is special and its
>>> presence implies other constraints which we probably don't want to think
>>> about here (around frame_num in particular).
>>>
>>> I think END / truncating the list would be best option?
>>>
>>
>> Nope, that would still put it into bad state. With your approach decoder does
>> not recover from artifacts. Try sample from bug report #7374.
>
> Adding a spurious reset here throws away all previous reference frames, which
> will break the stream where it wouldn't otherwise be if the corrupted frame
> would have been bypassed for referencing. For example, in real-time cases
> with feedback a stream which has encountered errors can be recovered without
> an intra frame by referring to an older frame which still exists in the DPB.
Sample: . The bad frame here
has frame_num 24, but we already hit an error before that point and the
feedback about that makes frame_num 25 refer to LTRF 1 such that 24 is never
used. (From a simulator rather than a real capture, because random bit errors
are never where you want them.)
It doesn't exactly hit the original issue because the leftover MMCO count from
the previous slice is not large enough. With:
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 5645a203a7..977b4ed12f 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -875,6 +875,7 @@ int ff_h264_decode_ref_pic_marking(H264SliceContext *sl,
GetBitContext *gb,
av_log(logctx, AV_LOG_ERROR,
"illegal memory management control operation %d\n",
opcode);
+sl->nb_mmco = i + 1;
return -1;
}
if (opcode == MMCO_END)
to make sure the MMCO count is written with a high enough value it
Re: [FFmpeg-devel] [PATCH]lavc/xpmdec: Allow more colours per character
2018-12-10 16:49 GMT+01:00, Paul B Mahol : > On 12/10/18, Carl Eugen Hoyos wrote: >> 2018-12-06 19:11 GMT+01:00, Carl Eugen Hoyos : >> >>> Attached patch fixes decoding the files attached to ticket #6234. >>> >>> Please comment, Carl Eugen >> >> Ping. > > Probably ok. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.
From: Mohammad Izadi
The dynamic metadata contains data for color volume transform - application 4
of SPMTE 2094-40:2016 standard. The data comes from HEVC in the
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
I'll add support to HEVC in a follow-up.
---
libavutil/Makefile | 2 +
libavutil/frame.c| 1 +
libavutil/frame.h| 7 +
libavutil/hdr_dynamic_metadata.c | 40
libavutil/hdr_dynamic_metadata.h | 344 +++
libavutil/version.h | 2 +-
6 files changed, 395 insertions(+), 1 deletion(-)
create mode 100644 libavutil/hdr_dynamic_metadata.c
create mode 100644 libavutil/hdr_dynamic_metadata.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index caddc7e155..7dcb92b06b 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -31,6 +31,7 @@ HEADERS = adler32.h
\
file.h\
frame.h \
hash.h\
+ hdr_dynamic_metadata.h\
hmac.h\
hwcontext.h \
hwcontext_cuda.h \
@@ -119,6 +120,7 @@ OBJS = adler32.o
\
fixed_dsp.o \
frame.o \
hash.o \
+ hdr_dynamic_metadata.o \
hmac.o \
hwcontext.o \
imgutils.o \
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9b3fb13e68..c5f30b6847 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table
properties";
case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table data";
#endif
+case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR Dynamic
Metadata SMPTE2094-40";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 66f27f44bd..1b65a34ab3 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -166,6 +166,13 @@ enum AVFrameSideDataType {
* function in libavutil/timecode.c.
*/
AV_FRAME_DATA_S12M_TIMECODE,
+
+/**
+ * HDR dynamic metadata associated with a video frame. The payload is
+ * an AVDynamicMetadataSMPTE2094_40 type and contains information for color
+ * volume transform - application 4 of SPMTE 2094-40:2016 standard.
+ */
+AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40,
};
enum AVActiveFormatDescription {
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
new file mode 100644
index 00..59dfcc84e4
--- /dev/null
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -0,0 +1,40 @@
+/**
+ * Copyright (c) 2018 Mohammad Izadi
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "hdr_dynamic_metadata.h"
+#include "mem.h"
+
+AVDynamicMetadataSMPTE2094_40 *av_dynamic_metadata_smpte2094_40_alloc(void)
+{
+return av_mallocz(sizeof(AVDynamicMetadataSMPTE2094_40));
+}
+
+AVDynamicMetadataSMPTE2094_40
*av_dynamic_metadata_smpte2094_40_create_side_data(AVFrame *frame)
+{
+AVFrameSideData *side_data = av_frame_new_side_data(frame,
+
AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40,
+
sizeof(AVDynamicMetadataSMPTE2094_40));
+if (!side_data)
+return NULL;
+
+memset(side_data->data, 0, sizeof(AVDynamicMetadataSMPTE2094_40));
+
+return (AVDynamicMetadataSMPTE2094_40 *)side_data->data;
+}
Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs
Hi,, On 11/21/17, Bjorn Roche wrote: > Support for transparencies in animated gifs requires modifying both > libavcodec/gif.c and libavformat/gif.c because both the graphics > control extension (handled by libavformat/gif.c) and the raw frame data > (handled by libavcodec/gif.c) must be changed. This is because > transparencies in GIF can be used both to create a transparent image, > and to provide optimization. > > How transparencies are interpreted in a given frame is controlled by > the “disposal method”, which must be set appropriately in the graphics > control extension. > > The “in place” disposal method is used when transparency indicates > optimization, and the “background” disposal method is used when > transparency is intended to be preserved. In order to support both > disposal methods, libavcodec/gif.c must signal to libavformat/gif.c > which disposal method is required for every frame. This is done with a > new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a > change to avcodec.h > > Unfortunately, the addition of a new side data type causes some of the > FATE tests to fail, so the fate tests are updated here as well. What about rewritting code instead so it behaves correctly? For example muxing gif and encoding gif should work with codec copy. To get that working one needs to change muxer and encoder so muxer does not write extensions but encoder does. Adding side data is not going to make codec copy work. I'm planning to do this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
I came across a similar discussion here: https://github.com/OpenImageIO/oiio/pull/1412 Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
Moritz Barsnick (2018-12-10): > That was my interpretation. It's a density, if units != 0, otherwise > the aspect ratio. (Would a density not correspond to the SAR? I.e. not > make sense with square pixels?) I did not follow the beginning of the discussion, but just in case it can help and was not obvious in the first place: Having a density makes sense even for square pixels to carry the information of the physical size of the image. It makes sense if the original has a well-defined physical size, like a scanned document. Also, the density can give the aspect ratio, but there is a catch: if the density is 20 px/mm horizontally and 10 px/mm vertically, that means pixels are (1/20)×(1/10) mm², hence their aspect ratio is 10/20 = 1/2, not 20/10 = 2/1. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
On Mon, Dec 10, 2018 at 13:19:57 +0100, Carl Eugen Hoyos wrote: > > units (1 byte) Units for the X and Y densities. > > units = 0: no units, X and Y specify the pixel aspect ratio > > units = 1: X and Y are dots per inch > > units = 2: X and Y are dots per cm > > Xdensity (2 bytes) Horizontal pixel density > > Ydensity (2 bytes) Vertical pixel density > The "density" (unless they intentionally reversed the meaning of the > word) is always the inverse of the aspect ratio. That's what I was wondering as well. > Did they reverse the meaning in your opinion? > Does it make sense to argue that if the unit is "0", the meaning of the > density changes? That was my interpretation. It's a density, if units != 0, otherwise the aspect ratio. (Would a density not correspond to the SAR? I.e. not make sense with square pixels?) I was wondering what other implementations do? jpglib, *Magick. Reference images? I didn't find anything quickly, but one may need to check closer. Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/xpmdec: Allow more colours per character
On 12/10/18, Carl Eugen Hoyos wrote: > 2018-12-06 19:11 GMT+01:00, Carl Eugen Hoyos : > >> Attached patch fixes decoding the files attached to ticket #6234. >> >> Please comment, Carl Eugen > > Ping. Probably ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: implement input file stream disabling
At Michael's suggestion, this patch lets -vn/-an/-sn/-dn work for input
files. Individual streams can still be let through e.g.
ffmpeg -an -discard:a:1 none -i file ...
will let (only) the 2nd audio stream be seen during stream selection and
filtergraph construction.
Thanks,
Gyan
From 9823a71f2055f2c4c4484536291bbd2afee36a81 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 10 Dec 2018 20:38:20 +0530
Subject: [PATCH] ffmpeg: implement input file stream disabling
-vn/-an/-sn/-dn can be set to stop processing of streams
of said type from an input file.
---
fftools/ffmpeg_filter.c | 7 +++
fftools/ffmpeg_opt.c| 17 +
2 files changed, 24 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 6518d50870..8c0ff99dd9 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -293,10 +293,17 @@ static void init_input_filter(FilterGraph *fg,
AVFilterInOut *in)
exit_program(1);
}
ist = input_streams[input_files[file_idx]->ist_index + st->index];
+if (ist->user_set_discard == AVDISCARD_ALL) {
+av_log(NULL, AV_LOG_FATAL, "Stream specifier '%s' in filtergraph
description %s "
+ "matches a disabled input stream.\n", p, fg->graph_desc);
+exit_program(1);
+}
} else {
/* find the first unused stream of corresponding type */
for (i = 0; i < nb_input_streams; i++) {
ist = input_streams[i];
+if (ist->user_set_discard == AVDISCARD_ALL)
+continue;
if (ist->dec_ctx->codec_type == type && ist->discard)
break;
}
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index d4851a2cd8..59f4236127 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -746,6 +746,13 @@ static void add_input_streams(OptionsContext *o,
AVFormatContext *ic)
MATCH_PER_STREAM_OPT(discard, str, discard_str, ic, st);
ist->user_set_discard = AVDISCARD_NONE;
+
+if ((o->video_disable && ist->st->codecpar->codec_type ==
AVMEDIA_TYPE_VIDEO) ||
+(o->audio_disable && ist->st->codecpar->codec_type ==
AVMEDIA_TYPE_AUDIO) ||
+(o->subtitle_disable && ist->st->codecpar->codec_type ==
AVMEDIA_TYPE_SUBTITLE) ||
+(o->data_disable && ist->st->codecpar->codec_type ==
AVMEDIA_TYPE_DATA))
+ist->user_set_discard = AVDISCARD_ALL;
+
if (discard_str && av_opt_eval_int(, discard_opt, discard_str,
>user_set_discard) < 0) {
av_log(NULL, AV_LOG_ERROR, "Error parsing discard %s.\n",
discard_str);
@@ -2174,6 +2181,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
int new_area;
ist = input_streams[i];
new_area = ist->st->codecpar->width *
ist->st->codecpar->height + 1*!!ist->st->codec_info_nb_frames;
+if (ist->user_set_discard == AVDISCARD_ALL)
+continue;
if((qcr!=MKTAG('A', 'P', 'I', 'C')) && (ist->st->disposition &
AV_DISPOSITION_ATTACHED_PIC))
new_area = 1;
if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
@@ -2195,6 +2204,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
int score;
ist = input_streams[i];
score = ist->st->codecpar->channels +
1*!!ist->st->codec_info_nb_frames;
+if (ist->user_set_discard == AVDISCARD_ALL)
+continue;
if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
score > best_score) {
best_score = score;
@@ -2216,6 +2227,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
AVCodec const *output_codec =
avcodec_find_encoder(oc->oformat->subtitle_codec);
int input_props = 0, output_props = 0;
+if (input_streams[i]->user_set_discard == AVDISCARD_ALL)
+continue;
if (output_codec)
output_descriptor =
avcodec_descriptor_get(output_codec->id);
if (input_descriptor)
@@ -2237,6 +2250,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
if (!o->data_disable ) {
enum AVCodecID codec_id = av_guess_codec(oc->oformat, NULL,
filename, NULL, AVMEDIA_TYPE_DATA);
for (i = 0; codec_id != AV_CODEC_ID_NONE && i < nb_input_streams;
i++) {
+if (input_streams[i]->user_set_discard == AVDISCARD_ALL)
+continue;
if (input_streams[i]->st->codecpar->codec_type ==
AVMEDIA_TYPE_DATA
&& input_streams[i]->st->codecpar->codec_id == codec_id )
new_data_stream(o, oc, i);
@@
[FFmpeg-devel] [PATCH] fate: add prog suffix in fate-mov-mp4-with-mov-in24-ver
Maybe we should set a ffprobe variable in the fate Makefile, like done for ffmpeg on ln 8. Gyan From f1cdb3ee993602618bad243df07c0e33263cc211 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Mon, 10 Dec 2018 20:44:33 +0530 Subject: [PATCH] fate: add prog suffix in fate-mov-mp4-with-mov-in24-ver Prevent test failure with builds that set a suffix and/or extension for the ffprobe binary --- tests/fate/mov.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index 4df0fe6490..8ed66cf135 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -123,4 +123,4 @@ fate-mov-faststart-4gb-overflow: CMD = run tools/qt-faststart$(EXESUF) $(TARGET_ fate-mov-faststart-4gb-overflow: CMP = oneline fate-mov-faststart-4gb-overflow: REF = bc875921f151871e787c4b4023269b29 -fate-mov-mp4-with-mov-in24-ver: CMD = run ffprobe -show_entries stream=codec_name -select_streams 1 $(TARGET_SAMPLES)/mov/mp4-with-mov-in24-ver.mp4 +fate-mov-mp4-with-mov-in24-ver: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name -select_streams 1 $(TARGET_SAMPLES)/mov/mp4-with-mov-in24-ver.mp4 -- 2.19.2___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] apc: Read duration from file
On 12/10/18, Tomas Härdin wrote: > The first in a series of CRYO APC patches > > /Tomas LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores
On 12/6/18, Paul B Mahol wrote:
> On 12/6/18, Baptiste Coudurier wrote:
>> On Thu, Dec 6, 2018 at 7:45 AM Paul B Mahol wrote:
>>
>>> On 12/6/18, Baptiste Coudurier wrote:
>>> > Hi Paul,
>>> >
>>> > On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol wrote:
>>> >
>>> >> On 12/6/18, Baptiste Coudurier wrote:
>>> >> > Hi Paul
>>> >> >
>>> >> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol
>>> >> > wrote:
>>> >> >
>>> >> >> Signed-off-by: Paul B Mahol
>>> >> >> ---
>>> >> >> libavformat/mxfenc.c | 49
>>>
>>> >> >> 1 file changed, 49 insertions(+)
>>> >> >>
>>> >> >> [...]
>>> >> >>
>>> >> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream
>>> >> >> *st,
>>> >> >> AVPacket *pkt)
>>> >> >> +{
>>> >> >> +MXFContext *mxf = s->priv_data;
>>> >> >> +MXFStreamContext *sc = st->priv_data;
>>> >> >> +int i, profile;
>>> >> >> +
>>> >> >> +if (mxf->header_written)
>>> >> >> +return 1;
>>> >> >> +
>>> >> >> +sc->codec_ul = NULL;
>>> >> >> +profile = st->codecpar->profile;
>>> >> >>
>>> >> >
>>> >> > We should fetch the profile from the bitstream.
>>> >> >
>>> >>
>>> >> AFAIK profile is not stored in it.
>>> >>
>>> >
>>> > Right. My thinking is how would this work going from MOV to MXF ? Or
>>> would
>>> > it work when encoding ?
>>>
>>> It works when encoding and stream copying, last time I tried.
>>>
>>
>> After looking at the code, it seems like it would work assuming essence
>> comes from MXF or MOV,
>> raw would not work though but we can accept that.
>>
>> So I think the patch is fine, as well as the demuxer one, could you
>> please
>> apply the demuxer one first ?
>
> It is listed before muxer anyway, muxer patch is last one.
> Or there is something I'm missing.
>
will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/gifdec: truncate too big width/height for invalid gif files
Fixes #6874.
Signed-off-by: Paul B Mahol
---
libavcodec/gifdec.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 54f1d4c0ba..0eb1c21d99 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -179,12 +179,20 @@ static int gif_read_image(GifState *s, AVFrame *frame)
}
/* verify that all the image is inside the screen dimensions */
-if (!width || width > s->screen_width || left >= s->screen_width) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid image width.\n");
+if (!width || width > s->screen_width) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid image width: %d,
truncating.\n", width);
+width = s->screen_width;
+}
+if (left >= s->screen_width) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid left position: %d.\n", left);
return AVERROR_INVALIDDATA;
}
-if (!height || height > s->screen_height || top >= s->screen_height) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid image height.\n");
+if (!height || height > s->screen_height) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid image height, truncating:
%d.\n", height);
+height = s->screen_height;
+}
+if (top >= s->screen_height) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid top position: %d.\n", top);
return AVERROR_INVALIDDATA;
}
if (left + width > s->screen_width) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek
2018-12-10 9:46 GMT+01:00, Gyan : > > On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: >> 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos : >> >>> It appears to me that NewTek abused our willingness to add an optional >>> external nonfree library, I don't see many better options. See Ticket >>> #7589 and a blog post by a NewTek engineer confirming the issue. >>> >>> Patch untested. >> After several people have objected claiming NewTek would fix this >> situation, a week has passed: No visible reaction whatsoever, not >> even requesting more time. >> >> What are those suggesting who were against this patch? > > Contact Newtek with your concerns and a deadline and what > action you're considering beyond the deadline. Done. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
2018-12-10 9:29 GMT+01:00, Moritz Barsnick : > On Mon, Dec 10, 2018 at 02:54:54 +0100, Carl Eugen Hoyos wrote: >> I hope somebody can prove me wrong! > > Not sure, see below. > >> This would need a slightly more sophisticated update to the decoder. > > Because it is also presumed incorrect? > >> put_bits(p, 16, 0x0102); >> put_bits(p, 8, 0); /* units type: 0 - aspect ratio >> */ >> -put_bits(p, 16, sar.num); >> put_bits(p, 16, sar.den); >> +put_bits(p, 16, sar.num); >> put_bits(p, 8, 0); /* thumbnail width */ > > If a 640x480 (640 x dimension, 480 y dimension) image has a SAR of 4/3, > 4 (or the x dimension) is its numerator, 3 (or the y dimension) is its > denominator. > > The spec (and Wikipedia) says: > units (1 byte) Units for the X and Y densities. > units = 0: no units, X and Y specify the pixel aspect ratio > units = 1: X and Y are dots per inch > units = 2: X and Y are dots per cm > Xdensity (2 bytes) Horizontal pixel density > Ydensity (2 bytes) Vertical pixel density > > So Xdensity and Ydensity should be (e.g.) 4 and 3 in this case, which > are sar.num and sar.den (judging by the struct's field names), > respectively. > > It seems to me that that is what the original implementation does. The "density" (unless they intentionally reversed the meaning of the word) is always the inverse of the aspect ratio. Did they reverse the meaning in your opinion? Does it make sense to argue that if the unit is "0", the meaning of the density changes? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/2] lavf/file: Add support for file syncing.
This commit adds support for IO synchronization API to the file backend.
---
libavformat/file.c | 11 +++
libavformat/os_support.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 1d321c4205..58fd55b928 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -254,6 +254,16 @@ static int64_t file_seek(URLContext *h, int64_t pos, int
whence)
return ret < 0 ? AVERROR(errno) : ret;
}
+static int file_sync(URLContext *h)
+{
+if (h->flags & AVIO_FLAG_WRITE) {
+FileContext *c = h->priv_data;
+if (fsync(c->fd) < 0)
+return AVERROR(errno);
+}
+return 0;
+}
+
static int file_close(URLContext *h)
{
FileContext *c = h->priv_data;
@@ -353,6 +363,7 @@ const URLProtocol ff_file_protocol = {
.url_close = file_close,
.url_get_file_handle = file_get_handle,
.url_check = file_check,
+.url_sync= file_sync,
.url_delete = file_delete,
.url_move= file_move,
.priv_data_size = sizeof(FileContext),
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 7a56dc9a7c..1864763cb1 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -93,6 +93,8 @@ static inline int is_dos_path(const char *path)
#ifndef S_IWUSR
#define S_IWUSR S_IWRITE
#endif
+
+#define fsync(fd) _commit((fd))
#endif
#if CONFIG_NETWORK
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/2] lavf: Add general API for IO buffer synchronization.
This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.
The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op,
the result code is AVERROR(ENOSYS).
---
libavformat/avio.c| 7 +++
libavformat/avio.h| 20
libavformat/aviobuf.c | 17 +
libavformat/url.h | 12
4 files changed, 56 insertions(+)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..5754a7c20d 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
return size;
}
+int ffurl_sync(URLContext *h)
+{
+if (h->prot->url_sync)
+return h->prot->url_sync(h);
+return AVERROR(ENOSYS);
+}
+
int ffurl_get_file_handle(URLContext *h)
{
if (!h || !h->prot || !h->prot->url_get_file_handle)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..9e2ef14e60 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -349,6 +349,14 @@ typedef struct AVIOContext {
* Try to buffer at least this amount of data before flushing it
*/
int min_packet_size;
+
+/**
+ * A callback for synchronizing buffers with the media state.
+ *
+ * @return 0 on success, AVERROR(ENOSYS) if the operation is not supported
+ * and ignored, or other AVERROR < 0 on error.
+ */
+int (*sync)(void *opaque);
} AVIOContext;
/**
@@ -586,6 +594,18 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
av_printf_format(2, 3);
*/
void avio_flush(AVIOContext *s);
+/**
+ * Flush internal buffers and ensure the synchronized state of the
+ * resource associated with the context s. This call may be expensive.
+ * Not all resources support syncing, this operation is a no-op
+ * if sync is not supported or needed.
+ * This function can only be used if s was opened by avio_open().
+ *
+ * @return 0 on success, AVERROR(ENOSYS) if the operation is not supported
+ * and ignored, or other AVERROR < 0 on error.
+ */
+int avio_sync(AVIOContext *s);
+
/**
* Read size bytes from AVIOContext into buf.
* @return number of bytes read or AVERROR
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..c1c9334719 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -243,6 +243,14 @@ void avio_flush(AVIOContext *s)
avio_seek(s, seekback, SEEK_CUR);
}
+int avio_sync(AVIOContext *s)
+{
+avio_flush(s);
+if (s->sync)
+return s->sync(s->opaque);
+return AVERROR(ENOSYS);
+}
+
int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
{
int64_t offset1;
@@ -978,6 +986,12 @@ static int64_t io_read_seek(void *opaque, int
stream_index, int64_t timestamp, i
return internal->h->prot->url_read_seek(internal->h, stream_index,
timestamp, flags);
}
+static int io_sync(void *opaque)
+{
+AVIOInternal *internal = opaque;
+return ffurl_sync(internal->h);
+}
+
int ffio_fdopen(AVIOContext **s, URLContext *h)
{
AVIOInternal *internal = NULL;
@@ -1026,6 +1040,9 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
if (h->prot->url_read_seek)
(*s)->seekable |= AVIO_SEEKABLE_TIME;
+
+if (h->prot->url_sync)
+(*s)->sync = io_sync;
}
(*s)->short_seek_get = io_short_seek;
(*s)->av_class = _avio_class;
diff --git a/libavformat/url.h b/libavformat/url.h
index 4750bfff82..5b8cd22e5a 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -97,6 +97,7 @@ typedef struct URLProtocol {
int (*url_delete)(URLContext *h);
int (*url_move)(URLContext *h_src, URLContext *h_dst);
const char *default_whitelist;
+int (*url_sync)(URLContext *h);
} URLProtocol;
/**
@@ -228,6 +229,17 @@ int64_t ffurl_seek(URLContext *h, int64_t pos, int whence);
int ffurl_closep(URLContext **h);
int ffurl_close(URLContext *h);
+/**
+ * Flush any buffered data and synchronize the resource accessed
+ * by the URLContext h. This call may be expensive.
+ * Not all types of resources support syncing, the call is a no-op
+ * if sync is not supported or needed.
+ *
+ * @return 0 on success, AVERROR(ENOSYS) if the operation is not supported
+ * and ignored, or other AVERROR < 0 on error.
+ */
+int ffurl_sync(URLContext *h);
+
/**
* Return the filesize of the resource accessed by h, AVERROR(ENOSYS)
* if the
[FFmpeg-devel] [PATCH] avformat: add vividas demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vividas.c| 708 +++
3 files changed, 710 insertions(+)
create mode 100644 libavformat/vividas.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 0e43a12df5..c42ceb40c5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,7 @@ OBJS-$(CONFIG_VC1_DEMUXER) += rawdec.o
vc1dec.o
OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
OBJS-$(CONFIG_VC1T_DEMUXER) += vc1test.o
OBJS-$(CONFIG_VC1T_MUXER)+= vc1testenc.o
+OBJS-$(CONFIG_VIVIDAS_DEMUXER) += vividas.o
OBJS-$(CONFIG_VIVO_DEMUXER) += vivo.o
OBJS-$(CONFIG_VMD_DEMUXER) += sierravmd.o
OBJS-$(CONFIG_VOBSUB_DEMUXER)+= subtitles.o # mpeg demuxer is in
the dependencies
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index df83b04484..399625fd78 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -422,6 +422,7 @@ extern AVInputFormat ff_vc1_demuxer;
extern AVOutputFormat ff_vc1_muxer;
extern AVInputFormat ff_vc1t_demuxer;
extern AVOutputFormat ff_vc1t_muxer;
+extern AVInputFormat ff_vividas_demuxer;
extern AVInputFormat ff_vivo_demuxer;
extern AVInputFormat ff_vmd_demuxer;
extern AVInputFormat ff_vobsub_demuxer;
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
new file mode 100644
index 00..86748dd780
--- /dev/null
+++ b/libavformat/vividas.c
@@ -0,0 +1,708 @@
+/*
+ * Vividas VIV format Demuxer
+ * Copyright (c) 2012 Krzysztof Klinikowski
+ * Copyright (c) 2010 Andrzej Szombierski
+ * based on vivparse Copyright (c) 2007 Måns Rullgård
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * @brief Vividas VIV (.viv) file demuxer
+ * @author Andrzej Szombierski [qq at kuku eu org] (2010-07)
+ * @sa http://wiki.multimedia.cx/index.php?title=Vividas_VIV
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avio_internal.h"
+#include "avformat.h"
+
+#define MAX_AUDIO_SUBPACKETS 100
+
+typedef struct VIV_SB_block {
+int size, n_packets;
+int64_t byte_offset;
+int packet_offset;
+} VIV_SB_block;
+
+typedef struct VIV_SB_entry {
+int size, flag;
+} VIV_SB_entry;
+
+typedef struct VIV_AudioSubpacket {
+int start, pcm_bytes;
+} VIV_AudioSubpacket;
+
+typedef struct VividasDemuxContext {
+int n_sb_blocks;
+VIV_SB_block *sb_blocks;
+
+uint32_t sb_key;
+int64_t sb_offset;
+
+int current_sb, current_sb_entry;
+uint8_t *sb_buf;
+AVIOContext *sb_pb;
+int n_sb_entries;
+VIV_SB_entry *sb_entries;
+
+int n_audio_subpackets;
+int current_audio_subpacket;
+
+int audio_sample;
+
+VIV_AudioSubpacket audio_subpackets[MAX_AUDIO_SUBPACKETS];
+} VividasDemuxContext;
+
+static int viv_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "vividas03", 9))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static const unsigned short keybits[32] = {
+ 163, 416, 893, 82, 223, 572, 1137, 430,
+ 659, 1104, 13, 626, 695, 972, 1465, 686,
+ 843, 1216, 317, 1122, 1383, 92, 513, 1158,
+1243, 48, 573, 1306, 1495, 396, 1009, 350,
+};
+
+static uint32_t decode_key(uint8_t *buf)
+{
+uint32_t key = 0;
+int i;
+
+for (i = 0; i < 32; i++) {
+unsigned p = keybits[i];
+key |= !!(buf[p>>3] & (1<<(p&7))) << i;
+}
+
+return key;
+}
+
+static void put_v(uint8_t *p, int v)
+{
+if (v>>28)
+*p++ = ((v>>28)&0x7f)|0x80;
+if (v>>21)
+*p++ = ((v>>21)&0x7f)|0x80;
+if (v>>14)
+*p++ = ((v>>14)&0x7f)|0x80;
+if (v>>7)
+*p++ = ((v>>7)&0x7f)|0x80;
+}
+
+static unsigned int recover_key(unsigned char sample[4], int expected_size)
+{
+unsigned char plaintext[8] = { 'S', 'B' };
+
+put_v(plaintext+2, expected_size);
+
+return (sample[0]^plaintext[0])|
+((sample[1]^plaintext[1])<<8)|
+((sample[2]^plaintext[2])<<16)|
+((sample[3]^plaintext[3])<<24);
+}
+
+static void xor_block(void *p1, void *p2, int size, int key, int *key_ptr)
+{
+int *d1 = p1;
+int *d2 = p2;
+int k = *key_ptr;
+
+size >>= 2;
+
+while
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
On Mon, Dec 10, 2018 at 12:33:52PM +0100, Michael Niedermayer wrote: > On Mon, Dec 10, 2018 at 02:54:54AM +0100, Carl Eugen Hoyos wrote: > > Hi! > > > > Reading the specification and Wikipedia, it appears to me that FFmpeg > > is writing wrong values as aspect ratio for jfif files. > > I hope somebody can prove me wrong! > > > > This would need a slightly more sophisticated update to the decoder. > > > > Please comment, Carl Eugen > > mjpegenc_common.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > 03077e11ffcc0b2faf5a2be46b0cb2ea224eca57 > > 0001-lavc-mjpegenc_common-Fix-aspect-ratio.patch > > From 9c42114da17c20ef6d81d3989b5521eaefc15819 Mon Sep 17 00:00:00 2001 > > From: Carl Eugen Hoyos > > Date: Mon, 10 Dec 2018 02:50:39 +0100 > > Subject: [PATCH] lavc/mjpegenc_common: Fix aspect ratio. > > > > Reported-by: Ulf Zibis > > --- > > libavcodec/mjpegenc_common.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > if its correct, this requires a bump to the version of libavcodec so > the decoder can detect if a file is from before or after the change also there is related code in libavcodec/vaapi_encode_mjpeg.c [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
On Mon, Dec 10, 2018 at 02:54:54AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Reading the specification and Wikipedia, it appears to me that FFmpeg > is writing wrong values as aspect ratio for jfif files. > I hope somebody can prove me wrong! > > This would need a slightly more sophisticated update to the decoder. > > Please comment, Carl Eugen > mjpegenc_common.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 03077e11ffcc0b2faf5a2be46b0cb2ea224eca57 > 0001-lavc-mjpegenc_common-Fix-aspect-ratio.patch > From 9c42114da17c20ef6d81d3989b5521eaefc15819 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Mon, 10 Dec 2018 02:50:39 +0100 > Subject: [PATCH] lavc/mjpegenc_common: Fix aspect ratio. > > Reported-by: Ulf Zibis > --- > libavcodec/mjpegenc_common.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) if its correct, this requires a bump to the version of libavcodec so the decoder can detect if a file is from before or after the change [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] Add ADPCM IMA CRYO APC encoder
From 32cc6a96f80b5406e8327d912c8fc38812e6a664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 23 Nov 2018 15:15:02 +0100
Subject: [PATCH 3/3] Add ADPCM IMA CRYO APC encoder
No trellis quantization yet
---
Changelog | 1 +
libavcodec/adpcmenc.c | 33 +
libavcodec/allcodecs.c | 1 +
libavcodec/version.h | 4 ++--
tests/fate/acodec.mak | 2 ++
tests/ref/acodec/adpcm-ima_apc | 4
6 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 tests/ref/acodec/adpcm-ima_apc
diff --git a/Changelog b/Changelog
index f678feed65..e6ae0c1187 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
- dhav demuxer
- PCM-DVD encoder
- CRYO APC muxer
+- ADPCM IMA CRYO APC encoder
version 4.1:
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 668939c778..0d757d5b46 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -54,6 +54,7 @@ typedef struct ADPCMEncodeContext {
TrellisNode *node_buf;
TrellisNode **nodep_buf;
uint8_t *trellis_hash;
+int extradata_updated;
} ADPCMEncodeContext;
#define FREEZE_INTERVAL 128
@@ -124,6 +125,15 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
bytestream_put_le16(, ff_adpcm_AdaptCoeff2[i] * 4);
}
break;
+case AV_CODEC_ID_ADPCM_IMA_APC:
+if (avctx->trellis) {
+av_log(avctx, AV_LOG_ERROR, "trellis encoding not implemented for CRYO APC\n");
+return AVERROR_PATCHWELCOME;
+}
+//extradata will be output in adpcm_encode_frame()
+avctx->frame_size = BLKSIZE * 2 / avctx->channels;
+avctx->block_align = BLKSIZE;
+break;
case AV_CODEC_ID_ADPCM_YAMAHA:
avctx->frame_size = BLKSIZE * 2 / avctx->channels;
avctx->block_align = BLKSIZE;
@@ -491,6 +501,28 @@ static int adpcm_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
dst = avpkt->data;
switch(avctx->codec->id) {
+case AV_CODEC_ID_ADPCM_IMA_APC:
+//initialize predictors using initial samples
+if (!c->extradata_updated) {
+uint8_t *side_data = av_packet_new_side_data(
+avpkt, AV_PKT_DATA_NEW_EXTRADATA, 8);
+
+if (!side_data) {
+return AVERROR(ENOMEM);
+}
+
+for (ch = 0; ch < avctx->channels; ch++) {
+c->status[ch].prev_sample = samples[ch];
+bytestream_put_le32(_data, c->status[ch].prev_sample);
+}
+c->extradata_updated = 1;
+}
+for (i = 0; i < frame->nb_samples*avctx->channels/2; i++) {
+uint8_t l = adpcm_ima_compress_sample(>status[0], samples[2*i+0]);
+uint8_t r = adpcm_ima_compress_sample(>status[st], samples[2*i+1]);
+*dst++ = (l<<4) | r;
+}
+break;
case AV_CODEC_ID_ADPCM_IMA_WAV:
{
int blocks, j;
@@ -721,6 +753,7 @@ AVCodec ff_ ## name_ ## _encoder = {\
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, "ADPCM IMA QuickTime");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, "ADPCM IMA WAV");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_APC, adpcm_ima_apc, sample_fmts, "ADPCM IMA CRYO APC");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, "ADPCM Microsoft");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, "ADPCM Shockwave Flash");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, "ADPCM Yamaha");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d70646e91a..873f236531 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -586,6 +586,7 @@ extern AVCodec ff_adpcm_g726_decoder;
extern AVCodec ff_adpcm_g726le_encoder;
extern AVCodec ff_adpcm_g726le_decoder;
extern AVCodec ff_adpcm_ima_amv_decoder;
+extern AVCodec ff_adpcm_ima_apc_encoder;
extern AVCodec ff_adpcm_ima_apc_decoder;
extern AVCodec ff_adpcm_ima_dat4_decoder;
extern AVCodec ff_adpcm_ima_dk3_decoder;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f758093582..5677a7feba 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 41
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 42
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak
index 80d26de0f9..69bfa6940e 100644
--- a/tests/fate/acodec.mak
+++ b/tests/fate/acodec.mak
@@ -45,6 +45,7 @@ fate-acodec-pcm-u%le: FMT = nut
fate-acodec-pcm-f%be: FMT = au
FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_ADX, ADX) += adx
[FFmpeg-devel] [PATCH 2/3] Add CRYO APC muxer
From f08c1554f30839c7d42a9c5e677619f2c8b11c11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 22 Nov 2018 22:28:30 +0100
Subject: [PATCH 2/3] Add CRYO APC muxer
---
Changelog| 1 +
doc/general.texi | 2 +-
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apcenc.c | 119 +++
libavformat/version.h| 4 +-
6 files changed, 125 insertions(+), 3 deletions(-)
create mode 100644 libavformat/apcenc.c
diff --git a/Changelog b/Changelog
index 1f53ff46da..f678feed65 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
- truehd_core bitstream filter
- dhav demuxer
- PCM-DVD encoder
+- CRYO APC muxer
version 4.1:
diff --git a/doc/general.texi b/doc/general.texi
index d8832407bb..72da4019cb 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -400,7 +400,7 @@ library:
@item CRC testing format@tab X @tab
@item Creative Voice@tab X @tab X
@tab Created for the Sound Blaster Pro.
-@item CRYO APC @tab @tab X
+@item CRYO APC @tab X @tab X
@tab Audio format used in some games by CRYO Interactive Entertainment.
@item D-Cinema audio@tab X @tab X
@item Deluxe Paint Animation@tab @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d0d621de07..1ac8c20cca 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -91,6 +91,7 @@ OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
+OBJS-$(CONFIG_APC_MUXER) += apcenc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 5fb5bf17c6..3bc1be430a 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -52,6 +52,7 @@ extern AVInputFormat ff_amrnb_demuxer;
extern AVInputFormat ff_amrwb_demuxer;
extern AVInputFormat ff_anm_demuxer;
extern AVInputFormat ff_apc_demuxer;
+extern AVOutputFormat ff_apc_muxer;
extern AVInputFormat ff_ape_demuxer;
extern AVInputFormat ff_apng_demuxer;
extern AVOutputFormat ff_apng_muxer;
diff --git a/libavformat/apcenc.c b/libavformat/apcenc.c
new file mode 100644
index 00..dba1b3b90c
--- /dev/null
+++ b/libavformat/apcenc.c
@@ -0,0 +1,119 @@
+/*
+ * CRYO APC audio format muxer
+ * Copyright (c) 2018 Tomas Härdin
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avio_internal.h"
+#include "internal.h"
+
+#define APC_HEADER_SIZE (8*4)
+
+static int apc_write_header(AVFormatContext *s)
+{
+AVIOContext *pb = s->pb;
+AVCodecParameters *par;
+AVStream *st;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "Must have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+st = s->streams[0];
+par = st->codecpar;
+
+if (par->channels <= 0 || par->channels > 2) {
+av_log(s, AV_LOG_ERROR, "Must be mono or stereo\n");
+return AVERROR(EINVAL);
+}
+
+if (par->extradata_size != 0 && par->extradata_size != 8) {
+av_log(s, AV_LOG_ERROR,
+"Must have exactly 0 or 8 bytes of extradata, got %i\n",
+par->extradata_size);
+return AVERROR(EINVAL);
+}
+
+ffio_wfourcc(pb, "CRYO");
+ffio_wfourcc(pb, "_APC");
+ffio_wfourcc(pb, "1.20");
+avio_wl32(pb, 0); //number or samples
+avio_wl32(pb, par->sample_rate);
+
+//write extradata if we have it (remuxing)
+//else write dummy values and wait for AV_PKT_DATA_NEW_EXTRADATA (encoding)
+if (par->extradata_size) {
+avio_write(pb, par->extradata, par->extradata_size);
+} else {
+avio_wl64(pb, 0);
+}
+
+avio_wl32(pb, par->channels-1);
+avpriv_set_pts_info(st, 64, 1, par->sample_rate);
+return 0;
+}
+
+static int apc_write_packet(AVFormatContext *s, AVPacket *pkt)
+{
+int extradata_size = 0;
+uint8_t *extradata = av_packet_get_side_data(
+pkt,
[FFmpeg-devel] [PATCH 1/3] apc: Read duration from file
The first in a series of CRYO APC patches /TomasFrom d0988031b97c22a9bda6832eb8871e917335aae6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Fri, 23 Nov 2018 14:12:50 +0100 Subject: [PATCH 1/3] apc: Read duration from file --- libavformat/apc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/apc.c b/libavformat/apc.c index b180a50c9b..52f93df3ca 100644 --- a/libavformat/apc.c +++ b/libavformat/apc.c @@ -49,8 +49,9 @@ static int apc_read_header(AVFormatContext *s) st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO; st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_APC; -avio_rl32(pb); /* number of samples */ +st->duration = avio_rl32(pb); /* number of samples */ st->codecpar->sample_rate = avio_rl32(pb); +avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); /* initial predictor values for adpcm decoder */ if (ff_get_extradata(s, st->codecpar, pb, 2 * 4) < 0) -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes startcode condition and update FATE
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, December 10, 2018 01:40
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes
> startcode condition and update FATE
>
> >
> > #define START_CODE 0x01 ///< start_code_prefix_one_3bytes
> > +#define START_CODE_4 0x0001 ///< start_code_4bytes
>
> (There is no syntax element called "start_code_4bytes".)
>
Deleted.
> >
> > #define IS_IRAP_NAL(nal) (nal->type >= 16 && nal->type <= 23)
> > #define IS_IDR_NAL(nal) (nal->type == HEVC_NAL_IDR_W_RADL || nal-
> >type == HEVC_NAL_IDR_N_LP)
> > @@ -239,7 +240,7 @@ static int parse_nal_units(AVCodecParserContext *s,
> const uint8_t *buf,
> > }
> > }
> > /* didn't find a picture! */
> > -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> > +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with
> size %d\n", buf_size);
> > return -1;
> > }
> >
> > @@ -267,8 +268,7 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> HEVC_NAL_SEI_PREFIX ||
> > (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
> > if (pc->frame_start_found) {
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > } else if (nut <= HEVC_NAL_RASL_R ||
> > (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT))
> {
> > @@ -277,14 +277,19 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if (!pc->frame_start_found) {
> > pc->frame_start_found = 1;
> > } else { // First slice of next frame found
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > }
> > }
> > }
> >
> > return END_NOT_FOUND;
> > +
> > +found:
> > +pc->frame_start_found = 0;
> > +if (((pc->state64 >> 3 * 8) & 0x) == START_CODE_4)
> > +return i - 6;
> > +return i - 5;
> > }
>
> Maybe? Special-casing four bytes doesn't make me feel good about this,
> given that leading_zero_8bits can be included as many times as you like at
> the beginning of a NAL unit.
>
> If there are a large number of zeroes between two frames, which packet do
> you want them to end up in? This changes it from "all at the end of the first
> frame" to "all except the last one at the end of the first frame", and it's
> not
> immediately obvious to me why that would be the right choice. Why not, for
> example, put all of the zeroes into the second frame?
Modified and sent a new patch to find all leading_zero_8bits and put them into
the second frame.
Thanks
---
Linjie Fu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
Given that leading_zero_8bits can be included many times at the beginning
of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
in last frame and may lead to some warnings in parse_nal_units when s->flags
is set to PARSER_FLAG_COMPLETE_FRAMES.
Modify to put all of the zeroes between two frames into the second frame.
Modify the code to print the buf_size like in H264 and reduce the duplication.
Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
{ 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
To verify the output of FATE:
ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
+bitexact hevc-mp4.mov
ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
Signed-off-by: Linjie Fu
---
[v2]: Update FATE checksum.
[v3]: Cope with more leading_zero_8bits cases.
libavcodec/hevc_parser.c | 14 +-
tests/fate/hevc.mak | 2 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 369d1338d0..62100ac654 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -239,7 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
}
}
/* didn't find a picture! */
-av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
+av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with size
%d\n", buf_size);
return -1;
}
@@ -267,8 +267,7 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
HEVC_NAL_SEI_PREFIX ||
(nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
if (pc->frame_start_found) {
-pc->frame_start_found = 0;
-return i - 5;
+goto found;
}
} else if (nut <= HEVC_NAL_RASL_R ||
(nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
@@ -277,14 +276,19 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
if (!pc->frame_start_found) {
pc->frame_start_found = 1;
} else { // First slice of next frame found
-pc->frame_start_found = 0;
-return i - 5;
+goto found;
}
}
}
}
return END_NOT_FOUND;
+
+found:
+pc->frame_start_found = 0;
+while (i - 6 >= 0 && !buf[i - 6])
+i--;
+return i - 5;
}
static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index db3ea19340..ab8da53535 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER
HEVC_MP4TOANNEXB_BSF MOV_MUXER
fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
fate-hevc-bsf-mp4toannexb: CMD = md5 -i $(TARGET_PATH)/tests/data/hevc-mp4.mov
-c:v copy -fflags +bitexact -f hevc
fate-hevc-bsf-mp4toannexb: CMP = oneline
-fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
+fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
$(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact
FATE_HEVC += fate-hevc-skiploopfilter
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: calculate and store DAR from user SAR
mån 2018-12-10 klockan 10:17 +0100 skrev Paul B Mahol:
> > Signed-off-by: Paul B Mahol
> ---
> libavformat/mxfenc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..006a9da1f8 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2368,6 +2368,11 @@ static int mxf_write_header(AVFormatContext *s)
> sc->v_chroma_sub_sample = 2;
> sc->color_siting = 0xFF;
>
> +if (st->codecpar->sample_aspect_ratio.num &&
> st->codecpar->sample_aspect_ratio.den) {
> +sc->aspect_ratio =
> av_mul_q(st->codecpar->sample_aspect_ratio,
> +av_make_q(st->codecpar->width,
> st->codecpar->height));
> +}
> +
Nice, look OK of course
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add gif parser
On 12/9/18, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/Makefile | 1 + > libavcodec/gif_parser.c | 188 > libavcodec/parsers.c| 1 + > 3 files changed, 190 insertions(+) > create mode 100644 libavcodec/gif_parser.c > Will apply set ASAP! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mxfenc: calculate and store DAR from user SAR
Signed-off-by: Paul B Mahol
---
libavformat/mxfenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3549b4137d..006a9da1f8 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2368,6 +2368,11 @@ static int mxf_write_header(AVFormatContext *s)
sc->v_chroma_sub_sample = 2;
sc->color_siting = 0xFF;
+if (st->codecpar->sample_aspect_ratio.num &&
st->codecpar->sample_aspect_ratio.den) {
+sc->aspect_ratio = av_mul_q(st->codecpar->sample_aspect_ratio,
+av_make_q(st->codecpar->width,
st->codecpar->height));
+}
+
if (pix_desc) {
sc->component_depth = pix_desc->comp[0].depth;
sc->h_chroma_sub_sample = 1 << pix_desc->log2_chroma_w;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek
Gyan , 10 Ara 2018 Pzt, 11:47 tarihinde şunu yazdı: > > On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: > > 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos : > > > >> It appears to me that NewTek abused our willingness to add an optional > >> external nonfree library, I don't see many better options. See Ticket > >> #7589 and a blog post by a NewTek engineer confirming the issue. > >> > >> Patch untested. > > After several people have objected claiming NewTek would fix this > > situation, a week has passed: No visible reaction whatsoever, not > > even requesting more time. > > > > What are those suggesting who were against this patch? > > Contact Newtek with your concerns and a deadline and what action you're > considering beyond the deadline. > > Gyan Newtek released 3.7.1 version of their SDK which does not include ffmpeg.exe md5sum is: e2a29174333f20cb6cc66ec5e27ccbf3 Downloads/NewTek NDI 3.7.1 SDK.exe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter
Hi Mark, Do you have any comments regarding this patch ? Best Regards, Zachary > -Original Message- > From: Zhou, Zachary > Sent: Monday, December 3, 2018 6:56 PM > To: FFmpeg development discussions and patches > Cc: Zhou, Zachary > Subject: RE: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter > > ping? any more comments ? > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek
On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos : It appears to me that NewTek abused our willingness to add an optional external nonfree library, I don't see many better options. See Ticket #7589 and a blog post by a NewTek engineer confirming the issue. Patch untested. After several people have objected claiming NewTek would fix this situation, a week has passed: No visible reaction whatsoever, not even requesting more time. What are those suggesting who were against this patch? Contact Newtek with your concerns and a deadline and what action you're considering beyond the deadline. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
On Mon, Dec 10, 2018 at 02:54:54 +0100, Carl Eugen Hoyos wrote: > I hope somebody can prove me wrong! Not sure, see below. > This would need a slightly more sophisticated update to the decoder. Because it is also presumed incorrect? > put_bits(p, 16, 0x0102); > put_bits(p, 8, 0); /* units type: 0 - aspect ratio */ > -put_bits(p, 16, sar.num); > put_bits(p, 16, sar.den); > +put_bits(p, 16, sar.num); > put_bits(p, 8, 0); /* thumbnail width */ If a 640x480 (640 x dimension, 480 y dimension) image has a SAR of 4/3, 4 (or the x dimension) is its numerator, 3 (or the y dimension) is its denominator. The spec (and Wikipedia) says: units (1 byte) Units for the X and Y densities. units = 0: no units, X and Y specify the pixel aspect ratio units = 1: X and Y are dots per inch units = 2: X and Y are dots per cm Xdensity (2 bytes) Horizontal pixel density Ydensity (2 bytes) Vertical pixel density So Xdensity and Ydensity should be (e.g.) 4 and 3 in this case, which are sar.num and sar.den (judging by the struct's field names), respectively. It seems to me that that is what the original implementation does. What is yours and Ulf's interpretation? Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
