Re: [FFmpeg-devel] [PATCH] avformat: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
On Mon, Feb 16, 2015 at 10:49:52AM +, Kevin Wheatley wrote: > ffmpeg and qtdump could not decode pasp/colr atoms in the files made by > ffmpeg, > when outputting DNxHD due to the incorrect padding placement. Now we add the > padding in the correct place, we also always add padding for Final Cut > compatibility. > > Tidy up FATE changes due to padding changes. applied the case for DNxHD, for the more general case, please explain which case(s) and software need them, and how to reproduce that I dont see where the text would allow one to add such padding by ones own choice. I just see a note that says that parsers need to cope with it. Thats not the same as saying its ok to add it in all cases. But maybe iam missing something, i didnt read the whole document [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 07:57:05AM +, Kevin Wheatley wrote: > > > Sent on the go... > > > On 19 Feb 2015, at 18:35, Michael Niedermayer wrote: > > > > theres no encoder, the data could instead come from another mov > > file or a binary encoder used by some user application with > > libavformat > > Michael, > > Thanks for your response, I must be confused then. What I thought was based > on the following. > > I have say a set of image files that I want to encode as dnxhd in QuickTime, > so ffmpeg sets up the encoder, and during each image's encoding the encoder > needs some information such as if the movie is encoded with interlaced > fields, and also the specifics of the resolution and bit rates there's a > codec/compression Id associated with those settings. When writing the avid > atoms, they also should have those same values encoded in them. > > This is important as if instead of starting from image files we start from an > existing movie with the atom present, we would not want to use values based > on that atom, which is what s currently done, I wanted to find the dnxencoder > structure to correctly populate the atom. If you start with a existing movie and copy the packets one by one there is no decoder and no encoder, so no dnxencoder structure if you want to put some value in the avid atom which are stored in the bitstream/packets of dnxhd and not in the generic data structures like width/height would be then you have to extract these from the dnxhd bitstream one way or another because thats the only thing thats there in the memory of your machine. I dont know what exact information you want/need from the dnxhd encoder ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 11:44 AM, Michael Niedermayer wrote: > If you start with a existing movie and copy the packets one by one > there is no decoder and no encoder, so no dnxencoder structure > > if you want to put some value in the avid atom which are stored in the > bitstream/packets of dnxhd and not in the generic data structures > like width/height would be then you have to extract these from the > dnxhd bitstream one way or another because thats the only thing thats > there in the memory of your machine. I dont know what exact information > you want/need from the dnxhd encoder ... hmm, maybe I should just say that copy is not supported for DNxHD files then as that sounds a pain to deal with, or I could put better check in the arbitrary buffer offsets the mov_write_avid_tag function uses to access track->vos_data, which is what sent me down the direction of trying to access the encoder data. Is there a sensible function I can use to find a specific atom within the buffer? On a related note when doing a -c copy is it supposed to preserve color range (trc, space, primaries) in the output if it is set on the input/command line? Thanks Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
--- libavformat/hlsenc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 1831c17..0f14e90 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -242,10 +242,12 @@ static int hls_window(AVFormatContext *s, int last) int target_duration = 0; int ret = 0; AVIOContext *out = NULL; +char temp_filename[1024]; int64_t sequence = FFMAX(hls->start_sequence, hls->sequence - hls->nb_entries); int version = hls->flags & HLS_SINGLE_FILE ? 4 : 3; -if ((ret = avio_open2(&out, s->filename, AVIO_FLAG_WRITE, +snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename); +if ((ret = avio_open2(&out, temp_filename, AVIO_FLAG_WRITE, &s->interrupt_callback, NULL)) < 0) goto fail; @@ -280,6 +282,8 @@ static int hls_window(AVFormatContext *s, int last) fail: avio_closep(&out); +if (ret >= 0) +ff_rename(temp_filename, s->filename, s); return ret; } -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] hlsenc: remove the AVIOContext for the playlist from the muxer context
Its only used in one function, having it in the context serves no purpose.
---
libavformat/hlsenc.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 29bf30e..1831c17 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -85,8 +85,6 @@ typedef struct HLSContext {
char *baseurl;
char *format_options_str;
AVDictionary *format_options;
-
-AVIOContext *pb;
} HLSContext;
static int hls_delete_old_segments(HLSContext *hls) {
@@ -243,10 +241,11 @@ static int hls_window(AVFormatContext *s, int last)
HLSSegment *en;
int target_duration = 0;
int ret = 0;
+AVIOContext *out = NULL;
int64_t sequence = FFMAX(hls->start_sequence, hls->sequence -
hls->nb_entries);
int version = hls->flags & HLS_SINGLE_FILE ? 4 : 3;
-if ((ret = avio_open2(&hls->pb, s->filename, AVIO_FLAG_WRITE,
+if ((ret = avio_open2(&out, s->filename, AVIO_FLAG_WRITE,
&s->interrupt_callback, NULL)) < 0)
goto fail;
@@ -255,32 +254,32 @@ static int hls_window(AVFormatContext *s, int last)
target_duration = ceil(en->duration);
}
-avio_printf(hls->pb, "#EXTM3U\n");
-avio_printf(hls->pb, "#EXT-X-VERSION:%d\n", version);
+avio_printf(out, "#EXTM3U\n");
+avio_printf(out, "#EXT-X-VERSION:%d\n", version);
if (hls->allowcache == 0 || hls->allowcache == 1) {
-avio_printf(hls->pb, "#EXT-X-ALLOW-CACHE:%s\n", hls->allowcache == 0 ?
"NO" : "YES");
+avio_printf(out, "#EXT-X-ALLOW-CACHE:%s\n", hls->allowcache == 0 ?
"NO" : "YES");
}
-avio_printf(hls->pb, "#EXT-X-TARGETDURATION:%d\n", target_duration);
-avio_printf(hls->pb, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
+avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
+avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
av_log(s, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n",
sequence);
for (en = hls->segments; en; en = en->next) {
-avio_printf(hls->pb, "#EXTINF:%f,\n", en->duration);
+avio_printf(out, "#EXTINF:%f,\n", en->duration);
if (hls->flags & HLS_SINGLE_FILE)
- avio_printf(hls->pb, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
+ avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
en->size, en->pos);
if (hls->baseurl)
-avio_printf(hls->pb, "%s", hls->baseurl);
-avio_printf(hls->pb, "%s\n", en->filename);
+avio_printf(out, "%s", hls->baseurl);
+avio_printf(out, "%s\n", en->filename);
}
if (last)
-avio_printf(hls->pb, "#EXT-X-ENDLIST\n");
+avio_printf(out, "#EXT-X-ENDLIST\n");
fail:
-avio_closep(&hls->pb);
+avio_closep(&out);
return ret;
}
@@ -486,7 +485,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
hls_free_segments(hls->segments);
hls_free_segments(hls->old_segments);
-avio_closep(&hls->pb);
return 0;
}
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
Hi, On Fri, Feb 20, 2015 at 6:56 AM, Kevin Wheatley wrote: > On Fri, Feb 20, 2015 at 11:44 AM, Michael Niedermayer > wrote: > > If you start with a existing movie and copy the packets one by one > > there is no decoder and no encoder, so no dnxencoder structure > > > > if you want to put some value in the avid atom which are stored in the > > bitstream/packets of dnxhd and not in the generic data structures > > like width/height would be then you have to extract these from the > > dnxhd bitstream one way or another because thats the only thing thats > > there in the memory of your machine. I dont know what exact information > > you want/need from the dnxhd encoder ... > > > hmm, maybe I should just say that copy is not supported for DNxHD > files then as that sounds a pain to deal with Why wouldn't the mov demuxer parse these atoms and fill them in the same way the dnxhd encoder does? The idea is that anything that outputs encoded dnxhd frames should fill these data structures (where-ever they are, but should probably be in some lavformat structure, not a lavcodec structure), and for backwards compat you should also deal with the fact that they might not be there. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hlsenc: remove the AVIOContext for the playlist from the muxer context
On Fri, Feb 20, 2015 at 12:55:13PM +0100, Hendrik Leppkes wrote: > Its only used in one function, having it in the context serves no purpose. > --- > libavformat/hlsenc.c | 28 +--- > 1 file changed, 13 insertions(+), 15 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
Please excuse my newbie knowledge of the code base BTW... I've just done a simple test ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb 115M /quicktimes/ffmpeg_test.mov During this the vos_data contains... 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 38 07 80 00 04 38 00 00 38 88 ... Which looks to me like the start of the VC3/DNxHD bit stream and in this case the code puts valid data in the header atoms. If I then fmpeg -i quicktimes/ffmpeg_test.mov -c copy quicktimes/ffmpeg_test_copy.mov the vos_data instead contains 00 00 00 18 41 43 4C 52 41 43 4C 52 30 30 30 31 00 00 00 01 00 00 00 00 00 00 00 18 41 50 52 47 41 50 52 47 ... which is the start of the Avid atoms from the incomming Quicktime. So I could peak into the stream and 'guess' based on the content being 0x00, 0x00, 0x02, 0x80, 0x01 that we are encoding and can trust the contents, else I could search through looking for the atom via the string "ARESARES" and then having located it I could assume to use that. The only oddball case is if it is not found, at that point the code needs to know if it is interlaced as well as the avid codec identifier, or maybe that is the point at which we 'give up' and fail with unsupported? Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
On Fri, Feb 20, 2015 at 12:55:14PM +0100, Hendrik Leppkes wrote: > --- > libavformat/hlsenc.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c > index 1831c17..0f14e90 100644 > --- a/libavformat/hlsenc.c > +++ b/libavformat/hlsenc.c > @@ -242,10 +242,12 @@ static int hls_window(AVFormatContext *s, int last) > int target_duration = 0; > int ret = 0; > AVIOContext *out = NULL; > +char temp_filename[1024]; > int64_t sequence = FFMAX(hls->start_sequence, hls->sequence - > hls->nb_entries); > int version = hls->flags & HLS_SINGLE_FILE ? 4 : 3; > > -if ((ret = avio_open2(&out, s->filename, AVIO_FLAG_WRITE, > +snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename); > +if ((ret = avio_open2(&out, temp_filename, AVIO_FLAG_WRITE, >&s->interrupt_callback, NULL)) < 0) > goto fail; > > @@ -280,6 +282,8 @@ static int hls_window(AVFormatContext *s, int last) > > fail: > avio_closep(&out); > +if (ret >= 0) > +ff_rename(temp_filename, s->filename, s); what if s->filename is not a local file ? or am i missing something that prevents that ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
On Fri, Feb 20, 2015 at 1:38 PM, Michael Niedermayer wrote: > On Fri, Feb 20, 2015 at 12:55:14PM +0100, Hendrik Leppkes wrote: >> --- >> libavformat/hlsenc.c | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c >> index 1831c17..0f14e90 100644 >> --- a/libavformat/hlsenc.c >> +++ b/libavformat/hlsenc.c >> @@ -242,10 +242,12 @@ static int hls_window(AVFormatContext *s, int last) >> int target_duration = 0; >> int ret = 0; >> AVIOContext *out = NULL; >> +char temp_filename[1024]; >> int64_t sequence = FFMAX(hls->start_sequence, hls->sequence - >> hls->nb_entries); >> int version = hls->flags & HLS_SINGLE_FILE ? 4 : 3; >> >> -if ((ret = avio_open2(&out, s->filename, AVIO_FLAG_WRITE, >> +snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename); >> +if ((ret = avio_open2(&out, temp_filename, AVIO_FLAG_WRITE, >>&s->interrupt_callback, NULL)) < 0) >> goto fail; >> >> @@ -280,6 +282,8 @@ static int hls_window(AVFormatContext *s, int last) >> >> fail: >> avio_closep(&out); >> +if (ret >= 0) >> +ff_rename(temp_filename, s->filename, s); > > what if s->filename is not a local file ? > or am i missing something that prevents that ? > What else could it be? It writes to separate segment files as well, not sure that would work on anything but local files. For the record, this is the same method used in dashenc for writing its manifest file, and it can avoid a sort-of race condition when serving the files through a web server directly (ie. web server reading while in the middle of re-writing it). - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 12:35:59PM +, Kevin Wheatley wrote: > Please excuse my newbie knowledge of the code base BTW... > > I've just done a simple test > > ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb > 115M /quicktimes/ffmpeg_test.mov > > During this the vos_data contains... > > 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 04 38 07 80 00 04 38 00 00 38 88 ... > > Which looks to me like the start of the VC3/DNxHD bit stream and in > this case the code puts valid data in the header atoms. > > If I then > > fmpeg -i quicktimes/ffmpeg_test.mov -c copy quicktimes/ffmpeg_test_copy.mov > > the vos_data instead contains > > 00 00 00 18 41 43 4C 52 41 43 4C 52 30 30 30 31 00 00 00 01 00 00 00 > 00 00 00 00 18 41 50 52 47 41 50 52 47 ... > > which is the start of the Avid atoms from the incomming Quicktime. > > So I could peak into the stream and 'guess' based on the content being > 0x00, 0x00, 0x02, 0x80, 0x01 that we are encoding and can trust the > contents, else I could search through looking for the atom via the > string "ARESARES" and then having located it I could assume to use > that. The only oddball case is if it is not found, at that point the > code needs to know if it is interlaced as well as the avid codec > identifier, or maybe that is the point at which we 'give up' and fail > with unsupported? if you need to put 2 bits from a fixed location of the "first" packet into some avid atoms its probably easiest to read them straight out of the first packet into some new field in a struct and then use that when writing the atoms. IIUC theres no generic field in AVStream, AVCodecContext or elsewhere that holds this information. If there is, setting this field from the encoder/demuxer and using it would be the more correct path extracting the data from vos_data seems trickier It would also be possible to add a first_packet field where vos_data is and always initialize it to the first packet and use that instead I sure do not fully know all the details of the issue so i might be missing something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
On Fri, Feb 20, 2015 at 02:15:30PM +0100, Hendrik Leppkes wrote: > On Fri, Feb 20, 2015 at 1:38 PM, Michael Niedermayer wrote: > > On Fri, Feb 20, 2015 at 12:55:14PM +0100, Hendrik Leppkes wrote: > >> --- > >> libavformat/hlsenc.c | 6 +- > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c > >> index 1831c17..0f14e90 100644 > >> --- a/libavformat/hlsenc.c > >> +++ b/libavformat/hlsenc.c > >> @@ -242,10 +242,12 @@ static int hls_window(AVFormatContext *s, int last) > >> int target_duration = 0; > >> int ret = 0; > >> AVIOContext *out = NULL; > >> +char temp_filename[1024]; > >> int64_t sequence = FFMAX(hls->start_sequence, hls->sequence - > >> hls->nb_entries); > >> int version = hls->flags & HLS_SINGLE_FILE ? 4 : 3; > >> > >> -if ((ret = avio_open2(&out, s->filename, AVIO_FLAG_WRITE, > >> +snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename); > >> +if ((ret = avio_open2(&out, temp_filename, AVIO_FLAG_WRITE, > >>&s->interrupt_callback, NULL)) < 0) > >> goto fail; > >> > >> @@ -280,6 +282,8 @@ static int hls_window(AVFormatContext *s, int last) > >> > >> fail: > >> avio_closep(&out); > >> +if (ret >= 0) > >> +ff_rename(temp_filename, s->filename, s); > > > > what if s->filename is not a local file ? > > or am i missing something that prevents that ? > > > > What else could it be? http, ftp, who knows also ff_rename() would interpret a "http://"; differently from avio_open2(), so something more is needed to not end up with odd rename() calls > It writes to separate segment files as well, > not sure that would work on anything but local files. i dont know either but if someone passes "ftp://..."; it should either work or fail with a error message or mostly work while printing a warning > > For the record, this is the same method used in dashenc for writing > its manifest file, and it can avoid a sort-of race condition when > serving the files through a web server directly (ie. web server > reading while in the middle of re-writing it). > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
Hi, if I read the code correctly, the colr atom is only written in the mov muxer if the flag write_colr is specified. Was that behaviour chosen to have better backward compatibility or is there another reason not to write this standard atom by default? Thanks and best regards, Robert ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
Here is the kind of thing that this looks like... This is definitely
NOT a patch :-)
On Fri, Feb 20, 2015 at 1:22 PM, Michael Niedermayer wrote:
> On Fri, Feb 20, 2015 at 12:35:59PM +, Kevin Wheatley wrote:
>> Please excuse my newbie knowledge of the code base BTW...
>>
>> I've just done a simple test
>>
>> ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb
>> 115M /quicktimes/ffmpeg_test.mov
>>
>> During this the vos_data contains...
>>
>> 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 04 38 07 80 00 04 38 00 00 38 88 ...
>>
>> Which looks to me like the start of the VC3/DNxHD bit stream and in
>> this case the code puts valid data in the header atoms.
>>
>> If I then
>>
>> fmpeg -i quicktimes/ffmpeg_test.mov -c copy quicktimes/ffmpeg_test_copy.mov
>>
>> the vos_data instead contains
>>
>> 00 00 00 18 41 43 4C 52 41 43 4C 52 30 30 30 31 00 00 00 01 00 00 00
>> 00 00 00 00 18 41 50 52 47 41 50 52 47 ...
>>
>> which is the start of the Avid atoms from the incomming Quicktime.
>>
>> So I could peak into the stream and 'guess' based on the content being
>> 0x00, 0x00, 0x02, 0x80, 0x01 that we are encoding and can trust the
>> contents, else I could search through looking for the atom via the
>> string "ARESARES" and then having located it I could assume to use
>> that. The only oddball case is if it is not found, at that point the
>> code needs to know if it is interlaced as well as the avid codec
>> identifier, or maybe that is the point at which we 'give up' and fail
>> with unsupported?
>
> if you need to put 2 bits from a fixed location of the "first" packet
> into some avid atoms its probably easiest to read them straight out of
> the first packet into some new field in a struct and then use that
> when writing the atoms.
>
> IIUC theres no generic field in AVStream, AVCodecContext or elsewhere
> that holds this information. If there is, setting this field from the
> encoder/demuxer and using it would be the more correct path
>
> extracting the data from vos_data seems trickier
>
> It would also be possible to add a first_packet field where vos_data
> is and always initialize it to the first packet and use that instead
>
> I sure do not fully know all the details of the issue so i might be
> missing something
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> There will always be a question for which you do not know the correct answer.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a72f84e..dc5a7b4 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1033,6 +1033,10 @@ static int mov_write_hvcc_tag(AVIOContext *pb, MOVTrack
*track)
static int mov_write_avid_tag(AVIOContext *pb, MOVTrack *track)
{
int i;
+int interlaced = 0;
+int cid = 0;
+uint32_t temp;
+
avio_wb32(pb, 24); /* size */
ffio_wfourcc(pb, "ACLR");
ffio_wfourcc(pb, "ACLR");
@@ -1056,10 +1060,43 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack
*track)
ffio_wfourcc(pb, "ARES");
ffio_wfourcc(pb, "ARES");
ffio_wfourcc(pb, "0001");
-avio_wb32(pb, AV_RB32(track->vos_data + 0x28)); /* dnxhd cid, some id ? */
+
+if (track->vos_data && track->vos_len > 0x29) {
+if (track->vos_data[0] == 0x00 &&
+track->vos_data[1] == 0x00 &&
+track->vos_data[2] == 0x02 &&
+track->vos_data[3] == 0x80 &&
+(track->vos_data[4] == 0x01 ||track->vos_data[4] == 0x02)) {
+/* looks like a DNxHD bit stream */
+interlaced = (track->vos_data[5] & 2);
+cid = AV_RB32(track->vos_data + 0x28);
+} else if (track->vos_len > 120) { /* big enough to contain the atom */
+for (i = 0; i < (track->vos_len - 4); i += 4) {
+temp = AV_RL32(track->vos_data + i);
+if ((AV_RL32(track->vos_data + i) == MKTAG('A', 'R', 'E',
'S')) &&
+(AV_RL32(track->vos_data + i + 4) == MKTAG('A', 'R', 'E',
'S')))
+break;
+}
+if (i < (track->vos_len - 12))
+{
+interlaced = track->enc->field_order > AV_FIELD_PROGRESSIVE;
+cid = AV_RB32(track->vos_data + i + 12);
+} else {
+// couldn't find it in the buffer
+printf("couldn't find it\n");
+}
+}
+} else {
+ printf("buffer too small\n");
+ // log some error not enough buffer to contain the info?
+ // return non 0?
+}
+
+
+avio_wb32(pb, cid); /* dnxhd cid, some id ? */
avio_wb32(pb, track->enc->width);
/* values below are based on samples created with quicktime and avid
codecs */
-if (track->vos_data[5] & 2) { // interlaced
+if (interlaced) {
a
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 01:48:55PM +, Kevin Wheatley wrote: > Here is the kind of thing that this looks like... This is definitely > NOT a patch :-) i dont understand this patch please explain why you use vos_data it can be the first packet and you seem to implement that case but it is not always the first packet and you seem to add alot of code to handle this. But if the data is in the dnxhd packets using that always and not vos_data seems much easier what am i missing ? or one could ask the other way around why vos data is set inconsistently, is there a case where setting it to the first packet does not work? [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger wrote: > if I read the code correctly, the colr atom is only written in the mov > muxer if the flag write_colr is specified. Was that behaviour chosen to > have better backward compatibility or is there another reason not to write > this standard atom by default? I chose that way to preserve the older behaviour, as it can change how files will be interpreted. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi: add showvolume filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/avf_showvolume.c | 197 +++
3 files changed, 199 insertions(+)
create mode 100644 libavfilter/avf_showvolume.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 289c63b..7e64a20 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -234,6 +234,7 @@ OBJS-$(CONFIG_AVECTORSCOPE_FILTER) +=
avf_avectorscope.o
OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o
OBJS-$(CONFIG_SHOWSPECTRUM_FILTER) += avf_showspectrum.o
+OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
OBJS-$(CONFIG_SHOWWAVES_FILTER) += avf_showwaves.o
# multimedia sources
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 55de154..e236d05 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -249,6 +249,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(CONCAT, concat, avf);
REGISTER_FILTER(SHOWCQT,showcqt,avf);
REGISTER_FILTER(SHOWSPECTRUM, showspectrum, avf);
+REGISTER_FILTER(SHOWVOLUME, showvolume, avf);
REGISTER_FILTER(SHOWWAVES, showwaves, avf);
/* multimedia sources */
diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c
new file mode 100644
index 000..5ab9410
--- /dev/null
+++ b/libavfilter/avf_showvolume.c
@@ -0,0 +1,197 @@
+/*
+ * Copyright (c) 2015 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/opt.h"
+#include "libavutil/parseutils.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "audio.h"
+#include "video.h"
+#include "internal.h"
+
+typedef struct ShowVolumeContext {
+const AVClass *class;
+AVFrame *outpicref;
+int w, h;
+int f;
+AVRational frame_rate;
+} ShowVolumeContext;
+
+#define OFFSET(x) offsetof(ShowVolumeContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption showvolume_options[] = {
+{ "rate", "set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE,
{.str="25"}, 0, 0, FLAGS },
+{ "r","set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE,
{.str="25"}, 0, 0, FLAGS },
+{ "w", "set channel width", OFFSET(w), AV_OPT_TYPE_INT, {.i64=400}, 40,
1080, FLAGS },
+{ "h", "set channel height", OFFSET(h), AV_OPT_TYPE_INT, {.i64=20}, 1,
100, FLAGS },
+{ "f", "set fade", OFFSET(f), AV_OPT_TYPE_INT, {.i64=20}, 1,
255, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(showvolume);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+AVFilterLink *inlink = ctx->inputs[0];
+AVFilterLink *outlink = ctx->outputs[0];
+static const enum AVSampleFormat sample_fmts[] = { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE };
+static const enum AVPixelFormat pix_fmts[] = { AV_PIX_FMT_RGBA,
AV_PIX_FMT_NONE };
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &inlink->out_formats);
+
+layouts = ff_all_channel_layouts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ff_channel_layouts_ref(layouts, &inlink->out_channel_layouts);
+
+formats = ff_all_samplerates();
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &inlink->out_samplerates);
+
+formats = ff_make_format_list(pix_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &outlink->in_formats);
+
+return 0;
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+ShowVolumeContext *s = ctx->priv;
+int nb_samples;
+
+nb_samples = FFMAX(1024, ((double)inlink->sample_rate /
av_q2d(s->frame_rate)) + 0.5);
+inlink->partial_buf_size =
+inlink->min_samples =
+inlink->max_samples = nb_samples;
+
+return 0;
+}
+
+static int config_output(AVFilterLink *outlink)
+{
+ShowVolumeContext *s = outlink->src-
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 2:14 PM, Michael Niedermayer wrote: > On Fri, Feb 20, 2015 at 01:48:55PM +, Kevin Wheatley wrote: >> Here is the kind of thing that this looks like... This is definitely >> NOT a patch :-) > > i dont understand this patch there are at least two of us. > please explain why you use vos_data > it can be the first packet and you seem to implement that case > but it is not always the first packet and you seem to add alot of > code to handle this. But if the data is in the dnxhd packets > using that always and not vos_data seems much easier > what am i missing ? probably nothing, I've only tried to find a small change to the code, and to localise the effect to the function so as to minimise the effect of the change - I really don't have a full enough grasp of the code base to do otherwise. > or one could ask the other way around why vos data is set > inconsistently, is there a case where setting it to the first packet > does not work? I'm simply showing how the current contents of vos_data can be used, like you say it would be nice if it was always one or the other, but for whatever reason the copy case puts the atoms in there, which is why the current code without the patch generates incorrect atoms when copy is used on DNxHD files as the code that writes the new atom expects the bitstream, all I did was try a quick detection of what the contents are and use them appropriately. to see if the files would then be fixed. In my case I'm unable to read the files in The Foundry's Nuke if I 'copy' them via ffmpeg because the atom was written incorrectly, but with the diff applied then the copied files will load. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
Am Freitag, 20. Februar 2015 schrieb Kevin Wheatley : > On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger > wrote: > > if I read the code correctly, the colr atom is only written in the mov > > muxer if the flag write_colr is specified. Was that behaviour chosen to > > have better backward compatibility or is there another reason not to > write > > this standard atom by default? > > I chose that way to preserve the older behaviour, as it can change how > files will be interpreted. > > I assumed that but isn't the change then a change for the better (then maybe requiring a version bump and an entry in the release notes)? After all Apple muxers write it by default as well and not trusting the input metadata seems to me like something that should be opt-out rather than opt-in but that's just my 2c. Just as another data point, I think ffmbc writes it by default. If it helps, I can go through a few samples created by well-known tools (e.g. Adobe Media Encoder) and post, if they write it by default. Best regards, Robert Kevin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] wtvdec: fix integer overflow resulting in errors with large files
This fixes a regression in 9fbc613f0df1628e7e78bca791fa8833846f8210 --- libavformat/wtvdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c index a752ee2..95b2312 100644 --- a/libavformat/wtvdec.c +++ b/libavformat/wtvdec.c @@ -965,7 +965,7 @@ static int read_header(AVFormatContext *s) uint8_t root[WTV_SECTOR_SIZE]; AVIOContext *pb; int64_t timeline_pos; -int ret; +int64_t ret; wtv->epoch = wtv->pts= -- 2.3.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer wrote: > applied the case for DNxHD, for the more general case, please > explain which case(s) and software need them, and how to reproduce > that My experience and by the looks of things other people using libquicktime have seen issues with Final Cut having problems reading the files if the stds http://libquicktime.cvs.sourceforge.net/viewvc/libquicktime/libquicktime/src/stsdtable.c?view=markup quicktime_write_stsd_video() line 643 is where they sometimes pad. http://comments.gmane.org/gmane.comp.video.libquicktime.devel/1348 appears to be the discussion around why they do it > I dont see where the text would allow one to add such padding by > ones own choice. I just see a note that says that parsers need to > cope with it. Thats not the same as saying its ok to add it in all > cases. > But maybe iam missing something, i didnt read the whole document no I would agree it only indicates it is optional Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] wtvdec: fix integer overflow resulting in errors with large files
On Fri, Feb 20, 2015 at 09:30:04AM -0600, Rodger Combs wrote: > This fixes a regression in 9fbc613f0df1628e7e78bca791fa8833846f8210 > --- > libavformat/wtvdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?
On Fri, Feb 20, 2015 at 02:48:31PM +, Kevin Wheatley wrote: > On Fri, Feb 20, 2015 at 2:14 PM, Michael Niedermayer wrote: > > On Fri, Feb 20, 2015 at 01:48:55PM +, Kevin Wheatley wrote: > >> Here is the kind of thing that this looks like... This is definitely > >> NOT a patch :-) > > > > i dont understand this patch > > there are at least two of us. > > > please explain why you use vos_data > > it can be the first packet and you seem to implement that case > > but it is not always the first packet and you seem to add alot of > > code to handle this. But if the data is in the dnxhd packets > > using that always and not vos_data seems much easier > > what am i missing ? > > probably nothing, I've only tried to find a small change to the code, > and to localise the effect to the function so as to minimise the > effect of the change - I really don't have a full enough grasp of the > code base to do otherwise. theres some code that memcpies extradata into vos_data and that is skiped if TAG_IS_AVCI(trk->tag), try to also skip this for DNxHD [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
On Fri, Feb 20, 2015 at 04:04:52PM +, Kevin Wheatley wrote: > On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer > wrote: > > applied the case for DNxHD, for the more general case, please > > explain which case(s) and software need them, and how to reproduce > > that > > My experience and by the looks of things other people using > libquicktime have seen issues with Final Cut having problems reading > the files if the stds > > http://libquicktime.cvs.sourceforge.net/viewvc/libquicktime/libquicktime/src/stsdtable.c?view=markup > > quicktime_write_stsd_video() line 643 is where they sometimes pad. > > http://comments.gmane.org/gmane.comp.video.libquicktime.devel/1348 > > appears to be the discussion around why they do it hmm, ok, i guess doing the same "sometimes" padding is what we should do then too if you want to submit a patch along these lines, ill apply it unless it breaks something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add showvolume filter
On Fri, Feb 20, 2015 at 02:28:21PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/avf_showvolume.c | 197
> +++
> 3 files changed, 199 insertions(+)
> create mode 100644 libavfilter/avf_showvolume.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 289c63b..7e64a20 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -234,6 +234,7 @@ OBJS-$(CONFIG_AVECTORSCOPE_FILTER) +=
> avf_avectorscope.o
> OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
> OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o
> OBJS-$(CONFIG_SHOWSPECTRUM_FILTER) += avf_showspectrum.o
> +OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
> OBJS-$(CONFIG_SHOWWAVES_FILTER) += avf_showwaves.o
>
> # multimedia sources
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 55de154..e236d05 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -249,6 +249,7 @@ void avfilter_register_all(void)
> REGISTER_FILTER(CONCAT, concat, avf);
> REGISTER_FILTER(SHOWCQT,showcqt,avf);
> REGISTER_FILTER(SHOWSPECTRUM, showspectrum, avf);
> +REGISTER_FILTER(SHOWVOLUME, showvolume, avf);
> REGISTER_FILTER(SHOWWAVES, showwaves, avf);
>
> /* multimedia sources */
> diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c
> new file mode 100644
> index 000..5ab9410
> --- /dev/null
> +++ b/libavfilter/avf_showvolume.c
> @@ -0,0 +1,197 @@
> +/*
> + * Copyright (c) 2015 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/opt.h"
> +#include "libavutil/parseutils.h"
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "audio.h"
> +#include "video.h"
> +#include "internal.h"
> +
> +typedef struct ShowVolumeContext {
> +const AVClass *class;
> +AVFrame *outpicref;
> +int w, h;
> +int f;
> +AVRational frame_rate;
> +} ShowVolumeContext;
> +
> +#define OFFSET(x) offsetof(ShowVolumeContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> +
> +static const AVOption showvolume_options[] = {
> +{ "rate", "set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE,
> {.str="25"}, 0, 0, FLAGS },
> +{ "r","set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE,
> {.str="25"}, 0, 0, FLAGS },
> +{ "w", "set channel width", OFFSET(w), AV_OPT_TYPE_INT, {.i64=400}, 40,
> 1080, FLAGS },
> +{ "h", "set channel height", OFFSET(h), AV_OPT_TYPE_INT, {.i64=20}, 1,
> 100, FLAGS },
> +{ "f", "set fade", OFFSET(f), AV_OPT_TYPE_INT, {.i64=20}, 1,
> 255, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(showvolume);
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +AVFilterFormats *formats = NULL;
> +AVFilterChannelLayouts *layouts = NULL;
> +AVFilterLink *inlink = ctx->inputs[0];
> +AVFilterLink *outlink = ctx->outputs[0];
> +static const enum AVSampleFormat sample_fmts[] = { AV_SAMPLE_FMT_FLTP,
> AV_SAMPLE_FMT_NONE };
> +static const enum AVPixelFormat pix_fmts[] = { AV_PIX_FMT_RGBA,
> AV_PIX_FMT_NONE };
> +
> +formats = ff_make_format_list(sample_fmts);
> +if (!formats)
> +return AVERROR(ENOMEM);
> +ff_formats_ref(formats, &inlink->out_formats);
> +
> +layouts = ff_all_channel_layouts();
> +if (!layouts)
> +return AVERROR(ENOMEM);
> +ff_channel_layouts_ref(layouts, &inlink->out_channel_layouts);
> +
> +formats = ff_all_samplerates();
> +if (!formats)
> +return AVERROR(ENOMEM);
> +ff_formats_ref(formats, &inlink->out_samplerates);
> +
> +formats = ff_make_format_list(pix_fmts);
> +if (!formats)
> +return AVERROR(ENOMEM);
> +ff_formats_ref(formats, &outlink->in_formats);
> +
> +return 0;
> +}
> +
> +static int config_input(AVFilterLink *inlink)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +ShowVolumeContext *s = ctx->p
Re: [FFmpeg-devel] [PATCH] lavfi: add showvolume filter
On Fri, Feb 20, 2015 at 02:28:21PM +, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/avf_showvolume.c | 197 > +++ > 3 files changed, 199 insertions(+) > create mode 100644 libavfilter/avf_showvolume.c > [...] You could make a viewer that uses ebur128 metadata, as an alternative to its default viewer. The sound level will be way more accurate. -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
On 20.02.2015 14:30, Michael Niedermayer wrote: On Fri, Feb 20, 2015 at 02:15:30PM +0100, Hendrik Leppkes wrote: On Fri, Feb 20, 2015 at 1:38 PM, Michael Niedermayer wrote: On Fri, Feb 20, 2015 at 12:55:14PM +0100, Hendrik Leppkes wrote: What else could it be? http, ftp, who knows also ff_rename() would interpret a "http://"; differently from avio_open2(), so something more is needed to not end up with odd rename() calls It writes to separate segment files as well, not sure that would work on anything but local files. i dont know either but if someone passes "ftp://..."; it should either work or fail with a error message or mostly work while printing a warning Some ftp servers claim thay allow to upload atomically. Who knows whats the true. I wouldn't do that probably. But real regression is in case someone doesn't really care to have live stream, but just want to generate manifest and chunks on remote server directly for later use. For me you patch is OK, but maybe it is worth to add rename as part of protocol implementation to support these cases too. Assuming tempfile could have hardcoded name like ".filename" instead of "filename" and rename it when is ready. For the record, this is the same method used in dashenc for writing its manifest file, and it can avoid a sort-of race condition when serving the files through a web server directly (ie. web server reading while in the middle of re-writing it). And the same in smoothstreaming encoder. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/ffmenc: do not fail on missing codec
On 20.02.2015 01:53, Michael Niedermayer wrote: On Thu, Feb 19, 2015 at 11:52:50PM +0100, Lukasz Marek wrote: ffm encoder fails when codec is not found. It may happen when stream is being copied. This commit allows to store such stream and provides backward compatibility with version prior 2.5 release. fixes #4266 Signed-off-by: Lukasz Marek LGTM pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] hlsenc: write playlist into a temp file and replace the original atomically
On Sat, Feb 21, 2015 at 12:10:09AM +0100, Lukasz Marek wrote: > On 20.02.2015 14:30, Michael Niedermayer wrote: > >On Fri, Feb 20, 2015 at 02:15:30PM +0100, Hendrik Leppkes wrote: > >>On Fri, Feb 20, 2015 at 1:38 PM, Michael Niedermayer > >>wrote: > >>>On Fri, Feb 20, 2015 at 12:55:14PM +0100, Hendrik Leppkes wrote: > >>What else could it be? > > > >http, ftp, who knows > >also ff_rename() would interpret a "http://"; differently from > >avio_open2(), so something more is needed to not end up with odd > >rename() calls > > > >>It writes to separate segment files as well, > >>not sure that would work on anything but local files. > >i dont know either > >but if someone passes "ftp://..."; it should either work or fail > >with a error message or mostly work while printing a warning > > Some ftp servers claim thay allow to upload atomically. Who knows > whats the true. I wouldn't do that probably. But real regression is > in case someone doesn't really care to have live stream, but just > want to generate manifest and chunks on remote server directly for > later use. > > For me you patch is OK, ok, applied ive also made rename optional and disabled it if its not the file protocol > but maybe it is worth to add rename as part > of protocol implementation to support these cases too. Assuming > tempfile could have hardcoded name like ".filename" instead of > "filename" and rename it when is ready. yes, though this seems too much work if its for just this > > >>For the record, this is the same method used in dashenc for writing > >>its manifest file, and it can avoid a sort-of race condition when > >>serving the files through a web server directly (ie. web server > >>reading while in the middle of re-writing it). > > And the same in smoothstreaming encoder. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
Hi Robert, Kevin, > On Feb 20, 2015, at 9:56 AM, Robert Krüger wrote: > > Am Freitag, 20. Februar 2015 schrieb Kevin Wheatley : > >> On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger > > wrote: >>> if I read the code correctly, the colr atom is only written in the mov >>> muxer if the flag write_colr is specified. Was that behaviour chosen to >>> have better backward compatibility or is there another reason not to >> write >>> this standard atom by default? >> >> I chose that way to preserve the older behaviour, as it can change how >> files will be interpreted. >> >> I assumed that but isn't the change then a change for the better (then > maybe requiring a version bump and an entry in the release notes)? After > all Apple muxers write it by default as well and not trusting the input > metadata seems to me like something that should be opt-out rather than > opt-in but that's just my 2c. That's also my two cents and I also wondered why users have to opt-in to a correctly written file. The QuickTime spec says that colr is required with some streams (such as raw uyvy422 and v210), see: https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9. I'd propose that colr be written by default. The interpretation may be different but, since a file with a colr atom is more self-descriptive, the interpretation is more likely to be correct. Dave Rice > Just as another data point, I think ffmbc writes it by default. If it helps, > I can go through a few samples created by well-known tools (e.g. Adobe > Media Encoder) and post, if they write it by default. > > Best regards, > > Robert > > > Kevin >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > -- > Robert Krüger > Managing Partner > Lesspain GmbH & Co. KG > > www.lesspain-software.com > ___ > 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
[FFmpeg-devel] [PATCH] avcodec/tak: reset filter buffers
Zeroing them allows us to use scalarproduct_int16 even if the length of vectors
is not multiple of 16.
Signed-off-by: James Almer
---
libavcodec/takdec.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 2f0155d..0f808e0 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -451,6 +451,7 @@ static int decode_subframe(TAKDecContext *s, int32_t
*decoded,
s->filter[j] = x - ((tfilter[i] + y) >> (15 - filter_quant));
s->filter[i] = x - ((tfilter[j] + y) >> (15 - filter_quant));
}
+memset(s->filter + filter_order, 0, sizeof(s->filter) - filter_order*2);
if ((ret = decode_residues(s, &decoded[filter_order],
subframe_size - filter_order)) < 0)
@@ -467,15 +468,8 @@ static int decode_subframe(TAKDecContext *s, int32_t
*decoded,
for (i = 0; i < tmp; i++) {
int v = 1 << (filter_quant - 1);
-if (filter_order & -16)
-v += s->adsp.scalarproduct_int16(&s->residues[i], s->filter,
- filter_order & -16);
-for (j = filter_order & -16; j < filter_order; j += 4) {
-v += s->residues[i + j + 3] * s->filter[j + 3] +
- s->residues[i + j + 2] * s->filter[j + 2] +
- s->residues[i + j + 1] * s->filter[j + 1] +
- s->residues[i + j] * s->filter[j];
-}
+v += s->adsp.scalarproduct_int16(&s->residues[i], s->filter,
+ FFALIGN(filter_order, 16));
v = (av_clip(v >> filter_quant, -8192, 8191) << dshift) - *decoded;
*decoded++ = v;
s->residues[filter_order + i] = v >> dshift;
@@ -601,6 +595,7 @@ static int decorrelate(TAKDecContext *s, int c1, int c2,
int length)
code_size = 14 - get_bits(gb, 3);
s->filter[i] = get_sbits(gb, code_size);
}
+memset(s->filter + filter_order, 0, sizeof(s->filter) -
filter_order*2);
order_half = filter_order / 2;
length2= length - (filter_order - 1);
@@ -638,20 +633,7 @@ static int decorrelate(TAKDecContext *s, int c1, int c2,
int length)
for (i = 0; i < tmp; i++) {
int v = 1 << 9;
-if (filter_order == 16) {
-v += s->adsp.scalarproduct_int16(&s->residues[i],
s->filter,
- filter_order);
-} else {
-v += s->residues[i + 7] * s->filter[7] +
- s->residues[i + 6] * s->filter[6] +
- s->residues[i + 5] * s->filter[5] +
- s->residues[i + 4] * s->filter[4] +
- s->residues[i + 3] * s->filter[3] +
- s->residues[i + 2] * s->filter[2] +
- s->residues[i + 1] * s->filter[1] +
- s->residues[i] * s->filter[0];
-}
-
+v += s->adsp.scalarproduct_int16(&s->residues[i], s->filter,
16);
v = (av_clip(v >> 10, -8192, 8191) << dshift) - *p1;
*p1++ = v;
}
--
2.3.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/tak: remove unnecessary calls to emms_c()
It's already called by scalarproduct_int16 if required. Signed-off-by: James Almer --- libavcodec/takdec.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c index 0f808e0..77170b5 100644 --- a/libavcodec/takdec.c +++ b/libavcodec/takdec.c @@ -480,8 +480,6 @@ static int decode_subframe(TAKDecContext *s, int32_t *decoded, memcpy(s->residues, &s->residues[y], 2 * filter_order); } -emms_c(); - return 0; } @@ -641,7 +639,6 @@ static int decorrelate(TAKDecContext *s, int c1, int c2, int length) memcpy(s->residues, &s->residues[tmp], 2 * filter_order); } -emms_c(); break; } } -- 2.3.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/tak: clarify the size of residues buffer
Signed-off-by: James Almer
---
At least this is what i interpreted 544 meant. This patch can be discarded
otherwise.
libavcodec/takdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 77170b5..059fdaa 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -69,7 +69,7 @@ typedef struct TAKDecContext {
int8_t coding_mode[128];
DECLARE_ALIGNED(16, int16_t, filter)[MAX_PREDICTORS];
-DECLARE_ALIGNED(16, int16_t, residues)[544];
+DECLARE_ALIGNED(16, int16_t, residues)[MAX_PREDICTORS * 2 +
FF_INPUT_BUFFER_PADDING_SIZE];
} TAKDecContext;
static const int8_t mc_dmodes[] = { 1, 3, 4, 6, };
--
2.3.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
