Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations
2018-05-18 3:41 GMT+02:00, Rostislav Pehlivanov : > Pushed, thanks > Its a bittersweet victory, took 3 years but its finally done. Is it possible that you don't see that a "victory" always has a disadvantage? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] configure: error out on unsupported MSVC versions
2018-05-18 3:40 GMT+02:00, Rostislav Pehlivanov : > Pushed, thanks I believe you forgot the requested entry in the Changelog. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'
On Thu, May 17, 2018 at 1:10 PM, Gyan Doshi wrote: > > Of these, 10 failed (and have always failed) because of avformat_open_file > errors. Since I'm running this in MSYS2, > > '/ffmpeg/fate-suite/folder/samplefile' > > gets translated to > > 'G:/Code/ffmpeg/fate-suite/folder/samplefile' > > avformat_open_file is passed arg of 'G' and fails. This happens in 8 tests. > > You can avoid that by using a relative path to the samples. FATE does not properly quote/escape pathes for windows absolute pathes to work. Making sure that fate passes without your changes first is essential to find regressions. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Thu, 2018-05-17 at 12:30 +0200, Hendrik Leppkes wrote: > On Thu, May 17, 2018 at 8:08 AM, Xiang, Haihao wrote: > > On Wed, 2018-05-16 at 11:27 +0200, Hendrik Leppkes wrote: > > > On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao > > > wrote: > > > > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote: > > > > > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang > > > > > wrote: > > > > > > Signed-off-by: Haihao Xiang > > > > > > --- > > > > > > libavcodec/hevcdec.c | 5 + > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > > > > > > index c8877626d2..13d868bb4f 100644 > > > > > > --- a/libavcodec/hevcdec.c > > > > > > +++ b/libavcodec/hevcdec.c > > > > > > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext > > > > > > *avctx, > > > > > > const HEVCParamSets *ps, > > > > > > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; > > > > > > } > > > > > > > > > > > > +if (sps->vui.chroma_loc_info_present_flag) > > > > > > +avctx->chroma_sample_location = sps- > > > > > > > vui.chroma_sample_loc_type_top_field + 1; > > > > > > > > > > > > +else > > > > > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; > > > > > > > > > > > > > > > > This change is incomplete, refer to the patch I proposed earlier: > > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html > > > > > > > > > > > > > Sorry I didn't see your proposal before. Per spec, once > > > > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I > > > > think > > > > it > > > > would be better to add some checks when parsing the sequence parameters. > > > > > > > > > > It makes no real difference because you still need the check to be > > > able to set the LEFT default value for 4:2:0 only. > > > > If chroma_sample_loc_type_top_field is set correctly when parsing SPS, we > > may > > set chroma_sample_loc_type_top_field + 1 for 4:2:0 below no matter the > > present > > flag > > > > if (sps->chroma_format_idc == 1) > > avctx->chroma_sample_location = sps- > > >vui.chroma_sample_loc_type_top_field + > > 1; > > else > > avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; > > > > The fields in the sps struct should reflect the bitstream, > interpretation should be left out of it. > Actually the checks for some field are done in sps, e.g. def_disp_win_left_offset/def_disp_win_right_offset/def_disp_win_top_offset/ def_disp_win_bottom_offset. User needn't worry about the values when using these fields. > Like mentioned above, you always need the same checks anyway, all you > do is move it into another place. It is IMHO much cleaner to keep the > interpretation of all those values in the export_stream_params > function, its not like its complex or anything, but it cleanly > seperates parsing and interpretation, and ensures the sps struct only > contains values directly read from the bitstream. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Fri, May 18, 2018 at 10:52 AM, Xiang, Haihao wrote: > On Thu, 2018-05-17 at 12:30 +0200, Hendrik Leppkes wrote: >> On Thu, May 17, 2018 at 8:08 AM, Xiang, Haihao >> wrote: >> > On Wed, 2018-05-16 at 11:27 +0200, Hendrik Leppkes wrote: >> > > On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao >> > > wrote: >> > > > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote: >> > > > > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang >> > > > > >> > > > > wrote: >> > > > > > Signed-off-by: Haihao Xiang >> > > > > > --- >> > > > > > libavcodec/hevcdec.c | 5 + >> > > > > > 1 file changed, 5 insertions(+) >> > > > > > >> > > > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c >> > > > > > index c8877626d2..13d868bb4f 100644 >> > > > > > --- a/libavcodec/hevcdec.c >> > > > > > +++ b/libavcodec/hevcdec.c >> > > > > > @@ -344,6 +344,11 @@ static void >> > > > > > export_stream_params(AVCodecContext >> > > > > > *avctx, >> > > > > > const HEVCParamSets *ps, >> > > > > > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; >> > > > > > } >> > > > > > >> > > > > > +if (sps->vui.chroma_loc_info_present_flag) >> > > > > > +avctx->chroma_sample_location = sps- >> > > > > > > vui.chroma_sample_loc_type_top_field + 1; >> > > > > > >> > > > > > +else >> > > > > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; >> > > > > > >> > > > > >> > > > > This change is incomplete, refer to the patch I proposed earlier: >> > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html >> > > > > >> > > > >> > > > Sorry I didn't see your proposal before. Per spec, once >> > > > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I >> > > > think >> > > > it >> > > > would be better to add some checks when parsing the sequence >> > > > parameters. >> > > > >> > > >> > > It makes no real difference because you still need the check to be >> > > able to set the LEFT default value for 4:2:0 only. >> > >> > If chroma_sample_loc_type_top_field is set correctly when parsing SPS, we >> > may >> > set chroma_sample_loc_type_top_field + 1 for 4:2:0 below no matter the >> > present >> > flag >> > >> > if (sps->chroma_format_idc == 1) >> > avctx->chroma_sample_location = sps- >> > >vui.chroma_sample_loc_type_top_field + >> > 1; >> > else >> > avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; >> > >> >> The fields in the sps struct should reflect the bitstream, >> interpretation should be left out of it. >> > > Actually the checks for some field are done in sps, e.g. > def_disp_win_left_offset/def_disp_win_right_offset/def_disp_win_top_offset/ > def_disp_win_bottom_offset. User needn't worry about the values when using > these > fields. > > These fields are not available to "users". - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mpegts: keep track of AVProgram.pmt_version and set AV_PROGRAM_CHANGED on version updates
On Thu, 17 May 2018 18:13:34 -0700 Aman Gupta wrote: > On Thu, May 17, 2018 at 3:49 PM, Aman Gupta wrote: > > > From: Aman Gupta > > > > This can be used to detect changes to the streams in an AVProgram > > > > Forgot to add: I have seen two related patches in the wild that attempt to > solve this same problem in different ways. > > The first is in MythTV's ffmpeg fork, where they added a void > (*streams_changed)(void*); to AVFormatContext and call it from their mpegts > demuxer when the PMT changes. > > The second was proposed by XBMC in > https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html, where > they created a new AVMEDIA_TYPE_DATA stream with id=0 and attempted to send > packets to it whenever the PMT changed. > > The approach in this patch is similar to what's used by > AVFormatContext.event_flags and AVFMT_EVENT_FLAG_METADATA_UPDATED. > > I re-used AVProgram.flags for this purpose (which appears not to be used > for anything else). To be more explicit, it might be better to add > AVProgram.event_flags. Note that either way, the user would need to clear > AV_PROGRAM_CHANGED after detecting it (which should be documented). > > Another possibility would be to remove AV_PROGRAM_CHANGED altogether, which > means the user would need to keep a copy of program->version and compare it > to detect changes. Probably needs new doxygen that says that the API user can clear that change flag when convenient. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Properly expose intercepted ID3 tags to the API.
On Thu, 17 May 2018 20:49:42 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> The HLS demuxer will process any ID3 tags at the beginning of a segment in
> order to obtain timestamp data. However, when this data was parsed on a second
> or subsequent segment, the updated metadata would be discarded. This change
> preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_UPDATED
> event flag when appropriate.
> ---
> libavformat/hls.c | 34 +++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3d4f7f2647..3e2edb3484 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s, AVIOContext
> *pb,
> }
>
> /* Check if the ID3 metadata contents have changed */
> -static int id3_has_changed_values(struct playlist *pls, AVDictionary
> *metadata,
> - ID3v2ExtraMetaAPIC *apic)
> +static int id3_has_changed_values(struct playlist *pls, ID3v2ExtraMetaAPIC
> *apic)
> {
> -AVDictionaryEntry *entry = NULL;
> -AVDictionaryEntry *oldentry;
> -/* check that no keys have changed values */
> -while ((entry = av_dict_get(metadata, "", entry,
> AV_DICT_IGNORE_SUFFIX))) {
> -oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
> AV_DICT_MATCH_CASE);
> -if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
> -return 1;
> -}
> -
> /* check if apic appeared */
> if (apic && (pls->ctx->nb_streams != 2 ||
> !pls->ctx->streams[1]->attached_pic.data))
> return 1;
> @@ -1019,6 +1009,15 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
> int64_t timestamp = AV_NOPTS_VALUE;
>
> parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
> +ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> +av_dict_copy(&pls->ctx->metadata, metadata, 0);
> +/*
> + * If we've handled any ID3 metadata here, it's not going to be seen by
> the
> + * sub-demuxer. In the case that we got here because of an IO call during
> + * hls_read_header, this will be cleared. Otherwise, it provides the
> + * necessary hint to hls_read_packet that there is new metadata.
> + */
> +pls->ctx->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
Can't ID3 tags happen in large quantities with that ID3 timestamp hack
(curse whoever invented it)? Wouldn't that lead to a large number of
redundant events? Not sure though, I don't have the overview.
>
> if (timestamp != AV_NOPTS_VALUE) {
> pls->id3_mpegts_timestamp = timestamp;
> @@ -1037,12 +1036,10 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
> /* demuxer not yet opened, defer picture attachment */
> pls->id3_deferred_extra = extra_meta;
>
> -ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> -av_dict_copy(&pls->ctx->metadata, metadata, 0);
> pls->id3_initial = metadata;
>
> } else {
> -if (!pls->id3_changed && id3_has_changed_values(pls, metadata,
> apic)) {
> +if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
> avpriv_report_missing_feature(pls->ctx, "Changing ID3 metadata
> in HLS audio elementary stream");
> pls->id3_changed = 1;
> }
> @@ -1939,8 +1936,15 @@ static int hls_read_header(AVFormatContext *s)
> * Copy any metadata from playlist to main streams, but do not set
> * event flags.
> */
> -if (pls->n_main_streams)
> +if (pls->n_main_streams) {
> av_dict_copy(&pls->main_streams[0]->metadata,
> pls->ctx->metadata, 0);
> +/*
> + * If we've intercepted metadata, we will have set this event
> flag.
> + * Clear it to avoid confusion, since otherwise we will flag it
> as
> + * new metadata on the next call to hls_read_packet.
> + */
> +pls->ctx->event_flags = ~AVFMT_EVENT_FLAG_METADATA_UPDATED;
I think ~(unsigned)AVFMT_EVENT_... would be preferable for maximum
correctness.
> +}
>
> add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
> add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
On Thu, 17 May 2018 17:21:42 -0700 Aman Gupta wrote: > On Thu, May 17, 2018 at 5:04 PM, Aman Gupta wrote: > > > From: Aman Gupta > > > > Some filtered mpegts streams may erroneously include PMTs for programs > > that are not advertised in the PAT. This confuses ffmpeg and most > > players because multiple audio/video streams are created and it is > > unclear which ones actually contain data. > > > > See for example https://tmm1.s3.amazonaws.com/unknown-pmts.ts > > > > Before: > > > > Input #0, mpegts, from 'unknown-pmts.ts': > > Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s > > Program 4 > > Stream #0:2[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / > > 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], > > Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc > > Stream #0:3[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, > > 5.1(side), fltp, 384 kb/s > > Stream #0:4[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, > > stereo, fltp, 128 kb/s > > No Program > > Stream #0:0[0x31]: Video: mpeg2video ([2][0][0][0] / 0x0002), > > none(tv), 90k tbr, 90k tbn, 90k tbc > > Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 > > channels, fltp > > Stream #0:5[0x51]: Video: mpeg2video ([2][0][0][0] / 0x0002), > > none, 90k tbr, 90k tbn > > Stream #0:6[0x54](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels > > > > With skip_unknown_pmt=1: > > > > Input #0, mpegts, from 'unknown-pmts.ts': > > Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s > > Program 4 > > Stream #0:0[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / > > 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], > > Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc > > Stream #0:1[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, > > 5.1(side), fltp, 384 kb/s > > Stream #0:2[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, > > stereo, fltp, 128 kb/s > > > > Signed-off-by: Aman Gupta > > --- > > doc/demuxers.texi| 3 +++ > > libavformat/mpegts.c | 5 + > > 2 files changed, 8 insertions(+) > > > > diff --git a/doc/demuxers.texi b/doc/demuxers.texi > > index e7c2abce57..1d2ee5bf37 100644 > > --- a/doc/demuxers.texi > > +++ b/doc/demuxers.texi > > @@ -538,6 +538,9 @@ This demuxer accepts the following options: > > Set size limit for looking up a new synchronization. Default value is > > 65536. > > > > +@item skip_unknown_pmt > > +Skip PMTs for programs not defined in the PAT. Default value is 0. > > > > Maybe it's worth turning this option on by default? Sounds reasonable, but I don't know too much about TS. > We could also add debug/verbose logging when these PMTs are skipped, > but since it would happen every time the PMT is received it could become > very noisy. Just make it a higher log level. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'
On 5/18/2018 2:08 PM, Hendrik Leppkes wrote: You can avoid that by using a relative path to the samples. FATE does not properly quote/escape pathes for windows absolute pathes to work. That works. 0 fails. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'
On 5/18/2018 7:04 AM, Michael Niedermayer wrote: make: *** [fate-mpegts-probe-pmt-merge] Error 1 make: *** [fate-concat-demuxer-simple1-lavf-mxf_d10] Error 1 make: *** [fate-concat-demuxer-extended-lavf-mxf_d10] Error 1 make: *** [fate-concat-demuxer-simple1-lavf-mxf] Error 1 make: *** [fate-concat-demuxer-simple2-lavf-ts] Error 1 make: *** [fate-concat-demuxer-extended-lavf-mxf] Error 1 Patch withdrawn. ffprobe retains 'default' in order to set codec/format options. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config
Carl Eugen Hoyos (2018-05-14): > No, you have many times refused to allow them being solved. I have opposer your solutions because I think they are bad solutions and I can see a better one. I have proposed to help design said better solution, you have always declined but never given technical arguments. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
Hello Aman, On Thu, May 17, 2018 at 8:04 PM, Aman Gupta wrote: > From: Aman Gupta > > Some filtered mpegts streams may erroneously include PMTs for programs > that are not advertised in the PAT. This confuses ffmpeg and most > players because multiple audio/video streams are created and it is > unclear which ones actually contain data. I guess my big question would be, why is the ffmpeg TS demux interpreting some PIDs as containing PMT if they are not referenced by the PAT? I have to assume there is some heuristic in there which looks at arbitrary PID data and attempts to treat it as a PMT table (presumably in an attempt to play TS streams which are missing PAT). If that's the case, then I think *that's* what the patch should disable - assume the PAT/PMT are present and well-formed and don't play games trying to find a PMT assuming the PAT is absent/malformed. I can appreciate a player doing it's best to play some screwed up stream, but that sort of logic should not be the default. There are all sorts of strange proprietary data sent by broadcasters over PIDs and I wouldn't want those to get mis-detected as PMT when the spec says PIDs not explicitly in the PAT/PMT should be completely ignored. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Stream selection algorithm crossing program boundaries
Hello all, By default, ffmpeg will pick the "best" audio and video streams if the user doesn’t explicitly indicate such using the “-map” argument. However it completely ignores which programs streams are a part of, which can lead to cases where the video is picked from one program and the audio is from a completely different program. Is this something anyone is actively looking into? If not, I'll dig into it and see about respecting program membership in ffmpeg's selection algorithm. My larger concern is that with MPEG-TS streams, the commonly accepted heuristic is to play the first audio/video streams in the first PMT entry (this is what VLC does for example), rather than trying to pick the "best quality" streams, and it's not clear whether such a change in the selection algorithm would be accepted upstream (since it would make selection of audio/video in MPEG-TS streams behave differently than other formats). Thoughts? Devin --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/v210dec: Skip Canopus C210 extradata
On 17/05/18 12:20, Carl Eugen Hoyos wrote: > 2018-05-10 22:50 GMT+02:00, Carl Eugen Hoyos : > >> Peter Bubestinger provided a C210 file where every frame starts with >> 64 bytes of extradata (24 byte "INFO", 16 byte "RDRT", rest "FIEL"). >> Piotr confirmed that the Canopus decoder accepts files without the >> extradata but consumes it if present. >> Attached patch fixes the file in question visually. > Patch applied, Carl Eugen I've just tested with recent git (=including your path) and it seems to work properly. Also transcoded to FFV1 and compared framemd5: matches. Thank you very much! Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources
On 5/17/18, Tobias Rapp wrote: > Generates color bar test patterns based on EBU PAL recommendations. > > Signed-off-by: Tobias Rapp > --- > Changelog| 1 + > doc/filters.texi | 10 +++- > libavfilter/Makefile | 2 + > libavfilter/allfilters.c | 2 + > libavfilter/version.h| 2 +- > libavfilter/vsrc_testsrc.c | 106 > ++- > tests/fate/filter-video.mak | 6 +++ > tests/ref/fate/filter-pal100bars | 10 > tests/ref/fate/filter-pal75bars | 10 > 9 files changed, 146 insertions(+), 3 deletions(-) > create mode 100644 tests/ref/fate/filter-pal100bars > create mode 100644 tests/ref/fate/filter-pal75bars > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources
On 18.05.2018 15:23, Paul B Mahol wrote: On 5/17/18, Tobias Rapp wrote: Generates color bar test patterns based on EBU PAL recommendations. Signed-off-by: Tobias Rapp --- Changelog| 1 + doc/filters.texi | 10 +++- libavfilter/Makefile | 2 + libavfilter/allfilters.c | 2 + libavfilter/version.h| 2 +- libavfilter/vsrc_testsrc.c | 106 ++- tests/fate/filter-video.mak | 6 +++ tests/ref/fate/filter-pal100bars | 10 tests/ref/fate/filter-pal75bars | 10 9 files changed, 146 insertions(+), 3 deletions(-) create mode 100644 tests/ref/fate/filter-pal100bars create mode 100644 tests/ref/fate/filter-pal75bars lgtm Applied, thanks for the review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Stream selection algorithm crossing program boundaries
On 5/18/2018 6:50 PM, Devin Heitmueller wrote: Is this something anyone is actively looking into? If not, I'll dig into it and see about respecting program membership in ffmpeg's selection algorithm. My larger concern is that with MPEG-TS streams, the commonly accepted heuristic is to play the first audio/video streams in the first PMT entry (this is what VLC does for example), rather than trying to pick the "best quality" streams, and it's not clear whether such a change in the selection algorithm would be accepted upstream (since it would make selection of audio/video in MPEG-TS streams behave differently than other formats). Thoughts? If nb_input_files is 1, coupling the stream selection seems to me an improvement. But in the scenario of multiple inputs and no -map options, users usually intend to want a stream from all the sources, so in that case, using one of the streams as a 'key' for the other streams will break expectations. Unless the other inputs are meant for filtering, like a watermark, or background music. Your query has come at an inopportune time, since I intended to rewrite the Stream Selection chapter this weekend, since there are some quirks and nuances not covered or made plain, at present. But if you intend to proceed, of course, I'll wait. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avcodec/vc1: FIELDTX is only coded raw in interlaced frame I pictures
FIELDTX bitplane is only present in interlace frame I pictures. v->fieldtx_is_raw may spill over from a previous interlaced frame I picture while decoding a non-interlace frame I picture. Signed-off-by: Jerome Borsboom --- This patch set solves various issues that affected the SA10180.vc1 test file. With these patches applied, this file decodes bitequal to the Intel VAAPI decoder on Haswell. Please also review my patch set of May 9th that enables hwaccel decode of the SA10180.vc1 file. libavcodec/vc1_block.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c index f59c440943..daf30fdbfe 100644 --- a/libavcodec/vc1_block.c +++ b/libavcodec/vc1_block.c @@ -2680,7 +2680,7 @@ static void vc1_decode_i_blocks_adv(VC1Context *v) s->current_picture.motion_val[1][s->block_index[0] + v->blocks_off][1] = 0; // do actual MB decoding and displaying -if (v->fieldtx_is_raw) +if (v->fcm == ILACE_FRAME && v->fieldtx_is_raw) v->fieldtx_plane[mb_pos] = get_bits1(&v->s.gb); cbp = get_vlc2(&v->s.gb, ff_msmp4_mb_i_vlc.table, MB_INTRA_VLC_BITS, 2); if (v->acpred_is_raw) -- 2.13.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] avcodec/vc1: DIRECTBIT is only present in inter MBs
DIRECTBIT was decoded before the intra/inter MB branching when decoding
interlace frame B pictures. Resulting in mistakenly also decoding it for intra
MBs where this syntax element is not present.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1_block.c | 71 +-
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index aa2ea5024e..74935ec9e9 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -2173,41 +2173,6 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
}
}
-if (v->dmb_is_raw)
-direct = get_bits1(gb);
-else
-direct = v->direct_mb_plane[mb_pos];
-
-if (direct) {
-if (s->next_picture_ptr->field_picture)
-av_log(s->avctx, AV_LOG_WARNING, "Mixed frame/field direct mode
not supported\n");
-s->mv[0][0][0] =
s->current_picture.motion_val[0][s->block_index[0]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][0], v->bfraction, 0,
s->quarter_sample);
-s->mv[0][0][1] =
s->current_picture.motion_val[0][s->block_index[0]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][1], v->bfraction, 0,
s->quarter_sample);
-s->mv[1][0][0] =
s->current_picture.motion_val[1][s->block_index[0]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][0], v->bfraction, 1,
s->quarter_sample);
-s->mv[1][0][1] =
s->current_picture.motion_val[1][s->block_index[0]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][1], v->bfraction, 1,
s->quarter_sample);
-
-if (twomv) {
-s->mv[0][2][0] =
s->current_picture.motion_val[0][s->block_index[2]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[2]][0], v->bfraction, 0,
s->quarter_sample);
-s->mv[0][2][1] =
s->current_picture.motion_val[0][s->block_index[2]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[2]][1], v->bfraction, 0,
s->quarter_sample);
-s->mv[1][2][0] =
s->current_picture.motion_val[1][s->block_index[2]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[2]][0], v->bfraction, 1,
s->quarter_sample);
-s->mv[1][2][1] =
s->current_picture.motion_val[1][s->block_index[2]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[2]][1], v->bfraction, 1,
s->quarter_sample);
-
-for (i = 1; i < 4; i += 2) {
-s->mv[0][i][0] =
s->current_picture.motion_val[0][s->block_index[i]][0] = s->mv[0][i-1][0];
-s->mv[0][i][1] =
s->current_picture.motion_val[0][s->block_index[i]][1] = s->mv[0][i-1][1];
-s->mv[1][i][0] =
s->current_picture.motion_val[1][s->block_index[i]][0] = s->mv[1][i-1][0];
-s->mv[1][i][1] =
s->current_picture.motion_val[1][s->block_index[i]][1] = s->mv[1][i-1][1];
-}
-} else {
-for (i = 1; i < 4; i++) {
-s->mv[0][i][0] =
s->current_picture.motion_val[0][s->block_index[i]][0] = s->mv[0][0][0];
-s->mv[0][i][1] =
s->current_picture.motion_val[0][s->block_index[i]][1] = s->mv[0][0][1];
-s->mv[1][i][0] =
s->current_picture.motion_val[1][s->block_index[i]][0] = s->mv[1][0][0];
-s->mv[1][i][1] =
s->current_picture.motion_val[1][s->block_index[i]][1] = s->mv[1][0][1];
-}
-}
-}
-
if (ff_vc1_mbmode_intfrp[0][idx_mbmode][0] == MV_PMODE_INTFR_INTRA) { //
intra MB
for (i = 0; i < 4; i++) {
s->mv[0][i][0] =
s->current_picture.motion_val[0][s->block_index[i]][0] = 0;
@@ -2258,6 +2223,42 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
}
} else {
s->mb_intra = v->is_intra[s->mb_x] = 0;
+
+if (v->dmb_is_raw)
+direct = get_bits1(gb);
+else
+direct = v->direct_mb_plane[mb_pos];
+
+if (direct) {
+if (s->next_picture_ptr->field_picture)
+av_log(s->avctx, AV_LOG_WARNING, "Mixed frame/field direct
mode not supported\n");
+s->mv[0][0][0] =
s->current_picture.motion_val[0][s->block_index[0]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][0], v->bfraction, 0,
s->quarter_sample);
+s->mv[0][0][1] =
s->current_picture.motion_val[0][s->block_index[0]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][1], v->bfraction, 0,
s->quarter_sample);
+s->mv[1][0][0] =
s->current_picture.motion_val[1][s->block_index[0]][0] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][0], v->bfraction, 1,
s->quarter_sample);
+s->mv[1][0][1] =
s->current_picture.motion_val[1][s->block_index[0]][1] =
scale_mv(s->next_picture.motion_val[1][s->block_index[0]][1], v->bfraction, 1,
s->quarter_sample);
+
+if (twomv) {
+s->mv[0][2][0] =
s->current_picture.motion_val[0][s->block_index[2]][0] =
scale_mv(s->next_p
[FFmpeg-devel] [PATCH 4/5] avcodec/vc1: fix calculation of the last line of a slice
Only for the last slice of the first field is the last line of the slice
equal to the height of the field.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 750f4dff1c..fdbc852ec2 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -1082,7 +1082,7 @@ static int vc1_decode_frame(AVCodecContext *avctx, void
*data,
av_log(v->s.avctx, AV_LOG_ERROR, "first field slice count
too large\n");
continue;
}
-s->end_mb_y = (i <= n_slices1 + 1) ? mb_height :
FFMIN(mb_height, slices[i].mby_start % mb_height);
+s->end_mb_y = (i == n_slices1 + 1) ? mb_height :
FFMIN(mb_height, slices[i].mby_start % mb_height);
}
if (s->end_mb_y <= s->start_mb_y) {
av_log(v->s.avctx, AV_LOG_ERROR, "end mb y %d %d invalid\n",
s->end_mb_y, s->start_mb_y);
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] avcodec/vc1: store zero MVs for all blocks in a MB
Direct prediction for interlace frame B pictures references the mv in the
second block in an MB in the backward reference frame for the twomv case.
When the backward reference frame is an I frame, this value may be unset.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1_block.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 74935ec9e9..9c170a1e3c 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -2678,8 +2678,10 @@ static void vc1_decode_i_blocks_adv(VC1Context *v)
s->bdsp.clear_blocks(block[0]);
mb_pos = s->mb_x + s->mb_y * s->mb_stride;
s->current_picture.mb_type[mb_pos + v->mb_off]
= MB_TYPE_INTRA;
-s->current_picture.motion_val[1][s->block_index[0] +
v->blocks_off][0] = 0;
-s->current_picture.motion_val[1][s->block_index[0] +
v->blocks_off][1] = 0;
+for (int i = 0; i < 4; i++) {
+s->current_picture.motion_val[1][s->block_index[i] +
v->blocks_off][0] = 0;
+s->current_picture.motion_val[1][s->block_index[i] +
v->blocks_off][1] = 0;
+}
// do actual MB decoding and displaying
if (v->fcm == ILACE_FRAME && v->fieldtx_is_raw)
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] avcodec/vc1: fix mquant calculation for interlace field pictures
For interlace field pictures s->mb_height indicates the height of the full
picture in MBs, i.e. the two fields combined. A single field is half this
size. When calculating mquant for interlace field pictures, the bottom edge
is the last MB row of the field.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1_block.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index daf30fdbfe..aa2ea5024e 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -181,7 +181,8 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
mquant = -v->altpq;\
if ((edges&4) && s->mb_x == (s->mb_width - 1)) \
mquant = -v->altpq;\
-if ((edges&8) && s->mb_y == (s->mb_height - 1))\
+if ((edges&8) && \
+s->mb_y == ((s->mb_height >> v->field_mode) - 1)) \
mquant = -v->altpq;\
if (!mquant || mquant > 31) { \
av_log(v->s.avctx, AV_LOG_ERROR, \
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Stream selection algorithm crossing program boundaries
Hello Gyan,
Thanks for your comments. See inline:
> On May 18, 2018, at 10:24 AM, Gyan Doshi wrote:
> If nb_input_files is 1, coupling the stream selection seems to me an
> improvement. But in the scenario of multiple inputs and no -map options,
> users usually intend to want a stream from all the sources, so in that case,
> using one of the streams as a 'key' for the other streams will break
> expectations. Unless the other inputs are meant for filtering, like a
> watermark, or background music.
Indeed when I dug into the code it became clear that there is added complexity
when multiple input files are involved, if for no other reason than it’s not
immediately clear which input stream comes from which file and hence it’s
difficult to know which AVFormatContext to be looking at for a given stream. I
need the AVFormatContext to look at the program list, as well as potentially
reusing av_find_best_stream() if possible.
I suppose a question worth asking is whether a user would really be passing in
multiple files where the streams are already arranged into programs and expect
the audio to come from a different input file by default? My instinct would be
that even if he/she passed in multiple files, the default behavior should
probably be to pick the audio associated with the video as defined by the
program map (and render no audio if none is in the corresponding program). Of
course the user can always use -map to do something different.
I’m tempted to make the heuristic something like the following pseudocode:
If (nb_programs > 0) {
// Streams arranged into programs, so find first program
// Pick first video from that program
// Call av_find_best_stream() to find best audio for that video
} else {
// Use existing heuristic
}
With the above approach, we’re taking for granted that if the source input has
been arranged into programs, then the author had some preferences in mind with
regards to which streams to use by default, and thus by default we should
respect those decisions rather than trying to guess which streams to play (even
if he/she happened to specify multiple input files). If the content isn’t
arranged into programs then there’s no deterministic way to know which to play
by default, so fall back to the current algorithm. And of course if that’s not
what the user wants then he/she can always use -map.
If the above is unacceptable, I’m not against making the new heuristic only if
both the file contains one or more programs and there is only a single input
file. In fact the code for that is actually easier to implement (since I only
have to ever look at the AVFormatContext for the first input and not have to
try to correlate streams back to their corresponding input files). However I’m
not sure if the behavior should really vary based on whether multiple input
files are specified.
> Your query has come at an inopportune time, since I intended to rewrite the
> Stream Selection chapter this weekend, since there are some quirks and
> nuances not covered or made plain, at present. But if you intend to proceed,
> of course, I'll wait.
If we can come to a consensus on what the behavior should be (and believe it
will be accepted upstream), then I can take a crack at the actual
implementation.
Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Stream selection algorithm crossing program boundaries
Hi Devin, On 5/18/2018 9:17 PM, Devin Heitmueller wrote: Indeed when I dug into the code it became clear that there is added complexity when multiple input files are involved, if for no other reason than it’s not immediately clear which input stream comes from which file and hence it’s difficult to know which AVFormatContext to be looking at for a given stream. Since the proposed change will have to be in open_output_file() in ffmpeg_opt.c, you can check InputStream->file_index or do you mean something else? I suppose a question worth asking is whether a user would really be passing in multiple files where the streams are already arranged into programs and expect the audio to come from a different input file by default? Based on the thousands of users I've engaged with, at SE sites, most users have little to middling familiarity with ffmpeg, have cribbed and perhaps adjusted a command from a similar operation discussed elsewhere, and would be unaware of whether a file sports Programs or otherwise. if the user had clear and specific needs, they would supply -map and this conversation is moot. We are talking about those users relying either on ffmpeg "magic" or traditional behaviour they have encountered in past use. If multiple inputs are specified, that's a good clue that all inputs are intended for some use, and to me, of higher salience than presence of Programs, because the former is an express declaration by the user to ffmpeg of the resources required. The latter may be an incidental property of the input of which the user may or may not be aware. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/vc1: FIELDTX is only coded raw in interlaced frame I pictures
2018-05-18 17:06 GMT+02:00, Jerome Borsboom : > This patch set solves various issues that affected the SA10180.vc1 > test file. With these patches applied, this file decodes bitequal to > the Intel VAAPI decoder on Haswell. I still see artefacts beginning after ~22 seconds that are not visible with the reference decoder, the first 547 frames are bit-exact. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
On Fri, May 18, 2018 at 6:12 AM, Devin Heitmueller < dheitmuel...@kernellabs.com> wrote: > Hello Aman, > > On Thu, May 17, 2018 at 8:04 PM, Aman Gupta wrote: > > From: Aman Gupta > > > > Some filtered mpegts streams may erroneously include PMTs for programs > > that are not advertised in the PAT. This confuses ffmpeg and most > > players because multiple audio/video streams are created and it is > > unclear which ones actually contain data. > > I guess my big question would be, why is the ffmpeg TS demux > interpreting some PIDs as containing PMT if they are not referenced by > the PAT? I have to assume there is some heuristic in there which > looks at arbitrary PID data and attempts to treat it as a PMT table > (presumably in an attempt to play TS streams which are missing PAT). > There is no such heuristic, and ffmpeg is not interpreting random PIDs as containing PMTs. The issue is that the PMT PID advertised in the PAT contains multiple PMTs for different programs. This is because the broadcaster decided to re-use the same PID for multiple program PMTs. > If that's the case, then I think *that's* what the patch should > disable - assume the PAT/PMT are present and well-formed and don't > play games trying to find a PMT assuming the PAT is absent/malformed. > > I can appreciate a player doing it's best to play some screwed up > stream, but that sort of logic should not be the default. There are > all sorts of strange proprietary data sent by broadcasters over PIDs > and I wouldn't want those to get mis-detected as PMT when the spec > says PIDs not explicitly in the PAT/PMT should be completely ignored. > Again, we don't look at random PIDs and try to make sense of the data on them. I think this option makes sense by default, because it follows how the spec says the stream should be interpreted. Look at the PAT for programs, then search the pids listed for PMTs that match those programs. To be clear, this issue is specific to _filtered_ mpegts streams. In this case, my tuner hardware is trying to filter the mpegts stream from the broadcaster to include only the program I care about. It does this by rewriting the PAT to contain only the program I requested, but since it just passes through the pid reference in the PAT, all the PMTs (including those for other programs) come through. Most of the time this works fine, because the pmt pid only contains PMTs for a single program. Hope that makes sense, Aman > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_nlmeans: better weighting of centered pixel
On Sat, May 12, 2018 at 10:24:34PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_nlmeans.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
> index 82e779ce85..6c9c9d312d 100644
> --- a/libavfilter/vf_nlmeans.c
> +++ b/libavfilter/vf_nlmeans.c
> @@ -39,6 +39,7 @@
> #include "video.h"
>
> struct weighted_avg {
> +float max_weight;
> float total_weight;
> float sum;
> };
> @@ -403,6 +404,7 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg,
> int jobnr, int nb_jobs
> if (patch_diff_sq < s->max_meaningful_diff) {
> const unsigned weight_lut_idx = patch_diff_sq *
> s->pdiff_lut_scale;
> const float weight = s->weight_lut[weight_lut_idx]; //
> exp(-patch_diff_sq * s->pdiff_scale)
> +wa[x].max_weight = FFMAX(weight, wa[x].max_weight);
> wa[x].total_weight += weight;
> wa[x].sum += weight * src[x];
> }
> @@ -422,8 +424,10 @@ static void weight_averages(uint8_t *dst, ptrdiff_t
> dst_linesize,
> for (y = 0; y < h; y++) {
> for (x = 0; x < w; x++) {
> // Also weight the centered pixel
> -wa[x].total_weight += 1.f;
> -wa[x].sum += 1.f * src[x];
> +if (!isnormal(wa[x].max_weight))
> +wa[x].max_weight = 1.f;
> +wa[x].total_weight += wa[x].max_weight;
> +wa[x].sum += src[x] * wa[x].max_weight;
> dst[x] = av_clip_uint8(wa[x].sum / wa[x].total_weight);
> }
> dst += dst_linesize;
Do you mind adding a cpw/center-pixel-weight option with multiple modes?
"one" and "max" for a start would be nice, then eventually advanced modes
can be added. Please also mention https://arxiv.org/pdf/1211.1656 at least
in the commit description.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/vf_nlmeans: add amount parameter
On Sat, May 12, 2018 at 10:24:35PM +0200, Paul B Mahol wrote:
> For better control of denoising.
>
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 4
> libavfilter/vf_nlmeans.c | 5 -
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index d77c67eb10..60ce18298b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -11420,6 +11420,10 @@ Set research size.
> Same as @option{r} but for chroma planes.
>
> The default value is @var{0} and means automatic.
> +
> +@item a
> +Set denoising amount. Lower values reduces blurring.
> +Default value is @var{1.0} and means full denoising.
I'm not so fond of adding another semantically identical option to
"strength". Do you have some literature on such an option?
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] checkasm: add vf_nlmeans test for ssd_integral_image
On Thu, May 10, 2018 at 02:10:00AM +0200, Michael Niedermayer wrote: > On Tue, May 08, 2018 at 08:29:00AM +, Clément Bœsch wrote: > > ffmpeg | branch: master | Clément Bœsch | Sun May 6 10:57:23 > > 2018 +0200| [f679711c1b516786a39f9e582622a200502fff74] | committer: Clément > > Bœsch > > > > checkasm: add vf_nlmeans test for ssd_integral_image > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=f679711c1b516786a39f9e582622a200502fff74 > > --- > > > > tests/checkasm/Makefile | 1 + > > tests/checkasm/checkasm.c | 3 ++ > > tests/checkasm/checkasm.h | 1 + > > tests/checkasm/vf_nlmeans.c | 113 > > > > 4 files changed, 118 insertions(+) > > This causes > tests/checkasm/checkasm > to crash > (make fate does not crash) > > tell me if you cant reproduce it then ill rebuild and get a proper backtrace > & valgrind > > only got this ATM: > checkasm: using random seed 1025639728 > *** buffer overflow detected ***: tests/checkasm/checkasm terminated > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7fe82d5de29f] > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fe82d67987c] > /lib/x86_64-linux-gnu/libc.so.6(+0x10d750)[0x7fe82d678750] > tests/checkasm/checkasm[0x4c36c7] > tests/checkasm/checkasm[0x4a1774] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fe82d58cf45] > tests/checkasm/checkasm[0x4a1923] > Fixed in 2940af9389e5cb2a7509655195e5ccb928577ed2 Thanks & sorry about the delay -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
> The issue is that the PMT PID advertised in the PAT contains multiple PMTs > for different programs. This is because the broadcaster decided to re-use > the same PID for multiple program PMTs. Ugh, ok. I understand the case you're talking about now. Thanks for clarifying. > To be clear, this issue is specific to _filtered_ mpegts streams. In this > case, my tuner hardware is trying to filter the mpegts stream from the > broadcaster to include only the program I care about. This is actually what I assumed, but I thought you were referring to the broken behavior found in some of the LinuxTV command line tools which allow you to save the TS but they don't include the PAT in the list of filtered PIDs. Now that I understand what you're trying to do, the approach you've proposed makes sense. I withdrawal any objections. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
On Fri, May 18, 2018 at 10:28 AM, Devin Heitmueller < dheitmuel...@kernellabs.com> wrote: > > The issue is that the PMT PID advertised in the PAT contains multiple > PMTs > > for different programs. This is because the broadcaster decided to re-use > > the same PID for multiple program PMTs. > > Ugh, ok. I understand the case you're talking about now. Thanks for > clarifying. > > > To be clear, this issue is specific to _filtered_ mpegts streams. In this > > case, my tuner hardware is trying to filter the mpegts stream from the > > broadcaster to include only the program I care about. > > This is actually what I assumed, but I thought you were referring to > the broken behavior found in some of the LinuxTV command line tools > which allow you to save the TS but they don't include the PAT in the > list of filtered PIDs. > > Now that I understand what you're trying to do, the approach you've > proposed makes sense. I withdrawal any objections. > Thanks. I'll try to expand the commit message to make it more clear before committing. FYI, the way ffmpeg deals with missing PAT/PMT is by automatically creating streams for any PIDs that appear containing PES streams. In this case, those extra pids are not in the file, so the streams were only getting created because of the erroneous PMTs being seen. Aman > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 3/3] avformat/mpegts: add merge_pmt_versions option
From: Aman Gupta
This new optional flag makes it easier to deal with mpegts
samples where the PMT is updated and elementary streams move
to different PIDs in the middle of playback.
Previously, new AVStreams were created per PID, and it was up
to the user to figure out which streams had migrated to a new PID
(by iterating over the list of AVProgram and making guesses), and
switch seamlessly to the new AVStream during playback.
Transcoding or remuxing these streams with ffmpeg on the CLI was
also quite painful, and the user would need to extract each set of
PIDs into a separate file and then stitch them back together.
With this new option, the mpegts demuxer will automatically detect
PMT changes and feed data from the new PID to the original AVStream
that was created for the orignal PID. For mpegts samples with
stream_identifier_descriptor available, the unique ID is used to merge
PIDs together. If the stream id is not available, the demuxer attempts
to map PIDs based on their order and relation to the PCR pid.
With this change, I am able to playback and transcode/remux these
two samples which previously caused issues:
https://tmm1.s3.amazonaws.com/pmt-version-change.ts
https://kuroko.fushizen.eu/videos/pid_switch_sample.ts
I also have another longer sample which contains multiple PMT
changes, some of which change the ES pids and others which do not:
https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts
Demuxing this sample with the new option shows several new log
messages as the PMT changes are handled:
[mpegts @ 0x7ffe18801200] detected PMT change (version=3/4,
pcr_pid=0xf98/0xf9b)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for
new pid=0xf9b
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for
new pid=0xf9c
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for
new pid=0xf9d
[mpegts @ 0x7ffe18801200] detected PMT change (version=4/5,
pcr_pid=0xf9b/0xfa9)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for
new pid=0xfa9
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for
new pid=0xfaa
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for
new pid=0xfab
Signed-off-by: Aman Gupta
---
doc/demuxers.texi | 4 ++
libavformat/mpegts.c | 99 +--
tests/fate/mpegts.mak | 5 ++
tests/ref/fate/mpegts-probe-pmt-merge | 32 +++
4 files changed, 137 insertions(+), 3 deletions(-)
create mode 100644 tests/ref/fate/mpegts-probe-pmt-merge
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e7c2abce57..2f7d7e0f3a 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -552,6 +552,10 @@ Show the detected raw packet size, cannot be set by the
user.
Scan and combine all PMTs. The value is an integer with value from -1
to 1 (-1 means automatic setting, 1 means enabled, 0 means
disabled). Default value is -1.
+
+@item merge_pmt_versions
+Re-use existing streams when a PMT's version is updated and elementary
+streams move to different PIDs. Default value is 0.
@end table
@section mpjpeg
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 229202e09d..6346757ba4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -84,6 +84,7 @@ typedef struct MpegTSSectionFilter {
unsigned int end_of_section_reached : 1;
SectionCallback *section_cb;
void *opaque;
+int orig_pcr_pid; /* pmt specific */
} MpegTSSectionFilter;
struct MpegTSFilter {
@@ -147,6 +148,7 @@ struct MpegTSContext {
int scan_all_pmts;
int resync_size;
+int merge_pmt_versions;
/**/
/* private mpegts data */
@@ -172,6 +174,8 @@ static const AVOption options[] = {
{.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT |
AV_OPT_FLAG_READONLY },
{"scan_all_pmts", "scan and combine all PMTs", offsetof(MpegTSContext,
scan_all_pmts), AV_OPT_TYPE_BOOL,
{.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
+{"merge_pmt_versions", "re-use streams when PMT's version/pids change",
offsetof(MpegTSContext, merge_pmt_versions), AV_OPT_TYPE_BOOL,
+ {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
{"skip_changes", "skip changing / adding streams / programs",
offsetof(MpegTSContext, skip_changes), AV_OPT_TYPE_BOOL,
{.i64 = 0}, 0, 1, 0 },
{"skip_clear", "skip clearing programs", offsetof(MpegTSContext,
skip_clear), AV_OPT_TYPE_BOOL,
@@ -1083,6 +1087,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
if (!pes->st) {
if (ts->skip_changes)
goto skip;
+if (ts->merge_pmt_versions)
+goto skip; /* wait for PMT to merge new stream */
pes->st = avformat_new_stream(ts->stream, NULL)
[FFmpeg-devel] [PATCH v4 2/3] avformat/mpegts: keep track of PMT details in AVProgram/AVStream
From: Aman Gupta
With these fields, the user has enough information to
detect PMT changes and switch to new streams when the PMT
is updated with new ES pids.
To do so, the user would monitor the AVProgram they're interested
in for changes to pmt_version. If the version changes, they would
iterate over the program's streams to find new streams added with
the updated version number.
If new versions of streams are found, then the user would first try
to replace existing streams where stream_identifier matched.
If stream_identifier is not available, then the user would compare
pmt_stream_idx instead to replace the stream that was previously
at the same position within the PMT.
Signed-off-by: Aman Gupta
---
libavformat/mpegts.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index fc9bb3940e..229202e09d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -330,12 +330,23 @@ static void set_pmt_found(MpegTSContext *ts, unsigned int
programid)
p->pmt_found = 1;
}
-static void set_pcr_pid(AVFormatContext *s, unsigned int programid, unsigned
int pid)
+static void update_av_program_info(AVFormatContext *s, unsigned int programid,
+ unsigned int pid, int version)
{
int i;
for (i = 0; i < s->nb_programs; i++) {
-if (s->programs[i]->id == programid) {
-s->programs[i]->pcr_pid = pid;
+AVProgram *program = s->programs[i];
+if (program->id == programid) {
+int old_pcr_pid = program->pcr_pid,
+old_version = program->pmt_version;
+program->pcr_pid = pid;
+program->pmt_version = version;
+
+if (old_version != -1 && old_version != version) {
+av_log(s, AV_LOG_DEBUG,
+ "detected PMT change on program %d (version=%d/%d,
pcr_pid=0x%x/0x%x)\n",
+ programid, old_version, version, old_pcr_pid, pid);
+}
break;
}
}
@@ -2036,7 +2047,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
return;
pcr_pid &= 0x1fff;
add_pid_to_pmt(ts, h->id, pcr_pid);
-set_pcr_pid(ts->stream, h->id, pcr_pid);
+update_av_program_info(ts->stream, h->id, pcr_pid, h->version);
av_log(ts->stream, AV_LOG_TRACE, "pcr_pid=0x%x\n", pcr_pid);
@@ -2078,7 +2089,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
set_pmt_found(ts, h->id);
-for (;;) {
+for (i = 0; ; i++) {
st = 0;
pes = NULL;
stream_type = get8(&p, p_end);
@@ -2099,6 +2110,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
if (!pes->st)
goto out;
pes->st->id = pes->pid;
+pes->st->program_num = h->id;
+pes->st->pmt_version = h->version;
+pes->st->pmt_stream_idx = i;
}
st = pes->st;
} else if (is_pes_stream(stream_type, prog_reg_desc)) {
@@ -2110,6 +2124,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
if (!st)
goto out;
st->id = pes->pid;
+st->program_num = h->id;
+st->pmt_version = h->version;
+st->pmt_stream_idx = i;
}
} else {
int idx = ff_find_stream_index(ts->stream, pid);
@@ -2120,6 +2137,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t
*section, int section_len
if (!st)
goto out;
st->id = pid;
+st->program_num = h->id;
+st->pmt_version = h->version;
+st->pmt_stream_idx = i;
st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
if (stream_type == 0x86 && prog_reg_desc == AV_RL32("CUEI")) {
mpegts_find_stream_type(st, stream_type, SCTE_types);
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 1/3] avformat: add fields to AVProgram/AVStream for PMT change tracking
From: Aman Gupta
These fields will allow the mpegts demuxer to expose details about
the PMT/program which created the AVProgram and its AVStreams.
In mpegts, a PMT which advertises streams has a version number
which can be incremented at any time. When the version changes,
the pids which correspond to each of it's streams can also change.
Since ffmpeg creates a new AVStream per pid by default, an API user
needs the ability to (a) detect when the PMT changed, and (b) tell
which AVStream were added to replace earlier streams.
This has been a long-standing issue with ffmpeg's handling of mpegts
streams with PMT changes, and I found two related patches in the wild
that attempt to solve the same problem.
The first is in MythTV's ffmpeg fork, where they added a
void (*streams_changed)(void*); to AVFormatContext and call it from
their fork of the mpegts demuxer whenever the PMT changes.
The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html,
where they created a new AVMEDIA_TYPE_DATA stream with id=0 and
attempted to send packets to it whenever the PMT changed.
Signed-off-by: Aman Gupta
---
doc/APIchanges | 4
libavformat/avformat.h | 8
libavformat/utils.c| 1 +
libavformat/version.h | 2 +-
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index befa58c84a..a592073ca5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2018-05-xx - xx - lavf 58.15.100 - avformat.h
+ Add pmt_version field to AVProgram
+ Add program_num, pmt_version, pmt_stream_idx to AVStream
+
2018-05-xx - xx - lavf 58.14.100 - avformat.h
Add AV_DISPOSITION_STILL_IMAGE
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6dce88fad5..ade918f99c 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1103,6 +1103,13 @@ typedef struct AVStream {
*/
int stream_identifier;
+/**
+ * Details of the MPEG-TS program which created this stream.
+ */
+int program_num;
+int pmt_version;
+int pmt_stream_idx;
+
int64_t interleaver_chunk_size;
int64_t interleaver_chunk_duration;
@@ -1260,6 +1267,7 @@ typedef struct AVProgram {
int program_num;
int pmt_pid;
int pcr_pid;
+int pmt_version;
/*
* All fields below this line are not part of the public API. They
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 636fae3779..a4aa4e10b1 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4569,6 +4569,7 @@ AVProgram *av_new_program(AVFormatContext *ac, int id)
return NULL;
dynarray_add(&ac->programs, &ac->nb_programs, program);
program->discard = AVDISCARD_NONE;
+program->pmt_version = -1;
}
program->id = id;
program->pts_wrap_reference = AV_NOPTS_VALUE;
diff --git a/libavformat/version.h b/libavformat/version.h
index e9b94cc216..c8e89cdce1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 14
+#define LIBAVFORMAT_VERSION_MINOR 15
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Properly expose intercepted ID3 tags to the API.
On Fri, May 18, 2018 at 2:54 AM, wm4 wrote:
> On Thu, 17 May 2018 20:49:42 -0700
> rshaf...@tunein.com wrote:
>
> > From: Richard Shaffer
> >
> > The HLS demuxer will process any ID3 tags at the beginning of a segment
> in
> > order to obtain timestamp data. However, when this data was parsed on a
> second
> > or subsequent segment, the updated metadata would be discarded. This
> change
> > preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_
> UPDATED
> > event flag when appropriate.
> > ---
> > libavformat/hls.c | 34 +++---
> > 1 file changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 3d4f7f2647..3e2edb3484 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s,
> AVIOContext *pb,
> > }
> >
> > /* Check if the ID3 metadata contents have changed */
> > -static int id3_has_changed_values(struct playlist *pls, AVDictionary
> *metadata,
> > - ID3v2ExtraMetaAPIC *apic)
> > +static int id3_has_changed_values(struct playlist *pls,
> ID3v2ExtraMetaAPIC *apic)
> > {
> > -AVDictionaryEntry *entry = NULL;
> > -AVDictionaryEntry *oldentry;
> > -/* check that no keys have changed values */
> > -while ((entry = av_dict_get(metadata, "", entry,
> AV_DICT_IGNORE_SUFFIX))) {
> > -oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
> AV_DICT_MATCH_CASE);
> > -if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
> > -return 1;
> > -}
> > -
> > /* check if apic appeared */
> > if (apic && (pls->ctx->nb_streams != 2 || !pls->ctx->streams[1]->
> attached_pic.data))
> > return 1;
> > @@ -1019,6 +1009,15 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
> > int64_t timestamp = AV_NOPTS_VALUE;
> >
> > parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
> > +ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> > +av_dict_copy(&pls->ctx->metadata, metadata, 0);
> > +/*
> > + * If we've handled any ID3 metadata here, it's not going to be
> seen by the
> > + * sub-demuxer. In the case that we got here because of an IO call
> during
> > + * hls_read_header, this will be cleared. Otherwise, it provides the
> > + * necessary hint to hls_read_packet that there is new metadata.
> > + */
> > +pls->ctx->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
>
> Can't ID3 tags happen in large quantities with that ID3 timestamp hack
> (curse whoever invented it)? Wouldn't that lead to a large number of
> redundant events? Not sure though, I don't have the overview.
>
Yes, that's a good point. If timestamps are in ID3 tags, they'll be at the
start of every segment. I can think of several ways to handle that:
Option 1: Technically it is updated metadata, so mark it as updated. Leave
it up to the API caller to figure out whether they care about it or not.
Option 2: Filter out timestamp ID3 frames, and only mark it as updated if
some other ID3 tag or frame is present.
Option 3: Compare the new metadata with the last seen metadata, and only
set the event flag if something besides the timestamp has actually changed.
That would filter out false updates for the API consumer, but I'm pretty
sure nothing else that handles metadata updates works this way.
Any thoughts? Personally I'd lean towards 1 or 2.
>
> >
> > if (timestamp != AV_NOPTS_VALUE) {
> > pls->id3_mpegts_timestamp = timestamp;
> > @@ -1037,12 +1036,10 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
> > /* demuxer not yet opened, defer picture attachment */
> > pls->id3_deferred_extra = extra_meta;
> >
> > -ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> > -av_dict_copy(&pls->ctx->metadata, metadata, 0);
> > pls->id3_initial = metadata;
> >
> > } else {
> > -if (!pls->id3_changed && id3_has_changed_values(pls, metadata,
> apic)) {
> > +if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
> > avpriv_report_missing_feature(pls->ctx, "Changing ID3
> metadata in HLS audio elementary stream");
> > pls->id3_changed = 1;
> > }
> > @@ -1939,8 +1936,15 @@ static int hls_read_header(AVFormatContext *s)
> > * Copy any metadata from playlist to main streams, but do not
> set
> > * event flags.
> > */
> > -if (pls->n_main_streams)
> > +if (pls->n_main_streams) {
> > av_dict_copy(&pls->main_streams[0]->metadata,
> pls->ctx->metadata, 0);
> > +/*
> > + * If we've intercepted metadata, we will have set this
> event flag.
> > + * Clear it to avoid confusion, since otherwise we will
> flag it as
> > + * new metadata on the next call to hls_read_packet.
> > + */
> > +
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/vc1: FIELDTX is only coded raw in interlaced frame I pictures
> 2018-05-18 17:06 GMT+02:00, Jerome Borsboom : > >> This patch set solves various issues that affected the SA10180.vc1 >> test file. With these patches applied, this file decodes bitequal to >> the Intel VAAPI decoder on Haswell. > > I still see artefacts beginning after ~22 seconds that are not visible > with the reference decoder, the first 547 frames are bit-exact. > > Carl Eugen I have found the issue that produces the artifacts. I need to update both ffmpeg and the Intel VAAPI driver as both make the same wrong assumption. Please expect at least one more patch in the coming days to resolve this issue. Regards, Jerome ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
- Original Message -
> From: "Rostislav Pehlivanov"
> To: "FFmpeg development discussions and patches"
> Sent: Tuesday, May 15, 2018 4:46:02 PM
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets
> with top/bottom field
> On 15 May 2018 at 18:03, wm4 wrote:
>
>> On Tue, 15 May 2018 17:15:05 +0100
>> Rostislav Pehlivanov wrote:
>>
>> > On 15 May 2018 at 15:55, wm4 wrote:
>> >
>> > > On Mon, 14 May 2018 18:26:35 -0400
>> > > Patrick Keroulas wrote:
>> > >
>> > > > Signed-off-by: Patrick Keroulas > savoirfairelinux.com>
>> > > > ---
>> > > > doc/APIchanges | 3 +++
>> > > > libavcodec/avcodec.h | 8
>> > > > libavcodec/version.h | 4 ++--
>> > > > 3 files changed, 13 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/doc/APIchanges b/doc/APIchanges
>> > > > index bbefc83..d06868e 100644
>> > > > --- a/doc/APIchanges
>> > > > +++ b/doc/APIchanges
>> > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>> > > >
>> > > > API changes, most recent first:
>> > > >
>> > > > +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
>> > > > + Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
>> > > > +
>> > > > 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
>> > > > Add AVCUDADeviceContext.stream.
>> > > >
>> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> > > > index fb0c6fa..14811be 100644
>> > > > --- a/libavcodec/avcodec.h
>> > > > +++ b/libavcodec/avcodec.h
>> > > > @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
>> > > > */
>> > > > #define AV_PKT_FLAG_DISPOSABLE 0x0010
>> > > >
>> > > > +/**
>> > > > + * The packet contains a top field.
>> > > > + */
>> > > > +#define AV_PKT_FLAG_TOP_FIELD 0x0020
>> > > > +/**
>> > > > + * The packet contains a bottom field.
>> > > > + */
>> > > > +#define AV_PKT_FLAG_BOTTOM_FIELD 0x0040
>> > > >
>> > > > enum AVSideDataParamChangeFlags {
>> > > > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
>> > > > diff --git a/libavcodec/version.h b/libavcodec/version.h
>> > > > index 3fda743..b9752ce 100644
>> > > > --- a/libavcodec/version.h
>> > > > +++ b/libavcodec/version.h
>> > > > @@ -28,8 +28,8 @@
>> > > > #include "libavutil/version.h"
>> > > >
>> > > > #define LIBAVCODEC_VERSION_MAJOR 58
>> > > > -#define LIBAVCODEC_VERSION_MINOR 19
>> > > > -#define LIBAVCODEC_VERSION_MICRO 101
>> > > > +#define LIBAVCODEC_VERSION_MINOR 20
>> > > > +#define LIBAVCODEC_VERSION_MICRO 100
>> > > >
>> > > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR,
>>
>> > > \
>> > > >
>> > > LIBAVCODEC_VERSION_MINOR, \
>> > >
>> > > So far we could avoid codec-specific packet flags, and I think it
>> > > should stay this way. Maybe make it side data, something with naming
>> > > specific to the bitpacked codec. Or alternatively, if this codec
>> > > is 100% RTP specific and there's no such thing as standard bitpacked
>> > > packets (e.g. muxed in other files etc.), add it to the packet
>> > > directly. The RTP code "repacks" it already on the libavformat side
>> > > anyway.
>> > > ___
>> > > ffmpeg-devel mailing list
>> > > ffmpeg-devel@ffmpeg.org
>> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > >
>> >
>> > This codec isn't RTP specific, its the same as V210. There are no flags
>> in
>> > the bitstream, its just a sequence of packed pixels. And just like v210
>> > there's a standard for what packets need to look like (rfc4175, and
>> > unfortunately it does specify the fields need to be separate), so
>> packing 2
>> > fields in the muxer isn't really an option.
>>
>> Then why are there separate bitpacked and v210 decoders/codec_ids?
>>
>
> Its a different type of packing.
>
>
>
>> > Side data seems a bit of an overkill for a flag. I'd say the field flags
>> > are not codec specific as some raw codecs and containers can signal
>> fields
>> > per packet. So I don't really mind them.
>>
>> You want codec specific flags to accumulate in AVPacket.flags? Can't way
>> until we change the flags field to int128_t.
>>
>>
> No, but I think 2 more bits won't hurt much, especially considering pretty
> much all formats supporting interlaced content split each field into a
> separate packet.
Recomposing a frame from fields on the demux side would make the bitpacked
decoder
completely useless. Can we find a consensus? How about reusing
AVPictureStructure
as suggested by Derek?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option
On Fri, May 18, 2018 at 10:43 AM, Aman Gupta wrote: > > > On Fri, May 18, 2018 at 10:28 AM, Devin Heitmueller < > dheitmuel...@kernellabs.com> wrote: > >> > The issue is that the PMT PID advertised in the PAT contains multiple >> PMTs >> > for different programs. This is because the broadcaster decided to >> re-use >> > the same PID for multiple program PMTs. >> >> Ugh, ok. I understand the case you're talking about now. Thanks for >> clarifying. >> >> > To be clear, this issue is specific to _filtered_ mpegts streams. In >> this >> > case, my tuner hardware is trying to filter the mpegts stream from the >> > broadcaster to include only the program I care about. >> >> This is actually what I assumed, but I thought you were referring to >> the broken behavior found in some of the LinuxTV command line tools >> which allow you to save the TS but they don't include the PAT in the >> list of filtered PIDs. >> >> Now that I understand what you're trying to do, the approach you've >> proposed makes sense. I withdrawal any objections. >> > > Thanks. > > I'll try to expand the commit message to make it more clear before > committing. > Updated commit message and applied as-is (off by default). Aman > > FYI, the way ffmpeg deals with missing PAT/PMT is by automatically > creating streams for any PIDs that appear containing PES streams. > > In this case, those extra pids are not in the file, so the streams were > only getting created because of the erroneous PMTs being seen. > > Aman > > >> >> Devin >> >> -- >> Devin J. Heitmueller - Kernel Labs >> http://www.kernellabs.com >> > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Properly expose intercepted ID3 tags to the API.
On Fri, 18 May 2018 11:54:52 -0700
Richard Shaffer wrote:
> On Fri, May 18, 2018 at 2:54 AM, wm4 wrote:
>
> > On Thu, 17 May 2018 20:49:42 -0700
> > rshaf...@tunein.com wrote:
> >
> > > From: Richard Shaffer
> > >
> > > The HLS demuxer will process any ID3 tags at the beginning of a segment
> > in
> > > order to obtain timestamp data. However, when this data was parsed on a
> > second
> > > or subsequent segment, the updated metadata would be discarded. This
> > change
> > > preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_
> > UPDATED
> > > event flag when appropriate.
> > > ---
> > > libavformat/hls.c | 34 +++---
> > > 1 file changed, 19 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > index 3d4f7f2647..3e2edb3484 100644
> > > --- a/libavformat/hls.c
> > > +++ b/libavformat/hls.c
> > > @@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s,
> > AVIOContext *pb,
> > > }
> > >
> > > /* Check if the ID3 metadata contents have changed */
> > > -static int id3_has_changed_values(struct playlist *pls, AVDictionary
> > *metadata,
> > > - ID3v2ExtraMetaAPIC *apic)
> > > +static int id3_has_changed_values(struct playlist *pls,
> > ID3v2ExtraMetaAPIC *apic)
> > > {
> > > -AVDictionaryEntry *entry = NULL;
> > > -AVDictionaryEntry *oldentry;
> > > -/* check that no keys have changed values */
> > > -while ((entry = av_dict_get(metadata, "", entry,
> > AV_DICT_IGNORE_SUFFIX))) {
> > > -oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
> > AV_DICT_MATCH_CASE);
> > > -if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
> > > -return 1;
> > > -}
> > > -
> > > /* check if apic appeared */
> > > if (apic && (pls->ctx->nb_streams != 2 || !pls->ctx->streams[1]->
> > attached_pic.data))
> > > return 1;
> > > @@ -1019,6 +1009,15 @@ static void handle_id3(AVIOContext *pb, struct
> > playlist *pls)
> > > int64_t timestamp = AV_NOPTS_VALUE;
> > >
> > > parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
> > > +ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> > > +av_dict_copy(&pls->ctx->metadata, metadata, 0);
> > > +/*
> > > + * If we've handled any ID3 metadata here, it's not going to be
> > seen by the
> > > + * sub-demuxer. In the case that we got here because of an IO call
> > during
> > > + * hls_read_header, this will be cleared. Otherwise, it provides the
> > > + * necessary hint to hls_read_packet that there is new metadata.
> > > + */
> > > +pls->ctx->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
> >
> > Can't ID3 tags happen in large quantities with that ID3 timestamp hack
> > (curse whoever invented it)? Wouldn't that lead to a large number of
> > redundant events? Not sure though, I don't have the overview.
> >
>
> Yes, that's a good point. If timestamps are in ID3 tags, they'll be at the
> start of every segment. I can think of several ways to handle that:
>
> Option 1: Technically it is updated metadata, so mark it as updated. Leave
> it up to the API caller to figure out whether they care about it or not.
>
> Option 2: Filter out timestamp ID3 frames, and only mark it as updated if
> some other ID3 tag or frame is present.
>
> Option 3: Compare the new metadata with the last seen metadata, and only
> set the event flag if something besides the timestamp has actually changed.
> That would filter out false updates for the API consumer, but I'm pretty
> sure nothing else that handles metadata updates works this way.
>
> Any thoughts? Personally I'd lean towards 1 or 2.
2 sounds good.
>
> >
> > >
> > > if (timestamp != AV_NOPTS_VALUE) {
> > > pls->id3_mpegts_timestamp = timestamp;
> > > @@ -1037,12 +1036,10 @@ static void handle_id3(AVIOContext *pb, struct
> > playlist *pls)
> > > /* demuxer not yet opened, defer picture attachment */
> > > pls->id3_deferred_extra = extra_meta;
> > >
> > > -ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> > > -av_dict_copy(&pls->ctx->metadata, metadata, 0);
> > > pls->id3_initial = metadata;
> > >
> > > } else {
> > > -if (!pls->id3_changed && id3_has_changed_values(pls, metadata,
> > apic)) {
> > > +if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
> > > avpriv_report_missing_feature(pls->ctx, "Changing ID3
> > metadata in HLS audio elementary stream");
> > > pls->id3_changed = 1;
> > > }
> > > @@ -1939,8 +1936,15 @@ static int hls_read_header(AVFormatContext *s)
> > > * Copy any metadata from playlist to main streams, but do not
> > set
> > > * event flags.
> > > */
> > > -if (pls->n_main_streams)
> > > +if (pls->n_main_streams) {
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On 18 May 2018 at 20:05, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:
>
> - Original Message -
> > From: "Rostislav Pehlivanov"
> > To: "FFmpeg development discussions and patches" <
> ffmpeg-devel@ffmpeg.org>
> > Sent: Tuesday, May 15, 2018 4:46:02 PM
> > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> packets with top/bottom field
>
> > On 15 May 2018 at 18:03, wm4 wrote:
> >
> >> On Tue, 15 May 2018 17:15:05 +0100
> >> Rostislav Pehlivanov wrote:
> >>
> >> > On 15 May 2018 at 15:55, wm4 wrote:
> >> >
> >> > > On Mon, 14 May 2018 18:26:35 -0400
> >> > > Patrick Keroulas wrote:
> >> > >
> >> > > > Signed-off-by: Patrick Keroulas >> savoirfairelinux.com>
> >> > > > ---
> >> > > > doc/APIchanges | 3 +++
> >> > > > libavcodec/avcodec.h | 8
> >> > > > libavcodec/version.h | 4 ++--
> >> > > > 3 files changed, 13 insertions(+), 2 deletions(-)
> >> > > >
> >> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> >> > > > index bbefc83..d06868e 100644
> >> > > > --- a/doc/APIchanges
> >> > > > +++ b/doc/APIchanges
> >> > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >> > > >
> >> > > > API changes, most recent first:
> >> > > >
> >> > > > +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
> >> > > > + Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
> >> > > > +
> >> > > > 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
> >> > > > Add AVCUDADeviceContext.stream.
> >> > > >
> >> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> > > > index fb0c6fa..14811be 100644
> >> > > > --- a/libavcodec/avcodec.h
> >> > > > +++ b/libavcodec/avcodec.h
> >> > > > @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
> >> > > > */
> >> > > > #define AV_PKT_FLAG_DISPOSABLE 0x0010
> >> > > >
> >> > > > +/**
> >> > > > + * The packet contains a top field.
> >> > > > + */
> >> > > > +#define AV_PKT_FLAG_TOP_FIELD 0x0020
> >> > > > +/**
> >> > > > + * The packet contains a bottom field.
> >> > > > + */
> >> > > > +#define AV_PKT_FLAG_BOTTOM_FIELD 0x0040
> >> > > >
> >> > > > enum AVSideDataParamChangeFlags {
> >> > > > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> >> > > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> >> > > > index 3fda743..b9752ce 100644
> >> > > > --- a/libavcodec/version.h
> >> > > > +++ b/libavcodec/version.h
> >> > > > @@ -28,8 +28,8 @@
> >> > > > #include "libavutil/version.h"
> >> > > >
> >> > > > #define LIBAVCODEC_VERSION_MAJOR 58
> >> > > > -#define LIBAVCODEC_VERSION_MINOR 19
> >> > > > -#define LIBAVCODEC_VERSION_MICRO 101
> >> > > > +#define LIBAVCODEC_VERSION_MINOR 20
> >> > > > +#define LIBAVCODEC_VERSION_MICRO 100
> >> > > >
> >> > > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_
> VERSION_MAJOR,
> >>
> >> > > \
> >> > > >
> >> > > LIBAVCODEC_VERSION_MINOR, \
> >> > >
> >> > > So far we could avoid codec-specific packet flags, and I think it
> >> > > should stay this way. Maybe make it side data, something with naming
> >> > > specific to the bitpacked codec. Or alternatively, if this codec
> >> > > is 100% RTP specific and there's no such thing as standard bitpacked
> >> > > packets (e.g. muxed in other files etc.), add it to the packet
> >> > > directly. The RTP code "repacks" it already on the libavformat side
> >> > > anyway.
> >> > > ___
> >> > > ffmpeg-devel mailing list
> >> > > ffmpeg-devel@ffmpeg.org
> >> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> > >
> >> >
> >> > This codec isn't RTP specific, its the same as V210. There are no
> flags
> >> in
> >> > the bitstream, its just a sequence of packed pixels. And just like
> v210
> >> > there's a standard for what packets need to look like (rfc4175, and
> >> > unfortunately it does specify the fields need to be separate), so
> >> packing 2
> >> > fields in the muxer isn't really an option.
> >>
> >> Then why are there separate bitpacked and v210 decoders/codec_ids?
> >>
> >
> > Its a different type of packing.
> >
> >
> >
> >> > Side data seems a bit of an overkill for a flag. I'd say the field
> flags
> >> > are not codec specific as some raw codecs and containers can signal
> >> fields
> >> > per packet. So I don't really mind them.
> >>
> >> You want codec specific flags to accumulate in AVPacket.flags? Can't way
> >> until we change the flags field to int128_t.
> >>
> >>
> > No, but I think 2 more bits won't hurt much, especially considering
> pretty
> > much all formats supporting interlaced content split each field into a
> > separate packet.
>
> Recomposing a frame from fields on the demux side would make the bitpacked
> decoder
> completely useless. Can we find a consensus? How about reusing
> AVPictureStructure
> as suggested by Derek?
>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On Fri, 18 May 2018 20:09:02 +0100
Rostislav Pehlivanov wrote:
> On 18 May 2018 at 20:05, Patrick Keroulas <
> patrick.kerou...@savoirfairelinux.com> wrote:
>
> >
> > - Original Message -
> > > From: "Rostislav Pehlivanov"
> > > To: "FFmpeg development discussions and patches" <
> > ffmpeg-devel@ffmpeg.org>
> > > Sent: Tuesday, May 15, 2018 4:46:02 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > packets with top/bottom field
> >
> > > On 15 May 2018 at 18:03, wm4 wrote:
> > >
> > >> On Tue, 15 May 2018 17:15:05 +0100
> > >> Rostislav Pehlivanov wrote:
> > >>
> > >> > On 15 May 2018 at 15:55, wm4 wrote:
> > >> >
> > >> > > On Mon, 14 May 2018 18:26:35 -0400
> > >> > > Patrick Keroulas wrote:
> > >> > >
> > >> > > > Signed-off-by: Patrick Keroulas > >> savoirfairelinux.com>
> > >> > > > ---
> > >> > > > doc/APIchanges | 3 +++
> > >> > > > libavcodec/avcodec.h | 8
> > >> > > > libavcodec/version.h | 4 ++--
> > >> > > > 3 files changed, 13 insertions(+), 2 deletions(-)
> > >> > > >
> > >> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> > >> > > > index bbefc83..d06868e 100644
> > >> > > > --- a/doc/APIchanges
> > >> > > > +++ b/doc/APIchanges
> > >> > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> > >> > > >
> > >> > > > API changes, most recent first:
> > >> > > >
> > >> > > > +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
> > >> > > > + Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
> > >> > > > +
> > >> > > > 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
> > >> > > > Add AVCUDADeviceContext.stream.
> > >> > > >
> > >> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > >> > > > index fb0c6fa..14811be 100644
> > >> > > > --- a/libavcodec/avcodec.h
> > >> > > > +++ b/libavcodec/avcodec.h
> > >> > > > @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
> > >> > > > */
> > >> > > > #define AV_PKT_FLAG_DISPOSABLE 0x0010
> > >> > > >
> > >> > > > +/**
> > >> > > > + * The packet contains a top field.
> > >> > > > + */
> > >> > > > +#define AV_PKT_FLAG_TOP_FIELD 0x0020
> > >> > > > +/**
> > >> > > > + * The packet contains a bottom field.
> > >> > > > + */
> > >> > > > +#define AV_PKT_FLAG_BOTTOM_FIELD 0x0040
> > >> > > >
> > >> > > > enum AVSideDataParamChangeFlags {
> > >> > > > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> > >> > > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > >> > > > index 3fda743..b9752ce 100644
> > >> > > > --- a/libavcodec/version.h
> > >> > > > +++ b/libavcodec/version.h
> > >> > > > @@ -28,8 +28,8 @@
> > >> > > > #include "libavutil/version.h"
> > >> > > >
> > >> > > > #define LIBAVCODEC_VERSION_MAJOR 58
> > >> > > > -#define LIBAVCODEC_VERSION_MINOR 19
> > >> > > > -#define LIBAVCODEC_VERSION_MICRO 101
> > >> > > > +#define LIBAVCODEC_VERSION_MINOR 20
> > >> > > > +#define LIBAVCODEC_VERSION_MICRO 100
> > >> > > >
> > >> > > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_
> > VERSION_MAJOR,
> > >>
> > >> > > \
> > >> > > >
> > >> > > LIBAVCODEC_VERSION_MINOR, \
> > >> > >
> > >> > > So far we could avoid codec-specific packet flags, and I think it
> > >> > > should stay this way. Maybe make it side data, something with naming
> > >> > > specific to the bitpacked codec. Or alternatively, if this codec
> > >> > > is 100% RTP specific and there's no such thing as standard bitpacked
> > >> > > packets (e.g. muxed in other files etc.), add it to the packet
> > >> > > directly. The RTP code "repacks" it already on the libavformat side
> > >> > > anyway.
> > >> > > ___
> > >> > > ffmpeg-devel mailing list
> > >> > > ffmpeg-devel@ffmpeg.org
> > >> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >> > >
> > >> >
> > >> > This codec isn't RTP specific, its the same as V210. There are no
> > flags
> > >> in
> > >> > the bitstream, its just a sequence of packed pixels. And just like
> > v210
> > >> > there's a standard for what packets need to look like (rfc4175, and
> > >> > unfortunately it does specify the fields need to be separate), so
> > >> packing 2
> > >> > fields in the muxer isn't really an option.
> > >>
> > >> Then why are there separate bitpacked and v210 decoders/codec_ids?
> > >>
> > >
> > > Its a different type of packing.
> > >
> > >
> > >
> > >> > Side data seems a bit of an overkill for a flag. I'd say the field
> > flags
> > >> > are not codec specific as some raw codecs and containers can signal
> > >> fields
> > >> > per packet. So I don't really mind them.
> > >>
> > >> You want codec specific flags to accumulate in AVPacket.flags? Can't way
> > >> until we change the flags field to int128_t.
> > >>
> > >>
> > > No, but I think 2 more bits won't hurt much, especially considering
> > pretty
> > > much all formats supporting interlaced content split each field into a
> > > separate packet.
> >
> > Recomposing a frame fro
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On 18 May 2018 at 21:03, wm4 wrote:
> On Fri, 18 May 2018 20:09:02 +0100
> Rostislav Pehlivanov wrote:
>
> > On 18 May 2018 at 20:05, Patrick Keroulas <
> > patrick.kerou...@savoirfairelinux.com> wrote:
> >
> > >
> > > - Original Message -
> > > > From: "Rostislav Pehlivanov"
> > > > To: "FFmpeg development discussions and patches" <
> > > ffmpeg-devel@ffmpeg.org>
> > > > Sent: Tuesday, May 15, 2018 4:46:02 PM
> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > > packets with top/bottom field
> > >
> > > > On 15 May 2018 at 18:03, wm4 wrote:
> > > >
> > > >> On Tue, 15 May 2018 17:15:05 +0100
> > > >> Rostislav Pehlivanov wrote:
> > > >>
> > > >> > On 15 May 2018 at 15:55, wm4 wrote:
> > > >> >
> > > >> > > On Mon, 14 May 2018 18:26:35 -0400
> > > >> > > Patrick Keroulas wrote:
> > > >> > >
> > > >> > > > Signed-off-by: Patrick Keroulas > > >> savoirfairelinux.com>
> > > >> > > > ---
> > > >> > > > doc/APIchanges | 3 +++
> > > >> > > > libavcodec/avcodec.h | 8
> > > >> > > > libavcodec/version.h | 4 ++--
> > > >> > > > 3 files changed, 13 insertions(+), 2 deletions(-)
> > > >> > > >
> > > >> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> > > >> > > > index bbefc83..d06868e 100644
> > > >> > > > --- a/doc/APIchanges
> > > >> > > > +++ b/doc/APIchanges
> > > >> > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> > > >> > > >
> > > >> > > > API changes, most recent first:
> > > >> > > >
> > > >> > > > +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
> > > >> > > > + Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
> > > >> > > > +
> > > >> > > > 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
> > > >> > > > Add AVCUDADeviceContext.stream.
> > > >> > > >
> > > >> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > >> > > > index fb0c6fa..14811be 100644
> > > >> > > > --- a/libavcodec/avcodec.h
> > > >> > > > +++ b/libavcodec/avcodec.h
> > > >> > > > @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
> > > >> > > > */
> > > >> > > > #define AV_PKT_FLAG_DISPOSABLE 0x0010
> > > >> > > >
> > > >> > > > +/**
> > > >> > > > + * The packet contains a top field.
> > > >> > > > + */
> > > >> > > > +#define AV_PKT_FLAG_TOP_FIELD 0x0020
> > > >> > > > +/**
> > > >> > > > + * The packet contains a bottom field.
> > > >> > > > + */
> > > >> > > > +#define AV_PKT_FLAG_BOTTOM_FIELD 0x0040
> > > >> > > >
> > > >> > > > enum AVSideDataParamChangeFlags {
> > > >> > > > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> > > >> > > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > > >> > > > index 3fda743..b9752ce 100644
> > > >> > > > --- a/libavcodec/version.h
> > > >> > > > +++ b/libavcodec/version.h
> > > >> > > > @@ -28,8 +28,8 @@
> > > >> > > > #include "libavutil/version.h"
> > > >> > > >
> > > >> > > > #define LIBAVCODEC_VERSION_MAJOR 58
> > > >> > > > -#define LIBAVCODEC_VERSION_MINOR 19
> > > >> > > > -#define LIBAVCODEC_VERSION_MICRO 101
> > > >> > > > +#define LIBAVCODEC_VERSION_MINOR 20
> > > >> > > > +#define LIBAVCODEC_VERSION_MICRO 100
> > > >> > > >
> > > >> > > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_
> > > VERSION_MAJOR,
> > > >>
> > > >> > > \
> > > >> > > >
> > > >> > > LIBAVCODEC_VERSION_MINOR, \
> > > >> > >
> > > >> > > So far we could avoid codec-specific packet flags, and I think
> it
> > > >> > > should stay this way. Maybe make it side data, something with
> naming
> > > >> > > specific to the bitpacked codec. Or alternatively, if this codec
> > > >> > > is 100% RTP specific and there's no such thing as standard
> bitpacked
> > > >> > > packets (e.g. muxed in other files etc.), add it to the packet
> > > >> > > directly. The RTP code "repacks" it already on the libavformat
> side
> > > >> > > anyway.
> > > >> > > ___
> > > >> > > ffmpeg-devel mailing list
> > > >> > > ffmpeg-devel@ffmpeg.org
> > > >> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >> > >
> > > >> >
> > > >> > This codec isn't RTP specific, its the same as V210. There are
> no
> > > flags
> > > >> in
> > > >> > the bitstream, its just a sequence of packed pixels. And just
> like
> > > v210
> > > >> > there's a standard for what packets need to look like (rfc4175,
> and
> > > >> > unfortunately it does specify the fields need to be separate),
> so
> > > >> packing 2
> > > >> > fields in the muxer isn't really an option.
> > > >>
> > > >> Then why are there separate bitpacked and v210 decoders/codec_ids?
> > > >>
> > > >
> > > > Its a different type of packing.
> > > >
> > > >
> > > >
> > > >> > Side data seems a bit of an overkill for a flag. I'd say the
> field
> > > flags
> > > >> > are not codec specific as some raw codecs and containers can
> signal
> > > >> fields
> > > >> > per packet. So I don't really mind them.
> > > >>
> > > >> You want codec specific flags to accumulate in AVPacket.flags?
> Can't way
> > > >> until we change the flags field to int128
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On Fri, 18 May 2018 21:59:13 +0100
Rostislav Pehlivanov wrote:
> On 18 May 2018 at 21:03, wm4 wrote:
>
> > On Fri, 18 May 2018 20:09:02 +0100
> > Rostislav Pehlivanov wrote:
> >
> > > On 18 May 2018 at 20:05, Patrick Keroulas <
> > > patrick.kerou...@savoirfairelinux.com> wrote:
> > >
> > > >
> > > > - Original Message -
> > > > > From: "Rostislav Pehlivanov"
> > > > > To: "FFmpeg development discussions and patches" <
> > > > ffmpeg-devel@ffmpeg.org>
> > > > > Sent: Tuesday, May 15, 2018 4:46:02 PM
> > > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > > > packets with top/bottom field
> > > >
> > > > > On 15 May 2018 at 18:03, wm4 wrote:
> > > > >
> > > > >> On Tue, 15 May 2018 17:15:05 +0100
> > > > >> Rostislav Pehlivanov wrote:
> > > > >>
> > > > >> > On 15 May 2018 at 15:55, wm4 wrote:
> > > > >> >
> > > > >> > > On Mon, 14 May 2018 18:26:35 -0400
> > > > >> > > Patrick Keroulas wrote:
> > > > >> > >
> > > > >> > > > Signed-off-by: Patrick Keroulas > > > >> savoirfairelinux.com>
> > > > >> > > > ---
> > > > >> > > > doc/APIchanges | 3 +++
> > > > >> > > > libavcodec/avcodec.h | 8
> > > > >> > > > libavcodec/version.h | 4 ++--
> > > > >> > > > 3 files changed, 13 insertions(+), 2 deletions(-)
> > > > >> > > >
> > > > >> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> > > > >> > > > index bbefc83..d06868e 100644
> > > > >> > > > --- a/doc/APIchanges
> > > > >> > > > +++ b/doc/APIchanges
> > > > >> > > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> > > > >> > > >
> > > > >> > > > API changes, most recent first:
> > > > >> > > >
> > > > >> > > > +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
> > > > >> > > > + Add AV_PKT_FLAG_TOP_FIELD and AV_PKT_FLAG_BOTTOM_FIELD.
> > > > >> > > > +
> > > > >> > > > 2018-05-xx - xx - lavu 56.18.101 - hwcontext_cuda.h
> > > > >> > > > Add AVCUDADeviceContext.stream.
> > > > >> > > >
> > > > >> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > > >> > > > index fb0c6fa..14811be 100644
> > > > >> > > > --- a/libavcodec/avcodec.h
> > > > >> > > > +++ b/libavcodec/avcodec.h
> > > > >> > > > @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
> > > > >> > > > */
> > > > >> > > > #define AV_PKT_FLAG_DISPOSABLE 0x0010
> > > > >> > > >
> > > > >> > > > +/**
> > > > >> > > > + * The packet contains a top field.
> > > > >> > > > + */
> > > > >> > > > +#define AV_PKT_FLAG_TOP_FIELD 0x0020
> > > > >> > > > +/**
> > > > >> > > > + * The packet contains a bottom field.
> > > > >> > > > + */
> > > > >> > > > +#define AV_PKT_FLAG_BOTTOM_FIELD 0x0040
> > > > >> > > >
> > > > >> > > > enum AVSideDataParamChangeFlags {
> > > > >> > > > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> > > > >> > > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > > > >> > > > index 3fda743..b9752ce 100644
> > > > >> > > > --- a/libavcodec/version.h
> > > > >> > > > +++ b/libavcodec/version.h
> > > > >> > > > @@ -28,8 +28,8 @@
> > > > >> > > > #include "libavutil/version.h"
> > > > >> > > >
> > > > >> > > > #define LIBAVCODEC_VERSION_MAJOR 58
> > > > >> > > > -#define LIBAVCODEC_VERSION_MINOR 19
> > > > >> > > > -#define LIBAVCODEC_VERSION_MICRO 101
> > > > >> > > > +#define LIBAVCODEC_VERSION_MINOR 20
> > > > >> > > > +#define LIBAVCODEC_VERSION_MICRO 100
> > > > >> > > >
> > > > >> > > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_
> > > > VERSION_MAJOR,
> > > > >>
> > > > >> > > \
> > > > >> > > >
> > > > >> > > LIBAVCODEC_VERSION_MINOR, \
> > > > >> > >
> > > > >> > > So far we could avoid codec-specific packet flags, and I think
> > it
> > > > >> > > should stay this way. Maybe make it side data, something with
> > naming
> > > > >> > > specific to the bitpacked codec. Or alternatively, if this codec
> > > > >> > > is 100% RTP specific and there's no such thing as standard
> > bitpacked
> > > > >> > > packets (e.g. muxed in other files etc.), add it to the packet
> > > > >> > > directly. The RTP code "repacks" it already on the libavformat
> > side
> > > > >> > > anyway.
> > > > >> > > ___
> > > > >> > > ffmpeg-devel mailing list
> > > > >> > > ffmpeg-devel@ffmpeg.org
> > > > >> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >> > >
> > > > >> >
> > > > >> > This codec isn't RTP specific, its the same as V210. There are
> > no
> > > > flags
> > > > >> in
> > > > >> > the bitstream, its just a sequence of packed pixels. And just
> > like
> > > > v210
> > > > >> > there's a standard for what packets need to look like (rfc4175,
> > and
> > > > >> > unfortunately it does specify the fields need to be separate),
> > so
> > > > >> packing 2
> > > > >> > fields in the muxer isn't really an option.
> > > > >>
> > > > >> Then why are there separate bitpacked and v210 decoders/codec_ids?
> > > > >>
> > > > >
> > > > > Its a different type of packing.
> > > > >
> >
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On 18 May 2018 at 22:17, wm4 wrote: > > > But I think a new side data type would be much saner. We could even > just make it something generic, like AV_PKT_DATA_ANCILLARY or > something. It's apparently just packet data which somehow couldn't go > into the packet data. > I agree, a generic ancillary side data type sounds better. It would have to be handled the same way as mastering metadata (e.g. to allocate it you'd need to use a separate function), since the size of the data struct can't be part of the API if we intend to add fields later. Patrick, if you're okay with that you should submit a patch which bases such side data on libavutil/mastering_display_metadata.h/.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field
On Fri, May 18, 2018 at 11:17 PM, wm4 wrote: > > Other flags are also generic. For a long time, AV_PKT_FLAG_KEY was the > only flag. It applies to every codec, and is in theory not necessary > for decoding (although some decoders might read it anyway, but that's > a separate story). > > If we add flags about fields now, this will cause only confusion, > because: > > [...] > 2. They're suddenly needed for correct decoding. > That would be my main concern. I abstract the connection between demuxer and decoder, and there is no field to transmit such mandatory flags right now, while I do handle side-data. So basically, this new flag would add additional work for everyone doing something similar, while using side-data would likely "just work". - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avformat/hls: Properly expose intercepted ID3 tags to the API.
From: Richard Shaffer
The HLS demuxer will process any ID3 tags at the beginning of a segment in
order to obtain timestamp data. However, when this data was parsed on a second
or subsequent segment, the updated metadata would be discarded. This change
preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_UPDATED
event flag when appropriate.
---
Changes in this version:
* Only set metadata updated flag if we have non-timestamp metadata.
* Fix clearing of metadata updated flag in hls_read_header.
* Specifically cast operands to unsigned when using bitwise operators.
(This last one is almost certainly pedantic, but it doesn't hurt anything.)
libavformat/hls.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3d4f7f2647..342a022975 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
}
/* Check if the ID3 metadata contents have changed */
-static int id3_has_changed_values(struct playlist *pls, AVDictionary *metadata,
- ID3v2ExtraMetaAPIC *apic)
+static int id3_has_changed_values(struct playlist *pls, ID3v2ExtraMetaAPIC
*apic)
{
-AVDictionaryEntry *entry = NULL;
-AVDictionaryEntry *oldentry;
-/* check that no keys have changed values */
-while ((entry = av_dict_get(metadata, "", entry, AV_DICT_IGNORE_SUFFIX))) {
-oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
AV_DICT_MATCH_CASE);
-if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
-return 1;
-}
-
/* check if apic appeared */
if (apic && (pls->ctx->nb_streams != 2 ||
!pls->ctx->streams[1]->attached_pic.data))
return 1;
@@ -1019,6 +1009,19 @@ static void handle_id3(AVIOContext *pb, struct playlist
*pls)
int64_t timestamp = AV_NOPTS_VALUE;
parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
+ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
+av_dict_copy(&pls->ctx->metadata, metadata, 0);
+/*
+ * If we've handled any ID3 metadata here, it's not going to be seen by the
+ * sub-demuxer. In the case that we got here because of an IO call during
+ * hls_read_header, this will be cleared. Otherwise, it provides the
+ * necessary hint to hls_read_packet that there is new metadata. Note that
+ * we only set the update flag if we have metadata other than a timestamp.
+ */
+if (av_dict_count(metadata) > (timestamp == AV_NOPTS_VALUE ? 0 : 1)) {
+pls->ctx->event_flags = (unsigned)pls->ctx->event_flags |
+(unsigned)AVFMT_EVENT_FLAG_METADATA_UPDATED;
+}
if (timestamp != AV_NOPTS_VALUE) {
pls->id3_mpegts_timestamp = timestamp;
@@ -1037,12 +1040,10 @@ static void handle_id3(AVIOContext *pb, struct playlist
*pls)
/* demuxer not yet opened, defer picture attachment */
pls->id3_deferred_extra = extra_meta;
-ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
-av_dict_copy(&pls->ctx->metadata, metadata, 0);
pls->id3_initial = metadata;
} else {
-if (!pls->id3_changed && id3_has_changed_values(pls, metadata, apic)) {
+if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
avpriv_report_missing_feature(pls->ctx, "Changing ID3 metadata in
HLS audio elementary stream");
pls->id3_changed = 1;
}
@@ -1939,8 +1940,16 @@ static int hls_read_header(AVFormatContext *s)
* Copy any metadata from playlist to main streams, but do not set
* event flags.
*/
-if (pls->n_main_streams)
+if (pls->n_main_streams) {
av_dict_copy(&pls->main_streams[0]->metadata, pls->ctx->metadata,
0);
+/*
+ * If we've intercepted metadata, we will have set this event flag.
+ * Clear it to avoid confusion, since otherwise we will flag it as
+ * new metadata on the next call to hls_read_packet.
+ */
+pls->ctx->event_flags = (unsigned)pls->ctx->event_flags &
+~(unsigned)AVFMT_EVENT_FLAG_METADATA_UPDATED;
+}
add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
--
2.15.1 (Apple Git-101)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_parser: create nalus without trailing bits
From: Aman Gupta Fixes "unknown SEI type 128" debug messages from the parser on https://tmm1.s3.amazonaws.com/vts.mpg Signed-off-by: Aman Gupta --- libavcodec/h264_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c index 1a9840a62c..a546239370 100644 --- a/libavcodec/h264_parser.c +++ b/libavcodec/h264_parser.c @@ -311,7 +311,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, buf_index += consumed; -ret = init_get_bits8(&nal.gb, nal.data, nal.size); +ret = init_get_bits(&nal.gb, nal.data, nal.size_bits); if (ret < 0) goto fail; get_bits1(&nal.gb); -- 2.14.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream
- Make ffmpeg to output stats for each video streams and each ouptut file
ffmpeg output log in print_report.
- The report of video/audio sizes is clear as previously all output
video/audio sizes were combined to report and it is unclear such stats
is for one output files or aggregates for all output files.
Signed-off-by: Wang Cao
---
fftools/ffmpeg.c | 182 ++-
1 file changed, 101 insertions(+), 81 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..4aa6c1d3e4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1526,17 +1526,28 @@ static int reap_filters(int flush)
return 0;
}
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
{
uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
uint64_t subtitle_size = 0;
uint64_t data_size = 0;
+int64_t total_size;
float percent = -1.0;
int i, j;
int pass1_used = 1;
+AVFormatContext *oc;
for (i = 0; i < nb_output_streams; i++) {
OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
+
switch (ost->enc_ctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1545,25 +1556,37 @@ static void print_final_stats(int64_t total_size)
}
extra_size += ost->enc_ctx->extradata_size;
data_size += ost->data_size;
-if ( (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 |
AV_CODEC_FLAG_PASS2))
+
+if ((ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 | AV_CODEC_FLAG_PASS2))
!= AV_CODEC_FLAG_PASS1)
pass1_used = 0;
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index !=
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx;
+total_size = avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with
non seekable output too
+total_size = avio_tell(oc->pb);
+
+if (data_size && total_size>0 && total_size >= data_size)
+percent = 100.0 * (total_size - data_size) / data_size;
+
+av_log(NULL, AV_LOG_INFO, "video:%1.0fkB audio:%1.0fkB
subtitle:%1.0fkB other streams:%1.0fkB global headers:%1.0fkB muxing overhead:
",
+ video_size / 1024.0,
+ audio_size / 1024.0,
+ subtitle_size / 1024.0,
+ other_size / 1024.0,
+ extra_size / 1024.0);
+
+if (percent >= 0.0)
+av_log(NULL, AV_LOG_INFO, "%f%%", percent);
+else
+av_log(NULL, AV_LOG_INFO, "unknown");
+av_log(NULL, AV_LOG_INFO, "\n");
+}
}
-if (data_size && total_size>0 && total_size >= data_size)
-percent = 100.0 * (total_size - data_size) / data_size;
-av_log(NULL, AV_LOG_INFO, "video:%1.0fkB audio:%1.0fkB subtitle:%1.0fkB
other streams:%1.0fkB global headers:%1.0fkB muxing overhead: ",
- video_size / 1024.0,
- audio_size / 1024.0,
- subtitle_size / 1024.0,
- other_size / 1024.0,
- extra_size / 1024.0);
-if (percent >= 0.0)
-av_log(NULL, AV_LOG_INFO, "%f%%", percent);
-else
-av_log(NULL, AV_LOG_INFO, "unknown");
-av_log(NULL, AV_LOG_INFO, "\n");
/* print verbose per-stream stats */
for (i = 0; i < nb_input_files; i++) {
@@ -1676,13 +1699,6 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
t = (cur_time-timer_start) / 100.0;
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non
seekable output too
-total_size = avio_tell(oc->pb);
-
vid = 0;
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(&buf_script, 0, 1);
@@ -1693,12 +1709,12 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
if (!ost->stream_copy)
q = ost->quality / (float) FF_QP2LAMBDA;
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(&buf, "q=%2.1f ", q);
av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
}
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO && (is_
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: create nalus without trailing bits
On Fri, May 18, 2018 at 4:50 PM, Aman Gupta wrote: > From: Aman Gupta > > Fixes "unknown SEI type 128" debug messages from the parser > on https://tmm1.s3.amazonaws.com/vts.mpg This fixed SEI parsing, but now I'm seeing other parser errors on the same input: Overread SPS by 8 bits illegal reordering_of_pic_nums_idc 5 So this is still not quite right. Aman > > > Signed-off-by: Aman Gupta > --- > libavcodec/h264_parser.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c > index 1a9840a62c..a546239370 100644 > --- a/libavcodec/h264_parser.c > +++ b/libavcodec/h264_parser.c > @@ -311,7 +311,7 @@ static inline int parse_nal_units(AVCodecParserContext > *s, > > buf_index += consumed; > > -ret = init_get_bits8(&nal.gb, nal.data, nal.size); > +ret = init_get_bits(&nal.gb, nal.data, nal.size_bits); > if (ret < 0) > goto fail; > get_bits1(&nal.gb); > -- > 2.14.2 > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: create nalus without trailing bits
On Fri, May 18, 2018 at 05:19:48PM -0700, Aman Gupta wrote: > On Fri, May 18, 2018 at 4:50 PM, Aman Gupta wrote: > > > From: Aman Gupta > > > > Fixes "unknown SEI type 128" debug messages from the parser > > on https://tmm1.s3.amazonaws.com/vts.mpg > > > This fixed SEI parsing, but now I'm seeing other parser errors on the same > input: > > Overread SPS by 8 bits > illegal reordering_of_pic_nums_idc 5 > > So this is still not quite right. yes, the patch also breaks some fate tests for example fate-h264-conformance-bamq1_jvc_c [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream
On Fri, May 18, 2018 at 04:54:25PM -0700, Wang Cao wrote: > - Make ffmpeg to output stats for each video streams and each ouptut file > ffmpeg output log in print_report. > - The report of video/audio sizes is clear as previously all output > video/audio sizes were combined to report and it is unclear such stats > is for one output files or aggregates for all output files. > > Signed-off-by: Wang Cao > --- > fftools/ffmpeg.c | 182 ++- > 1 file changed, 101 insertions(+), 81 deletions(-) This causes the report to disappear for ./ffmpeg -i ~/tickets/1660/alaw_2.aif -f null - file should be in the ticket on trac, if not, say so and ill figure out where the file is [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
