[Ffmpeg-devel-irc] ffmpeg-devel.log.20141130

[burek]

[00:01] <cone-428> ffmpeg.git 03Neil Birkbeck 07master:e4788e9cd987: avfilter/vf_yadif: fix extra leading dup frame when deint=1
[01:48] <kurosu> err, didn't expect git send-email to do that... 
[01:54] <iive> you didn't expect that it would actually send an email?
[01:55] <kurosu> no that it would cc: people beside me
[01:56] <rcombs> it auto-cc's a bunch of relevant people if you don't tell it not to
[01:57] <rcombs> the man page explains it
[01:57] <kurosu> yeah, I've set suppresscc to all
[01:57] <kurosu> not even sure I had benefit in receiving it
[02:05] <cone-428> ffmpeg.git 03Michael Niedermayer 07master:e74f2be1edde: avformat/riffdec: ask for samples with wav header size < 14
[02:11] <cehoyos> kurosu: Sorry for the unhelpful review, but please let's not commit patches that break compilation.
[02:12] <rcombs> \o/
[02:15] <kierank> hmmm 302m should be planar
[03:06] <kierank> is this not allowed in C? const uint32_t **samples = (uint32_t **)frame->data;
[03:43] <BBB> kierank I dont see why not, unless frame->data itself is const
[04:27] <cone-428> ffmpeg.git 03Christophe Gisquet 07master:6a2bfd52e50b: h264_ps: move and export aspect_ratio
[09:38] <rcombs> cehoyos: that ticket interests me, because it could relate to the concept of having a full GPU decode->filter->encode pipeline
[09:39] <rcombs> cehoyos: e.g. if instead of moving the CVImageBuffer data from VDA (or VideoToolbox) into an AVFrame, we left it in the native structures as long as possible
[09:59] <cehoyos> rcombs: This is one of those tickets "I wish FFmpeg would be a Formula One car" that I don't like but if you think it makes sense please work on it!
[10:01] <wm4> rcombs: you can already receive raw vda images
[10:02] <wm4> we considered using coreimage in mpv, but apparently it was completely useless
[10:03] <rcombs> wm4: oh? How so?
[10:04] <rcombs> (as in, what made it useless?)
[10:05] <wm4> as in nothing of value
[10:06] <rcombs> oh, no filters worth using?
[10:06] <wm4> although now I'm wondering if they at least expose a good deinterlacer
[10:06] <rcombs> I'm pretty sure it can at least convert between pixel formats and do scaling, which would be useful for ffmpeg
[10:08] <rcombs> it can also definitely do image overlays with alpha masks
[10:13] <wm4> oh is that the ffmpeg.c perspective again
[10:13] <rcombs> yeah
[10:15] <rcombs> in a simple case of decode(H.264)->deinterlace->scale->burn subtitles->encode(H.264) on OS X (with VT/CI/CV) or Linux (with VAAPI or VDPAU and whatever else is useful there), it'd be very nice to have all of those operations done with buffers staying on the GPU the whole time
[10:18] <wm4> rcombs: sounds like that would be a pain, and the output crap
[10:19] <rcombs> probably could compare well to e.g. x264 veryfast, though, particularly on lower-end CPUs
[10:20] <cehoyos> VDPAI does not support encoding, are you sure VA-API does?
[10:20] <rcombs> (and might save power)
[10:20] <rcombs> cehoyos: quite certain
[10:20] <rcombs> cehoyos: as I have a not-quite-finished VAAPI-based ffmpeg H.264 encoder laying around here
[10:20] <cehoyos> I mean: If there is a driver that supports VA-API and encoding?
[10:21] <rcombs> (based on the reference code from libva)
[10:21] <rcombs> my Haswell i5 supports it
[10:21] <cehoyos> (Actually I should probably ask: Is there a driver that supports VA-API encoding and beats x264 ultrafast on any hardware?)
[10:21] <rcombs> now that I'm not sure of; I haven't done detailed performance comparisons
[10:22] <cehoyos> Anyway: All this dicussion is fruitless, just send your patch!
[10:22] <nevcairiel> on low end systems it can easily beat ultrafast in speed
[10:22] <nevcairiel> but even on highend there is a distinct advantage of keeping the CPU free to do other things
[10:22] <rcombs> "not quite finished" == "gives H.264 output that plays, but seems to screw up either timestamps or ref frames or something like that; the output stutters and jumps back and forth"
[10:22] <cehoyos> I meant quality but even speed surprises me: I thought the low-end systems have slow GPUs.
[10:23] <nevcairiel> recent GPUs have fixed function encoders
[10:23] <nevcairiel> ie. gpu speed is no factor
[10:23] <cehoyos> I know but I thought slow CPUs get slow GPUs
[10:23] <cehoyos> But if GPU speed is really no factor...
[10:27] <kurosu> cehoyos, ok about squashing the patches - I just wanted to try to separate authorship cleanly
[10:27] <kurosu> the original author has gone silent it seems (though no mail was rejected by the server so the address is valid)
[10:31] <cehoyos> kurosu: I may have mxed up what you meant with "next patch" in your mail, I just wanted to say that I agree with your reasoning but we try not to commit / merge code that doesn't compile.
[10:31] <kurosu> the "next" patch just removes a duplicated enum declaration (that is already in h264.h)
[10:31] <cehoyos> (I was thinking of 6/6 but I suspect that wasn't what you meant.)
[10:32] <cehoyos> That was the one I was answering, it cannot be "next"
[10:32] <cehoyos> ;-)
[10:32] <kurosu> This is 4/6, so previous is 3/6 (adding the filter) and 5/6 is removing the duplication
[10:32] <cehoyos> But it appears we agree.
[10:32] <kurosu> next is 5/6
[10:32] <kurosu> yeah, whatever
[10:33] <cehoyos> No, 4/6 is removing the duplication afaict.
[10:33] <kurosu> I mean, whatever = it's no big deal
[10:33] <kurosu> [PATCH 4/6] h264_changesps_bsf: fix compilation
[10:33] <kurosu> but really, yes, the point is we understood each other
[10:35] <kurosu> cehoyos, reading your mail, you're in favor of just fixing compilation for the original patch ?
[10:35] <kurosu> again, compilation was broken because the original author hacked the code to export the sps in an unclean fashion (requiring h264_ps being build but not modifying the build system)
[10:36] <kurosu> *export the aspect ratio
[10:36] <kurosu> so a separate patch was made for this and committed by Michael
[10:37] <kurosu> I think though the "build fix" is just "follow the author's intent" without actually changing the code much
[10:57] <cehoyos> My suggestion was: "Please merge 4/6 into 3/6"
[11:37] <cone-481> ffmpeg.git 03Michael Niedermayer 07master:2fbb9e647cf4: avcodec/wma: Use avpriv_float_dsp_alloc()
[11:37] <cone-481> ffmpeg.git 03Michael Niedermayer 07master:1aca990bd9e3: avcodec/libmp3lame: Use avpriv_float_dsp_alloc()
[11:37] <cone-481> ffmpeg.git 03Michael Niedermayer 07master:93f959b672b1: avcodec/atrac3: Use avpriv_float_dsp_alloc()
[12:54] <cone-481> ffmpeg.git 03Michael Niedermayer 07master:6b0ab561d019: avcodec/adxenc: match prediction used in the decoder
[13:04] <cone-481> ffmpeg.git 03Michael Niedermayer 07master:0b5adc352008: avcodec/adxenc: fix rounding
[13:20] <cehoyos> Wow, the usecase for changing SPS must be incredibly difficult to understand...
[13:23] <kierank> changing aspect ratio
[13:25] <cehoyos> And adding or removing cropping
[13:42] <kurosu> and fixing buggy hardware encoders that will never get fixed, or just letting the user shoot itself in the foot if he wishes so
[13:42] <kurosu> in my case I want to add cropping to a personal VHS capture, the tape having been destroyed
[13:43] <kierank> kurosu: what parameter would you need to correct?
[13:48] <cone-481> ffmpeg.git 03Christophe Gisquet 07master:4c592c39087a: ffmpeg: take bsf arguments from the command line
[13:52] <cehoyos> kurosu: Of course, looking at the patch there are actually even more useful features, I was just wondering that not everybody seems to understand.
[13:53] <kurosu> kierank, add cropping that was never added by my father (poor him, he doesn't even know what a sps is)
[13:53] <kurosu> cehoyos, my point, but I don't want to be confrontational
[13:55] <cehoyos> So I should read the email as being constructive? Hmm, I'll try my best.
[14:03] <Daemon404> cehoyos,  http://www.privatepaste.com/e758b97257
[14:06] <cehoyos> Thank you!
[14:07] <cehoyos> I would have preferred the solution chosen for mkv that prevents writing such files but if you prefer this one, I can definitely live with it.
[14:08] <cehoyos> btw: You need "--disable-mms --disable-sse" iirc to get a C-only build.
[14:08] <cehoyos> (--disable-asm never did what everybody believes it does.)
[14:09] <cehoyos> s/mms/mmx
[14:10] <cehoyos> --disable-mmx is sufficient to disable sse, but it probably still uses some hand-optimized asm.
[14:10] <Daemon404> its not my build
[14:10] <cehoyos> Understood.
[14:52] <koda> cehoyos: btw feel free to ask me directly next time, no reason to bother Daemon404 for that
[14:53] <koda> cehoyos: also the config line is taken from the one i use for libav, where it does what people expect
[15:37] <cehoyos> Please avoid claiming nonsense here (my description of the issue above wasn't accurate, but that doesn't make it less true).
[16:03] <koda> cehoyos: sorry your nonsense does not apply here, doublecheck your claims
[16:03] <koda> also my first point still stands
[16:07] <cehoyos> So when running ./configure --disable-asm, you don't get "#define HAVE_INLINE_ASM 1"?
[16:08] <cehoyos> What is your first point? Derek was here when I asked about the sample for the first time and he said he will forward the question.
[16:12] <koda> never mind..
[18:26] <cone-411> ffmpeg.git 03Reinhard Tartler 07master:0f257e29c552: Treat all '*.pnm' files as non-text file
[18:26] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:79440651149c: Merge commit '0f257e29c5520b215e573e7e3abde8e5a4743309'
[19:22] <cone-411> ffmpeg.git 03Reinhard Tartler 07master:8895bf7b7865: Replace lena.pnm
[19:22] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:d828b0814302: Merge commit '8895bf7b78650c0c21c88cec0484e138ec511a4b'
[19:22] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:21c0c0f9d4a1: LICENSE.md: Add tests/reference.pnm
[21:40] <cone-411> ffmpeg.git 03Michael Stypa 07release/2.4:9984d492dc51: fix Makefile objects for pulseaudio support
[21:40] <cone-411> ffmpeg.git 03Dave Yeo 07release/2.4:89b52d25b4b8: libavutil/thread.h: Support OS/2 threads
[21:40] <cone-411> ffmpeg.git 03Dave Yeo 07release/2.4:d48e0aed3c17: libavutil/threads.h: correct an include to be local
[21:58] <cone-411> ffmpeg.git 03Carl Eugen Hoyos 07release/2.4:2719ba9ee35f: lavc/utils: Make pix_fmt desc pointer const.
[21:58] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:f7e9fcda2df1: avcodec/options_table fix min of audio channels and sample rate
[21:58] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:11dfd1fa20fa: avcodec/utvideodec: fix assumtation that slice_height >= 1
[21:59] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:cfda2a677c25: avcodec/wmaprodec: Fix integer overflow in sfb_offsets initialization
[21:59] <cone-411> ffmpeg.git 03Lukasz Marek 07release/2.4:cf8b91a28e93: lavu/opt: fix av_opt_get function
[21:59] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:a3fdc0b35bd7: avcodec/mpeg4video_parser: fix spurious extradata parse warnings
[21:59] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:3bb48296ef0f: avformat/hlsenc: Free context after hls_append_segment
[21:59] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:2abc6e930ba1: doc/APIchanges: Fix some wrong versions
[21:59] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:af0a95ee033b: swscale/x86/rgb2rgb_template: handle the first 2 lines with C in rgb24toyv12_*()
[22:05] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:5c2d8bbffa21: update for 2.4.4
[22:15] <ubitux> damn gegl is using ffmpeg
[22:15] <ubitux> GEGL-geglmodule.c-Message: Module '/usr/lib/gegl-0.2/ff-load.so' load error: /usr/lib/gegl-0.2/ff-load.so: undefined symbol: av_read_packe
[22:15] <ubitux> +t
[22:16] <ubitux> or i should say it's trying
[22:19] <jamrial> michaelni: maybe backport b546023b to 2.4?
[22:42] <cone-411> ffmpeg.git 03Kieran Kunhya 07release/2.4:6f580e87350c: swscale: fix yuv2yuvX_8 assembly on x86
[22:42] <michaelni> jamrial, backported
[23:20] <cone-411> ffmpeg.git 03Mark Reid 07master:e5d217f04899: libavformat/mxfdec.c: initial support for EssenceGroups
[23:34] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:8653419e9d16: avformat/mxfdec: Reset structural_components_count when allocation fails
[23:48] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:06336ce76025: avformat: replace some odd 30-60 rates by higher less odd ones in  get_std_framerate()
[00:00] --- Mon Dec  1 2014