Re: [FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)
resend_headers seems to be only related to PAT/PMT stuff
Calling avformat_write_header multiple times do not seems that creepy to
me, because we are handling multiples ts chunks (so, basically, multiple
headers must be written)
Pushing the 'system_b' options to every mpegts chunks through
resend_header means that system_b implies PAT/PMT for every chunks (the
current 'resend_headers' behavior), with is not a good solution
Thanks !
On 15/05/2016 00:14, Michael Niedermayer wrote:
> On Mon, May 09, 2016 at 06:17:36PM +0200, Jack wrote:
>> Signed-off-by: jack
>> ---
>> libavformat/hlsenc.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index a9fa5d8..77712d0 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -624,6 +624,11 @@ static int hls_start(AVFormatContext *s)
>> err = avformat_write_header(vtt_oc,NULL);
>> if (err < 0)
>> return err;
>> +} else {
>> +HLSContext *hls = s->priv_data;
>> +av_dict_copy(&options, hls->format_options, 0);
>> +avformat_write_header(hls->avf, &options);
>> +av_dict_free(&options);
>
> why does resend_headers not resend the headers?
>
> calling avformat_write_header() multiple times looks odd unless theres
> something iam missing
>
> [...]
>
>
>
> ___
> 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] avcodec: Add AVClass to AVCodecParameters
On Sat, 14 May 2016 23:34:19 +0200 Michael Niedermayer wrote: > I would not call AVOption crazy nor useless It has its uses, but using AVOption as generic accessor API inconsistently on top of a "native" C API is pretty crazy. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)
On Sun, May 15, 2016 at 2:10 PM, wrote: > resend_headers seems to be only related to PAT/PMT stuff > Calling avformat_write_header multiple times do not seems that creepy to > me, because we are handling multiples ts chunks (so, basically, multiple > headers must be written) > > Pushing the 'system_b' options to every mpegts chunks through > resend_header means that system_b implies PAT/PMT for every chunks (the > current 'resend_headers' behavior), with is not a good solution > calling avformat_write_headers on every chunk without actually creating a new muxer seems like an ugly kludge and not a fix (and likely to blow up at some point). Please don't top post on this ML: - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSOC 2016] Ideas on FFV1 P frame project
Hello, I'm currently working on GSOC 2016 project for upgrading FFV1 codec with an ability to use P frames. Maybe some of you have any suggestions or recommendations. While working on qualification task I implemented a simple modification of codec to encode P frames without motion compensation, so now the base for trying several MC approaches is ready. My plan of upgrade is the next: 1) I want to try current realization of OBMC algorithm from snow*.c 2) Then try to take some ideas from HEVC 2.1) In paper "Overview of the High Efficiency Video Coding (HEVC) Standard" (can be found here http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6316136) motion compensation process is described. It includes quarter pixel interpolation technic, intra- and inter-frame predicting strategies, quadtree of frame blocks, several types of predicted units, so there is a lot of stuff to try next. 2.2) In "PARALLEL AMVP CANDIDATE LIST CONSTRUCTION FOR HEVC" ( https://www.researchgate.net/profile/Liang_Zhao57/publication/261497818_Parallel_AMVP_candidate_list_construction_for_HEVC/links/54117bd10cf264cee28b3964.pdf) can be found algorithm to make MC process faster. 2.3) Authors of "HEVC Lossless Coding and Improvements" ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352.3447&rep=rep1&type=pdf) proposed Sample-Based Angular Intra Prediction algrorithm special for lossless compression, which can be tried too. 3) Try to use filtration just like bilateral in "SEPARABLE BILATERAL FILTERING FOR FAST VIDEO PREPROCESSING" ( http://elynxsdk.free.fr/ext-docs/Bilateral/ICME2005_TPLV.pdf) as pre-processing part, it can reduce compression size due to encoding noise values only from a current frame. 4) Maybe try some non common ideas like not use motion vectors as in "Lossless Video Sequence Compression Using Adaptive Prediction" ( https://www.researchgate.net/profile/K_Sayood/publication/51386836_Lossless_Video_Sequence_Compression_Using_Adaptive_Prediction/links/5489cf110cf225bf669c7487.pdf ). I'll be appreciate for any ideas or comments how to improve proposed project. Regards, Stanislav D. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add MTAF demuxer and decoder
Hi,
patches attached.
From abc698513cbbf96b464ff5e9995d9e1e4f12 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 15 May 2016 20:35:14 +0200
Subject: [PATCH 1/2] avformat: add MTAF demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mtaf.c | 81
3 files changed, 83 insertions(+)
create mode 100644 libavformat/mtaf.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 742aff5..6684ead 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -301,6 +301,7 @@ OBJS-$(CONFIG_MPL2_DEMUXER) += mpl2dec.o subtitles.o
OBJS-$(CONFIG_MSF_DEMUXER) += msf.o
OBJS-$(CONFIG_MPSUB_DEMUXER) += mpsubdec.o subtitles.o
OBJS-$(CONFIG_MSNWC_TCP_DEMUXER) += msnwc_tcp.o
+OBJS-$(CONFIG_MTAF_DEMUXER) += mtaf.o
OBJS-$(CONFIG_MTV_DEMUXER) += mtv.o
OBJS-$(CONFIG_MUSX_DEMUXER) += musx.o
OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e6ee8d6..0a38793 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -209,6 +209,7 @@ void av_register_all(void)
REGISTER_DEMUXER (MPSUB,mpsub);
REGISTER_DEMUXER (MSF, msf);
REGISTER_DEMUXER (MSNWC_TCP,msnwc_tcp);
+REGISTER_DEMUXER (MTAF, mtaf);
REGISTER_DEMUXER (MTV, mtv);
REGISTER_DEMUXER (MUSX, musx);
REGISTER_DEMUXER (MV, mv);
diff --git a/libavformat/mtaf.c b/libavformat/mtaf.c
new file mode 100644
index 000..b25c2aa
--- /dev/null
+++ b/libavformat/mtaf.c
@@ -0,0 +1,81 @@
+/*
+ * MTAF demuxer
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+
+static int mtaf_probe(AVProbeData *p)
+{
+if (p->buf_size < 0x44)
+return 0;
+
+if (AV_RL32(p->buf) != MKTAG('M','T','A','F') ||
+AV_RL32(p->buf + 0x40) != MKTAG('H','E','A','D'))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static int mtaf_read_header(AVFormatContext *s)
+{
+int stream_count;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(s->pb, 0x5c);
+st->duration = avio_rl32(s->pb);
+avio_skip(s->pb, 1);
+stream_count = avio_r8(s->pb);
+if (!stream_count)
+return AVERROR_INVALIDDATA;
+
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id= AV_CODEC_ID_ADPCM_MTAF;
+st->codecpar->channels= 2 * stream_count;
+st->codecpar->sample_rate = 48000;
+st->codecpar->block_align = 0x110 * st->codecpar->channels / 2;
+avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
+
+avio_seek(s->pb, 0x800, SEEK_SET);
+
+return 0;
+}
+
+static int mtaf_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+return av_get_packet(s->pb, pkt, par->block_align);
+}
+
+AVInputFormat ff_mtaf_demuxer = {
+.name = "mtaf",
+.long_name = NULL_IF_CONFIG_SMALL("Konami PS2 MTAF"),
+.read_probe = mtaf_probe,
+.read_header= mtaf_read_header,
+.read_packet= mtaf_read_packet,
+.extensions = "mtaf",
+};
--
2.5.0
From a3c0ddfde6a75a6d0724f52c8c9779e5123abebb Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 15 May 2016 20:45:04 +0200
Subject: [PATCH 2/2] avcodec: add adpcm MTAF decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 41 ++
libavcodec/adpcm_data.c | 67 +
libavcodec/adpcm_data.h | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/utils.c | 2 ++
8 files changed, 121 insertions(+)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3f0ffd1..3a9dd95 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -707,6 +707,7 @@ OBJS-$(CON
Re: [FFmpeg-devel] Tee improvement - discussion
On Wed, 11 May 2016, Jan Sebechlebsky wrote: Hi, I'll be working on tee muxer improvement during GSoC 2016 and I thought maybe it is a good idea to ask about ideas which any of you might have regarding what could be done in avformat/tee. Currently, the tee muxer works in a simple way, incoming packets are just iteratively fed to several output muxers (each muxer blocking the next). Also there is no possibility to reset muxer on error. My current idea is to create queue for each output (as Marton suggested) and process each output in separate thread. I was also considering using just single queue, but since the AVPackets are referenced counted, the memory overhead is negligible and using multiple queues will simplify the code. Apart from getting advantage of non-blocking processing with multiple slave muxers, error handling will also be improved. The option allowing to ignore failure on certain outputs is already implemented (this allows for example network streaming to continue even after disk fills up, or recording to file to continue when network error occurs). In the final solution the tee muxer will also support restarting failed output. There is a question how to deal with restart, there are several options what to do and this could be also configurable for the user (with reasonable default set): (Does these options make sense to you? Do you have ideas for more? ) - Attempt restart immediately after failure, if it doesn't succeed attempt with the next packet (keyframe). Repeat (argument) times before giving up on that output. - Attempt restart after certain time (argument). - Combination of two options above. Attempt to recover with next keyframes, after several failures wait for some amount of time and attempt again. I think a per-output restart_delay with an 1 second default, and a per-output restart_with_keyframe boolean flag defaulting to true would be simple yet powerful enough. Another question is what to do when some of the queues becomes full, discussed options were so far: - Block write_packet call until the queue frees - this might be useful when producer is faster than consumer, and we don't want to drop any packets when recording to file. - Drop some yet unprocessed packets (until next keyframe, or free some portion of queue) to free the queue - this might be useful for network outputs. I suggest a per-output "blocking" boolean flag to specify outputs, where - in case of a full queue - writing is blocked. A per-output queue_size setting might be useful as well. If a queue is full, but non-blocking, then the producer should set an overflow flag of that queue, and not push any further data to the queue, unless the overflow flag is cleared. The consumer should be responsible to clear the overflow flag. If the consumer feels itself ready to receive packets, but an overflow happened, then it should probably want to drop all existing packets in its queue and clear the flag after that. This way if the consumer is only slightly slower than the producer, the packet losses will be bursty, and this also reduce the chance to operate with an always almost-full queue causing unnecessary latency and memory usage. Once the consumer is receiving packets again, it should wait for the first keyframe (if restart_with_keyframe is set) and start processing packets from that. I'm thinking of implementing this queue by wrapping up AVFifoBuffer (similarily than AVThreadMessageQueue does but with the configurable behaviour as described above). Exactly what behaviour is missing from AVThreadMessageQueue? Isn't there a chance to extend that, or implement all additional logic on top of it? If you have any ideas or notes regarding what would be good to do in libavformat/tee and want to join discussion, I'll be glad to take them into account and improve the proposed project. Great, thanks. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add MTAF demuxer and decoder
On 5/15/2016 6:33 PM, Paul B Mahol wrote:
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3f0ffd1..3a9dd95 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -707,6 +707,7 @@ OBJS-$(CONFIG_ADPCM_IMA_WAV_ENCODER) += adpcmenc.o
> adpcm_data.o
> OBJS-$(CONFIG_ADPCM_IMA_WS_DECODER) += adpcm.o adpcm_data.o
> OBJS-$(CONFIG_ADPCM_MS_DECODER) += adpcm.o adpcm_data.o
> OBJS-$(CONFIG_ADPCM_MS_ENCODER) += adpcmenc.o adpcm_data.o
> +OBJS-$(CONFIG_ADPCM_MTAF_DECODER) += adpcm.o adpcm_data.o
> OBJS-$(CONFIG_ADPCM_PSX_DECODER) += adpcm.o adpcm_data.o
> OBJS-$(CONFIG_ADPCM_SBPRO_2_DECODER) += adpcm.o adpcm_data.o
> OBJS-$(CONFIG_ADPCM_SBPRO_3_DECODER) += adpcm.o adpcm_data.o
> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> index 0b6b92e..e624b85 100644
> --- a/libavcodec/adpcm.c
> +++ b/libavcodec/adpcm.c
> @@ -107,6 +107,10 @@ static av_cold int adpcm_decode_init(AVCodecContext *
> avctx)
> case AV_CODEC_ID_ADPCM_EA_XAS:
> max_channels = 6;
> break;
> +case AV_CODEC_ID_ADPCM_MTAF:
> +min_channels = 2;
> +max_channels = 8;
> +break;
> case AV_CODEC_ID_ADPCM_PSX:
> max_channels = 8;
> break;
> @@ -159,6 +163,7 @@ static av_cold int adpcm_decode_init(AVCodecContext *
> avctx)
> case AV_CODEC_ID_ADPCM_AFC:
> case AV_CODEC_ID_ADPCM_DTK:
> case AV_CODEC_ID_ADPCM_PSX:
> +case AV_CODEC_ID_ADPCM_MTAF:
> avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
> break;
> case AV_CODEC_ID_ADPCM_IMA_WS:
> @@ -342,6 +347,15 @@ static inline int16_t
> adpcm_yamaha_expand_nibble(ADPCMChannelStatus *c, uint8_t
> return c->predictor;
> }
>
> +static inline int16_t adpcm_mtaf_expand_nibble(ADPCMChannelStatus *c,
> uint8_t nibble)
> +{
You should use local variables here, like in other expand_nibbble() functions.
> +c->predictor += ff_adpcm_mtaf_stepsize[c->step][nibble];
> +c->predictor = av_clip_int16(c->predictor);
> +c->step += ff_adpcm_index_table[nibble];
> +c->step = av_clip(c->step, 0, 31);
av_clip_uintp2(step, 5);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC 2016] Ideas on FFV1 P frame project
Hi On Sun, May 15, 2016 at 07:44:11PM +0300, Станислав Долганов wrote: > Hello, > I'm currently working on GSOC 2016 project for upgrading FFV1 codec with an > ability to use P frames. Maybe some of you have any suggestions or > recommendations. > > While working on qualification task I implemented a simple modification of > codec to encode P frames without motion compensation, so now the base for > trying several MC approaches is ready. > > My plan of upgrade is the next: > 1) I want to try current realization of OBMC algorithm from snow*.c > 2) Then try to take some ideas from HEVC > 2.1) In paper "Overview of the High Efficiency Video Coding (HEVC) > Standard" (can be found here > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6316136) motion > compensation process is described. It includes quarter pixel interpolation > technic, intra- and inter-frame predicting strategies, quadtree of frame > blocks, several types of predicted units, so there is a lot of stuff to try > next. good ideas it also probably makes sense to try 1/8 pel and smaller blocks at some later point if time remains > 2.2) In "PARALLEL AMVP CANDIDATE LIST CONSTRUCTION FOR HEVC" ( > https://www.researchgate.net/profile/Liang_Zhao57/publication/261497818_Parallel_AMVP_candidate_list_construction_for_HEVC/links/54117bd10cf264cee28b3964.pdf) > can be found algorithm to > make MC process faster. It probably makes sense to first identify which parts take most time and cause parallelization bottlenecks before optimizing > 2.3) Authors of "HEVC Lossless Coding and Improvements" ( > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352.3447&rep=rep1&type=pdf) > proposed Sample-Based Angular Intra Prediction algrorithm special for > lossless compression, which can be tried too. yes > 3) Try to use filtration just like bilateral in "SEPARABLE BILATERAL > FILTERING FOR FAST VIDEO PREPROCESSING" ( > http://elynxsdk.free.fr/ext-docs/Bilateral/ICME2005_TPLV.pdf) as > pre-processing part, it can reduce compression size due to encoding noise > values only from a current frame. > 4) Maybe try some non common ideas like not use motion vectors as in > "Lossless Video Sequence Compression Using Adaptive Prediction" ( > https://www.researchgate.net/profile/K_Sayood/publication/51386836_Lossless_Video_Sequence_Compression_Using_Adaptive_Prediction/links/5489cf110cf225bf669c7487.pdf > ). this sounds very interresting I think the general plan layed out by your mail above looks good! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add properties for lossless to AVCodecParameters
On 5/8/2016 12:18 PM, Hendrik Leppkes wrote:
> On Sun, May 8, 2016 at 12:10 PM, Michael Niedermayer
> wrote:
>> Fixes Ticket5467
>>
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/avcodec.h |4
>> libavcodec/utils.c |2 ++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 3813a0a..1db2e0f 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -4050,6 +4050,10 @@ typedef struct AVCodecParameters {
>> * Audio only. Number of samples to skip after a discontinuity.
>> */
>> int seek_preroll;
>> +
>> +/** Properties, like FF_CODEC_PROPERTY_LOSSLESS.
>> + */
>> +int properties;
>> } AVCodecParameters;
>>
>
> There properties are not part of any container we support and therefor
> not really fitting into this structure.
>
> - Hendrik
Guess i'm late to the party, but we support the DTS-HD container and it has a
field that reports if the stream is lossless or not.
See
http://atsc.org/wp-content/uploads/2015/03/Non-Real-Time-Content-Delivery.pdf
section E.2.8 and table E.12, Bitw_Aupres_Metadata field.
For that matter I'll submit a patch soon to read some fields from this header to
get stream duration and bitrate since libavformat currently reports neither.
Assuming this properties field is added to AVCodecParameters it could be used to
report the losslessness of the stream as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/11] avcodec/mips: loongson optimize h264dsp with mmi v2
1.no longer use register name directly and optimized code format 2.to be compatibal with O32, specify type of address variable with mips_reg and handle the address varialbe with PTR_ operator 3.optimize some unalignment faults in load and store 4.use uld and mtc1 to workaround cpu 3A2000 gslwlc1 bug (gslwlc1 instruction extension bug in O32 ABI) At 2016-05-15 01:56:34, "Michael Niedermayer" wrote: >On Fri, May 13, 2016 at 06:03:27PM +0800, 周晓勇 wrote: >> From 4adf70c0eb9a85fe6cbedb043ed8ce08024c48dc Mon Sep 17 00:00:00 2001 >> From: ZhouXiaoyong >> Date: Sat, 7 May 2016 14:16:28 +0800 > >> Subject: [PATCH 03/11] avcodec/mips: loongson optimize h264dsp with mmi v2 > >please provide more verbose commit messages >A commit message should state >what is changed >why it is changed >how it is changed >as well as what effects that has on user, compatibility, performance, ... > >[...] >-- >Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >Those who are best at talking, realize last or never when they are wrong. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
