Re: [FFmpeg-devel] [PATCH] support for latest git of libilbc
On Thu, Sep 18, 2014 at 09:40:20PM -0700, Timothy Gu wrote: > On Thu, Sep 18, 2014 at 7:49 PM, Gianluigi Tiesi wrote: > > Hi, > > > > in the latest git commits of libilbc developers removed WebRtc_xxx > typedefs > > > > The attached patch uses int types instead, > > it's safe to apply also for previous versions since > > WebRtc_Word16 was always a typedef of int16_t and > > WebRtc_UWord16 a typedef of uint16_t > > LGTM. Sorry for not noticing that FFmpeg is using the WebRtc_ typedefs when > I updated the libilbc to upstream. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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/dv_profile: deprecate internal function that shouldn't be public
On Fri, Sep 19, 2014 at 01:50:28AM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > Unlike us, libav got rid of the internal symbols before the header became > public on > an actual relase, so we're stuck with it until next bump. > I renamed the function to ff_ since it's only used outside libavcodec when > called > with the public symbol. > > doc/APIchanges | 3 +++ > libavcodec/dv_profile.c | 12 ++-- > libavcodec/dv_profile.h | 6 ++ > libavcodec/dv_profile_internal.h | 8 > libavcodec/dvdec.c | 3 ++- > libavcodec/version.h | 5 - > 6 files changed, 33 insertions(+), 4 deletions(-) LGTM [...] -- 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] More specific error codes
Thank you for your feedback. Any more comments/advices? Are patch submissions on this topic welcome? -- Andrey Utkin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/1] configure: Refactor setting of feature test macro _XOPEN_SOURCE
On Thu, Sep 18, 2014 at 8:24 PM, Jörg Krause wrote: > > On 09/18/2014 07:10 PM, Reimar Döffinger wrote: > >> On 18.09.2014, at 17:26, Michael Niedermayer wrote: >> >>> On Thu, Sep 18, 2014 at 04:22:27PM +0200, Jörg Krause wrote: >>> glibc, uclibc, and musl uses feature test macros to expose definitions conforming to the standards ISO C, POSIX and extensions. According to which feature test macros are defined by the user or the compiler, the header file used by these libraries internally defines various other macros. glibc and uclibc also defines release test macros, eg __GLIBC__ and __UCLIBC__ in . musl does not have (and do not want) such a macro like __MUSL__. Building ffmpeg with the musl toolchain needs the feature test macro _XOPEN_SOURCE=600 to be defined. As it is not possible to detect musl check for the header file, which is assumed to be specific to glibc, uclibc, and musl. Signed-off-by: Jörg Krause --- Changes v1 -> v2: - do not set _XOPEN_SOURCE twice for glibc and uclibc >>> why do you not add the musl check at the end of the if/elif chain as >>> suggested ? >>> does that have some issue or problem ? >>> >>> now your patch removes POSIX_C_SOURCE=200112 for glibc & uclibc >>> maybe thats ok, maybe its not but it certainly doesnt belong in a >>> patch that adds musl support >>> If you think this change is desireable, please submit a seperate >>> patch >>> >> May I suggest to change configure to always add these (POSIX_C_SOURCE and >> _XOPEN_SOURCE) and we just remove them specifically for cases that cause >> issues? >> And this time _document_ why we even have these hacks. >> Because as it it's impossible to know if all those special case are there >> for a reason or if they only exist because it's fun and nicely obfuscates >> configure. >> > > LGTM. I also discussed with the people at the musl mailing list and this > was their opinion to. First define the default and then add the hacks. > > > libav has also been working on this particular issue, and they are just adding _DEFAULT_SOURCE to the defines if the specific libc is unknown. Would that work? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Questions on adding a FATE test for the HLS muxer
On Fri, Sep 19, 2014 at 04:15:13AM +, Raento Mika wrote: > On 19/09/14 01:27, "Michael Niedermayer" wrote: > > >On Thu, Sep 18, 2014 at 06:05:38PM +, Raento Mika wrote: > >> Hiy'all > >> > >> As suggested by Michael, I'm trying to add a FATE test for the new > >> single_file option to the HLS muxer. > >> > >> I have something working, but I'm not sure what's the best way to do > >>this. > >> The wiki page is not very complete. > >> > >> The HLS muxer produces a number of .ts files (well, one for the > >> single_file case) and a m3u8 file. The m3u8 is output several times > >>during > >> the muxing. > >> > >> The existing tests I found all use a single output, passing '-' as the > >> output filename to ffmpeg. Doing this generates a file that looks like > >> > >> >> second segment>... > >> > >> checking this against a reference file will indeed verify the whole > >> output, but is not very readable. Should I do this? And if so, how do I > >> add a new reference file to FATE. > > Hi, thanks for the great feedback > > > > >the output files, each should be checked against a md5 stored in git > >also the whole should be demuxed again (with framecrc) and that too > >compared against the good framecrc output in git. > > Is there an example that does this (multiple outputs)? The ones I found > with some searching all just used one output, a pipe. there are the image tests like fate-lavf-bmp which have multiple files, though iam not sure if they are a good reference > > (I'm not saying that I won't write the necessary support, I just wish > somebody had already done it :-) > > > > >theres no real reference file for the fate-suite for this as theres > >not one correct ts file set. slight changes in the ts muxer or > >encoders would change the output > > I would at least personally prefer the actual playlist and framecrc lists > to be used for comparison, rather than an md5 - with the md5 you'd have > very little visibility into _what_ changed. yes, for framecrc & the playlist, still the generated ts file(s) needs a md5 or similar check too. Not just framecrc from them being demuxed, as that could be unchanged and the ts still changing. And while it doesnt give any details of what changes its still usefull to detect bugs if for exampe one makes a change thats not supposed to change the generated ts [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] More specific error codes
On Fri, Sep 19, 2014 at 12:59:35PM +0300, Andrey Utkin wrote: > Thank you for your feedback. > Any more comments/advices? > Are patch submissions on this topic welcome? yes, but please also seperate addition of codes and their use so you dont waste time changing alot of code to a error code that then someone finds a better factorization for Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]: libavcodec/webp
On Thu, Sep 18, 2014 at 10:34:11PM -0700, Pascal Massimino wrote: > Hi Reimar, > > On Thu, Sep 18, 2014 at 12:28 PM, Reimar Döffinger > wrote: > > > On 18 September 2014 10:55:00 CEST, Pascal Massimino < > > pascal.massim...@gmail.com> wrote: > > >Hi Reimar, > > > > > >On Thu, Sep 18, 2014 at 9:33 AM, Reimar Döffinger > > > > > >wrote: > > > > > >> On 18.09.2014, at 08:45, Pascal Massimino > > > > > >> wrote: > > >> > Hi, > > >> > > > >> > the webp lossless doc was unclear regarding palette index falling > > >out of > > >> > range. > > >> > See issue #206 [1] for the bug report. > > >> > The solution retained was to treat out-of-range index as color > > >> 0x, > > >> > so we could keep the speed-up in libwebp (we use fake extra entries > > >in > > >> the > > >> > cmap to handle out-of-bound values without the extra branch). > > >> > > > >> > The doc was clarified (along with few other loose ends) in patch > > >#71605 > > >> [2] > > >> > Attached is the fix for ffmpeg's webp decoder to treat out-of-bound > > >index > > >> > as transparent-black instead of reporting an error. > > >> > > >> The spec now says "should be set". I don't fully understand why we > > >would > > >> ordinarily expect out-of-range value. > > >> > > > > > >corrupt files, for instance. Or just malicious ones. > > > > Why in all the world would you make handling of corrupted and malicious > > files part of the spec? > > That certainly should be left up to the decoder! > > A safety-oriented or conformance checking one would immediately abort, a > > speed oriented one would do whatever is fastest and a data recovery one > > would use advanced error resilience methods. > > Why would it be desirable for all of them to be forced to do the same > > thing? > > > > >I also don't understand why the issue talks about speed loss in the > > >> decoder, when it is the encoder that decides to use out-of-bounds > > >values. > > >> > > > > > >I considered both options: making the values forbidden, or defining a > > >behaviour for out-of-bound. > > >It turned out (see bug issue text) that introducing the bound-check in > > >an > > >already tight-loop was slowing down decoding up to 9%. > > >All things considered, pragmatism indicates that the latter option > > >should > > >be favored. > > > > Sorry that makes no sense. > > If an input is invalid you decoder can do whatever it wants. > > Declaring something as invalid in the spec purely logically can in no way > > cause a slowdown. > > Now for libwebp you might have some issues if you insist that you want it > > to be both reference decoder and fast at the same time. But that's an issue > > with your choice of implementing things, not the spec. > > With the explanation you gave, I would say both your change to the spec and > > the proposed FFmpeg change are just nonsense. > > > > > while i don't necessarily disagree with the above generally speaking [*], > let me repeat that > this is a pragmatic choice. I'm not going to give up on the speed-up i have > right now for > some hypothetical decoder later. This was facilitated by the fact that the > change was minor > and innocuous for ffmpeg. > > /skal > > (on a tangential side, this change also saves 2-6 bytes for files that > actually have 0x > color in their palette, somewhat frequent case, because you then don't need > to transmit this color) should i apply the patch or wait ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] UDP TS feed switching from EAC3 to AC3 audio
On Thu, Sep 18, 2014 at 02:35:42PM -0600, Ryan Owen wrote: > I have a TS feed that I'm reading with libavformat/libavcodec over > multicast. The feed comes from an over-the-air channel, where the video is > mpeg2 and the audio is AC3. > > Occasionally there are some dropped packets, and that somehow leads > libavcodec/ac3_parser.c to think the audio codec has changed to EAC3. > When this happens, I call avcodec_open2 with the new codec info, but it > fails with the error "invalid extradata size" (the extradata size is 0). > That is probably to be expected, because the audio frame is invalid due to > the dropped packets anyway. > > The problem comes when the next valid audio frame arrives. ac3_parser.c > has this logic in ac3_sync(): > > if(hdr.bitstream_id>10) > hdr_info->codec_id = AV_CODEC_ID_EAC3; > else if (hdr_info->codec_id == AV_CODEC_ID_NONE) > hdr_info->codec_id = AV_CODEC_ID_AC3; > > Because of the previous bad frame, hdr_info->codec_id got switched to > AV_CODEC_ID_EAC3. But because of the "else if" condition, it can't switch > back to AV_CODEC_ID_AC3. Even though the new frame is valid, avcodec_open2 > continues to fail because EAC3 doesn't like the extradata size to be 0. > > I'm wondering if it would be ok to change the "else if" to just an "else", no > or if that would break some other scenario. I don't know enough about > AC3/EAC3 to understand why it shouldn't switch back to AC3. there would be a race condition > > Any suggestions on how to work around this problem? the decoder could make the switch, the parser cant switch the decoder at least not easily so the solution would be to check this in the decoder and switch there [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Change deprecated use of _SVID_SOURCE to _DEFAULT_SOURCE
What should be tested in configure? IMO take this patch and and if it breaks some old systems (not sure why it would) have a configure option to revert this on those systems. On Thu, Sep 18, 2014 at 5:39 PM, Carl Eugen Hoyos wrote: > Daniel Bomar gmail.com> writes: > >> This is from /usr/include/features.h which is provided by glibc. The >> ./configure, make build that ffmpeg uses only generates a warning but >> for some reason Chromium's ninja + clang build system generates an >> error. > > Imo, this should be tested in configure. > > Carl Eugen > > ___ > 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] postproc: add basic deblock filter visualization support
Signed-off-by: Michael Niedermayer
---
libpostproc/postprocess.c | 36 +++-
libpostproc/postprocess_internal.h |1 +
libpostproc/postprocess_template.c | 14 ++
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index b6da294..de95745 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -151,6 +151,7 @@ static const struct PPFilter filters[]=
{"tn", "tmpnoise", 1, 7, 8, TEMP_NOISE_FILTER},
{"fq", "forcequant",1, 0, 0, FORCE_QUANT},
{"be", "bitexact", 1, 0, 0, BITEXACT},
+{"vi", "visualize", 1, 0, 0, VISUALIZE},
{NULL, NULL,0,0,0,0} //End Marker
};
@@ -430,7 +431,7 @@ static inline void horizX1Filter(uint8_t *src, int stride,
int QP)
* accurate deblock filter
*/
static av_always_inline void do_a_deblock_C(uint8_t *src, int step,
-int stride, const PPContext *c)
+int stride, const PPContext *c,
int mode)
{
int y;
const int QP= c->QP;
@@ -485,6 +486,32 @@ static av_always_inline void do_a_deblock_C(uint8_t *src,
int step,
sums[8] = sums[7] - src[3*step] + last;
sums[9] = sums[8] - src[4*step] + last;
+if (mode & VISUALIZE) {
+// src[0*step] = av_clip_uint8(src[0*step]+32);
+// src[1*step] = av_clip_uint8(src[1*step]-32);
+// src[2*step] = av_clip_uint8(src[2*step]+32);
+// src[3*step] = av_clip_uint8(src[3*step]-32);
+// src[4*step] = av_clip_uint8(src[4*step]+32);
+// src[5*step] = av_clip_uint8(src[5*step]-32);
+// src[6*step] = av_clip_uint8(src[6*step]+32);
+// src[7*step] = av_clip_uint8(src[7*step]-32);
+src[0*step] =
+src[1*step] =
+src[2*step] =
+src[3*step] =
+src[4*step] =
+src[5*step] =
+src[6*step] =
+src[7*step] = 128;
+// src[0*step]= av_clip_uint8((-sums[0] - sums[2] +
22*src[0*step])>>3);
+// src[1*step]= av_clip_uint8((-sums[1] - sums[3] +
22*src[1*step])>>3);
+// src[2*step]= av_clip_uint8((-sums[2] - sums[4] +
22*src[2*step])>>3);
+// src[3*step]= av_clip_uint8((-sums[3] - sums[5] +
22*src[3*step])>>3);
+// src[4*step]= av_clip_uint8((-sums[4] - sums[6] +
22*src[4*step])>>3);
+// src[5*step]= av_clip_uint8((-sums[5] - sums[7] +
22*src[5*step])>>3);
+// src[6*step]= av_clip_uint8((-sums[6] - sums[8] +
22*src[6*step])>>3);
+// src[7*step]= av_clip_uint8((-sums[7] - sums[9] +
22*src[7*step])>>3);
+}
src[0*step]= (sums[0] + sums[2] + 2*src[0*step])>>4;
src[1*step]= (sums[1] + sums[3] + 2*src[1*step])>>4;
src[2*step]= (sums[2] + sums[4] + 2*src[2*step])>>4;
@@ -516,6 +543,13 @@ static av_always_inline void do_a_deblock_C(uint8_t *src,
int step,
d = FFMAX(d, q);
}
+if ((mode & VISUALIZE) && d) {
+d= (d < 0) ? 32 : -32;
+src[3*step]= av_clip_uint8(src[3*step] - d);
+src[4*step]= av_clip_uint8(src[4*step] + d);
+d = 0;
+}
+
src[3*step]-= d;
src[4*step]+= d;
}
diff --git a/libpostproc/postprocess_internal.h
b/libpostproc/postprocess_internal.h
index 43aaf84..1ebd974 100644
--- a/libpostproc/postprocess_internal.h
+++ b/libpostproc/postprocess_internal.h
@@ -69,6 +69,7 @@
#define TEMP_NOISE_FILTER 0x10
#define FORCE_QUANT 0x20
#define BITEXACT0x100
+#define VISUALIZE 0x200
//use if you want a faster postprocessing code
//cannot differentiate between chroma & luma filters (both on or both off)
diff --git a/libpostproc/postprocess_template.c
b/libpostproc/postprocess_template.c
index 7eddb22..aee0a74 100644
--- a/libpostproc/postprocess_template.c
+++ b/libpostproc/postprocess_template.c
@@ -2544,7 +2544,7 @@ Switch between
/**
* accurate deblock filter
*/
-static av_always_inline void RENAME(do_a_deblock)(uint8_t *src, int step, int
stride, PPContext *c){
+static av_always_inline void RENAME(do_a_deblock)(uint8_t *src, int step, int
stride, PPContext *c, int mode){
int64_t dc_mask, eq_mask, both_masks;
int64_t sums[10*8*2];
src+= step*3; // src points to begin of the 8x8 Block
@@ -3272,6 +3272,12 @@ static void RENAME(postProcess)(const uint8_t src[], int
Re: [FFmpeg-devel] [PATCH]: libavcodec/webp
On Fri, Sep 19, 2014 at 08:08:10AM +0200, Reimar Döffinger wrote: > On 19 September 2014 07:34:11 CEST, Pascal Massimino > wrote: > >Hi Reimar, > >while i don't necessarily disagree with the above generally speaking > >[*], > >let me repeat that > >this is a pragmatic choice. I'm not going to give up on the speed-up i > >have > >right now for > >some hypothetical decoder later. > > I think we're completely past each other. > Changing the spec to say these values are invalid does not require changes to > any decoder. > Any decoder that is conformant would still be a confirming decoder. > Thus it is completely impossible that this would make your decoder slower!! > If you do understand anything other than that your claim it would make your > decoder slower is simply _wrong_ and untrue you are still misunderstanding me. > On the contrary your spec is the one that requires decoder changes, and at > least in theory might cause slowdown. > But even if you decide to keep the spec changed, it seems like a rather > obfuscated way to specify it. > As far as I can tell you basically changed the codec to only support palette > size 256 and non-coded palette entries are opaque black. > Not to mention that it is a spec change that renders previously compliant > implementation non-compliant (as FFmpeg proves) and all that because you > don't want to have e.g. a configure option to switch libwebp between a fast > and a "thorough compliance check" mode, which would solve the issue without > changing the spec or causing slowdown for the fast config. > With how little consideration such changes are made is what scares the hell > out of anyone wanting to implement it or vp* in hardware. > > >(on a tangential side, this change also saves 2-6 bytes for files that > >actually have 0x > >color in their palette, somewhat frequent case, because you then don't > >need > >to transmit this color) > > I noticed that, however one additional entry is enough for that, leaving any > other entries still available for error resilience and future extensions. > Also, if you want the encoder to actually use it the "should" should be > "must" instead. I think you are correct in several points your raise, but discussing the webp spec on ffmpeg-devel is probably not optimal. Not sure which is the appropriate place ... As is, the spec says out of range values should be transparent black and thats what the patch changes the decoder to, thus its correct. if some consensus is found and the spec is changed we can revert or amend our decoder again patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] postproc: add basic deblock filter visualization support
On Fri, Sep 19, 2014 at 03:44:31PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libpostproc/postprocess.c | 36
> +++-
> libpostproc/postprocess_internal.h |1 +
> libpostproc/postprocess_template.c | 14 ++
> 3 files changed, 46 insertions(+), 5 deletions(-)
>
> diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
> index b6da294..de95745 100644
> --- a/libpostproc/postprocess.c
> +++ b/libpostproc/postprocess.c
> @@ -151,6 +151,7 @@ static const struct PPFilter filters[]=
> {"tn", "tmpnoise", 1, 7, 8, TEMP_NOISE_FILTER},
> {"fq", "forcequant",1, 0, 0, FORCE_QUANT},
> {"be", "bitexact", 1, 0, 0, BITEXACT},
> +{"vi", "visualize", 1, 0, 0, VISUALIZE},
> {NULL, NULL,0,0,0,0} //End Marker
> };
>
> @@ -430,7 +431,7 @@ static inline void horizX1Filter(uint8_t *src, int
> stride, int QP)
> * accurate deblock filter
> */
> static av_always_inline void do_a_deblock_C(uint8_t *src, int step,
> -int stride, const PPContext *c)
> +int stride, const PPContext *c,
> int mode)
> {
> int y;
> const int QP= c->QP;
> @@ -485,6 +486,32 @@ static av_always_inline void do_a_deblock_C(uint8_t
> *src, int step,
> sums[8] = sums[7] - src[3*step] + last;
> sums[9] = sums[8] - src[4*step] + last;
>
> +if (mode & VISUALIZE) {
> +// src[0*step] = av_clip_uint8(src[0*step]+32);
> +// src[1*step] = av_clip_uint8(src[1*step]-32);
> +// src[2*step] = av_clip_uint8(src[2*step]+32);
> +// src[3*step] = av_clip_uint8(src[3*step]-32);
> +// src[4*step] = av_clip_uint8(src[4*step]+32);
> +// src[5*step] = av_clip_uint8(src[5*step]-32);
> +// src[6*step] = av_clip_uint8(src[6*step]+32);
> +// src[7*step] = av_clip_uint8(src[7*step]-32);
> +src[0*step] =
> +src[1*step] =
> +src[2*step] =
> +src[3*step] =
> +src[4*step] =
> +src[5*step] =
> +src[6*step] =
> +src[7*step] = 128;
> +// src[0*step]= av_clip_uint8((-sums[0] - sums[2] +
> 22*src[0*step])>>3);
> +// src[1*step]= av_clip_uint8((-sums[1] - sums[3] +
> 22*src[1*step])>>3);
> +// src[2*step]= av_clip_uint8((-sums[2] - sums[4] +
> 22*src[2*step])>>3);
> +// src[3*step]= av_clip_uint8((-sums[3] - sums[5] +
> 22*src[3*step])>>3);
> +// src[4*step]= av_clip_uint8((-sums[4] - sums[6] +
> 22*src[4*step])>>3);
> +// src[5*step]= av_clip_uint8((-sums[5] - sums[7] +
> 22*src[5*step])>>3);
> +// src[6*step]= av_clip_uint8((-sums[6] - sums[8] +
> 22*src[6*step])>>3);
> +// src[7*step]= av_clip_uint8((-sums[7] - sums[9] +
> 22*src[7*step])>>3);
> +}
If you want to add dead code, please at least explain above why it should
be kept.
[...]
No opinion on the rest of the patchset; don't forget to bump micro if you
apply.
--
Clément B.
pgpwLgd5tTDF5.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [patch] Only decode forced dvd-subtitles
Ok, not to beat a dead horse, but I think I've gotten this working. I think it
might work better in lavc/dvdsubdec.c. AFAICT this works and doesn't produce
mangled tracks. Patch at end of email. (Sorry for the inline patch) If this is
a good patch, I'll add the appropriate documentation and do a proper
commit-patch
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 7355c03..874c28b 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -39,6 +39,7 @@ typedef struct DVDSubContext
uint8_t alpha[256];
uint8_t *buf;
int buf_size;
+ int only_dec_forced;
#ifdef DEBUG
int sub_id;
#endif
@@ -548,6 +549,9 @@ static int dvdsub_decode(AVCodecContext *avctx,
if (!is_menu && find_smallest_bounding_rectangle(sub) == 0)
goto no_subtitle;
+if (ctx->only_dec_forced && !(sub->rects[0]->flags &
AV_SUBTITLE_FLAG_FORCED))
+goto no_subtitle;
+
#if defined(DEBUG)
{
char ppm_name[32];
@@ -652,6 +656,7 @@ static av_cold int dvdsub_close(AVCodecContext *avctx)
#define VD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
{ "palette", "set the global palette", OFFSET(palette_str),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
+{ "only_dec_forced", "Only decode forced subtitles",
OFFSET(only_dec_forced), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, VD},
{ NULL }
};
static const AVClass dvdsub_class = {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
>
>
> What do you think might be the problem here?
>
>
I changed streams order in deckling_dec.cpp
and Video now on 0:0
/* Setup streams. */
st = avformat_new_stream(avctx, NULL);
if (!st) {
av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
goto error;
}
st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
st->codec->width = ctx->bmd_width;
st->codec->height = ctx->bmd_height;
st->codec->pix_fmt = AV_PIX_FMT_UYVY422;
st->codec->time_base.den = ctx->bmd_tb_den;
st->codec->time_base.num = ctx->bmd_tb_num;
st->codec->bit_rate= avpicture_get_size(st->codec->pix_fmt,
ctx->bmd_width, ctx->bmd_height) * 1/av_q2d(st->codec->time_base) * 8;
st->codec->codec_tag = MKTAG('U', 'Y', 'V', 'Y');
avpriv_set_pts_info(st, 64, 1, 100); /* 64 bits pts in us */
ctx->video_st=st;
st = avformat_new_stream(avctx, NULL);
if (!st) {
av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
goto error;
}
st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
st->codec->codec_id= AV_CODEC_ID_PCM_S16LE;
st->codec->sample_rate = bmdAudioSampleRate48kHz;
st->codec->channels= 8;
avpriv_set_pts_info(st, 64, 1, 100); /* 64 bits pts in us */
ctx->audio_st=st;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On Fri, Sep 19, 2014 at 8:53 AM, Amnon Israely wrote: >> >> >> What do you think might be the problem here? >> >> > I changed streams order in deckling_dec.cpp > and Video now on 0:0 Video is not guaranteed to be always on 0:0, and therefore you are trying to fix a nonexistent problem here. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
Nicholas Robbins ffmpeg.org> writes:
> +{ "only_dec_forced", "Only decode forced subtitles",
Please use the same option name as for pgs subtitles.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Change deprecated use of _SVID_SOURCE to _DEFAULT_SOURCE
Daniel Bomar gmail.com> writes: > What should be tested in configure? You wrote that compilation fails for you with an error, I originally assumed this can be reproduced with current FFmpeg git head (rereading our mail, I am not so sure). If compilation fails, this can be tested in configure. > IMO take this patch and if it breaks some old > systems (not sure why it would) have a configure > option to revert this on those systems. This does not sound like an acceptable approach to me. If it is really more than unlikely that it breaks old systems, please explain why. From your explanation and without further reading, I would assume that it will break things easily (but I may absolutely be wrong in which case there is no argument against the patch). If the issue is not reproducible with current FFmpeg, I wonder what should be fixed... Please do not top-post here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
On Fri, Sep 19, 2014 at 07:33:26AM -0700, Nicholas Robbins wrote: > Ok, not to beat a dead horse, but I think I've gotten this working. I think > it might work better in lavc/dvdsubdec.c. AFAICT this works and doesn't > produce mangled tracks. Patch at end of email. (Sorry for the inline patch) > If this is a good patch, I'll add the appropriate documentation and do a > proper commit-patch > > > > diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c > index 7355c03..874c28b 100644 > --- a/libavcodec/dvdsubdec.c > +++ b/libavcodec/dvdsubdec.c > @@ -39,6 +39,7 @@ typedef struct DVDSubContext >uint8_t alpha[256]; >uint8_t *buf; >int buf_size; > + int only_dec_forced; > #ifdef DEBUG >int sub_id; > #endif the patch is corrupted, place make sure the stuff you use to send email doesnt mangle patches or attach the patch (which generally fixes these kind of issues) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
On Fri, 19 Sep 2014 07:33:26 -0700
Nicholas Robbins wrote:
> Ok, not to beat a dead horse, but I think I've gotten this working. I think
> it might work better in lavc/dvdsubdec.c. AFAICT this works and doesn't
> produce mangled tracks. Patch at end of email. (Sorry for the inline patch)
> If this is a good patch, I'll add the appropriate documentation and do a
> proper commit-patch
>
>
>
> diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
> index 7355c03..874c28b 100644
> --- a/libavcodec/dvdsubdec.c
> +++ b/libavcodec/dvdsubdec.c
> @@ -39,6 +39,7 @@ typedef struct DVDSubContext
>uint8_t alpha[256];
>uint8_t *buf;
>int buf_size;
> + int only_dec_forced;
> #ifdef DEBUG
>int sub_id;
> #endif
> @@ -548,6 +549,9 @@ static int dvdsub_decode(AVCodecContext *avctx,
> if (!is_menu && find_smallest_bounding_rectangle(sub) == 0)
> goto no_subtitle;
>
> +if (ctx->only_dec_forced && !(sub->rects[0]->flags &
> AV_SUBTITLE_FLAG_FORCED))
> +goto no_subtitle;
> +
> #if defined(DEBUG)
> {
> char ppm_name[32];
> @@ -652,6 +656,7 @@ static av_cold int dvdsub_close(AVCodecContext *avctx)
> #define VD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> { "palette", "set the global palette", OFFSET(palette_str),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
> +{ "only_dec_forced", "Only decode forced subtitles",
> OFFSET(only_dec_forced), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, VD},
> { NULL }
> };
> static const AVClass dvdsub_class = {
Sorry, but didn't the discussion go towards that ffmpeg.c should filter
out subtitles flagged as forced?
And in fact, the PGS decoder should be changed to flag forced subs
correctly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: deprecate internal function that shouldn't be public
On 19/09/14 6:58 AM, Michael Niedermayer wrote: > On Fri, Sep 19, 2014 at 01:50:28AM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> Unlike us, libav got rid of the internal symbols before the header became >> public on >> an actual relase, so we're stuck with it until next bump. >> I renamed the function to ff_ since it's only used outside libavcodec when >> called >> with the public symbol. >> >> doc/APIchanges | 3 +++ >> libavcodec/dv_profile.c | 12 ++-- >> libavcodec/dv_profile.h | 6 ++ >> libavcodec/dv_profile_internal.h | 8 >> libavcodec/dvdec.c | 3 ++- >> libavcodec/version.h | 5 - >> 6 files changed, 33 insertions(+), 4 deletions(-) > > LGTM Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Change deprecated use of _SVID_SOURCE to _DEFAULT_SOURCE
On Fri, 19 Sep 2014 08:19:34 -0500 Daniel Bomar wrote: > What should be tested in configure? IMO take this patch and and if it > breaks some old systems (not sure why it would) have a configure > option to revert this on those systems. I suppose it should test inet_aton, which is apparently why _SVID_SOURCE is needed in the first place. But it's probably not reasonable to demand from you to clean this up, since there's no way knowing which ancient and broken systems may need it and so on. Anyway, why not define both _SVID_SOURCE and _DEFAULT_SOURCE? Could work. From what I understand, the purpose is removing the warning that is printed with recent glibc. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
> On Friday, September 19, 2014 12:31 PM, Carl Eugen Hoyos
> wrote:
> > Nicholas Robbins ffmpeg.org> writes:
>
>> +{ "only_dec_forced", "Only decode forced
> subtitles",
>
> Please use the same option name as for pgs subtitles.
>
> Carl Eugen
Ok, I'll do that. Also I noticed that dvdsubdec.c says:
#define VD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
{ "palette", "set the global palette", OFFSET(palette_str),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD }
While pgssubdec.c says:
#define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
{"forced_subs_only", "Only show forced subtitles",
OFFSET(forced_subs_only), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, SD},
Shouldn't dvdsubdec have SD rather than VD for readability at least?
Also, this requires the option be set by "-forced_subs_only 1". How does one
implement boolean options so I could set it by "-forced_subs_only"?
-Nick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
> On Friday, September 19, 2014 1:15 PM, wm4 wrote: > > Sorry, but didn't the discussion go towards that ffmpeg.c should filter > out subtitles flagged as forced? > > And in fact, the PGS decoder should be changed to flag forced subs > correctly. I've never peeked inside ffmpeg.c so I don't know if I can figure out how to remove the unforced subs there, but if that is the only way to get this patch in, I'll see if I can figure it out. -N ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ffprobe shows errors on ts file
Hi, following file shows a bunch of errors in ffprobe: https://www.dropbox.com/s/04djuv4zn0l4lkx/espn.ts?dl=0 I'm not an expert in decoding that's why I try to ask here. I converted the file to mp4 and used the mp4toannexb filter, then I used h264analyze. You can find the output below: https://www.dropbox.com/s/88r838f5bbb7fs8/h264.log?dl=0 What seems bogus to me is the parameter num_ref_frames=5 in SPS. But GOP is 7 B frames in a row like, IBBBPBBBP...but I don't know if this is a problem at all. ffprobe output: $ ffprobe espn.ts ffprobe version 2.2.4 Copyright (c) 2007-2014 the FFmpeg developers built on Jul 1 2014 17:20:19 with gcc 4.9.0 (GCC) 20140604 (prerelease) configuration: --prefix=/usr --disable-debug --disable-static --enable-avisynth --enable-avresample --enable-decoder=atrac3 --enable-decoder=atrac3p --enable-dxva2 --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-pic --enable-postproc --enable-runtime-cpudetect --enable-shared --enable-swresample --enable-vdpau --enable-version3 --enable-x11grab libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat55. 33.100 / 55. 33.100 libavdevice55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libavresample 1. 2. 0 / 1. 2. 0 libswscale 2. 5.102 / 2. 5.102 libswresample 0. 18.100 / 0. 18.100 libpostproc52. 3.100 / 52. 3.100 [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [mpegts @ 0x17713a0] PES packet size mismatch Last message repeated 1 times [h264 @ 0x1776000] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 0x1776000] decode_slice_header error [h264 @ 0x1776000] no frame! [h264 @ 0x1776000] top block unavailable for requested intra4x4 mode -1 at 1 0 [h264 @ 0x1776000] error while decoding MB 1 0, bytestream 165395 [h264 @ 0x1776000] mmco: unref short failure [h264 @ 0x1776000] number of reference frames (0+6) exceeds max (5; probably corrupt input), discarding one [h264 @ 0x1776000] concealing 3600 DC, 3600 AC, 3600 MV errors in I frame [h264 @ 0x1776000] cabac decode of qscale diff failed at 38 4 [h264 @ 0x1776000] error while decoding MB 38 4, bytestream 3764 [h264 @ 0x1776000] concealing 3291 DC, 3291 AC, 3291 MV errors in B frame [h264 @ 0x1776000] concealing 2981 DC, 2981 AC, 2981 MV errors in B frame [h264 @ 0x1776000] concealing 1704 DC, 1704 AC, 1704 MV errors in B frame [h264 @ 0x1776000] concealing 3345 DC, 3345 AC, 3345 MV errors in B frame [h264 @ 0x1776000] concealing 3097 DC, 3097 AC, 3097 MV errors in B frame [h264 @ 0x1776000] concealing 2967 DC, 2967 AC, 2967 MV errors in B frame [h264 @ 0x1776000] concealing 2420 DC, 2420 AC, 2420 MV errors in B frame [h264 @ 0x1776000] mmco: unref short failure [h264 @ 0x1776000] concealing 3409 DC, 3409 AC, 3409 MV errors in P frame [mpegts @ 0x17713a0] PES packet size mismatch Last message repeated 1 times Input #0, mpegts, from 'espn.ts': Duration: 00:00:10.29, start: 19440.259811, bitrate: 4740 kb/s Program 1 Stream #0:0[0x1023](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:1[0x1022]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc Maybe anyone can shed some light on this? Thanks a lot. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/assdec: output ASS packets
After this the order from the original file is stored through readorder
when doing ffmpeg -i input.ass -c copy output.mkv.
And now that the ASS muxer honors the ReadOrder, extracting the ass back
(without transcoding) restores the original order.
TODO: micro bump
---
libavformat/assdec.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/libavformat/assdec.c b/libavformat/assdec.c
index a5f792a..f176565 100644
--- a/libavformat/assdec.c
+++ b/libavformat/assdec.c
@@ -29,6 +29,7 @@
typedef struct ASSContext {
FFDemuxSubtitlesQueue q;
+unsigned readorder;
} ASSContext;
static int ass_probe(AVProbeData *p)
@@ -52,18 +53,26 @@ static int ass_read_close(AVFormatContext *s)
return 0;
}
-static int read_ts(const uint8_t *p, int64_t *start, int *duration)
+static int read_dialogue(ASSContext *ass, AVBPrint *dst, const uint8_t *p,
+ int64_t *start, int *duration)
{
int64_t end;
+int layer, pos;
int hh1, mm1, ss1, ms1;
int hh2, mm2, ss2, ms2;
-if (sscanf(p, "%*[^,],%d:%d:%d%*c%d,%d:%d:%d%*c%d",
+if (sscanf(p, "Dialogue: %d,%d:%d:%d%*c%d,%d:%d:%d%*c%d,%n", &layer,
&hh1, &mm1, &ss1, &ms1,
- &hh2, &mm2, &ss2, &ms2) == 8) {
+ &hh2, &mm2, &ss2, &ms2, &pos) >= 9) {
end= (hh2*3600LL + mm2*60LL + ss2) * 100LL + ms2;
*start = (hh1*3600LL + mm1*60LL + ss1) * 100LL + ms1;
*duration = end - *start;
+
+av_bprint_clear(dst);
+av_bprintf(dst, "%u,%d,%s", ass->readorder++, layer, p + pos);
+while (dst->str[dst->len - 1] == '\r' ||
+ dst->str[dst->len - 1] == '\n')
+dst->str[--dst->len] = 0;
return 0;
}
return -1;
@@ -88,7 +97,7 @@ static int64_t get_line(AVBPrint *buf, FFTextReader *tr)
static int ass_read_header(AVFormatContext *s)
{
ASSContext *ass = s->priv_data;
-AVBPrint header, line;
+AVBPrint header, line, rline;
int header_remaining, res = 0;
AVStream *st;
FFTextReader tr;
@@ -99,12 +108,13 @@ static int ass_read_header(AVFormatContext *s)
return AVERROR(ENOMEM);
avpriv_set_pts_info(st, 64, 1, 100);
st->codec->codec_type = AVMEDIA_TYPE_SUBTITLE;
-st->codec->codec_id = AV_CODEC_ID_SSA;
+st->codec->codec_id = AV_CODEC_ID_ASS;
header_remaining = INT_MAX;
av_bprint_init(&header, 0, AV_BPRINT_SIZE_UNLIMITED);
av_bprint_init(&line, 0, AV_BPRINT_SIZE_UNLIMITED);
+av_bprint_init(&rline, 0, AV_BPRINT_SIZE_UNLIMITED);
for (;;) {
int64_t pos = get_line(&line, &tr);
@@ -125,9 +135,9 @@ static int ass_read_header(AVFormatContext *s)
int duration = -1;
AVPacket *sub;
-if (read_ts(line.str, &ts_start, &duration) < 0)
+if (read_dialogue(ass, &rline, line.str, &ts_start, &duration) < 0)
continue;
-sub = ff_subtitles_queue_insert(&ass->q, line.str, line.len, 0);
+sub = ff_subtitles_queue_insert(&ass->q, rline.str, rline.len, 0);
if (!sub) {
res = AVERROR(ENOMEM);
goto end;
@@ -139,6 +149,7 @@ static int ass_read_header(AVFormatContext *s)
}
av_bprint_finalize(&line, NULL);
+av_bprint_finalize(&rline, NULL);
res = avpriv_bprint_to_extradata(st->codec, &header);
if (res < 0)
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/assdec: output ASS packets
On Fri, 19 Sep 2014 20:49:49 +0200
Clément Bœsch wrote:
> After this the order from the original file is stored through readorder
> when doing ffmpeg -i input.ass -c copy output.mkv.
>
> And now that the ASS muxer honors the ReadOrder, extracting the ass back
> (without transcoding) restores the original order.
>
> TODO: micro bump
> ---
> libavformat/assdec.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/assdec.c b/libavformat/assdec.c
> index a5f792a..f176565 100644
> --- a/libavformat/assdec.c
> +++ b/libavformat/assdec.c
> @@ -29,6 +29,7 @@
>
> typedef struct ASSContext {
> FFDemuxSubtitlesQueue q;
> +unsigned readorder;
> } ASSContext;
>
> static int ass_probe(AVProbeData *p)
> @@ -52,18 +53,26 @@ static int ass_read_close(AVFormatContext *s)
> return 0;
> }
>
> -static int read_ts(const uint8_t *p, int64_t *start, int *duration)
> +static int read_dialogue(ASSContext *ass, AVBPrint *dst, const uint8_t *p,
> + int64_t *start, int *duration)
> {
> int64_t end;
> +int layer, pos;
> int hh1, mm1, ss1, ms1;
> int hh2, mm2, ss2, ms2;
>
> -if (sscanf(p, "%*[^,],%d:%d:%d%*c%d,%d:%d:%d%*c%d",
> +if (sscanf(p, "Dialogue: %d,%d:%d:%d%*c%d,%d:%d:%d%*c%d,%n", &layer,
What about "Comment: " lines?
> &hh1, &mm1, &ss1, &ms1,
> - &hh2, &mm2, &ss2, &ms2) == 8) {
> + &hh2, &mm2, &ss2, &ms2, &pos) >= 9) {
> end= (hh2*3600LL + mm2*60LL + ss2) * 100LL + ms2;
> *start = (hh1*3600LL + mm1*60LL + ss1) * 100LL + ms1;
> *duration = end - *start;
> +
> +av_bprint_clear(dst);
> +av_bprintf(dst, "%u,%d,%s", ass->readorder++, layer, p + pos);
> +while (dst->str[dst->len - 1] == '\r' ||
> + dst->str[dst->len - 1] == '\n')
> +dst->str[--dst->len] = 0;
> return 0;
> }
> return -1;
> @@ -88,7 +97,7 @@ static int64_t get_line(AVBPrint *buf, FFTextReader *tr)
> static int ass_read_header(AVFormatContext *s)
> {
> ASSContext *ass = s->priv_data;
> -AVBPrint header, line;
> +AVBPrint header, line, rline;
> int header_remaining, res = 0;
> AVStream *st;
> FFTextReader tr;
> @@ -99,12 +108,13 @@ static int ass_read_header(AVFormatContext *s)
> return AVERROR(ENOMEM);
> avpriv_set_pts_info(st, 64, 1, 100);
> st->codec->codec_type = AVMEDIA_TYPE_SUBTITLE;
> -st->codec->codec_id = AV_CODEC_ID_SSA;
> +st->codec->codec_id = AV_CODEC_ID_ASS;
>
> header_remaining = INT_MAX;
>
> av_bprint_init(&header, 0, AV_BPRINT_SIZE_UNLIMITED);
> av_bprint_init(&line, 0, AV_BPRINT_SIZE_UNLIMITED);
> +av_bprint_init(&rline, 0, AV_BPRINT_SIZE_UNLIMITED);
>
> for (;;) {
> int64_t pos = get_line(&line, &tr);
> @@ -125,9 +135,9 @@ static int ass_read_header(AVFormatContext *s)
> int duration = -1;
> AVPacket *sub;
>
> -if (read_ts(line.str, &ts_start, &duration) < 0)
> +if (read_dialogue(ass, &rline, line.str, &ts_start, &duration) <
> 0)
> continue;
> -sub = ff_subtitles_queue_insert(&ass->q, line.str, line.len, 0);
> +sub = ff_subtitles_queue_insert(&ass->q, rline.str, rline.len,
> 0);
> if (!sub) {
> res = AVERROR(ENOMEM);
> goto end;
> @@ -139,6 +149,7 @@ static int ass_read_header(AVFormatContext *s)
> }
>
> av_bprint_finalize(&line, NULL);
> +av_bprint_finalize(&rline, NULL);
>
> res = avpriv_bprint_to_extradata(st->codec, &header);
> if (res < 0)
Otherwise LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/assdec: output ASS packets
On Fri, Sep 19, 2014 at 09:00:28PM +0200, wm4 wrote:
> On Fri, 19 Sep 2014 20:49:49 +0200
> Clément Bœsch wrote:
>
> > After this the order from the original file is stored through readorder
> > when doing ffmpeg -i input.ass -c copy output.mkv.
> >
> > And now that the ASS muxer honors the ReadOrder, extracting the ass back
> > (without transcoding) restores the original order.
> >
> > TODO: micro bump
> > ---
> > libavformat/assdec.c | 25 ++---
> > 1 file changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavformat/assdec.c b/libavformat/assdec.c
> > index a5f792a..f176565 100644
> > --- a/libavformat/assdec.c
> > +++ b/libavformat/assdec.c
> > @@ -29,6 +29,7 @@
> >
> > typedef struct ASSContext {
> > FFDemuxSubtitlesQueue q;
> > +unsigned readorder;
> > } ASSContext;
> >
> > static int ass_probe(AVProbeData *p)
> > @@ -52,18 +53,26 @@ static int ass_read_close(AVFormatContext *s)
> > return 0;
> > }
> >
> > -static int read_ts(const uint8_t *p, int64_t *start, int *duration)
> > +static int read_dialogue(ASSContext *ass, AVBPrint *dst, const uint8_t *p,
> > + int64_t *start, int *duration)
> > {
> > int64_t end;
> > +int layer, pos;
> > int hh1, mm1, ss1, ms1;
> > int hh2, mm2, ss2, ms2;
> >
> > -if (sscanf(p, "%*[^,],%d:%d:%d%*c%d,%d:%d:%d%*c%d",
> > +if (sscanf(p, "Dialogue: %d,%d:%d:%d%*c%d,%d:%d:%d%*c%d,%n", &layer,
>
> What about "Comment: " lines?
>
We can't store them in ASS. ASS only assume Dialogue lines. You definitely
don't want Comments to appear as Dialogue.
One way of exporting them could be side data.
[...]
--
Clément B.
pgpN8q1Q855Ap.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Only decode forced subtitle entries from dvdsub track.
Signed-off-by: Nicholas Robbins
---
libavcodec/dvdsubdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 7355c03..de1ecbf 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -39,6 +39,7 @@ typedef struct DVDSubContext
uint8_t alpha[256];
uint8_t *buf;
int buf_size;
+ int forced_subs_only;
#ifdef DEBUG
int sub_id;
#endif
@@ -548,6 +549,9 @@ static int dvdsub_decode(AVCodecContext *avctx,
if (!is_menu && find_smallest_bounding_rectangle(sub) == 0)
goto no_subtitle;
+if (ctx->forced_subs_only && !(sub->rects[0]->flags &
AV_SUBTITLE_FLAG_FORCED))
+goto no_subtitle;
+
#if defined(DEBUG)
{
char ppm_name[32];
@@ -652,6 +656,7 @@ static av_cold int dvdsub_close(AVCodecContext *avctx)
#define VD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
{ "palette", "set the global palette", OFFSET(palette_str),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
+{ "forced_subs_only", "Only show forced subtitles",
OFFSET(forced_subs_only), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, VD},
{ NULL }
};
static const AVClass dvdsub_class = {
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add _DEFAULT_SOURCE to hide warning about _SVID_SOURCE depreciation
As suggested, this just adds _DEFAULT_SOURCE while preserving _SVID_SOURCE for whatever old systems still need it. Signed-off-by: Daniel Bomar --- libavformat/os_support.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/os_support.c b/libavformat/os_support.c index e8f063a..f9d6eea 100644 --- a/libavformat/os_support.c +++ b/libavformat/os_support.c @@ -21,6 +21,7 @@ */ /* needed by inet_aton() */ +#define _DEFAULT_SOURCE #define _SVID_SOURCE #include "config.h" -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
Also add mmxext versions of vsad8 and vsad_intra8, and sse2 versions of vsad16 and vsad_intra16. Since vsad8 and vsad16 are not bitexact, they are accordingly marked as approximate. Signed-off-by: James Almer --- Unrelated to this patch, but this simd implementation of vsad is *far* from approximate. Here's an excerpt of the output from motion-test.c (modified to use vsad and ignore the bitexact flag). mmx2 for 16x16 pixels testing 'vsad' error: mmx=9867 c=12871 error: mmx=9654 c=11976 error: mmx=9399 c=12579 error: mmx=11566 c=14152 error: mmx=9751 c=13461 In contrast, sad_xy2 (also approximate) is off by 1 or 2, not 3000. libavcodec/x86/me_cmp.asm| 161 +++ libavcodec/x86/me_cmp_init.c | 133 ++- 2 files changed, 181 insertions(+), 113 deletions(-) diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm index b657642..4c17cd4 100644 --- a/libavcodec/x86/me_cmp.asm +++ b/libavcodec/x86/me_cmp.asm @@ -25,6 +25,7 @@ SECTION_RODATA +pb_127: times 16 db 0x7f cextern pb_1 SECTION .text @@ -772,3 +773,163 @@ SAD_APPROX_XY2 8 SAD_APPROX_XY2 16 INIT_XMM sse2 SAD_APPROX_XY2 16 + +; +;int ff_vsad_intra(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, +; int line_size, int h); +; +; %1 = 8/16 +%macro VSAD_INTRA 1 +cglobal vsad_intra%1, 5, 5, 3, v, pix1, pix2, lsize, h +mova m0, [pix1q] +%if %1 == mmsize +mova m2, [pix1q+lsizeq] +psadbwm0, m2 +%else +mova m2, [pix1q+lsizeq] +mova m3, [pix1q+8] +mova m4, [pix1q+lsizeq+8] +psadbwm0, m2 +psadbwm3, m4 +paddw m0, m3 +%endif +sub hd, 2 + +.loop +leapix1q, [pix1q + 2*lsizeq] +%if %1 == mmsize +mova m1, [pix1q] +psadbwm2, m1 +paddw m0, m2 +mova m2, [pix1q+lsizeq] +psadbwm1, m2 +paddw m0, m1 +%else +mova m1, [pix1q] +mova m3, [pix1q+8] +psadbwm2, m1 +psadbwm4, m3 +paddw m0, m2 +paddw m0, m4 +mova m2, [pix1q+lsizeq] +mova m4, [pix1q+lsizeq+8] +psadbwm1, m2 +psadbwm3, m4 +paddw m0, m1 +paddw m0, m3 +%endif +sub hd, 2 +jg .loop + +%if mmsize == 16 +pshufd m1, m0, 0xe +paddd m0, m1 +%endif +movd eax, m0 +RET +%endmacro + +INIT_MMX mmxext +VSAD_INTRA 8 +VSAD_INTRA 16 +INIT_XMM sse2 +VSAD_INTRA 16 + +;- +;int ff_vsad_approx(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, +; int line_size, int h); +;- +; %1 = 8/16 +%macro VSAD_APPROX 1 +cglobal vsad%1_approx, 5, 5, 5, v, pix1, pix2, lsize, h +mova m1, [pb_127] +mova m0, [pix1q] +%if %1 == mmsize ; vsad8_mmx, vsad16_sse2 +mova m4, [pix1q+lsizeq] +%if mmsize == 16 +movu m3, [pix2q] +movu m2, [pix2q+lsizeq] +psubb m0, m3 +psubb m4, m2 +%else +psubb m0, [pix2q] +psubb m4, [pix2q+lsizeq] +%endif +pxor m0, m1 +pxor m4, m1 +psadbw m0, m4 +%else ; vsad16_mmxext +mova m3, [pix1q+8] +psubb m0, [pix2q] +psubb m3, [pix2q+8] +pxor m0, m1 +pxor m3, m1 +mova m4, [pix1q+lsizeq] +mova m5, [pix1q+lsizeq+8] +psubb m4, [pix2q+lsizeq] +psubb m5, [pix2q+lsizeq+8] +pxor m4, m1 +pxor m5, m1 +psadbw m0, m4 +psadbw m3, m5 +paddw m0, m3 +%endif +subhd, 2 + +.loop +lea pix1q, [pix1q + 2*lsizeq] +lea pix2q, [pix2q + 2*lsizeq] +mova m2, [pix1q] +%if %1 == mmsize ; vsad8_mmx, vsad16_sse2 +%if mmsize == 16 +movu m3, [pix2q] +psubb m2, m3 +%else +psubb m2, [pix2q] +%endif +pxor m2, m1 +psadbw m4, m2 +paddw m0, m4 +mova m4, [pix1q+lsizeq] +movu m3, [pix2q+lsizeq] +psubb m4, m3 +pxor m4, m1 +psadbw m2, m4 +paddw m0, m2 +%else ; vsad16_mmxext +mova m3, [pix1q+8] +psubb m2, [pix2q] +psubb m3, [pix2q+8] +pxor m2, m1 +pxor m3, m1 +psadbw m4, m2 +psadbw m5, m3 +paddw m0, m4 +paddw m0, m5 +mova m4, [pix1q+lsizeq] +mova m5, [pix1q+lsizeq+8] +psubb m4, [pix2q+lsizeq] +psubb m5, [pix2q+lsizeq+8] +pxor m4, m1 +pxor m5, m1 +psadbw m2, m4 +psadbw m3, m5 +paddw m0, m2 +paddw m0, m3 +%endif +subhd, 2 +jg .loop + +%if mmsize == 16 +pshufd m1, m0, 0xe +paddd m0, m1 +%endif +movd eax, m0 +RET +%endmacro + +INIT_MMX mmxext +VSAD_APPROX 8 +VSAD_APPROX 16 +INIT_XMM sse2 +VSAD_APPROX 16 diff --git a/libavcodec/x86/me_cmp_init.c b/libavcodec/x86/me_cmp_init.c index cb47d63..6dc59f5 100644 --- a/libavcodec/x86/me_cmp_init.c +++ b/libavcodec/x86/me_cmp_init.c
Re: [FFmpeg-devel] [PATCH] Add _DEFAULT_SOURCE to hide warning about _SVID_SOURCE depreciation
On Fri, Sep 19, 2014 at 02:56:00PM -0500, Daniel Bomar wrote: > As suggested, this just adds _DEFAULT_SOURCE while preserving > _SVID_SOURCE for whatever old systems still need it. > > Signed-off-by: Daniel Bomar > --- > libavformat/os_support.c | 1 + > 1 file changed, 1 insertion(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
On Fri, Sep 19, 2014 at 05:04:49PM -0300, James Almer wrote: > Also add mmxext versions of vsad8 and vsad_intra8, and sse2 versions of > vsad16 and vsad_intra16. > Since vsad8 and vsad16 are not bitexact, they are accordingly marked as > approximate. > > Signed-off-by: James Almer > --- > Unrelated to this patch, but this simd implementation of vsad is *far* > from approximate. > Here's an excerpt of the output from motion-test.c (modified to use vsad > and ignore the bitexact flag). > > mmx2 for 16x16 pixels > testing 'vsad' > error: mmx=9867 c=12871 > error: mmx=9654 c=11976 > error: mmx=9399 c=12579 > error: mmx=11566 c=14152 > error: mmx=9751 c=13461 it would be more interresting with real world data, vsad isnt even a motion estimation function, its used to detect interlaced areas [...] > +;- > +;int ff_vsad_approx(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, > +; int line_size, int h); > +;- > +; %1 = 8/16 > +%macro VSAD_APPROX 1 > +cglobal vsad%1_approx, 5, 5, 5, v, pix1, pix2, lsize, h > +mova m1, [pb_127] isnt this supposed to be 128 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
On 19/09/14 6:41 PM, Michael Niedermayer wrote: >> +mova m1, [pb_127] > isnt this supposed to be 128 ? Yes, will send a fixed version in a moment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
Also add mmxext versions of vsad8 and vsad_intra8, and sse2 versions of vsad16 and vsad_intra16. Since vsad8 and vsad16 are not bitexact, they are accordingly marked as approximate. Signed-off-by: James Almer --- libavcodec/x86/me_cmp.asm| 161 +++ libavcodec/x86/me_cmp_init.c | 133 ++- 2 files changed, 181 insertions(+), 113 deletions(-) diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm index b657642..95b99c4 100644 --- a/libavcodec/x86/me_cmp.asm +++ b/libavcodec/x86/me_cmp.asm @@ -26,6 +26,7 @@ SECTION_RODATA cextern pb_1 +cextern pb_80 SECTION .text @@ -772,3 +773,163 @@ SAD_APPROX_XY2 8 SAD_APPROX_XY2 16 INIT_XMM sse2 SAD_APPROX_XY2 16 + +; +;int ff_vsad_intra(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, +; int line_size, int h); +; +; %1 = 8/16 +%macro VSAD_INTRA 1 +cglobal vsad_intra%1, 5, 5, 3, v, pix1, pix2, lsize, h +mova m0, [pix1q] +%if %1 == mmsize +mova m2, [pix1q+lsizeq] +psadbwm0, m2 +%else +mova m2, [pix1q+lsizeq] +mova m3, [pix1q+8] +mova m4, [pix1q+lsizeq+8] +psadbwm0, m2 +psadbwm3, m4 +paddw m0, m3 +%endif +sub hd, 2 + +.loop +leapix1q, [pix1q + 2*lsizeq] +%if %1 == mmsize +mova m1, [pix1q] +psadbwm2, m1 +paddw m0, m2 +mova m2, [pix1q+lsizeq] +psadbwm1, m2 +paddw m0, m1 +%else +mova m1, [pix1q] +mova m3, [pix1q+8] +psadbwm2, m1 +psadbwm4, m3 +paddw m0, m2 +paddw m0, m4 +mova m2, [pix1q+lsizeq] +mova m4, [pix1q+lsizeq+8] +psadbwm1, m2 +psadbwm3, m4 +paddw m0, m1 +paddw m0, m3 +%endif +sub hd, 2 +jg .loop + +%if mmsize == 16 +pshufd m1, m0, 0xe +paddd m0, m1 +%endif +movd eax, m0 +RET +%endmacro + +INIT_MMX mmxext +VSAD_INTRA 8 +VSAD_INTRA 16 +INIT_XMM sse2 +VSAD_INTRA 16 + +;- +;int ff_vsad_approx(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, +; int line_size, int h); +;- +; %1 = 8/16 +%macro VSAD_APPROX 1 +cglobal vsad%1_approx, 5, 5, 5, v, pix1, pix2, lsize, h +mova m1, [pb_80] +mova m0, [pix1q] +%if %1 == mmsize ; vsad8_mmxext, vsad16_sse2 +mova m4, [pix1q+lsizeq] +%if mmsize == 16 +movu m3, [pix2q] +movu m2, [pix2q+lsizeq] +psubb m0, m3 +psubb m4, m2 +%else +psubb m0, [pix2q] +psubb m4, [pix2q+lsizeq] +%endif +pxor m0, m1 +pxor m4, m1 +psadbw m0, m4 +%else ; vsad16_mmxext +mova m3, [pix1q+8] +psubb m0, [pix2q] +psubb m3, [pix2q+8] +pxor m0, m1 +pxor m3, m1 +mova m4, [pix1q+lsizeq] +mova m5, [pix1q+lsizeq+8] +psubb m4, [pix2q+lsizeq] +psubb m5, [pix2q+lsizeq+8] +pxor m4, m1 +pxor m5, m1 +psadbw m0, m4 +psadbw m3, m5 +paddw m0, m3 +%endif +subhd, 2 + +.loop +lea pix1q, [pix1q + 2*lsizeq] +lea pix2q, [pix2q + 2*lsizeq] +mova m2, [pix1q] +%if %1 == mmsize ; vsad8_mmxext, vsad16_sse2 +%if mmsize == 16 +movu m3, [pix2q] +psubb m2, m3 +%else +psubb m2, [pix2q] +%endif +pxor m2, m1 +psadbw m4, m2 +paddw m0, m4 +mova m4, [pix1q+lsizeq] +movu m3, [pix2q+lsizeq] +psubb m4, m3 +pxor m4, m1 +psadbw m2, m4 +paddw m0, m2 +%else ; vsad16_mmxext +mova m3, [pix1q+8] +psubb m2, [pix2q] +psubb m3, [pix2q+8] +pxor m2, m1 +pxor m3, m1 +psadbw m4, m2 +psadbw m5, m3 +paddw m0, m4 +paddw m0, m5 +mova m4, [pix1q+lsizeq] +mova m5, [pix1q+lsizeq+8] +psubb m4, [pix2q+lsizeq] +psubb m5, [pix2q+lsizeq+8] +pxor m4, m1 +pxor m5, m1 +psadbw m2, m4 +psadbw m3, m5 +paddw m0, m2 +paddw m0, m3 +%endif +subhd, 2 +jg .loop + +%if mmsize == 16 +pshufd m1, m0, 0xe +paddd m0, m1 +%endif +movd eax, m0 +RET +%endmacro + +INIT_MMX mmxext +VSAD_APPROX 8 +VSAD_APPROX 16 +INIT_XMM sse2 +VSAD_APPROX 16 diff --git a/libavcodec/x86/me_cmp_init.c b/libavcodec/x86/me_cmp_init.c index cb47d63..6dc59f5 100644 --- a/libavcodec/x86/me_cmp_init.c +++ b/libavcodec/x86/me_cmp_init.c @@ -65,6 +65,18 @@ int ff_sad16_approx_xy2_mmxext(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int stride, int h); int ff_sad16_approx_xy2_sse2(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int stride, int h); +int ff_vsad_intra8_mmxext(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, + int line_size, int h); +int ff_vsad_intra16_mm
Re: [FFmpeg-devel] [patch] Only decode forced dvd-subtitles
On Fri, Sep 19, 2014 at 10:57:41AM -0700, Nicholas Robbins wrote:
> > On Friday, September 19, 2014 12:31 PM, Carl Eugen Hoyos
> > wrote:
>
>
>
>
> > > Nicholas Robbins ffmpeg.org> writes:
> >
> >> +{ "only_dec_forced", "Only decode forced
> > subtitles",
> >
> > Please use the same option name as for pgs subtitles.
> >
> > Carl Eugen
>
>
> Ok, I'll do that. Also I noticed that dvdsubdec.c says:
>
> #define VD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> { "palette", "set the global palette", OFFSET(palette_str),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD }
>
> While pgssubdec.c says:
>
> #define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> {"forced_subs_only", "Only show forced subtitles",
> OFFSET(forced_subs_only), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, SD},
>
> Shouldn't dvdsubdec have SD rather than VD for readability at least?
fixed
>
> Also, this requires the option be set by "-forced_subs_only 1". How does one
> implement boolean options so I could set it by "-forced_subs_only"?
thats currently not supported through AVOptions with FFmpeg.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
On Fri, Sep 19, 2014 at 07:18:10PM -0300, James Almer wrote: > Also add mmxext versions of vsad8 and vsad_intra8, and sse2 versions of > vsad16 and vsad_intra16. > Since vsad8 and vsad16 are not bitexact, they are accordingly marked as > approximate. > > Signed-off-by: James Almer > --- > libavcodec/x86/me_cmp.asm| 161 > +++ > libavcodec/x86/me_cmp_init.c | 133 ++- > 2 files changed, 181 insertions(+), 113 deletions(-) should be ok if the new code produces the same values as the old [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffprobe shows errors on ts file
On Fri, Sep 19, 2014 at 08:23:34PM +0200, airwolf wrote: > Hi, > > following file shows a bunch of errors in ffprobe: > https://www.dropbox.com/s/04djuv4zn0l4lkx/espn.ts?dl=0 > > I'm not an expert in decoding that's why I try to ask here. > I converted the file to mp4 and used the mp4toannexb filter, then I > used h264analyze. > You can find the output below: > https://www.dropbox.com/s/88r838f5bbb7fs8/h264.log?dl=0 Is there some decoder/player that can play this better ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext vsad functions to yasm
On 19/09/14 8:24 PM, Michael Niedermayer wrote: > On Fri, Sep 19, 2014 at 07:18:10PM -0300, James Almer wrote: >> Also add mmxext versions of vsad8 and vsad_intra8, and sse2 versions of >> vsad16 and vsad_intra16. >> Since vsad8 and vsad16 are not bitexact, they are accordingly marked as >> approximate. >> >> Signed-off-by: James Almer >> --- >> libavcodec/x86/me_cmp.asm| 161 >> +++ >> libavcodec/x86/me_cmp_init.c | 133 ++- >> 2 files changed, 181 insertions(+), 113 deletions(-) > > should be ok if the new code produces the same values as the old It does as far as i could test. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
