Re: [FFmpeg-devel] 答复: [PATCH] fftools/ffmpeg_ffplay_ffprobe_cmdutils:add -mask_url to replace the protocol address in the command with the asterisk (*)
Wujian(Chin) (12022-12-23): > I've modified most of the issues, and I've explained some of the issues that > don't. > If you don't accept my explanation, do you have any other better suggestions > and methods? I have already made a more detailed comment in the first thread. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] 答复: 答复: [PATCH] fftools/ffmpeg_ffplay_ffprobe_cmdutils:add -mask_url to replace the protocol address in the command with the asterisk (*)
Other issues have been modified. The following three issues have not been
modified. I have explained them:
>> @@ -215,13 +249,13 @@ static void prepare_app_arguments(int *argc_ptr, char
>> ***argv_ptr)
>> if (win32_argv_utf8) {
>> *argc_ptr = win32_argc;
>> *argv_ptr = win32_argv_utf8;
>> -return;
>> +goto end;
> We only use goto for error processing.
I think that it's more concise to use code this way.
>> +int i, j;
>> +for (i = 1; i < argc; i++) {
>> +char *match = strstr(argv[i], "://");
>> +if (match) {
>> +int total = strlen(argv[i]);
>> +for (j = 0; j < total; j++) {
>> +argv[i][j] = '*';
>> +}
>Masking the whole URL seems too much. Logins and passwords are introduced by
>the @ character.
I think that it would be better to replace the entire url, so that the code
implementation is simple.
>> +char **argv2;
>> +argv2 = av_mallocz(argc * sizeof(char *));
>sizeof(*argv2)
>
>> +maskFlag = 0;
>> +if (argc > 1 && !strcmp(argv[1], "-mask_url")) {
>> +argv[1] = argv[0];
>> +maskFlag = 1;
>> +argc--;
>> +argv++;
>> +}
>This option is not special nor important enough to warrant a special treatment
>like that.
This option needs to replace the URL. It is more appropriate to judge mask_url
and copy argv in this place.
If you think my idea is wrong, please give your specific advice,
thank you, Nicolas George.
-邮件原件-
发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 Nicolas George
发送时间: 2022年12月23日 17:13
收件人: FFmpeg development discussions and patches
抄送: wangqinghua (I)
主题: Re: [FFmpeg-devel] 答复: [PATCH] fftools/ffmpeg_ffplay_ffprobe_cmdutils:add
-mask_url to replace the protocol address in the command with the asterisk (*)
Wujian(Chin) (12022-12-23):
> I've modified most of the issues, and I've explained some of the issues that
> don't.
> If you don't accept my explanation, do you have any other better suggestions
> and methods?
I have already made a more detailed comment in the first thread.
--
Nicolas George
___
ffmpeg-user mailing list
ffmpeg-u...@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-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] Would a crypto file be acceptable?
ons 2022-12-21 klockan 16:44 +0100 skrev Mark Gaiser: > Hi, > > The ffmpeg crypto protocol handler [1] allows one to play encrypted > media. > > The great thing here is that it allows playback of any media format > that > ffmpeg supports! > Have a container format like mkv as an encrypted blob, no problem for > the > crypto plugin! > > I'm explicitly mentioning mkv (though there's many more) here because > that > isn't possible in HLS/MPD. While those streaming formats handle > encryption > too, they are very limited in terms of supported codecs and > containers. > > Playback of encrypted data works like this: > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > > While this works just fine, it's limited in use because the > cryptography > details have to be passed on the command line. Applications that > might well > support much of ffmpeg functionality can't easily hook into the > crypto > functionality. Take KODI for example, it allows playback of many of > the > formats ffmpeg supports but anything with crypto just isn't possible. > In > fact, anything that requires custom command line arguments isn't > possible. This sounds like business logic. Fix KODI instead. Much of this can also be handled by any competent OS at the filesystem layer. /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] fftools/ffmpeg_ffplay_ffprobe_cmdutils:add -mask_url to replace the protocol address in the command with the asterisk (*)
Wujian(Chin) (12022-12-23): > If you think my idea is wrong, please give your specific advice, I already have. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mxfdec: Reduce overflows in essence_length computation
fre 2022-12-23 klockan 00:25 +0100 skrev Michael Niedermayer:
> On Wed, Nov 16, 2022 at 12:49:10PM +0100, Tomas Härdin wrote:
> > sön 2022-11-13 klockan 00:44 +0100 skrev Michael Niedermayer:
> > > Fixes: signed integer overflow: -3741319169 - 9223372036823449370
> > > cannot be represented in type 'long'
> > > Fixes: 51896/clusterfuzz-testcase-minimized-
> > > ffmpeg_dem_MXF_fuzzer-
> > > 513039428681728
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/mxfdec.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index e6118e141d..42109cb43a 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -100,7 +100,7 @@ typedef struct MXFPartition {
> > > uint64_t previous_partition;
> > > int index_sid;
> > > int body_sid;
> > > - int64_t this_partition;
> > > + uint64_t this_partition;
> > > int64_t essence_offset; ///< absolute offset of
> > > essence
> > > int64_t essence_length;
> > > int32_t kag_size;
> > > @@ -3519,8 +3519,12 @@ static void
> > > mxf_compute_essence_containers(AVFormatContext *s)
> > > p->essence_offset = p->first_essence_klv.offset;
> > >
> > > /* essence container spans to the next partition */
> > > - if (x < mxf->partitions_count - 1)
> > > - p->essence_length = mxf-
> > > > partitions[x+1].this_partition - p->essence_offset;
> > > + if (x < mxf->partitions_count - 1) {
> > > + if (mxf->partitions[x+1].this_partition < p-
> > > > essence_offset) {
> > > + p->essence_length = -1;
> > > + } else
> > > + p->essence_length = mxf-
> > > > partitions[x+1].this_partition - p->essence_offset;
> > > + }
> >
> > A better solution might be to record the actual offset of the
> > partitions rather than relying on ThisPartition. Then we can
> > guarantee
> > that they are strictly increasing.
>
> do you mean that pack_ofs could be used here ?
this_partition should be == pack_ofs - run_in. I think we can just nuke
this_partition in the struct and use pack_ofs - run_in everywhere. Emit
a warning or bail out if any partition does not obey this contraint,
since such files have likely been written by bad muxers.
> but as pack_ofs is signed that either means dealing with potentially
> negative
> or changing it to uint64_t or adding a new field and avio_tell()
> somewhere?
pack_ofs can only be negative in case of error, in which case we should
bail out anyway. Something must be very wrong if lavf can't avio_tell()
For every partition, pack_ofs >= run_in. this_partition >= 0, and in
particular this_partition == 0 for the very first partition.
This is reminding me that I had some finer points to fix related to
run_in and deleting the superfluous sync stuff that's currently in the
code. Baptiste is fine with that, as it's a relic from when mxfdec
didn't have proper seek support.
/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".
[FFmpeg-devel] [PATCH 0/2] Initial support for fragmented TTML muxing
This enables pushing TTML together with another track (usually video) as part of CMAF Ingest, as defined by the DASH-IF Live Media Ingest Protocol. Currently does not function well with just the subtitle track unless the API user explicitly requests fragmentation with a nullptr packet, as the generic fragmentation decision logic is based on tracks which do not require squashing. Currently does support overlapping subtitles, but the implementation utilizes another packet queue for it, which is probably not optimal. Recommendations on how to improve things are welcome. Jan Ekström (2): avcodec/avpacket: add functionality to prepend to AVPacketLists avformat/movenc: add support for fragmented TTML muxing libavcodec/avpacket.c| 20 +++-- libavcodec/packet_internal.h | 2 + libavformat/movenc.c | 9 -- libavformat/movenc_ttml.c| 163 ++- 4 files changed, 176 insertions(+), 18 deletions(-) -- 2.38.1 ___ 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/2] avcodec/avpacket: add functionality to prepend to AVPacketLists
From: Jan Ekström
Signed-off-by: Jan Ekström
---
libavcodec/avpacket.c| 20 +++-
libavcodec/packet_internal.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 5fef65e97a..01eb9896d5 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -539,6 +539,7 @@ int avpriv_packet_list_put(PacketList *packet_buffer,
int flags)
{
PacketListEntry *pktl = av_malloc(sizeof(*pktl));
+unsigned int update_end_point = 1;
int ret;
if (!pktl)
@@ -562,13 +563,22 @@ int avpriv_packet_list_put(PacketList *packet_buffer,
pktl->next = NULL;
-if (packet_buffer->head)
-packet_buffer->tail->next = pktl;
-else
+if (packet_buffer->head) {
+if (flags & FF_PACKETLIST_FLAG_PREPEND) {
+pktl->next = packet_buffer->head;
+packet_buffer->head = pktl;
+update_end_point = 0;
+} else {
+packet_buffer->tail->next = pktl;
+}
+} else
packet_buffer->head = pktl;
-/* Add the packet in the buffered packet list. */
-packet_buffer->tail = pktl;
+if (update_end_point) {
+/* Add the packet in the buffered packet list. */
+packet_buffer->tail = pktl;
+}
+
return 0;
}
diff --git a/libavcodec/packet_internal.h b/libavcodec/packet_internal.h
index 92a0d4e6d5..43dc6222ce 100644
--- a/libavcodec/packet_internal.h
+++ b/libavcodec/packet_internal.h
@@ -32,6 +32,8 @@ typedef struct PacketList {
PacketListEntry *head, *tail;
} PacketList;
+#define FF_PACKETLIST_FLAG_PREPEND (1 << 0) /**< Prepend created AVPacketList
instead of appending */
+
/**
* Append an AVPacket to the list.
*
--
2.38.1
___
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/2] avformat/movenc: add support for fragmented TTML muxing
From: Jan Ekström
Attempts to base the fragmentation timing on other streams
as most receivers expect media fragments to be more or less
aligned.
Currently does not support fragmentation on subtitle track
only, as the subtitle packet queue timings would have to be
checked in addition to the current fragmentation timing logic.
Signed-off-by: Jan Ekström
---
libavformat/movenc.c | 9 ---
libavformat/movenc_ttml.c | 163 +-
2 files changed, 159 insertions(+), 13 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d49892283..e9a7984f8a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7188,15 +7188,6 @@ static int mov_init(AVFormatContext *s)
track->squash_fragment_samples_to_one =
ff_is_ttml_stream_paragraph_based(track->par);
-if (mov->flags & FF_MOV_FLAG_FRAGMENT &&
-track->squash_fragment_samples_to_one) {
-av_log(s, AV_LOG_ERROR,
- "Fragmentation is not currently supported for "
- "TTML in MP4/ISMV (track synchronization between "
- "subtitles and other media is not yet
implemented)!\n");
-return AVERROR_PATCHWELCOME;
-}
-
if (track->mode != MODE_ISM &&
track->par->codec_tag == MOV_ISMV_TTML_TAG &&
s->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
diff --git a/libavformat/movenc_ttml.c b/libavformat/movenc_ttml.c
index 6deae49657..27ec7d9487 100644
--- a/libavformat/movenc_ttml.c
+++ b/libavformat/movenc_ttml.c
@@ -54,6 +54,50 @@ static int mov_init_ttml_writer(MOVTrack *track,
AVFormatContext **out_ctx)
return 0;
}
+static void mov_calculate_start_and_end_of_other_tracks(
+AVFormatContext *s, MOVTrack *track, int64_t *start_pts, int64_t *end_pts)
+{
+MOVMuxContext *mov = s->priv_data;
+
+// Initialize at the end of the previous document/fragment, which is NOPTS
+// until the first fragment is created.
+int64_t max_track_end_dts = *start_pts = track->end_pts;
+
+for (unsigned int i = 0; i < s->nb_streams; i++) {
+MOVTrack *other_track = &mov->tracks[i];
+
+// Skip our own track, any other track that needs squashing,
+// or any track which still has its start_dts at NOPTS or
+// any track that did not yet get any packets.
+if (track == other_track ||
+other_track->squash_fragment_samples_to_one ||
+other_track->start_dts == AV_NOPTS_VALUE ||
+!other_track->entry) {
+continue;
+}
+
+{
+int64_t picked_start =
av_rescale_q_rnd(other_track->cluster[0].dts + other_track->cluster[0].cts,
+other_track->st->time_base,
+track->st->time_base,
+AV_ROUND_NEAR_INF |
AV_ROUND_PASS_MINMAX);
+int64_t picked_end = av_rescale_q_rnd(other_track->end_pts,
+other_track->st->time_base,
+track->st->time_base,
+AV_ROUND_NEAR_INF |
AV_ROUND_PASS_MINMAX);
+
+if (*start_pts == AV_NOPTS_VALUE)
+*start_pts = picked_start;
+else if (picked_start >= track->end_pts)
+*start_pts = FFMIN(*start_pts, picked_start);
+
+max_track_end_dts = FFMAX(max_track_end_dts, picked_end);
+}
+}
+
+*end_pts = max_track_end_dts;
+}
+
static int mov_write_ttml_document_from_queue(AVFormatContext *s,
AVFormatContext *ttml_ctx,
MOVTrack *track,
@@ -65,13 +109,87 @@ static int
mov_write_ttml_document_from_queue(AVFormatContext *s,
int64_t start_ts = track->start_dts == AV_NOPTS_VALUE ?
0 : (track->start_dts + track->track_duration);
int64_t end_ts = start_ts;
+unsigned int time_limited = 0;
+PacketList back_to_queue_list = { 0 };
+
+if (*out_start_ts != AV_NOPTS_VALUE) {
+// we have non-nopts values here, thus we have been given a time range
+time_limited = 1;
+start_ts = *out_start_ts;
+end_ts = *out_start_ts + *out_duration;
+}
if ((ret = avformat_write_header(ttml_ctx, NULL)) < 0) {
return ret;
}
while (!avpriv_packet_list_get(&track->squashed_packet_queue, pkt)) {
-end_ts = FFMAX(end_ts, pkt->pts + pkt->duration);
+unsigned int stop_at_current_packet = 0;
+int64_t pts_before = pkt->pts;
+int64_t duration_before = pkt->duration;
+
+if (time_limited) {
+// special cases first:
+
Re: [FFmpeg-devel] [PATCH 2/2] avformat/movenc: add support for fragmented TTML muxing
Jan Ekström:
> From: Jan Ekström
>
> Attempts to base the fragmentation timing on other streams
> as most receivers expect media fragments to be more or less
> aligned.
>
> Currently does not support fragmentation on subtitle track
> only, as the subtitle packet queue timings would have to be
> checked in addition to the current fragmentation timing logic.
>
> Signed-off-by: Jan Ekström
> ---
> libavformat/movenc.c | 9 ---
> libavformat/movenc_ttml.c | 163 +-
> 2 files changed, 159 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 7d49892283..e9a7984f8a 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -7188,15 +7188,6 @@ static int mov_init(AVFormatContext *s)
> track->squash_fragment_samples_to_one =
> ff_is_ttml_stream_paragraph_based(track->par);
>
> -if (mov->flags & FF_MOV_FLAG_FRAGMENT &&
> -track->squash_fragment_samples_to_one) {
> -av_log(s, AV_LOG_ERROR,
> - "Fragmentation is not currently supported for "
> - "TTML in MP4/ISMV (track synchronization between "
> - "subtitles and other media is not yet
> implemented)!\n");
> -return AVERROR_PATCHWELCOME;
> -}
> -
> if (track->mode != MODE_ISM &&
> track->par->codec_tag == MOV_ISMV_TTML_TAG &&
> s->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> diff --git a/libavformat/movenc_ttml.c b/libavformat/movenc_ttml.c
> index 6deae49657..27ec7d9487 100644
> --- a/libavformat/movenc_ttml.c
> +++ b/libavformat/movenc_ttml.c
> @@ -54,6 +54,50 @@ static int mov_init_ttml_writer(MOVTrack *track,
> AVFormatContext **out_ctx)
> return 0;
> }
>
> +static void mov_calculate_start_and_end_of_other_tracks(
> +AVFormatContext *s, MOVTrack *track, int64_t *start_pts, int64_t
> *end_pts)
> +{
> +MOVMuxContext *mov = s->priv_data;
> +
> +// Initialize at the end of the previous document/fragment, which is
> NOPTS
> +// until the first fragment is created.
> +int64_t max_track_end_dts = *start_pts = track->end_pts;
> +
> +for (unsigned int i = 0; i < s->nb_streams; i++) {
> +MOVTrack *other_track = &mov->tracks[i];
> +
> +// Skip our own track, any other track that needs squashing,
> +// or any track which still has its start_dts at NOPTS or
> +// any track that did not yet get any packets.
> +if (track == other_track ||
> +other_track->squash_fragment_samples_to_one ||
> +other_track->start_dts == AV_NOPTS_VALUE ||
> +!other_track->entry) {
> +continue;
> +}
> +
> +{
> +int64_t picked_start =
> av_rescale_q_rnd(other_track->cluster[0].dts + other_track->cluster[0].cts,
> +
> other_track->st->time_base,
> +track->st->time_base,
> +AV_ROUND_NEAR_INF |
> AV_ROUND_PASS_MINMAX);
> +int64_t picked_end = av_rescale_q_rnd(other_track->end_pts,
> +
> other_track->st->time_base,
> +track->st->time_base,
> +AV_ROUND_NEAR_INF |
> AV_ROUND_PASS_MINMAX);
> +
> +if (*start_pts == AV_NOPTS_VALUE)
> +*start_pts = picked_start;
> +else if (picked_start >= track->end_pts)
> +*start_pts = FFMIN(*start_pts, picked_start);
> +
> +max_track_end_dts = FFMAX(max_track_end_dts, picked_end);
> +}
> +}
> +
> +*end_pts = max_track_end_dts;
> +}
> +
> static int mov_write_ttml_document_from_queue(AVFormatContext *s,
>AVFormatContext *ttml_ctx,
>MOVTrack *track,
> @@ -65,13 +109,87 @@ static int
> mov_write_ttml_document_from_queue(AVFormatContext *s,
> int64_t start_ts = track->start_dts == AV_NOPTS_VALUE ?
> 0 : (track->start_dts + track->track_duration);
> int64_t end_ts = start_ts;
> +unsigned int time_limited = 0;
> +PacketList back_to_queue_list = { 0 };
> +
> +if (*out_start_ts != AV_NOPTS_VALUE) {
> +// we have non-nopts values here, thus we have been given a time
> range
> +time_limited = 1;
> +start_ts = *out_start_ts;
> +end_ts = *out_start_ts + *out_duration;
> +}
>
> if ((ret = avformat_write_header(ttml_ctx, NULL)) < 0) {
> return ret;
> }
>
> while (!avpriv_packet_list_get(&track->squashed_packet_queue, pkt)) {
> -end_ts = FF
[FFmpeg-devel] [PATCH] ffmpeg-3.4.12 does not build (i686-w64-mingw32)
Hello, I tried to build ffmpeg-3.4.12, which is the last one supporting Windows XP, but it fails to compile the resource file for Windows. Running verbose build, it prints this output on the console: > $ make V=1 > i686-w64-mingw32-windres -I. -Isrc/ --preprocessor "i686-w64-mingw32-gcc -E > -xc-header -DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT > libavdevice/avdeviceres.o" -o libavdevice/avdeviceres.o > /home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/libavdevice/avdeviceres.rc > /bin/sh: i686-w64-mingw32-gcc -E -xc-header -DRC_INVOKED -MMD -MF > libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or > directory > make: *** > [/home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/ffbuild/common.mak:86: > libavdevice/avdeviceres.o] Error 1 I found a solution by comparing ffbuild/common.mak between this version and the latest 5.1.2, which has already fixed this bug. So, I'm wondering if it could be possible to apply the same patch for fixing this tiny issue in the next maintenance release of 3.4.x branch, if it will happen in the future. I attached that patch in this email for reference, if somebody can import that line from development sources. Sincerely, Carlo Bramini.--- origsrc/ffmpeg-3.4.12/ffbuild/common.mak2022-10-27 22:21:00.0 +0200 +++ src/ffmpeg-3.4.12/ffbuild/common.mak2022-12-23 10:46:32.733625900 +0100 @@ -83,7 +83,7 @@ COMPILE_NVCC = $(call COMPILE,NVCC) -$(if $(ASMSTRIPFLAGS), $(STRIP) $(ASMSTRIPFLAGS) $@) %.o: %.rc - $(WINDRES) $(IFLAGS) --preprocessor "$(DEPWINDRES) -E -xc-header -DRC_INVOKED $(CC_DEPFLAGS)" -o $@ $< + $(WINDRES) $(IFLAGS) $(foreach ARG,$(CC_DEPFLAGS),--preprocessor-arg "$(ARG)") -o $@ $< %.i: %.c $(CC) $(CCFLAGS) $(CC_E) $< ___ 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] Would a crypto file be acceptable?
On Fri, Dec 23, 2022 at 12:05 PM Tomas Härdin wrote: > ons 2022-12-21 klockan 16:44 +0100 skrev Mark Gaiser: > > Hi, > > > > The ffmpeg crypto protocol handler [1] allows one to play encrypted > > media. > > > > The great thing here is that it allows playback of any media format > > that > > ffmpeg supports! > > Have a container format like mkv as an encrypted blob, no problem for > > the > > crypto plugin! > > > > I'm explicitly mentioning mkv (though there's many more) here because > > that > > isn't possible in HLS/MPD. While those streaming formats handle > > encryption > > too, they are very limited in terms of supported codecs and > > containers. > > > > Playback of encrypted data works like this: > > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > > > > While this works just fine, it's limited in use because the > > cryptography > > details have to be passed on the command line. Applications that > > might well > > support much of ffmpeg functionality can't easily hook into the > > crypto > > functionality. Take KODI for example, it allows playback of many of > > the > > formats ffmpeg supports but anything with crypto just isn't possible. > > In > > fact, anything that requires custom command line arguments isn't > > possible. > > This sounds like business logic. Fix KODI instead. Much of this can > also be handled by any competent OS at the filesystem layer. > Then M3U as a format is business logic too. HLS and MPD are business logic too. At least, based on your comment, they would fall into that same category. The difference between those formats and my suggestion? M3U -> playback of very specific formats "crypto" -> playback of anything ffmpeg supports M3U has a file format. crypto has none. Say a hypothetical streaming service (no, i don't have ambitions to start one) would want to give access to higher quality and different codecs then is possible with HLS/MPD. A service like that currently has to invent their own custom format, probably as a fork of ffmpeg, to accomplish this. With a file format for crypto this functionality would just exist. I'm suggesting that giving crypto this file format would be a win with not even that much effort on the ffmpeg code side. > /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". > ___ 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] Would a crypto file be acceptable?
Mark Gaiser (12022-12-23): > Then M3U as a format is business logic too. > HLS and MPD are business logic too. > At least, based on your comment, they would fall into that same category. > > The difference between those formats and my suggestion? First difference: they point to several files, yours is about a single file. Second difference: they exist out there, yours you are trying to invent just for that. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Would a crypto file be acceptable?
On Fri, Dec 23, 2022 at 5:34 PM Nicolas George wrote: > Mark Gaiser (12022-12-23): > > Then M3U as a format is business logic too. > > HLS and MPD are business logic too. > > At least, based on your comment, they would fall into that same category. > > > > The difference between those formats and my suggestion? > > First difference: they point to several files, yours is about a single > file. > They actually point to N files. Could also be just 1. Also, they could use this proposed ".crypto" file as their files. > Second difference: they exist out there, yours you are trying to invent > just for that. > That's just lame. I'm not trying to invent it just to invent something. I have an actual need for this where this would be a solution. > > -- > 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] Would a crypto file be acceptable?
Mark Gaiser (12022-12-23): > They actually point to N files. Could also be just 1. Wow, what an interesing and crucial distinction for the discussion. Goodbye. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Would a crypto file be acceptable?
I can't find a single thing about this in the ffmpeg documentation. How is this called, where can I read more about it and - most importantly - does it work out of the box? No, it does not. This was a suggestion that sounds like a better option than a custom metadata descriptor file that is only used for one particular use case, at least to me. Regardless, this would be a rather big security hole as a potential key would be plainly visible in url logging. Therefore "hiding" it in a file is probably a better and more secure approach. The same applies to your custom descriptor file, of course. Especially if it's stored on disk, as ramdisks/pipes/sockets aren't as ubiquitous as you might think. ___ 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] AC3 decoding throws error number -16976906 ... vlc plays well
I have got a mpeg ts file with following composition (shown by ffprobe) ffprobe version N-109444-geef763c705 Copyright (c) 2007-2022 the FFmpeg developers built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04) configuration: --enable-openssl libavutil 57. 43.100 / 57. 43.100 libavcodec 59. 55.103 / 59. 55.103 libavformat59. 34.102 / 59. 34.102 libavdevice59. 8.101 / 59. 8.101 libavfilter 8. 53.100 / 8. 53.100 libswscale 6. 8.112 / 6. 8.112 libswresample 4. 9.100 / 4. 9.100 [mpegts @ 0x56201c2c1cc0] Could not find codec parameters for stream 1 (Audio: ac3 ([129][0][0][0] / 0x0081), stereo, fltp): unspecified sample rate Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (500) options Input #0, mpegts, from 'ff_vlc.ts': Duration: 00:10:00.02, start: 1.40, bitrate: 1839 kb/s Program 1 Metadata: service_name: Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 856x480 [SAR 320:321 DAR 16:9], 30 fps, 59.94 tbr, 90k tbn Stream #0:1[0x101](spa): Audio: ac3 ([129][0][0][0] / 0x0081), stereo, fltp -- I intend to transcode this so that I copy the video as it is but the audio will be encoded to aac ...so that I can play it in the browser. I use the following ffmpeg command to attempt that ffmpeg -i ff_vlc.ts -vcodec copy -acodec aac -map 0:v:0 -map 0:a:0 ff_vlc_2.ts this throws errors with -16976906 as follows..( I have clipped the repetitive excessively long output) ffmpeg -i ff_vlc.ts -vcodec copy -acodec aac -map 0:v:0 -map 0:a:0 ff_vlc_2.ts ffmpeg version N-109444-geef763c705 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04) configuration: --enable-openssl libavutil 57. 43.100 / 57. 43.100 libavcodec 59. 55.103 / 59. 55.103 libavformat59. 34.102 / 59. 34.102 libavdevice59. 8.101 / 59. 8.101 libavfilter 8. 53.100 / 8. 53.100 libswscale 6. 8.112 / 6. 8.112 libswresample 4. 9.100 / 4. 9.100 [mpegts @ 0x55b4369b2440] Could not find codec parameters for stream 1 (Audio: ac3 ([129][0][0][0] / 0x0081), stereo, fltp): unspecified sample rate Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (500) options Input #0, mpegts, from 'ff_vlc.ts': Duration: 00:10:00.02, start: 1.40, bitrate: 1839 kb/s Program 1 Metadata: service_name: Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 856x480 [SAR 320:321 DAR 16:9], 30 fps, 59.94 tbr, 90k tbn Stream #0:1[0x101](spa): Audio: ac3 ([129][0][0][0] / 0x0081), stereo, fltp Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (ac3 (native) -> aac (native)) Press [q] to stop, [?] for help Error while decoding stream #0:1: Error number -16976906 occurred Last message repeated 17065 times Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Error while decoding stream #0:1: Error number -16976906 occurred Last message repeated 2 times Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Error while decoding stream #0:1: Error number -16976906 occurred Last message repeated 2 times Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Error while decoding stream #0:1: Error number -16976906 occurred Last message repeated 2 times (repetitive output clipped and removed) Last message repeated 2 times Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Error while decoding stream #0:1: Error number -16976906 occurred Last message repeated 2 times Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Too many packets buffered for output stream 0:0. Error submitting a packet to the muxer for output stream #0:0. Error while decoding stream #0:1: Error number -16976906 occurred Too many packets buffered fo
Re: [FFmpeg-devel] AC3 decoding throws error number -16976906 ... vlc plays well
On 12/23/2022 3:29 PM, Mahesh Velankar wrote: I have got a mpeg ts file with following composition (shown by ffprobe) Open a ticket in https://trac.ffmpeg.org/ with the sample to reproduce this problem. Alternatively, write to the ffmpeg-user mailing list, as this one is for development. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/mjpegbdec: Check for AVDISCARD_ALL
On 11/12/2022 8:44 PM, Michael Niedermayer wrote:
Fixes: Assertion failure
Fixes:
51825/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-6393802688692224
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegbdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mjpegbdec.c b/libavcodec/mjpegbdec.c
index 98c64b44ca..a82a95d70a 100644
--- a/libavcodec/mjpegbdec.c
+++ b/libavcodec/mjpegbdec.c
@@ -141,9 +141,10 @@ read_header:
av_log(avctx, AV_LOG_WARNING, "no picture\n");
return buf_size;
}
-
av_frame_move_ref(rframe, s->picture_ptr);
s->got_picture = 0;
+if (avctx->skip_frame == AVDISCARD_ALL)
+return AVERROR(EAGAIN);
Decode callback decoders don't return EAGAIN. If they don't generate a
frame but there was no error, then they return the amount of bytes
consumed while ensuring got_frame is 0.
*got_frame = 1;
if (!s->lossless && avctx->debug & FF_DEBUG_QP) {
___
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] ffmpeg-3.4.12 does not build (i686-w64-mingw32)
On Fri, Dec 23, 2022 at 04:04:31PM +0100, Carlo Bramini wrote: > Hello, > > I tried to build ffmpeg-3.4.12, which is the last one supporting Windows XP, > but it fails to compile the resource file for Windows. > Running verbose build, it prints this output on the console: > > > $ make V=1 > > i686-w64-mingw32-windres -I. -Isrc/ --preprocessor "i686-w64-mingw32-gcc -E > > -xc-header -DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT > > libavdevice/avdeviceres.o" -o libavdevice/avdeviceres.o > > /home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/libavdevice/avdeviceres.rc > > /bin/sh: i686-w64-mingw32-gcc -E -xc-header -DRC_INVOKED -MMD -MF > > libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or > > directory > > make: *** > > [/home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/ffbuild/common.mak:86: > > libavdevice/avdeviceres.o] Error 1 > > I found a solution by comparing ffbuild/common.mak between this version and > the latest 5.1.2, which has already fixed this bug. > So, I'm wondering if it could be possible to apply the same patch for fixing > this tiny issue in the next maintenance release of 3.4.x branch, if it will > happen in the future. > I attached that patch in this email for reference, if somebody can import > that line from development sources. > > Sincerely, > > Carlo Bramini. > --- origsrc/ffmpeg-3.4.12/ffbuild/common.mak 2022-10-27 22:21:00.0 > +0200 > +++ src/ffmpeg-3.4.12/ffbuild/common.mak 2022-12-23 10:46:32.733625900 > +0100 > @@ -83,7 +83,7 @@ COMPILE_NVCC = $(call COMPILE,NVCC) > -$(if $(ASMSTRIPFLAGS), $(STRIP) $(ASMSTRIPFLAGS) $@) > > %.o: %.rc > - $(WINDRES) $(IFLAGS) --preprocessor "$(DEPWINDRES) -E -xc-header > -DRC_INVOKED $(CC_DEPFLAGS)" -o $@ $< > + $(WINDRES) $(IFLAGS) $(foreach ARG,$(CC_DEPFLAGS),--preprocessor-arg > "$(ARG)") -o $@ $< > > %.i: %.c > $(CC) $(CCFLAGS) $(CC_E) $< This is the patch, you seem talking about. commit f9626d1065c43f1d51afe66bdf988b9f33729440 Author: Martin Storsjö Date: Sat May 15 00:42:38 2021 +0300 ffbuild: Avoid using the --preprocessor argument to windres Instead use --preprocessor-arg; in binutils 2.36, the --preprocessor flag was changed so that it no longer accepts a string containing multiple arguments, but the whole --preprocessor argument is treated as the path to the preprocessor executable (where the path can contain spaces). It's currently unclear whether this behaviour will stay or if it is going to be reverted in the future, see discussion at [1]. Just to be safe, avoid using the --preprocessor argument. Don't redeclare the full preprocessing command, but just add the $(CC_DEPFLAGS) options. Based on a patch by Kyle Schwartz. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=27594 Signed-off-by: Martin Storsjö [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 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 3/3] avformat/mxfdec: Reduce overflows in essence_length computation
On Fri, Dec 23, 2022 at 12:47:02PM +0100, Tomas Härdin wrote:
> fre 2022-12-23 klockan 00:25 +0100 skrev Michael Niedermayer:
> > On Wed, Nov 16, 2022 at 12:49:10PM +0100, Tomas Härdin wrote:
> > > sön 2022-11-13 klockan 00:44 +0100 skrev Michael Niedermayer:
> > > > Fixes: signed integer overflow: -3741319169 - 9223372036823449370
> > > > cannot be represented in type 'long'
> > > > Fixes: 51896/clusterfuzz-testcase-minimized-
> > > > ffmpeg_dem_MXF_fuzzer-
> > > > 513039428681728
> > > >
> > > > Found-by: continuous fuzzing process
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavformat/mxfdec.c | 10 +++---
> > > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > index e6118e141d..42109cb43a 100644
> > > > --- a/libavformat/mxfdec.c
> > > > +++ b/libavformat/mxfdec.c
> > > > @@ -100,7 +100,7 @@ typedef struct MXFPartition {
> > > > uint64_t previous_partition;
> > > > int index_sid;
> > > > int body_sid;
> > > > - int64_t this_partition;
> > > > + uint64_t this_partition;
> > > > int64_t essence_offset; ///< absolute offset of
> > > > essence
> > > > int64_t essence_length;
> > > > int32_t kag_size;
> > > > @@ -3519,8 +3519,12 @@ static void
> > > > mxf_compute_essence_containers(AVFormatContext *s)
> > > > p->essence_offset = p->first_essence_klv.offset;
> > > >
> > > > /* essence container spans to the next partition */
> > > > - if (x < mxf->partitions_count - 1)
> > > > - p->essence_length = mxf-
> > > > > partitions[x+1].this_partition - p->essence_offset;
> > > > + if (x < mxf->partitions_count - 1) {
> > > > + if (mxf->partitions[x+1].this_partition < p-
> > > > > essence_offset) {
> > > > + p->essence_length = -1;
> > > > + } else
> > > > + p->essence_length = mxf-
> > > > > partitions[x+1].this_partition - p->essence_offset;
> > > > + }
> > >
> > > A better solution might be to record the actual offset of the
> > > partitions rather than relying on ThisPartition. Then we can
> > > guarantee
> > > that they are strictly increasing.
> >
> > do you mean that pack_ofs could be used here ?
>
> this_partition should be == pack_ofs - run_in. I think we can just nuke
> this_partition in the struct and use pack_ofs - run_in everywhere. Emit
> a warning or bail out if any partition does not obey this contraint,
> since such files have likely been written by bad muxers.
ill post a patch doing that
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect your leaders based on what they did after the last election, not
based on what they say before an election.
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] avformat/mxfdec: Remove this_partition
Suggested-by: Tomas Härdin
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e6118e141d..cbacd03d1e 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -100,7 +100,6 @@ typedef struct MXFPartition {
uint64_t previous_partition;
int index_sid;
int body_sid;
-int64_t this_partition;
int64_t essence_offset; ///< absolute offset of essence
int64_t essence_length;
int32_t kag_size;
@@ -725,10 +724,14 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
UID op;
uint64_t footer_partition;
uint32_t nb_essence_containers;
+uint64_t this_partition;
if (mxf->partitions_count >= INT_MAX / 2)
return AVERROR_INVALIDDATA;
+if (klv_offset < 0 || klv_offset > INT64_MAX - RUN_IN_MAX)
+return AVERROR_INVALIDDATA;
+
tmp_part = av_realloc_array(mxf->partitions, mxf->partitions_count + 1,
sizeof(*mxf->partitions));
if (!tmp_part)
return AVERROR(ENOMEM);
@@ -771,7 +774,13 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->complete = uid[14] > 2;
avio_skip(pb, 4);
partition->kag_size = avio_rb32(pb);
-partition->this_partition = avio_rb64(pb);
+this_partition = avio_rb64(pb);
+if (this_partition != klv_offset + mxf->run_in) {
+av_log(mxf->fc, AV_LOG_WARNING,
+ "this_partition %"PRId64" mismatches %"PRId64"\n",
+ this_partition, klv_offset + mxf->run_in);
+this_partition = klv_offset + mxf->run_in;
+}
partition->previous_partition = avio_rb64(pb);
footer_partition = avio_rb64(pb);
partition->header_byte_count = avio_rb64(pb);
@@ -791,8 +800,8 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
av_dict_set(&s->metadata, "operational_pattern_ul", str, 0);
}
-if (partition->this_partition &&
-partition->previous_partition == partition->this_partition) {
+if (this_partition &&
+partition->previous_partition == this_partition) {
av_log(mxf->fc, AV_LOG_ERROR,
"PreviousPartition equal to ThisPartition %"PRIx64"\n",
partition->previous_partition);
@@ -800,11 +809,11 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
if (!mxf->parsing_backward && mxf->last_forward_partition > 1) {
MXFPartition *prev =
mxf->partitions + mxf->last_forward_partition - 2;
-partition->previous_partition = prev->this_partition;
+partition->previous_partition = prev->pack_ofs + mxf->run_in;
}
/* if no previous body partition are found point to the header
* partition */
-if (partition->previous_partition == partition->this_partition)
+if (partition->previous_partition == this_partition)
partition->previous_partition = 0;
av_log(mxf->fc, AV_LOG_ERROR,
"Overriding PreviousPartition with %"PRIx64"\n",
@@ -826,7 +835,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
"PartitionPack: ThisPartition = 0x%"PRIX64
", PreviousPartition = 0x%"PRIX64", "
"FooterPartition = 0x%"PRIX64", IndexSID = %i, BodySID = %i\n",
-partition->this_partition,
+this_partition,
partition->previous_partition, footer_partition,
partition->index_sid, partition->body_sid);
@@ -887,7 +896,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
return 0;
}
-static uint64_t partition_score(MXFPartition *p)
+static uint64_t partition_score(MXFContext *mxf, MXFPartition *p)
{
uint64_t score;
if (!p)
@@ -900,7 +909,7 @@ static uint64_t partition_score(MXFPartition *p)
score = 3;
else
score = 1;
-return (score << 60) | ((uint64_t)p->this_partition >> 4);
+return (score << 60) | ((uint64_t)p->pack_ofs + mxf->run_in >> 4);
}
static int mxf_add_metadata_set(MXFContext *mxf, MXFMetadataSet **metadata_set)
@@ -3244,10 +3253,10 @@ static const MXFMetadataReadTableEntry
mxf_metadata_read_table[] = {
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, NULL, 0, AnyType },
};
-static int mxf_metadataset_init(MXFMetadataSet *ctx, enum MXFMetadataSetType
type, MXFPartition *partition)
+static int mxf_metadataset_init(MXFContext *mxf, MXFMetadataSet *ctx, enum
MXFMetadataSetType type, MXFPartition *partition)
{
ctx->type = type;
-ctx->partition_score = partition_score(partition);
+ctx->partition_score = partition_score(mxf, partition);
switch (type){
case MultipleDescriptor:
case Descriptor:
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Remove this_partition
On Fri, 23 Dec 2022, Michael Niedermayer wrote:
Suggested-by: Tomas Härdin
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
this_partition should be == pack_ofs - run_in, not pack_ofs + run_in.
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e6118e141d..cbacd03d1e 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -100,7 +100,6 @@ typedef struct MXFPartition {
uint64_t previous_partition;
int index_sid;
int body_sid;
-int64_t this_partition;
int64_t essence_offset; ///< absolute offset of essence
int64_t essence_length;
int32_t kag_size;
@@ -725,10 +724,14 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
UID op;
uint64_t footer_partition;
uint32_t nb_essence_containers;
+uint64_t this_partition;
if (mxf->partitions_count >= INT_MAX / 2)
return AVERROR_INVALIDDATA;
+if (klv_offset < 0 || klv_offset > INT64_MAX - RUN_IN_MAX)
+return AVERROR_INVALIDDATA;
+
tmp_part = av_realloc_array(mxf->partitions, mxf->partitions_count + 1,
sizeof(*mxf->partitions));
if (!tmp_part)
return AVERROR(ENOMEM);
@@ -771,7 +774,13 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->complete = uid[14] > 2;
avio_skip(pb, 4);
partition->kag_size = avio_rb32(pb);
-partition->this_partition = avio_rb64(pb);
+this_partition = avio_rb64(pb);
+if (this_partition != klv_offset + mxf->run_in) {
+av_log(mxf->fc, AV_LOG_WARNING,
+ "this_partition %"PRId64" mismatches %"PRId64"\n",
+ this_partition, klv_offset + mxf->run_in);
+this_partition = klv_offset + mxf->run_in;
+}
partition->previous_partition = avio_rb64(pb);
footer_partition = avio_rb64(pb);
partition->header_byte_count = avio_rb64(pb);
@@ -791,8 +800,8 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
av_dict_set(&s->metadata, "operational_pattern_ul", str, 0);
}
-if (partition->this_partition &&
-partition->previous_partition == partition->this_partition) {
+if (this_partition &&
+partition->previous_partition == this_partition) {
av_log(mxf->fc, AV_LOG_ERROR,
"PreviousPartition equal to ThisPartition %"PRIx64"\n",
partition->previous_partition);
@@ -800,11 +809,11 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
if (!mxf->parsing_backward && mxf->last_forward_partition > 1) {
MXFPartition *prev =
mxf->partitions + mxf->last_forward_partition - 2;
-partition->previous_partition = prev->this_partition;
+partition->previous_partition = prev->pack_ofs + mxf->run_in;
}
/* if no previous body partition are found point to the header
* partition */
-if (partition->previous_partition == partition->this_partition)
+if (partition->previous_partition == this_partition)
partition->previous_partition = 0;
av_log(mxf->fc, AV_LOG_ERROR,
"Overriding PreviousPartition with %"PRIx64"\n",
@@ -826,7 +835,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
"PartitionPack: ThisPartition = 0x%"PRIX64
", PreviousPartition = 0x%"PRIX64", "
"FooterPartition = 0x%"PRIX64", IndexSID = %i, BodySID = %i\n",
-partition->this_partition,
+this_partition,
partition->previous_partition, footer_partition,
partition->index_sid, partition->body_sid);
@@ -887,7 +896,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
return 0;
}
-static uint64_t partition_score(MXFPartition *p)
+static uint64_t partition_score(MXFContext *mxf, MXFPartition *p)
{
uint64_t score;
if (!p)
@@ -900,7 +909,7 @@ static uint64_t partition_score(MXFPartition *p)
score = 3;
else
score = 1;
-return (score << 60) | ((uint64_t)p->this_partition >> 4);
+return (score << 60) | ((uint64_t)p->pack_ofs + mxf->run_in >> 4);
}
You can use pack_ofs here directly instead of this_partition, so the
function prototype does not have to be changed.
Regards,
Marton
static int mxf_add_metadata_set(MXFContext *mxf, MXFMetadataSet **metadata_set)
@@ -3244,10 +3253,10 @@ static const MXFMetadataReadTableEntry
mxf_metadata_read_table[] = {
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, NULL, 0, AnyType },
};
-static int mxf_metadataset_init(MXFMetadataSet *ctx, enum MXFMetadataSetType
type, MXFPartition *partition)
+static int mxf_metadataset_init(MXFContext *mxf, MXFMetadataSet *ctx, enum
MXFMetadataSetType type, MXFPartition *partition)
{
ct
