Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line
I don't think we should be using errno when avoidable, and it is avoidable here
by disallowing min/max int32 values themselves. Or using strtoll.
I'm also rather sceptical about allowing negative values here, does that make
sense?
Admittedly the type is set to just "int", but maybe it should be unsigned
instead?
On 28.06.2019, at 08:46, Olivier MAIGNIAL wrote:
> Hello here!
>
> A simple ping about this patch
> If you have any question, feel free to ask!
>
> Regards,
> Olivier
>
> On Wed, Jun 19, 2019 at 3:38 PM Olivier Maignial
> wrote:
>
>> === PROBLEM ===
>>
>> I was trying to record h264 + aac streams from an RTSP server to mp4 file.
>> using this command line:
>>ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
>> aac_adtstoasc test.mp4
>>
>> FFmpeg then fail to record audio and output this logs:
>>[rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
>>[rtsp @ 0xcda1f0] Error parsing AU headers
>>...
>>[rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio:
>> aac, 48000 Hz, 1 channels): unspecified sample format
>>
>> In SDP provided by my RTSP server I had this fmtp line:
>>a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr;
>> config=1188; sizeLength=13; indexLength=3; indexDeltaLength=3;
>>
>> In FFmpeg code, I found a check introduced by commit
>> 24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than
>> 32 for fmtp line parameters.
>> However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams)
>> give examples of "profile-level-id" values for AAC, up to 55.
>> Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any
>> limit of size on interger parameters given in fmtp line.
>>
>> === FIX ===
>>
>> Instead of prohibit values over 32, I propose to check the possible
>> integer overflow.
>> The use of strtol allow to check the string validity and the possible
>> overflow.
>> Value is then checked against INT32_MIN and INT32_MAX. Using INT32_MIN/MAX
>> ensure to have the same behavior on 32 or 64 bits platforms.
>>
>> This patch fix my problem and I now can record my RTSP AAC stream to mp4.
>> It has passed the full fate tests suite sucessfully.
>>
>> Signed-off-by: Olivier Maignial
>> ---
>>
>> Changes V5 -> V6:
>>- Simplify code
>>
>> libavformat/rtpdec_mpeg4.c | 15 ++-
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
>> index 4f70599..9c4f8a1 100644
>> --- a/libavformat/rtpdec_mpeg4.c
>> +++ b/libavformat/rtpdec_mpeg4.c
>> @@ -289,15 +289,20 @@ static int parse_fmtp(AVFormatContext *s,
>> for (i = 0; attr_names[i].str; ++i) {
>> if (!av_strcasecmp(attr, attr_names[i].str)) {
>> if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
>> -int val = atoi(value);
>> -if (val > 32) {
>> +char *end_ptr = NULL;
>> +errno = 0;
>> +long int val = strtol(value, _ptr, 10);
>> +if (end_ptr == value || end_ptr[0] != '\0' ||
>> +errno == ERANGE ||
>> +val < INT32_MIN || val > INT32_MAX) {
>> av_log(s, AV_LOG_ERROR,
>> - "The %s field size is invalid (%d)\n",
>> - attr, val);
>> + "The %s field value is not a valid number,
>> or overflows int32: %s\n",
>> + attr, value);
>> return AVERROR_INVALIDDATA;
>> }
>> +
>> *(int *)((char *)data+
>> -attr_names[i].offset) = val;
>> +attr_names[i].offset) = (int) val;
>> } else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
>> char *val = av_strdup(value);
>> if (!val)
>> --
>> 2.7.4
>>
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avformat/vividas: Fixes overflow in shift in recover_key()
On 28.06.2019, at 22:53, Michael Niedermayer wrote: > Fixes: left shift of 133 by 24 places cannot be represented in type 'int' > Fixes: > 15365/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5716153105645568 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/vividas.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/vividas.c b/libavformat/vividas.c > index 753328245d..ed2eaea633 100644 > --- a/libavformat/vividas.c > +++ b/libavformat/vividas.c > @@ -118,7 +118,7 @@ static unsigned recover_key(unsigned char sample[4], > unsigned expected_size) > return (sample[0]^plaintext[0])| > ((sample[1]^plaintext[1])<<8)| > ((sample[2]^plaintext[2])<<16)| > -((sample[3]^plaintext[3])<<24); > +((unsigned)(sample[3]^plaintext[3])<<24); Shouldn't this just be return AV_RL32(sample) ^ AV_RL32(plaintext); ? If so, the code might be worthy of review for more needless overcomplication... ___ 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] dashdec: Fix reading values from SegmentTimeline inside, Period
> 在 2019年6月29日，07:03，Stefan _ 写道： > > Hi, > > attached patch fixes a small oversight in dashdec. > > YouTube uses DASH manifests structured like this for live recordings, > seeking is currently broken in those cases. > > <0001-dashdec-Fix-reading-values-from-SegmentTimeline-insi.patch>___ > 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". LGTM Thanks Steven ___ 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] dashdec: Fix reading values from SegmentTimeline inside, Period
Hi,
attached patch fixes a small oversight in dashdec.
YouTube uses DASH manifests structured like this for live recordings,
seeking is currently broken in those cases.
From b0eceb6bbe0c931d8c67a22980816bf3f8dd0bbe Mon Sep 17 00:00:00 2001
From: sfan5
Date: Sat, 29 Jun 2019 00:51:28 +0200
Subject: [PATCH] dashdec: Fix reading values from SegmentTimeline inside
Period
This was missed in commit e752da546463e693865d92a837fc0e8d2b28db2e.
---
libavformat/dashdec.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 5727d13a51..f0f9aa1d59 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -842,7 +842,7 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
xmlNodePtr representation_segmenttemplate_node = NULL;
xmlNodePtr representation_baseurl_node = NULL;
xmlNodePtr representation_segmentlist_node = NULL;
-xmlNodePtr segmentlists_tab[2];
+xmlNodePtr segmentlists_tab[3];
xmlNodePtr fragment_timeline_node = NULL;
xmlNodePtr fragment_templates_tab[5];
char *duration_val = NULL;
@@ -1003,9 +1003,10 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
xmlNodePtr fragmenturl_node = NULL;
segmentlists_tab[0] = representation_segmentlist_node;
segmentlists_tab[1] = adaptionset_segmentlist_node;
+segmentlists_tab[2] = period_segmentlist_node;
-duration_val = get_val_from_nodes_tab(segmentlists_tab, 2, "duration");
-timescale_val = get_val_from_nodes_tab(segmentlists_tab, 2, "timescale");
+duration_val = get_val_from_nodes_tab(segmentlists_tab, 3, "duration");
+timescale_val = get_val_from_nodes_tab(segmentlists_tab, 3, "timescale");
if (duration_val) {
rep->fragment_duration = (int64_t) strtoll(duration_val, NULL, 10);
av_log(s, AV_LOG_TRACE, "rep->fragment_duration = [%"PRId64"]\n", rep->fragment_duration);
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add DICOM Support
On 6/29/19, Michael Niedermayer wrote: > On Fri, Jun 28, 2019 at 02:02:29PM +0530, Shivam wrote: >> >> On 6/27/19 9:21 PM, Michael Niedermayer wrote: >> >On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: >> >>On 6/26/19 4:37 PM, Michael Niedermayer wrote: >> >>>On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: >> On 6/26/19, Michael Niedermayer wrote: >> >On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: >> >>On 6/25/19 2:12 AM, Michael Niedermayer wrote: >> >>>On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: >> Hi! >> >> The code is to add DICOM Support. The patch is only for >> uncompressed >> dicom files using explicit value representation. I would extend >> it, once >> i >> clarify some doubts. As dicom image files contain lots of >> metadata >> about >> the patient. So, should i display that data while demuxing or >> should i >> ignore and only demux the image data ?. In the current patch, i >> have >> made an >> option "-metadata", which when used will print the data on the >> terminal >> while demuxing. >> >>>metadata should be exported to be usable by applications. >> >>> >> >>>For teh API design a one test is that it should be possible to have >> >>> a >> >>>dicom file as input and a format with similar features as output >> >>> and not >> >>>loose any significant data. >> >>>Printing to the terminal cannot achieve that easily. >> >>So, should i export it to a csv file ? >> >does it fit into the metadata system we have ? >> > >> To clarify, you mean frame metadata system? >> >>>data that is specific to a frame would belong in the frame metadata >> >>>data that is specific to a stream would belong into that streams >> >>> metadata >> >>>data that is specific to the container would belong to its metadata >> >>> >> >>>iam not sure if multiple streams or frames can be in a single dicom >> >>>"container" / file. If they can then it should be clear what goes >> >>> where >> >>>if not then all 3 options would from the point of view of dicom be the >> >>>same. And in that case what is most convenient for interoperation with >> >>>other formats should be picked. That is lets introduce the least >> >>> amount >> >>>of differences to how similar data is handled in other formats >> >>Dicom files contain multiple frames, but number of streams is always >> >> one >> >>(video) like GIF,( I haven't done multiframe support yet i am working on >> >> it >> >>), The data specific to image/frames/pixels can be fit in the three >> >>categories of our metadata system, >> >>but their is extradata in DICOM files >> >>like : patient_name, medical_device_name , medical_procedure_done, >> >>study_date >> >why could this not be fit in metadata ? >> >> Yeah this can fit in the key, value pair of our AVDictionaryEntry (and >> can >> be written with "-f ffmetadata"). So, should i assign this to streams >> metadata or containers metadata as this data is not stream specific or >> container specific ?. > > whatever paul preferrs, if he has an oppinion on it. Otherwise choose > what feels better to you. Depends where is metadata stored, if its on container level, then obviously as stream metadata, otherwise as frame metadata. > > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Avoid a single point of failure, be that a person or equipment. > ___ 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] Add DICOM Support
On Fri, Jun 28, 2019 at 02:02:29PM +0530, Shivam wrote: > > On 6/27/19 9:21 PM, Michael Niedermayer wrote: > >On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: > >>On 6/26/19 4:37 PM, Michael Niedermayer wrote: > >>>On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: > On 6/26/19, Michael Niedermayer wrote: > >On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: > >>On 6/25/19 2:12 AM, Michael Niedermayer wrote: > >>>On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: > Hi! > > The code is to add DICOM Support. The patch is only for > uncompressed > dicom files using explicit value representation. I would extend it, > once > i > clarify some doubts. As dicom image files contain lots of metadata > about > the patient. So, should i display that data while demuxing or should i > ignore and only demux the image data ?. In the current patch, i have > made an > option "-metadata", which when used will print the data on the > terminal > while demuxing. > >>>metadata should be exported to be usable by applications. > >>> > >>>For teh API design a one test is that it should be possible to have a > >>>dicom file as input and a format with similar features as output and > >>>not > >>>loose any significant data. > >>>Printing to the terminal cannot achieve that easily. > >>So, should i export it to a csv file ? > >does it fit into the metadata system we have ? > > > To clarify, you mean frame metadata system? > >>>data that is specific to a frame would belong in the frame metadata > >>>data that is specific to a stream would belong into that streams metadata > >>>data that is specific to the container would belong to its metadata > >>> > >>>iam not sure if multiple streams or frames can be in a single dicom > >>>"container" / file. If they can then it should be clear what goes where > >>>if not then all 3 options would from the point of view of dicom be the > >>>same. And in that case what is most convenient for interoperation with > >>>other formats should be picked. That is lets introduce the least amount > >>>of differences to how similar data is handled in other formats > >>Dicom files contain multiple frames, but number of streams is always one > >>(video) like GIF,( I haven't done multiframe support yet i am working on it > >>), The data specific to image/frames/pixels can be fit in the three > >>categories of our metadata system, > >>but their is extradata in DICOM files > >>like : patient_name, medical_device_name , medical_procedure_done, > >>study_date > >why could this not be fit in metadata ? > > Yeah this can fit in the key, value pair of our AVDictionaryEntry (and can > be written with "-f ffmetadata"). So, should i assign this to streams > metadata or containers metadata as this data is not stream specific or > container specific ?. whatever paul preferrs, if he has an oppinion on it. Otherwise choose what feels better to you. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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 4/4] avformat/vividas: Fixes overflow in shift in recover_key()
Fixes: left shift of 133 by 24 places cannot be represented in type 'int' Fixes: 15365/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5716153105645568 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/vividas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/vividas.c b/libavformat/vividas.c index 753328245d..ed2eaea633 100644 --- a/libavformat/vividas.c +++ b/libavformat/vividas.c @@ -118,7 +118,7 @@ static unsigned recover_key(unsigned char sample[4], unsigned expected_size) return (sample[0]^plaintext[0])| ((sample[1]^plaintext[1])<<8)| ((sample[2]^plaintext[2])<<16)| -((sample[3]^plaintext[3])<<24); +((unsigned)(sample[3]^plaintext[3])<<24); } static void xor_block(void *p1, void *p2, unsigned size, int key, unsigned *key_ptr) -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avcodec/sanm: Optimize fill_frame() with av_memcpy_backptr()
Fixes: Timeout (76 sec -> 24 sec)
Fixes:
15043/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5699856238116864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/sanm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 811fd2188e..25aee7220f 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -1358,8 +1358,10 @@ static int read_frame_header(SANMVideoContext *ctx,
SANMFrameHeader *hdr)
static void fill_frame(uint16_t *pbuf, int buf_size, uint16_t color)
{
-while (buf_size--)
+if (buf_size--) {
*pbuf++ = color;
+av_memcpy_backptr((uint8_t*)pbuf, 2, 2*buf_size);
+}
}
static int copy_output(SANMVideoContext *ctx, SANMFrameHeader *hdr)
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/tta: Limit decoder to 16 channels
libtta 2.3 has a limit of 6 channels, so 16 is substantially above the
"official" already
Fixes: OOM
Fixes:
15249/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5643988125614080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/tta.c b/libavcodec/tta.c
index c7702610b6..4d27fcd555 100644
--- a/libavcodec/tta.c
+++ b/libavcodec/tta.c
@@ -163,7 +163,7 @@ static av_cold int tta_decode_init(AVCodecContext * avctx)
s->data_length = get_bits_long(, 32);
skip_bits_long(, 32); // CRC32 of header
-if (s->channels == 0) {
+if (s->channels == 0 || s->channels > 16) {
av_log(avctx, AV_LOG_ERROR, "Invalid number of channels\n");
return AVERROR_INVALIDDATA;
} else if (avctx->sample_rate == 0) {
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/rv10: Fix integer overflow in aspect ratio compare
Fixes: signed integer overflow: 2040 * 1187872 cannot be represented in type
'int'
Fixes:
15368/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV20_fuzzer-5681657136283648
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rv10.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 8f4497b9e0..729e4a8d2c 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -388,9 +388,9 @@ static int rv20_decode_picture_header(RVDecContext *rv)
// attempt to keep aspect during typical resolution switches
if (!old_aspect.num)
old_aspect = (AVRational){1, 1};
-if (2 * new_w * s->height == new_h * s->width)
+if (2 * (int64_t)new_w * s->height == (int64_t)new_h * s->width)
s->avctx->sample_aspect_ratio = av_mul_q(old_aspect,
(AVRational){2, 1});
-if (new_w * s->height == 2 * new_h * s->width)
+if ((int64_t)new_w * s->height == 2 * (int64_t)new_h * s->width)
s->avctx->sample_aspect_ratio = av_mul_q(old_aspect,
(AVRational){1, 2});
ret = ff_set_dimensions(s->avctx, new_w, new_h);
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add back alpha processing removed in 9cefb9e7ec
Am Fr., 28. Juni 2019 um 20:29 Uhr schrieb Paul B Mahol :
>
> On 6/28/19, Carl Eugen Hoyos wrote:
> > Am Fr., 28. Juni 2019 um 19:48 Uhr schrieb Paul B Mahol :
> >>
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavcodec/cfhd.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> >> index 846d334b9b..49a5a2c30a 100644
> >> --- a/libavcodec/cfhd.c
> >> +++ b/libavcodec/cfhd.c
> >> @@ -884,6 +884,8 @@ static int cfhd_decode(AVCodecContext *avctx, void
> >> *data, int *got_frame,
> >> high = s->plane[plane].l_h[7];
> >> for (i = 0; i < lowpass_height * 2; i++) {
> >> horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
> >> +if (avctx->pix_fmt == AV_PIX_FMT_GBRAP12 && act_plane ==
> >> 3)
> >> +process_alpha(dst, lowpass_width * 2);
> >
> > Please mention ticket #6265 in the commit message.
>
> That ticket is closed, instead, #7886 is open.
Yes;-)
(The sample is here in a directory ticket6265...)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add back alpha processing removed in 9cefb9e7ec
On 6/28/19, Carl Eugen Hoyos wrote:
> Am Fr., 28. Juni 2019 um 19:48 Uhr schrieb Paul B Mahol :
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/cfhd.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>> index 846d334b9b..49a5a2c30a 100644
>> --- a/libavcodec/cfhd.c
>> +++ b/libavcodec/cfhd.c
>> @@ -884,6 +884,8 @@ static int cfhd_decode(AVCodecContext *avctx, void
>> *data, int *got_frame,
>> high = s->plane[plane].l_h[7];
>> for (i = 0; i < lowpass_height * 2; i++) {
>> horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
>> +if (avctx->pix_fmt == AV_PIX_FMT_GBRAP12 && act_plane ==
>> 3)
>> +process_alpha(dst, lowpass_width * 2);
>
> Please mention ticket #6265 in the commit message.
That ticket is closed, instead, #7886 is open.
>
> Thank you!
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add back alpha processing removed in 9cefb9e7ec
Am Fr., 28. Juni 2019 um 19:48 Uhr schrieb Paul B Mahol :
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/cfhd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..49a5a2c30a 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -884,6 +884,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
> int *got_frame,
> high = s->plane[plane].l_h[7];
> for (i = 0; i < lowpass_height * 2; i++) {
> horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
> +if (avctx->pix_fmt == AV_PIX_FMT_GBRAP12 && act_plane == 3)
> +process_alpha(dst, lowpass_width * 2);
Please mention ticket #6265 in the commit message.
Thank you!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/cfhd: add back alpha processing removed in 9cefb9e7ec
Signed-off-by: Paul B Mahol
---
libavcodec/cfhd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..49a5a2c30a 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -884,6 +884,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
high = s->plane[plane].l_h[7];
for (i = 0; i < lowpass_height * 2; i++) {
horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
+if (avctx->pix_fmt == AV_PIX_FMT_GBRAP12 && act_plane == 3)
+process_alpha(dst, lowpass_width * 2);
low += lowpass_width;
high += lowpass_width;
dst += pic->linesize[act_plane] / 2;
--
2.17.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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
On 6/27/2019 9:59 AM, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavcodec/mjpeg_parser.c | 158
> +-
> 1 file changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
> index 07a6b2b..f59aa3e 100644
> --- a/libavcodec/mjpeg_parser.c
> +++ b/libavcodec/mjpeg_parser.c
> @@ -27,12 +27,131 @@
> */
>
> #include "parser.h"
> +#include "mjpeg.h"
> +#include "mjpegdec.h"
> +#include "get_bits.h"
>
> typedef struct MJPEGParserContext{
> ParseContext pc;
> +MJpegDecodeContext dec_ctx;
This is not acceptable. The parser shouldn't use decoder structs, as it
makes the former depend on the latter.
A reusable header parsing function should be standalone, so it may be
called from decoders, parsers, bitstream filters, and anything that may
require it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote: > The previous calculation code did not account for the fact that the > copy_offset for the start of the frame array is at index 0, yet the > scan line number from the rfc4175 RTP header starts at 1. > This caused 2 issues to appear: > - The first scan line was being copied into the array where the second > scan line should be. This caused the resulting video to have a green > line at the top of it. > - Since the packet containing the last scan line would fail the > calculation, the packet with the RTP marker would not be processed > which caused a log message saying "Missed previous RTP marker" to be > outputted for each frame. > > Signed-off-by: Jacob Siddall > --- > Changes in v2: > - Don't handle packet if the line number is less than 1 > > Section 12 in the VSF technical recommendation TR-03 specifies that the > video scan line numbers should start at 1. > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf > > Changes in v3: > - Changed the commit hash abbreviation in the patch file diff to be 10 > characters in length rather than 7. This was causing the patch file > to fail when it was applied. > > libavformat/rtpdec_rfc4175.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) The patch looks reasonable to me but i dont really know rfc4175 Ideally someone who knows rfc4175 should make the final decission to apply it maybe whoever applies it can also bump the micro version so user apps have a way to detect this line shifting change Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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 v3] lavf/vf_find_rect: add the dual input support function
On Fri, Jun 28, 2019 at 05:23:22PM +0200, Paul B Mahol wrote:
> On 6/28/19, Limin Wang wrote:
> > On Fri, Jun 28, 2019 at 09:49:27AM +0200, Michael Niedermayer wrote:
> >> On Thu, Jun 27, 2019 at 05:40:31PM +0800, lance.lmw...@gmail.com wrote:
> >> > From: Limin Wang
> >> >
> >> > Please using the below command for the testing:
> >> > ./ffmpeg -i input.ts -i ref.png -filter_complex
> >> > find_rect,cover_rect=cover.jpg:mode=cover output.ts
> >> >
> >> > I have updated the help document for the function change.
> >> >
> >> > Reviewed-by: Moritz Barsnick
> >> > Signed-off-by: Limin Wang
> >> > ---
> >> > doc/filters.texi | 12 +--
> >> > libavfilter/version.h | 2 +-
> >> > libavfilter/vf_find_rect.c | 173 +++--
> >> > 3 files changed, 118 insertions(+), 69 deletions(-)
> >> >
> >> > diff --git a/doc/filters.texi b/doc/filters.texi
> >> > index 2d9af46a6b..92e1dee07e 100644
> >> > --- a/doc/filters.texi
> >> > +++ b/doc/filters.texi
> >> > @@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
> >> > @var{black}.
> >> >
> >> > Find a rectangular object
> >> >
> >> > +This filter takes in two video inputs, the first input is considered
> >> > +the "main" source and is passed unchanged to the output. The "second"
> >> > +input is used as a rectangular object for finding. Now the "second"
> >> > +input will be auto converted to gray8 format.
> >> > +
> >> > It accepts the following options:
> >> >
> >> > @table @option
> >> > -@item object
> >> > -Filepath of the object image, needs to be in gray8.
> >> > -
> >> > @item threshold
> >> > Detection threshold, default is 0.5.
> >> >
> >> > @@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
> >> > @item
> >> > Cover a rectangular object by the supplied image of a given video using
> >> > @command{ffmpeg}:
> >> > @example
> >> > -ffmpeg -i file.ts -vf
> >> > find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
> >> > +ffmpeg -i file.ts -i newref.pgm -filter_complex
> >> > find_rect,cover_rect=cover.jpg:mode=cover new.mkv
> >>
> >> It will be needed to support the old syntax until the next 2 major API
> >> bumps
> >> at minimum.
> > I haven't find a good way to support the old the syntax. With the dual
> > input, the input has been configured with two input(main and
> > find_object), so it'll report error if with old syntax.
> >
> > Or how about to create a new video filter like find_logo and keep the
> > find_rect
> > filter untouch as I plan to improve it for logo detection.
>
> Unacceptable.
that would have been the easy option
>
> Is this filter actually useful? If not, just remove it.
there was a company that wanted it.
In fact they would have paid me if i didnt make it open source ...
So this must be important to at least them and their competitor.
If you think that we have too many filters then we could start a broader
discussion/thread maybe about combining or factoring things. But we probably
should only go there if theres a broad consensus. I dont want to step
on anyones toes ...
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
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 v3] lavf/vf_find_rect: add the dual input support function
On 6/28/19, Limin Wang wrote:
> On Fri, Jun 28, 2019 at 09:49:27AM +0200, Michael Niedermayer wrote:
>> On Thu, Jun 27, 2019 at 05:40:31PM +0800, lance.lmw...@gmail.com wrote:
>> > From: Limin Wang
>> >
>> > Please using the below command for the testing:
>> > ./ffmpeg -i input.ts -i ref.png -filter_complex
>> > find_rect,cover_rect=cover.jpg:mode=cover output.ts
>> >
>> > I have updated the help document for the function change.
>> >
>> > Reviewed-by: Moritz Barsnick
>> > Signed-off-by: Limin Wang
>> > ---
>> > doc/filters.texi | 12 +--
>> > libavfilter/version.h | 2 +-
>> > libavfilter/vf_find_rect.c | 173 +++--
>> > 3 files changed, 118 insertions(+), 69 deletions(-)
>> >
>> > diff --git a/doc/filters.texi b/doc/filters.texi
>> > index 2d9af46a6b..92e1dee07e 100644
>> > --- a/doc/filters.texi
>> > +++ b/doc/filters.texi
>> > @@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
>> > @var{black}.
>> >
>> > Find a rectangular object
>> >
>> > +This filter takes in two video inputs, the first input is considered
>> > +the "main" source and is passed unchanged to the output. The "second"
>> > +input is used as a rectangular object for finding. Now the "second"
>> > +input will be auto converted to gray8 format.
>> > +
>> > It accepts the following options:
>> >
>> > @table @option
>> > -@item object
>> > -Filepath of the object image, needs to be in gray8.
>> > -
>> > @item threshold
>> > Detection threshold, default is 0.5.
>> >
>> > @@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
>> > @item
>> > Cover a rectangular object by the supplied image of a given video using
>> > @command{ffmpeg}:
>> > @example
>> > -ffmpeg -i file.ts -vf
>> > find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
>> > +ffmpeg -i file.ts -i newref.pgm -filter_complex
>> > find_rect,cover_rect=cover.jpg:mode=cover new.mkv
>>
>> It will be needed to support the old syntax until the next 2 major API
>> bumps
>> at minimum.
> I haven't find a good way to support the old the syntax. With the dual
> input, the input has been configured with two input(main and
> find_object), so it'll report error if with old syntax.
>
> Or how about to create a new video filter like find_logo and keep the
> find_rect
> filter untouch as I plan to improve it for logo detection.
Unacceptable.
Is this filter actually useful? If not, just remove it.
>
>> That is first it would need to be deprecated and then we need 2 major API
>> bumps
>> before it can be removed.
>> Keep in mind users both of the command line tools as well as the API would
>> need to have their scripts / software updated/changed for this.
>> also to make the transition easy both variants should be supported at the
>> samw time so people can switch to the new syntax "immedeatly" and do not
>> need to time it with a specific version bump
>> Yes i know thats a bit annoying ...
>>
>> Theres of course no need to support newly added features with the old
>> syntax
>>
>> thanks
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> If a bugfix only changes things apparently unrelated to the bug with no
>> further explanation, that is a good sign that the bugfix is wrong.
>
>
>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2 1/2] doc/muxers: fix and update docs for HLS muxer
From: Jun Zhao
fix and update docs for HLS muxer
Signed-off-by: Jun Zhao
---
doc/muxers.texi | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index dd64672..d179584 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -525,7 +525,7 @@ See also the @ref{framehash} muxer.
@anchor{hls}
@section hls
-Apple HTTP Live Streaming muxer that segments MPEG-TS according to
+Apple HTTP Live Streaming muxer that segments MPEG-TS/fragmented MP4 according
to
the HTTP Live Streaming (HLS) specification.
It creates a playlist file, and one or more segment files. The output filename
@@ -767,20 +767,20 @@ ffmpeg -f lavfi -re -i testsrc -c:v h264 -hls_flags
delete_segments \
-hls_key_info_file file.keyinfo out.m3u8
@end example
-@item -hls_enc @var{enc}
+@item hls_enc @var{enc}
Enable (1) or disable (0) the AES128 encryption.
When enabled every segment generated is encrypted and the encryption key
is saved as @var{playlist name}.key.
-@item -hls_enc_key @var{key}
+@item hls_enc_key @var{key}
Hex-coded 16byte key to encrypt the segments, by default it
is randomly generated.
-@item -hls_enc_key_url @var{keyurl}
+@item hls_enc_key_url @var{keyurl}
If set, @var{keyurl} is prepended instead of @var{baseurl} to the key filename
in the playlist.
-@item -hls_enc_iv @var{iv}
+@item hls_enc_iv @var{iv}
Hex-coded 16byte initialization vector for every segment instead
of the autogenerated ones.
@@ -901,14 +901,22 @@ are always written into temporary file regardles of this
flag if @code{master_pl
@end table
-@item hls_playlist_type event
+@item hls_playlist_type @var{int}
+Set the HLS playlist type, Default value is 0.
+
+Other possible values:
+@table @option
+
+@item event
Emit @code{#EXT-X-PLAYLIST-TYPE:EVENT} in the m3u8 header. Forces
@option{hls_list_size} to 0; the playlist can only be appended to.
-@item hls_playlist_type vod
+@item vod
Emit @code{#EXT-X-PLAYLIST-TYPE:VOD} in the m3u8 header. Forces
@option{hls_list_size} to 0; the playlist must not change.
+@end table
+
@item method
Use the given HTTP method to create the hls files.
@example
@@ -1090,7 +1098,7 @@ Use persistent HTTP connections. Applicable only for HTTP
output.
@item timeout
Set timeout for socket I/O operations. Applicable only for HTTP output.
-@item -ignore_io_errors
+@item ignore_io_errors
Ignore IO errors during open, write and delete. Useful for long-duration runs
with network output.
@item headers
--
1.7.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".
Re: [FFmpeg-devel] [PATCH v3] lavf/vf_find_rect: add the dual input support function
On Fri, Jun 28, 2019 at 09:49:27AM +0200, Michael Niedermayer wrote:
> On Thu, Jun 27, 2019 at 05:40:31PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Please using the below command for the testing:
> > ./ffmpeg -i input.ts -i ref.png -filter_complex
> > find_rect,cover_rect=cover.jpg:mode=cover output.ts
> >
> > I have updated the help document for the function change.
> >
> > Reviewed-by: Moritz Barsnick
> > Signed-off-by: Limin Wang
> > ---
> > doc/filters.texi | 12 +--
> > libavfilter/version.h | 2 +-
> > libavfilter/vf_find_rect.c | 173 +++--
> > 3 files changed, 118 insertions(+), 69 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 2d9af46a6b..92e1dee07e 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
> > @var{black}.
> >
> > Find a rectangular object
> >
> > +This filter takes in two video inputs, the first input is considered
> > +the "main" source and is passed unchanged to the output. The "second"
> > +input is used as a rectangular object for finding. Now the "second"
> > +input will be auto converted to gray8 format.
> > +
> > It accepts the following options:
> >
> > @table @option
> > -@item object
> > -Filepath of the object image, needs to be in gray8.
> > -
> > @item threshold
> > Detection threshold, default is 0.5.
> >
> > @@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
> > @item
> > Cover a rectangular object by the supplied image of a given video using
> > @command{ffmpeg}:
> > @example
> > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
> > new.mkv
> > +ffmpeg -i file.ts -i newref.pgm -filter_complex
> > find_rect,cover_rect=cover.jpg:mode=cover new.mkv
>
> It will be needed to support the old syntax until the next 2 major API bumps
> at minimum.
I haven't find a good way to support the old the syntax. With the dual
input, the input has been configured with two input(main and
find_object), so it'll report error if with old syntax.
Or how about to create a new video filter like find_logo and keep the find_rect
filter untouch as I plan to improve it for logo detection.
> That is first it would need to be deprecated and then we need 2 major API
> bumps
> before it can be removed.
> Keep in mind users both of the command line tools as well as the API would
> need to have their scripts / software updated/changed for this.
> also to make the transition easy both variants should be supported at the
> samw time so people can switch to the new syntax "immedeatly" and do not
> need to time it with a specific version bump
> Yes i know thats a bit annoying ...
>
> Theres of course no need to support newly added features with the old syntax
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2 2/2] doc/muxers: fix docs format for DASH muxer
From: Jun Zhao
fix docs format for DASH muxer
Signed-off-by: Jun Zhao
---
doc/muxers.texi | 62 --
1 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d179584..c220bd2 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -220,64 +220,64 @@ In addition to the standard identifiers, an
ffmpeg-specific "$ext$" identifier i
When specified ffmpeg will replace $ext$ in the file name with muxing format's
extensions such as mp4, webm etc.,
@example
-ffmpeg -re -i -map 0 -map 0 -c:a libfdk_aac -c:v libx264
--b:v:0 800k -b:v:1 300k -s:v:1 320x170 -profile:v:1 baseline
--profile:v:0 main -bf 1 -keyint_min 120 -g 120 -sc_threshold 0
--b_strategy 0 -ar:a:1 22050 -use_timeline 1 -use_template 1
--window_size 5 -adaptation_sets "id=0,streams=v id=1,streams=a"
+ffmpeg -re -i -map 0 -map 0 -c:a libfdk_aac -c:v libx264 \
+-b:v:0 800k -b:v:1 300k -s:v:1 320x170 -profile:v:1 baseline \
+-profile:v:0 main -bf 1 -keyint_min 120 -g 120 -sc_threshold 0 \
+-b_strategy 0 -ar:a:1 22050 -use_timeline 1 -use_template 1 \
+-window_size 5 -adaptation_sets "id=0,streams=v id=1,streams=a" \
-f dash /path/to/out.mpd
@end example
@table @option
-@item -min_seg_duration @var{microseconds}
+@item min_seg_duration @var{microseconds}
This is a deprecated option to set the segment length in microseconds, use
@var{seg_duration} instead.
-@item -seg_duration @var{duration}
+@item seg_duration @var{duration}
Set the segment length in seconds (fractional value can be set). The value is
treated as average segment duration when @var{use_template} is enabled and
@var{use_timeline} is disabled and as minimum segment duration for all the
other
use cases.
-@item -window_size @var{size}
+@item window_size @var{size}
Set the maximum number of segments kept in the manifest.
-@item -extra_window_size @var{size}
+@item extra_window_size @var{size}
Set the maximum number of segments kept outside of the manifest before
removing from disk.
-@item -remove_at_exit @var{remove}
+@item remove_at_exit @var{remove}
Enable (1) or disable (0) removal of all segments when finished.
-@item -use_template @var{template}
+@item use_template @var{template}
Enable (1) or disable (0) use of SegmentTemplate instead of SegmentList.
-@item -use_timeline @var{timeline}
+@item use_timeline @var{timeline}
Enable (1) or disable (0) use of SegmentTimeline in SegmentTemplate.
-@item -single_file @var{single_file}
+@item single_file @var{single_file}
Enable (1) or disable (0) storing all segments in one file, accessed using
byte ranges.
-@item -single_file_name @var{file_name}
+@item single_file_name @var{file_name}
DASH-templated name to be used for baseURL. Implies @var{single_file} set to
"1". In the template, "$ext$" is replaced with the file name extension specific
for the segment format.
-@item -init_seg_name @var{init_name}
+@item init_seg_name @var{init_name}
DASH-templated name to used for the initialization segment. Default is
"init-stream$RepresentationID$.$ext$". "$ext$" is replaced with the file name
extension specific for the segment format.
-@item -media_seg_name @var{segment_name}
+@item media_seg_name @var{segment_name}
DASH-templated name to used for the media segments. Default is
"chunk-stream$RepresentationID$-$Number%05d$.$ext$". "$ext$" is replaced with
the file name extension specific for the segment format.
-@item -utc_timing_url @var{utc_url}
+@item utc_timing_url @var{utc_url}
URL of the page that will return the UTC timestamp in ISO format. Example:
"https://time.akamai.com/?iso;
@item method @var{method}
Use the given HTTP method to create output files. Generally set to PUT or POST.
-@item -http_user_agent @var{user_agent}
+@item http_user_agent @var{user_agent}
Override User-Agent field in HTTP header. Applicable only for HTTP output.
-@item -http_persistent @var{http_persistent}
+@item http_persistent @var{http_persistent}
Use persistent HTTP connections. Applicable only for HTTP output.
-@item -hls_playlist @var{hls_playlist}
+@item hls_playlist @var{hls_playlist}
Generate HLS playlist files as well. The master playlist is generated with the
filename master.m3u8.
One media playlist file is generated for each stream with filenames
media_0.m3u8, media_1.m3u8, etc.
-@item -streaming @var{streaming}
+@item streaming @var{streaming}
Enable (1) or disable (0) chunk streaming mode of output. In chunk streaming
mode, each frame will be a moof fragment which forms a chunk.
-@item -adaptation_sets @var{adaptation_sets}
+@item adaptation_sets @var{adaptation_sets}
Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c
id=y,streams=d,e" with x and y being the IDs
of the adaptation sets and a,b,c,d and e are the indices of the mapped streams.
To map all video (or audio) streams to an AdaptationSet, "v" (or "a") can be
used as stream identifier instead of IDs.
When no assignment is defined,
[FFmpeg-devel] [PATCH V2 0/2] Fix and update docs for HLS/DASH muxer
V2: - remove hyphen from option name in the docs Jun Zhao (2): doc/muxers: fix and update docs for HLS muxer doc/muxers: fix docs format for DASH muxer doc/muxers.texi | 86 ++ 1 files changed, 48 insertions(+), 38 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/2] doc/muxers: fix and update docs for HLS muxer
On 28-06-2019 07:02 PM, Jun Zhao wrote:
From: Jun Zhao
fix and update docs for HLS muxer
Signed-off-by: Jun Zhao
---
doc/muxers.texi | 68 ++
1 files changed, 38 insertions(+), 30 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index dd64672..d93d1cf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -554,32 +554,32 @@ segmentation.
This muxer supports the following options:
@table @option
-@item hls_init_time @var{seconds}
+@item -hls_init_time @var{seconds}
These docs are for API users as well, and since the hyphen isn't part of
the option name, it would be confusing. At least that was the consensus
when a similar change was proposed - see
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240380.html
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1 2/2] doc/muxers: fix docs format for DASH muxer
From: Jun Zhao
fix docs format for DASH muxer
Signed-off-by: Jun Zhao
---
doc/muxers.texi |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d93d1cf..044c838 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -256,7 +256,7 @@ DASH-templated name to used for the initialization segment.
Default is "init-str
DASH-templated name to used for the media segments. Default is
"chunk-stream$RepresentationID$-$Number%05d$.$ext$". "$ext$" is replaced with
the file name extension specific for the segment format.
@item -utc_timing_url @var{utc_url}
URL of the page that will return the UTC timestamp in ISO format. Example:
"https://time.akamai.com/?iso;
-@item method @var{method}
+@item -method @var{method}
Use the given HTTP method to create output files. Generally set to PUT or POST.
@item -http_user_agent @var{user_agent}
Override User-Agent field in HTTP header. Applicable only for HTTP output.
@@ -298,6 +298,7 @@ Write global SIDX atom. Applicable only for single file,
mp4 output, non-streami
@item -dash_segment_type @var{dash_segment_type}
Possible values:
+@table @option
@item auto
If this flag is set, the dash segment files format will be selected based on
the stream codec. This is the default mode.
@@ -306,6 +307,7 @@ If this flag is set, the dash segment files will be in in
ISOBMFF format.
@item webm
If this flag is set, the dash segment files will be in in WebM format.
+@end table
@item -ignore_io_errors @var{ignore_io_errors}
Ignore IO errors during open and write. Useful for long-duration runs with
network output.
--
1.7.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 V1 1/2] doc/muxers: fix and update docs for HLS muxer
From: Jun Zhao
fix and update docs for HLS muxer
Signed-off-by: Jun Zhao
---
doc/muxers.texi | 68 ++
1 files changed, 38 insertions(+), 30 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index dd64672..d93d1cf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -554,32 +554,32 @@ segmentation.
This muxer supports the following options:
@table @option
-@item hls_init_time @var{seconds}
+@item -hls_init_time @var{seconds}
Set the initial target segment length in seconds. Default value is @var{0}.
Segment will be cut on the next key frame after this time has passed on the
first m3u8 list.
After the initial playlist is filled @command{ffmpeg} will cut segments
at duration equal to @code{hls_time}
-@item hls_time @var{seconds}
+@item -hls_time @var{seconds}
Set the target segment length in seconds. Default value is 2.
Segment will be cut on the next key frame after this time has passed.
-@item hls_list_size @var{size}
+@item -hls_list_size @var{size}
Set the maximum number of playlist entries. If set to 0 the list file
will contain all the segments. Default value is 5.
-@item hls_delete_threshold @var{size}
+@item -hls_delete_threshold @var{size}
Set the number of unreferenced segments to keep on disk before @code{hls_flags
delete_segments}
deletes them. Increase this to allow continue clients to download segments
which
were recently referenced in the playlist. Default value is 1, meaning segments
older than
@code{hls_list_size+1} will be deleted.
-@item hls_ts_options @var{options_list}
+@item -hls_ts_options @var{options_list}
Set output format options using a :-separated list of key=value
parameters. Values containing @code{:} special characters must be
escaped.
-@item hls_wrap @var{wrap}
+@item -hls_wrap @var{wrap}
This is a deprecated option, you can use @code{hls_list_size}
and @code{hls_flags delete_segments} instead it
@@ -588,7 +588,7 @@ files, and limits the maximum number of segment files
written to disk
to @var{wrap}.
-@item hls_start_number_source
+@item -hls_start_number_source
Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) according to
the specified source.
Unless @code{hls_flags single_file} is set, it also specifies source of
starting sequence numbers of
segment and subtitle filenames. In any case, if @code{hls_flags append_list}
@@ -610,16 +610,16 @@ The start number will be based on the current date/time
as mmddHHMMSS. e.g.
@end table
-@item start_number @var{number}
+@item -start_number @var{number}
Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the
specified @var{number}
when @var{hls_start_number_source} value is @var{generic}. (This is the
default case.)
Unless @code{hls_flags single_file} is set, it also specifies starting
sequence numbers of segment and subtitle filenames.
Default value is 0.
-@item hls_allow_cache @var{allowcache}
+@item -hls_allow_cache @var{allowcache}
Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
-@item hls_base_url @var{baseurl}
+@item -hls_base_url @var{baseurl}
Append @var{baseurl} to every entry in the playlist.
Useful to generate playlists with absolute paths.
@@ -628,7 +628,7 @@ and it is not to be confused with the segment filename
sequence number
which can be cyclic, for example if the @option{wrap} option is
specified.
-@item hls_segment_filename @var{filename}
+@item -hls_segment_filename @var{filename}
Set the segment filename. Unless @code{hls_flags single_file} is set,
@var{filename} is used as a string format with the segment number:
@example
@@ -670,10 +670,10 @@ This example will produce the playlists segment file sets:
@file{vs0/file_000.ts}, @file{vs0/file_001.ts}, @file{vs0/file_002.ts}, etc.
and
@file{vs1/file_000.ts}, @file{vs1/file_001.ts}, @file{vs1/file_002.ts}, etc.
-@item use_localtime
+@item -use_localtime
Same as strftime option, will be deprecated.
-@item strftime
+@item -strftime
Use strftime() on @var{filename} to expand the segment filename with localtime.
The segment number is also available in this mode, but to use it, you need to
specify second_level_segment_index
hls_flag and %%d will be the specifier.
@@ -690,10 +690,10 @@ ffmpeg -i in.nut -strftime 1 -hls_flags
second_level_segment_index -hls_segment_
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-0001.ts}, @file{file-20160215-0002.ts}, etc.
-@item use_localtime_mkdir
+@item -use_localtime_mkdir
Same as strftime_mkdir option, will be deprecated .
-@item strftime_mkdir
+@item -strftime_mkdir
Used together with -strftime_mkdir, it will create all subdirectories which
is expanded in @var{filename}.
@example
@@ -711,7 +711,7 @@ produce the playlist, @file{out.m3u8}, and segment files:
@file{2016/02/15/file-20160215-1455569023.ts},
@file{2016/02/15/file-20160215-1455569024.ts},
Re: [FFmpeg-devel] [PATCH 2/2] lavc/mjpegdec: make code aligned
On Thu, Jun 27, 2019 at 04:58:24PM +0800, Zhong Li wrote: > Signed-off-by: Zhong Li > --- > libavcodec/mjpegdec.c | 450 > +- > 1 file changed, 225 insertions(+), 225 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header
On Thu, Jun 27, 2019 at 08:59:12PM +0800, Zhong Li wrote:
> It will be reused in the following mjpeg_parser patch
>
> Signed-off-by: Zhong Li
> ---
> Mark Thompson: This seems suspicious - MJPEG is generally 4:2:2 (e.g. UVC
> requires it), so I would expect a 4:2:2 format to be the default here? (Or
> maybe a longer list - VAAPI certainly supports 4:2:2, 4:2:0 and 4:4:4 on the
> same hardware.)
> Zhong: libmfx can support jpeg baseline profile with more output formats, but
> current ffmpeg-qsv decoder/vpp can't. Will extend supported format list as
> separated patch.
>
> libavcodec/mjpegdec.c | 37 -
> libavcodec/mjpegdec.h | 4
> 2 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index a65bc8d..5da66bb 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -157,6 +157,8 @@ av_cold int ff_mjpeg_decode_init(AVCodecContext *avctx)
> s->start_code= -1;
> s->first_picture = 1;
> s->got_picture = 0;
> +s->reinit_idct = 0;
> +s->size_change = 0;
> s->org_height= avctx->coded_height;
> avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
> avctx->colorspace = AVCOL_SPC_BT470BG;
> @@ -302,9 +304,9 @@ int ff_mjpeg_decode_dht(MJpegDecodeContext *s)
> return 0;
> }
>
> -int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> +int ff_mjpeg_decode_header(MJpegDecodeContext *s)
> {
> -int len, nb_components, i, width, height, bits, ret, size_change;
> +int len, nb_components, i, width, height, bits, ret;
> unsigned pix_fmt_id;
> int h_count[MAX_COMPONENTS] = { 0 };
> int v_count[MAX_COMPONENTS] = { 0 };
> @@ -324,7 +326,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> if (s->avctx->bits_per_raw_sample != bits) {
> av_log(s->avctx, s->avctx->bits_per_raw_sample > 0 ? AV_LOG_INFO :
> AV_LOG_DEBUG, "Changing bps from %d to %d\n", s->avctx->bits_per_raw_sample,
> bits);
> s->avctx->bits_per_raw_sample = bits;
> -init_idct(s->avctx);
> +s->reinit_idct = 1;
> }
I think the avctx->bits_per_raw_sample value should stay in sync with
the initialized idct
This patch would allow the bits_per_raw_sample to change and then
a subsequent error to skip init_idct()
maybe this is ok as it would be probably called later in a subsequent
frame but i think its better if they stay closer together or there
is nothing between them that can cause ine to exeucute without the other
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.
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/hlsenc: changing all filename length to MAX_URL_SIZE
Dear All,
throughout hlsenc code, all filename related buffer lengths are set
hardcoded as 1024. This PATCH change it to general value as MAX_URL_SIZE
of internal.h
please review this patch.
thank you in advance,
best regards,
Bela
>From 6814aa8c06a37e4f298dd5acc84081cc4283321e Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 28 Jun 2019 13:52:18 +0200
Subject: [PATCH] avformat/hlsenc: changing all filename length to MAX_URL_SIZE
Throughout hlsenc code, all filename related buffer lengths are set
hardcoded as 1024. This PATCH change it to general value as MAX_URL_SIZE
in internal.h
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5b0121f016..057134f410 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -64,13 +64,13 @@ typedef enum {
} CodecAttributeStatus;
#define KEYSIZE 16
-#define LINE_BUFFER_SIZE 1024
+#define LINE_BUFFER_SIZE MAX_URL_SIZE
#define HLS_MICROSECOND_UNIT 100
#define POSTFIX_PATTERN "_%d"
typedef struct HLSSegment {
-char filename[1024];
-char sub_filename[1024];
+char filename[MAX_URL_SIZE];
+char sub_filename[MAX_URL_SIZE];
double duration; /* in seconds */
int discont;
int64_t pos;
@@ -149,7 +149,7 @@ typedef struct VariantStream {
char *m3u8_name;
double initial_prog_date_time;
-char current_segment_final_filename_fmt[1024]; // when renaming segments
+char current_segment_final_filename_fmt[MAX_URL_SIZE]; // when renaming
segments
char *fmp4_init_filename;
char *base_output_dirname;
@@ -,7 +,7 @@ static int parse_playlist(AVFormatContext *s, const char
*url, VariantStream *vs
AVIOContext *in;
int ret = 0, is_segment = 0;
int64_t new_start_pos;
-char line[1024];
+char line[MAX_URL_SIZE];
const char *ptr;
const char *end;
@@ -1268,7 +1268,7 @@ static int create_master_playlist(AVFormatContext *s,
const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
int is_file_proto = proto && !strcmp(proto, "file");
int use_temp_file = is_file_proto && ((hls->flags & HLS_TEMP_FILE) ||
hls->master_publish_rate);
-char temp_filename[1024];
+char temp_filename[MAX_URL_SIZE];
input_vs->m3u8_created = 1;
if (!hls->master_m3u8_created) {
@@ -1433,8 +1433,8 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
HLSSegment *en;
int target_duration = 0;
int ret = 0;
-char temp_filename[1024];
-char temp_vtt_filename[1024];
+char temp_filename[MAX_URL_SIZE];
+char temp_vtt_filename[MAX_URL_SIZE];
int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
vs->nb_entries);
const char *proto = avio_find_protocol_name(vs->m3u8_name);
int is_file_proto = proto && !strcmp(proto, "file");
@@ -1594,7 +1594,7 @@ static int hls_start(AVFormatContext *s, VariantStream
*vs)
if (c->use_localtime) {
time_t now0;
struct tm *tm, tmpbuf;
-int bufsize = strlen(vs->basename) + 1024;
+int bufsize = strlen(vs->basename) + MAX_URL_SIZE;
char *buf = av_mallocz(bufsize);
if (!buf)
return AVERROR(ENOMEM);
--
2.20.1.windows.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".
Re: [FFmpeg-devel] [PATCH 1/5] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
On 2019-06-28 03:03, Hendrik Leppkes wrote: > On Fri, Jun 28, 2019 at 1:26 AM James Darnley wrote: >> >> On 2019-06-28 04:26, Linjie Fu wrote: >>> Previously, media driver provided planar format(like 420 8 bit), but >>> for HEVC Range Extension (422/444 8/10 bit), the decoded image is >>> produced in packed format. >>> >>> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding >>> for both VAAPI and QSV: >>> - Y210: 422 10 BIT >>> - AYUV: 444 8 BIT >>> - Y410: 444 10 BIT >>> >> >> >> Why am I suspicious that at least one of those is a re-ordered v210? I >> seem to recall that we rejected adding v210 to this list. Either they >> don't belong in this list or they don't belong because libavcodec has a >> proper decoder (at least for v210). >> > > They are not quite as bad as v210 (and not related). > > Microsoft documents them here as the recommended formats to be used on > Windows: > https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#444-formats-32-bits-per-pixel > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats > > - Hendrik Okay y410 and y210 use the highest 10 bits in each 16-bit word. I apologise for jumping to that conclusion. signature.asc Description: OpenPGP digital 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] libavformat/mpegtsenc: new interlaced mux mode
Hi, > Thank you for reviewing! New version [v2] at: https://patchwork.ffmpeg.org/patch/13745/ Regards. A.H. --- ___ 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] libavformat/mpegtsenc: new interleaved mux mode [v2]
Hi,
This is the second version of my patch for an “interleaved mpeg-TS mux”.
Supersedes: https://patchwork.ffmpeg.org/patch/13487/
Please, read the original thread for checks about the patch.
Changes from the initial version:
1. Option name changed from “mpegts_extra_mux” to “mpegts_interleave_mux”.
2. Corrected some aesthetic details of the code.
The functionality remains the same, so all tests are equally valid.
Regards.
A.H.
---From 54cfa26b83110bbd71d41fb9729828291dbfc873 Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Fri, 28 Jun 2019 10:42:00 +0100
Subject: [PATCH] libavformat/mpegtsenc: interleaved mux mode [v2]
This patch implements a new optional "interleaved mux mode" in the MPEGTS muxer.
The strategy that implements the current mux (selected by default) is based on
writing full PES packages sequentially. This mode can be problematic when using
with DTV broadcasts, as some large video PES packets can delay the writing of
other elementary streams.
The new optional parameter "-mpegts_interleave_mux 1" enables another strategy.
Instead of writing all PES packets sequentially, the first TS packet of each PES
packet is written when the PES packet is started. But the rest of the PES data
will be written later, and interleaved between all the mux streams.
This new (optional) behavior has clear advantages when multiplexing multiple
programs with several video streams. And although this does not turn the
current implementation into a professional muxer, it brings the result closer
to what professional equipment does.
Example of use:
ffmpeg -i INPUT.ts \
-map "i:0x101" -c:v:0 copy \
-map "i:0x102" -c:a:0 copy \
-map "i:0x101" -c:v:1 copy \
-map "i:0x102" -c:a:1 copy \
-program title=Prog1:st=0:st=1 \
-program title=Prog2:st=2:st=3 \
-f mpegts -muxrate 33M -mpegts_interleave_mux 1 OUTPUT.ts
Signed-off-by: Andreas Hakon
---
libavformat/mpegtsenc.c | 300 +++
1 file changed, 228 insertions(+), 72 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..bd4 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -97,6 +97,7 @@ typedef struct MpegTSWrite {
int pmt_start_pid;
int start_pid;
int m2ts_mode;
+int parallel_mux;
int reemit_pat_pmt; // backward compatibility
@@ -120,6 +121,7 @@ typedef struct MpegTSWrite {
/* a PES packet header is generated every DEFAULT_PES_HEADER_FREQ packets */
#define DEFAULT_PES_HEADER_FREQ 16
#define DEFAULT_PES_PAYLOAD_SIZE ((DEFAULT_PES_HEADER_FREQ - 1) * 184 + 170)
+#define MAX_PES_PAYLOAD 2 * 200 * 1024 // From mpegts.c
/* The section length is 12 bits. The first 2 are set to 0, the remaining
* 10 bits should not exceed 1021. */
@@ -227,17 +229,24 @@ static int mpegts_write_section1(MpegTSSection *s, int
tid, int id,
#define PAT_RETRANS_TIME 100
#define PCR_RETRANS_TIME 20
+#define PES_START_FLAG 1
+#define PES_FULL_FLAG 2
+/* Unused free flags: 4,8,16,32,64 */
+#define PES_NEEDS_END_FLAG 128
+
typedef struct MpegTSWriteStream {
struct MpegTSService *service;
int pid; /* stream associated pid */
int cc;
int discontinuity;
int payload_size;
+int payload_top;
int first_pts_check; ///< first pts check needed
int prev_payload_key;
int64_t payload_pts;
int64_t payload_dts;
int payload_flags;
+int pes_flags;
uint8_t *payload;
AVFormatContext *amux;
AVRational user_tb;
@@ -866,7 +875,7 @@ static int mpegts_init(AVFormatContext *s)
ts_st->user_tb = st->time_base;
avpriv_set_pts_info(st, 33, 1, 9);
-ts_st->payload = av_mallocz(ts->pes_payload_size);
+ts_st->payload = av_mallocz(ts->parallel_mux ? MAX_PES_PAYLOAD :
ts->pes_payload_size);
if (!ts_st->payload) {
ret = AVERROR(ENOMEM);
goto fail;
@@ -910,6 +919,8 @@ static int mpegts_init(AVFormatContext *s)
pids[i]= ts_st->pid;
ts_st->payload_pts = AV_NOPTS_VALUE;
ts_st->payload_dts = AV_NOPTS_VALUE;
+ts_st->payload_top = 0;
+ts_st->pes_flags = 0;
ts_st->first_pts_check = 1;
ts_st->cc = 15;
ts_st->discontinuity = ts->flags & MPEGTS_FLAG_DISCONT;
@@ -953,46 +964,52 @@ static int mpegts_init(AVFormatContext *s)
av_freep();
-/* if no video stream, use the first stream as PCR */
-if (service->pcr_pid == 0x1fff && s->nb_streams > 0) {
-pcr_st = s->streams[0];
-ts_st= pcr_st->priv_data;
-service->pcr_pid = ts_st->pid;
-} else
-ts_st = pcr_st->priv_data;
-
-if (ts->mux_rate > 1) {
-service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->sdt_packet_period = (int64_t)ts->mux_rate * SDT_RETRANS_TIME /
-
Re: [FFmpeg-devel] [PATCH] add FF_DECODE_ERROR_DECODE_SLICES flag for AVFrame.decode_error_flags
Sorry Michael I missed this one. I submitted an updated patch. Thanks Amir On Sat, Jun 22, 2019 at 11:13 AM Michael Niedermayer wrote: > On Fri, Jun 21, 2019 at 07:15:55AM -0700, Amir Pauker wrote: > > FF_DECODE_ERROR_DECODE_SLICES is set when decoding slices result with > error(s) but the returned value from > > avcodec_receive_frame is zero > > The first line of the commit message needs a "avutil:" prefix or similar > also the first line should ideally be shorter and a summary of the change > > [...] > > -- > 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" > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] add FF_DECODE_ERROR_DECODE_SLICES flag for AVFrame.decode_error_flags
avutil: add FF_DECODE_ERROR_DECODE_SLICES for AVFrame.decode_error_flags
Signed-off-by: Amir Pauker
---
doc/APIchanges | 3 +++
libavutil/frame.h | 1 +
libavutil/version.h | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 29a1936..b5fadc2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-06-21 - XX - lavu 56.30.100 - frame.h
+ Add FF_DECODE_ERROR_DECODE_SLICES
+
2019-06-14 - XX - lavu 56.29.100 - frame.h
Add FF_DECODE_ERROR_CONCEALMENT_ACTIVE
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 54e682e..732b077 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -564,6 +564,7 @@ typedef struct AVFrame {
#define FF_DECODE_ERROR_INVALID_BITSTREAM 1
#define FF_DECODE_ERROR_MISSING_REFERENCE 2
#define FF_DECODE_ERROR_CONCEALMENT_ACTIVE 4
+#define FF_DECODE_ERROR_DECODE_SLICES 8
/**
* number of audio channels, only used for audio.
diff --git a/libavutil/version.h b/libavutil/version.h
index dccbb38..e16b93e 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 29
+#define LIBAVUTIL_VERSION_MINOR 30
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add delayer bitstream filter
Hi Marton, > Maybe it's too much work for little benefit, but instead of this a more > generic "setts" bitstream filter might be implemented which can be used to > set both PTS and DTS similar to how the setpts/asetpts filter works for > frames. New version (ready to merge) is here: https://patchwork.ffmpeg.org/patch/13743/ As for improvements, they can be made after the first version is accepted. Regards. A.H. --- ___ 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] libavcodec: add timer bitstream filter
Hi,
This is a refined version of the initial version for the new “timer” BSF.
Supersedes: https://patchwork.ffmpeg.org/patch/13699/
Changes from the last version:
1. Name changed from “delayer” to “timer”.
2. Enabled negative offset values (aka time advance).
3. Improved less verbose log functionality.
It will be updated in the future with more parameters. However, the idea is to
add it first as is.
Regards.
A.H.
---From db0f73bde33cfb52361d9905f16cd7ad773ece3d Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Fri, 28 Jun 2019 09:38:54 +0100
Subject: [PATCH] libavcodec: add timer bitstream filter
This implements the new timer bitstream filter.
Signed-off-by: Andreas Hakon
---
doc/bitstream_filters.texi |4 ++
libavcodec/Makefile|1 +
libavcodec/bitstream_filters.c |1 +
libavcodec/timer_bsf.c | 86
4 files changed, 92 insertions(+)
create mode 100644 libavcodec/timer_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 40e8ada..777f4b6 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -629,6 +629,10 @@ codec) with metadata headers.
See also the @ref{mov2textsub} filter.
+@section timer
+
+Apply an offset to the PTS/DTS timestamps.
+
@section trace_headers
Log trace output containing all syntax elements in the coded stream
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73..0f2770a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1096,6 +1096,7 @@ OBJS-$(CONFIG_NULL_BSF) += null_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o
OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_TIMER_BSF) += timer_bsf.o
OBJS-$(CONFIG_TRACE_HEADERS_BSF) += trace_headers_bsf.o
OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= truehd_core_bsf.o mlp_parse.o
mlp.o
OBJS-$(CONFIG_VP9_METADATA_BSF) += vp9_metadata_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 4630039..be6af05 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -51,6 +51,7 @@ extern const AVBitStreamFilter ff_null_bsf;
extern const AVBitStreamFilter ff_prores_metadata_bsf;
extern const AVBitStreamFilter ff_remove_extradata_bsf;
extern const AVBitStreamFilter ff_text2movsub_bsf;
+extern const AVBitStreamFilter ff_timer_bsf;
extern const AVBitStreamFilter ff_trace_headers_bsf;
extern const AVBitStreamFilter ff_truehd_core_bsf;
extern const AVBitStreamFilter ff_vp9_metadata_bsf;
diff --git a/libavcodec/timer_bsf.c b/libavcodec/timer_bsf.c
new file mode 100644
index 000..3f1c7f6
--- /dev/null
+++ b/libavcodec/timer_bsf.c
@@ -0,0 +1,86 @@
+/*
+ * 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
+ * This bitstream filter applies an offset to the PTS/DTS timestamps.
+ *
+ */
+
+// TODO: Control time wrapping
+// TODO: Instead of using absolute timestamp offsets, use frame numbers
+
+#include "avcodec.h"
+#include "bsf.h"
+
+#include "libavutil/opt.h"
+
+typedef struct TimerContext {
+const AVClass *class;
+int offset;
+int first_debug_done;
+} TimerContext;
+
+static int timer_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+int ret;
+TimerContext *s = ctx->priv_data;
+int64_t opts,odts;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+opts = pkt->pts;
+if (pkt->pts != AV_NOPTS_VALUE) {
+pkt->pts += s->offset;
+}
+odts = pkt->dts;
+if (pkt->dts != AV_NOPTS_VALUE) {
+pkt->dts += s->offset;
+}
+
+if (!s->first_debug_done) {
+av_log(ctx, AV_LOG_DEBUG, "Updated PTS/DTS (%"PRId64"/%"PRId64" :
%"PRId64"/%"PRId64") with offset:%d\n",
+pkt->pts, pkt->dts, opts, odts, s->offset );
+}
+s->first_debug_done = 1;
+
+return 0;
+}
+
+#define OFFSET(x) offsetof(TimerContext, x)
+#define FLAGS
(AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_SUBTITLE_PARAM|AV_OPT_FLAG_BSF_PARAM)
+static const AVOption options[] = {
+{ "offset", NULL, OFFSET(offset), AV_OPT_TYPE_INT, { .i64
Re: [FFmpeg-devel] [PATCH] Add DICOM Support
On 6/27/19 9:21 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: On 6/26/19 4:37 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: On 6/26/19, Michael Niedermayer wrote: On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: On 6/25/19 2:12 AM, Michael Niedermayer wrote: On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: Hi! The code is to add DICOM Support. The patch is only for uncompressed dicom files using explicit value representation. I would extend it, once i clarify some doubts. As dicom image files contain lots of metadata about the patient. So, should i display that data while demuxing or should i ignore and only demux the image data ?. In the current patch, i have made an option "-metadata", which when used will print the data on the terminal while demuxing. metadata should be exported to be usable by applications. For teh API design a one test is that it should be possible to have a dicom file as input and a format with similar features as output and not loose any significant data. Printing to the terminal cannot achieve that easily. So, should i export it to a csv file ? does it fit into the metadata system we have ? To clarify, you mean frame metadata system? data that is specific to a frame would belong in the frame metadata data that is specific to a stream would belong into that streams metadata data that is specific to the container would belong to its metadata iam not sure if multiple streams or frames can be in a single dicom "container" / file. If they can then it should be clear what goes where if not then all 3 options would from the point of view of dicom be the same. And in that case what is most convenient for interoperation with other formats should be picked. That is lets introduce the least amount of differences to how similar data is handled in other formats Dicom files contain multiple frames, but number of streams is always one (video) like GIF,( I haven't done multiframe support yet i am working on it ), The data specific to image/frames/pixels can be fit in the three categories of our metadata system, but their is extradata in DICOM files like : patient_name, medical_device_name , medical_procedure_done, study_date why could this not be fit in metadata ? Yeah this can fit in the key, value pair of our AVDictionaryEntry (and can be written with "-f ffmetadata"). So, should i assign this to streams metadata or containers metadata as this data is not stream specific or container specific ?. Thank you, Shivam Goyal ___ 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] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
On Thu, Jun 27, 2019 at 08:59:13PM +0800, Zhong Li wrote: > Signed-off-by: Zhong Li > --- > libavcodec/mjpeg_parser.c | 158 > +- > 1 file changed, 157 insertions(+), 1 deletion(-) this breaks mjpeg decoding for example tickets/3229/bad.avi https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3229/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates 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 V2 3/4] lavf/dump: More disposition flag dump
From: Jun Zhao More disposition flag dump Signed-off-by: Jun Zhao --- libavformat/dump.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/libavformat/dump.c b/libavformat/dump.c index bb8c72f..1c44656 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -547,8 +547,16 @@ static void dump_stream_format(AVFormatContext *ic, int i, av_log(NULL, AV_LOG_INFO, " (visual impaired)"); if (st->disposition & AV_DISPOSITION_CLEAN_EFFECTS) av_log(NULL, AV_LOG_INFO, " (clean effects)"); +if (st->disposition & AV_DISPOSITION_ATTACHED_PIC) +av_log(NULL, AV_LOG_INFO, " (attached pic)"); +if (st->disposition & AV_DISPOSITION_TIMED_THUMBNAILS) +av_log(NULL, AV_LOG_INFO, " (timed thumbnails)"); +if (st->disposition & AV_DISPOSITION_CAPTIONS) +av_log(NULL, AV_LOG_INFO, " (captions)"); if (st->disposition & AV_DISPOSITION_DESCRIPTIONS) av_log(NULL, AV_LOG_INFO, " (descriptions)"); +if (st->disposition & AV_DISPOSITION_METADATA) +av_log(NULL, AV_LOG_INFO, " (metadata)"); if (st->disposition & AV_DISPOSITION_DEPENDENT) av_log(NULL, AV_LOG_INFO, " (dependent)"); if (st->disposition & AV_DISPOSITION_STILL_IMAGE) -- 1.7.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".
Re: [FFmpeg-devel] [PATCH v3] lavf/vf_find_rect: add the dual input support function
On Thu, Jun 27, 2019 at 05:40:31PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Please using the below command for the testing:
> ./ffmpeg -i input.ts -i ref.png -filter_complex
> find_rect,cover_rect=cover.jpg:mode=cover output.ts
>
> I have updated the help document for the function change.
>
> Reviewed-by: Moritz Barsnick
> Signed-off-by: Limin Wang
> ---
> doc/filters.texi | 12 +--
> libavfilter/version.h | 2 +-
> libavfilter/vf_find_rect.c | 173 +++--
> 3 files changed, 118 insertions(+), 69 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 2d9af46a6b..92e1dee07e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
> @var{black}.
>
> Find a rectangular object
>
> +This filter takes in two video inputs, the first input is considered
> +the "main" source and is passed unchanged to the output. The "second"
> +input is used as a rectangular object for finding. Now the "second"
> +input will be auto converted to gray8 format.
> +
> It accepts the following options:
>
> @table @option
> -@item object
> -Filepath of the object image, needs to be in gray8.
> -
> @item threshold
> Detection threshold, default is 0.5.
>
> @@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
> @item
> Cover a rectangular object by the supplied image of a given video using
> @command{ffmpeg}:
> @example
> -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
> new.mkv
> +ffmpeg -i file.ts -i newref.pgm -filter_complex
> find_rect,cover_rect=cover.jpg:mode=cover new.mkv
It will be needed to support the old syntax until the next 2 major API bumps
at minimum.
That is first it would need to be deprecated and then we need 2 major API bumps
before it can be removed.
Keep in mind users both of the command line tools as well as the API would
need to have their scripts / software updated/changed for this.
also to make the transition easy both variants should be supported at the
samw time so people can switch to the new syntax "immedeatly" and do not
need to time it with a specific version bump
Yes i know thats a bit annoying ...
Theres of course no need to support newly added features with the old syntax
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
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 V2 2/4] ffmpeg_opt: Respect default disposition when select audio/video
From: Jun Zhao
Respect default disposition when select audio/video
Signed-off-by: Jun Zhao
---
fftools/ffmpeg_opt.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 53d688b..f5ca18a 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2198,7 +2198,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int new_area;
ist = input_streams[i];
-new_area = ist->st->codecpar->width *
ist->st->codecpar->height + 1*!!ist->st->codec_info_nb_frames;
+new_area = ist->st->codecpar->width *
ist->st->codecpar->height + 1*!!ist->st->codec_info_nb_frames
+ + 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
if((qcr!=MKTAG('A', 'P', 'I', 'C')) && (ist->st->disposition &
AV_DISPOSITION_ATTACHED_PIC))
@@ -2221,7 +,8 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int score;
ist = input_streams[i];
-score = ist->st->codecpar->channels +
1*!!ist->st->codec_info_nb_frames;
+score = ist->st->codecpar->channels +
1*!!ist->st->codec_info_nb_frames
++ 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
--
1.7.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 V2 1/4] lavf/utils: Respect default disposition when select the AVStream
From: Jun Zhao Respect default disposition when select the AVStream Signed-off-by: Jun Zhao --- libavformat/utils.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index 3d764c1..886cd6f 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -4218,7 +4218,8 @@ int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type, continue; } } -disposition = !(st->disposition & (AV_DISPOSITION_HEARING_IMPAIRED | AV_DISPOSITION_VISUAL_IMPAIRED)); +disposition = !(st->disposition & (AV_DISPOSITION_HEARING_IMPAIRED | AV_DISPOSITION_VISUAL_IMPAIRED)) + + !! (st->disposition & AV_DISPOSITION_DEFAULT); count = st->codec_info_nb_frames; bitrate = par->bit_rate; multiframe = FFMIN(5, count); -- 1.7.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 V2 4/4] fate: add disposition default test case
From: Jun Zhao add disposition default test case Signed-off-by: Jun Zhao --- tests/fate/ffmpeg.mak |4 + tests/ref/fate/ffmpeg-disposition_default | 106 + 2 files changed, 110 insertions(+), 0 deletions(-) create mode 100644 tests/ref/fate/ffmpeg-disposition_default diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 71ab2f1..557064e 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -34,6 +34,10 @@ fate-ffmpeg-filter_complex_audio: CMD = framecrc -filter_complex "aevalsrc=0:d=0 FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER PNG_DECODER ALAC_DECODER PCM_S16LE_ENCODER RAWVIDEO_ENCODER) += fate-ffmpeg-attached_pics fate-ffmpeg-attached_pics: CMD = threads=2 framecrc -i $(TARGET_SAMPLES)/lossless-audio/inside.m4a -c:a pcm_s16le -max_muxing_queue_size 16 +# disposition default +FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER H264_DECODER AAC_DECODER) += fate-ffmpeg-disposition_default +fate-ffmpeg-disposition_default: CMD = framecrc -i $(TARGET_SAMPLES)/mov/disposition_default.mp4 -vn -aframes 100 + FATE_SAMPLES_FFMPEG-$(CONFIG_COLORKEY_FILTER) += fate-ffmpeg-filter_colorkey fate-ffmpeg-filter_colorkey: tests/data/filtergraphs/colorkey fate-ffmpeg-filter_colorkey: CMD = framecrc -idct simple -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/cavs/cavs.mpg -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/lena.pnm -an -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/colorkey -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -qscale 2 -frames:v 10 diff --git a/tests/ref/fate/ffmpeg-disposition_default b/tests/ref/fate/ffmpeg-disposition_default new file mode 100644 index 000..0ccf888 --- /dev/null +++ b/tests/ref/fate/ffmpeg-disposition_default @@ -0,0 +1,106 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: pcm_s16le +#sample_rate 0: 44100 +#channel_layout 0: 4 +#channel_layout_name 0: mono +0, 0, 0, 1024, 2048, 0x8e3cfba8 +0, 1024, 1024, 1024, 2048, 0x9f92feba +0, 2048, 2048, 1024, 2048, 0x17ab01ba +0, 3072, 3072, 1024, 2048, 0x8ae0fe83 +0, 4096, 4096, 1024, 2048, 0x27e7fdb7 +0, 5120, 5120, 1024, 2048, 0xcbe5f4e1 +0, 6144, 6144, 1024, 2048, 0xf3170253 +0, 7168, 7168, 1024, 2048, 0x842ffb9a +0, 8192, 8192, 1024, 2048, 0xf883ffd3 +0, 9216, 9216, 1024, 2048, 0x8ba5107e +0, 10240, 10240, 1024, 2048, 0xd9300100 +0, 11264, 11264, 1024, 2048, 0xe68df95d +0, 12288, 12288, 1024, 2048, 0xc65bfe90 +0, 13312, 13312, 1024, 2048, 0x3a3dfe8e +0, 14336, 14336, 1024, 2048, 0xe5e8e891 +0, 15360, 15360, 1024, 2048, 0xed3fe566 +0, 16384, 16384, 1024, 2048, 0x891a00a7 +0, 17408, 17408, 1024, 2048, 0x5733fd83 +0, 18432, 18432, 1024, 2048, 0x3f17fbf9 +0, 19456, 19456, 1024, 2048, 0x8d9af9a0 +0, 20480, 20480, 1024, 2048, 0x07befe47 +0, 21504, 21504, 1024, 2048, 0x1d9b0942 +0, 22528, 22528, 1024, 2048, 0xa80ef560 +0, 23552, 23552, 1024, 2048, 0xe32bfb07 +0, 24576, 24576, 1024, 2048, 0xa7bf12ad +0, 25600, 25600, 1024, 2048, 0xf328f4cb +0, 26624, 26624, 1024, 2048, 0xdfbcf999 +0, 27648, 27648, 1024, 2048, 0xe054ee68 +0, 28672, 28672, 1024, 2048, 0x23aef44f +0, 29696, 29696, 1024, 2048, 0xe8d6f9fc +0, 30720, 30720, 1024, 2048, 0x01760509 +0, 31744, 31744, 1024, 2048, 0x7a6af785 +0, 32768, 32768, 1024, 2048, 0x5821ea5e +0, 33792, 33792, 1024, 2048, 0x47291609 +0, 34816, 34816, 1024, 2048, 0x40c004a5 +0, 35840, 35840, 1024, 2048, 0xc32deeed +0, 36864, 36864, 1024, 2048, 0x594e087a +0, 37888, 37888, 1024, 2048, 0x99680bd4 +0, 38912, 38912, 1024, 2048, 0x73c9fb51 +0, 39936, 39936, 1024, 2048, 0x983bf683 +0, 40960, 40960, 1024, 2048, 0x0b8af1dc +0, 41984, 41984, 1024, 2048, 0x6e13fb89 +0, 43008, 43008, 1024, 2048, 0x56e3043f +0, 44032, 44032, 1024, 2048, 0x3dd4f3b4 +0, 45056, 45056, 1024, 2048, 0x67eaf658 +0, 46080, 46080, 1024, 2048, 0x550af765 +0, 47104, 47104, 1024, 2048, 0xc2c9f90e +0, 48128, 48128, 1024, 2048, 0x10980f21 +0, 49152, 49152, 1024, 2048, 0x6f96005b +0, 50176, 50176, 1024, 2048, 0x3bf7f2af +0,
[FFmpeg-devel] [PATCH V2 0/4] Respect default disposition when select stream
V2: - Add FATE test case, the test clip will upload to FATE server Jun Zhao (4): lavf/utils: Respect default disposition when select the AVStream ffmpeg_opt: Respect default disposition when select audio/video lavf/dump: More disposition flag dump fate: add disposition default test case fftools/ffmpeg_opt.c |6 +- libavformat/dump.c|8 ++ libavformat/utils.c |3 +- tests/fate/ffmpeg.mak |4 + tests/ref/fate/ffmpeg-disposition_default | 106 + 5 files changed, 124 insertions(+), 3 deletions(-) create mode 100644 tests/ref/fate/ffmpeg-disposition_default ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line
Hello here!
A simple ping about this patch
If you have any question, feel free to ask!
Regards,
Olivier
On Wed, Jun 19, 2019 at 3:38 PM Olivier Maignial
wrote:
> === PROBLEM ===
>
> I was trying to record h264 + aac streams from an RTSP server to mp4 file.
> using this command line:
> ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
> aac_adtstoasc test.mp4
>
> FFmpeg then fail to record audio and output this logs:
> [rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
> [rtsp @ 0xcda1f0] Error parsing AU headers
> ...
> [rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio:
> aac, 48000 Hz, 1 channels): unspecified sample format
>
> In SDP provided by my RTSP server I had this fmtp line:
> a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr;
> config=1188; sizeLength=13; indexLength=3; indexDeltaLength=3;
>
> In FFmpeg code, I found a check introduced by commit
> 24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than
> 32 for fmtp line parameters.
> However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams)
> give examples of "profile-level-id" values for AAC, up to 55.
> Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any
> limit of size on interger parameters given in fmtp line.
>
> === FIX ===
>
> Instead of prohibit values over 32, I propose to check the possible
> integer overflow.
> The use of strtol allow to check the string validity and the possible
> overflow.
> Value is then checked against INT32_MIN and INT32_MAX. Using INT32_MIN/MAX
> ensure to have the same behavior on 32 or 64 bits platforms.
>
> This patch fix my problem and I now can record my RTSP AAC stream to mp4.
> It has passed the full fate tests suite sucessfully.
>
> Signed-off-by: Olivier Maignial
> ---
>
> Changes V5 -> V6:
> - Simplify code
>
> libavformat/rtpdec_mpeg4.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
> index 4f70599..9c4f8a1 100644
> --- a/libavformat/rtpdec_mpeg4.c
> +++ b/libavformat/rtpdec_mpeg4.c
> @@ -289,15 +289,20 @@ static int parse_fmtp(AVFormatContext *s,
> for (i = 0; attr_names[i].str; ++i) {
> if (!av_strcasecmp(attr, attr_names[i].str)) {
> if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
> -int val = atoi(value);
> -if (val > 32) {
> +char *end_ptr = NULL;
> +errno = 0;
> +long int val = strtol(value, _ptr, 10);
> +if (end_ptr == value || end_ptr[0] != '\0' ||
> +errno == ERANGE ||
> +val < INT32_MIN || val > INT32_MAX) {
> av_log(s, AV_LOG_ERROR,
> - "The %s field size is invalid (%d)\n",
> - attr, val);
> + "The %s field value is not a valid number,
> or overflows int32: %s\n",
> + attr, value);
> return AVERROR_INVALIDDATA;
> }
> +
> *(int *)((char *)data+
> -attr_names[i].offset) = val;
> +attr_names[i].offset) = (int) val;
> } else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
> char *val = av_strdup(value);
> if (!val)
> --
> 2.7.4
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt playlist
> 在 2019年6月28日，上午4:36，Bodecs Bela 写道： > > ping > > 2019.06.24. 18:01 keltezéssel, Bodecs Bela írta: >> Dear All, >> >> currently master playlist and subtitle playlist creation does not use >> temporary files even when temp_file flag is set. Most of the use cases >> it is not a problem because master playlist creation happens once on the >> beginning of the whole process. But if master playlist is periodically >> re-created because of master_pl_refresh_rate is set, non-atomic playlist >> creation may cause problems in case of live streaming. This poblem (i.e >> non-atomic playlist >> creation) may also apply for subtitle playlist (vtt) creation in live >> streaming. >> This patch correct this behavior by adding missing functionality. >> >> please review this patch. >> >> thank you in advance, >> >> best regards, >> >> Bela >> >> >> ___ >> 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”. pushed Thanks Steven ___ 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".
