[Ffmpeg-devel-irc] ffmpeg-devel.log.20151115
burek
burek021 at gmail.com
Mon Nov 16 02:05:02 CET 2015
[02:15:11 CET] <cone-506> ffmpeg 03Michael Niedermayer 07master:9caa9414ccf2: avcodec/dxtory: Fix input size check in dxtory_decode_v1_420()
[02:15:12 CET] <cone-506> ffmpeg 03Michael Niedermayer 07master:76b6f4b7d919: avcodec/dxtory: Fix input size check in dxtory_decode_v1_410()
[02:15:13 CET] <cone-506> ffmpeg 03Michael Niedermayer 07master:08b520636e96: avcodec/takdec: Skip last p2 sample (which is unused)
[02:16:19 CET] <jamrial> michaelni_: did you see my question above?
[02:24:18 CET] <michaelni_> jamrial, isnt it rather simple to fix the function ? (which would avoid the API version revert problem)
[02:25:35 CET] <michaelni_> i can try to fix it but i dont have a system setup to test this so it would be a blind fix
[02:46:08 CET] <jamrial> michaelni_: no idea if rint is available on msvc 2012, so copying the libm.h fallback may not work
[02:46:44 CET] <michaelni_> ill post a patch in a moment
[02:46:58 CET] <jamrial> alright
[03:50:53 CET] <cone-506> ffmpeg 03Michael Niedermayer 07master:5c3dee7dadf8: avutil: Move av_rint64_clip_* to internal.h
[10:24:43 CET] <cone-277> ffmpeg 03Matthieu Bouron 07master:e162542e156a: lavc/internal: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM
[10:24:43 CET] <cone-277> ffmpeg 03Matthieu Bouron 07master:ad0203d7b026: lavc/mjpegdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability
[10:24:43 CET] <cone-277> ffmpeg 03Matthieu Bouron 07master:0cdc77f1040c: lavc/pngdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability
[10:29:01 CET] <cone-277> ffmpeg 03Andreas Cadhalpun 07master:6a69a175e7b5: mpegvideo: clear overread in clear_context
[12:26:29 CET] <andrewrk> does the ebur128 filter API provide a way to get the loudness information programatically?
[12:26:47 CET] <andrewrk> as opposed to logging the information
[12:28:47 CET] <nevcairiel> it sets it into the metadata
[12:29:46 CET] <nevcairiel> unfortunately there is no concept of "global" metadata in avfilter, so you would have to check the metadata of the last audioframe you passed through it
[12:31:15 CET] <andrewrk> hmm, I'll experiment with that. thanks.
[12:32:11 CET] <nevcairiel> it uses metadata keys like lavfi.r128.I for integrated loudness, lavfi.r128.LRA for loudness range
[12:32:25 CET] <nevcairiel> the keys are probably documented somewhere
[12:33:36 CET] <nevcairiel> M for momentary loudness, S for short term loudness, and the two I already mentioned
[12:35:19 CET] <andrewrk> I'm looking at the example video output from the documentation. this is great - one could use the integrated loudness to scan a song while playing it and gradually adjust the volume to perform loudness compensation
[12:37:46 CET] <cbsrobot> If I'm not wrong the per-channel weight is still missing in ebur128
[12:39:15 CET] <andrewrk> couldn't the filter graph put a channel remapping filter before the ebur128 filter so that it only has to deal with mono?
[12:39:33 CET] <andrewrk> or does the r128 spec have a better way to handle multple channels?
[12:39:42 CET] <nevcairiel> the spec handles multichannel just fine
[12:39:51 CET] <nevcairiel> as does the filter, afaik
[12:44:58 CET] <nevcairiel> in fact thats one of the big advantages of r128 over replaygain, it actually specifies how to handle multi-channel, making it useful for video, and nost just music
[12:55:27 CET] <ubitux> cbsrobot: per channel weights are defined by the standard and implemented
[12:55:41 CET] <ubitux> are you talking about a custom user weighting?
[12:56:16 CET] <ubitux> (see around line 382)
[12:56:26 CET] <cbsrobot> I was thinking about the SL and SR weighting
[12:57:02 CET] <ubitux> 1.41 weighting then i suppose, see the BACK_MASK
[12:57:56 CET] <cbsrobot> ah I see
[12:58:06 CET] <cbsrobot> so I was wrong
[12:58:35 CET] <ubitux> i'm doing the survey summary right now; should i just share the full results, or it's not correct to share the answers of everyone and i should make a summary?
[13:00:25 CET] <ubitux> we got 123 answers
[13:31:38 CET] <atomnuker> "CMVideoFormatDescriptionGetH264ParameterSetAtIndex"
[13:31:40 CET] <atomnuker> "kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder"
[13:32:50 CET] <wm4> welcome to apple
[13:33:31 CET] <wm4> it's even worse in objective c, where method calls always require you to pass named arguments
[13:44:38 CET] <wm4> michaelni_: I believe you attempted to fix the ogm missing timestamps problem with commit a7af002b5f4c71590ce2536132b40e8cdc0cac7e, but the resulting timestamps are still missing or nonsensical
[13:44:45 CET] <wm4> e.g. with one sample I get in ffprobe:
[13:44:46 CET] <wm4> pkt_pts_time=0.291959
[13:44:46 CET] <wm4> pkt_pts_time=N/A
[13:44:46 CET] Last message repeated 1 time(s).
[13:44:46 CET] <wm4> pkt_pts_time=0.417084
[13:44:47 CET] <wm4> pkt_pts_time=N/A
[13:44:48 CET] <wm4> pkt_pts_time=0.417084
[13:46:45 CET] <wm4> sometimes timestamps even plainly go backwards
[13:47:40 CET] <Daemon404> do you know if these files simply are screwy?
[13:47:59 CET] <wm4> other than being ogm? no
[13:48:27 CET] <wm4> and remuxing with mkvmerge fixes them
[13:49:10 CET] <Daemon404> right
[13:49:15 CET] <Daemon404> that was what i was going to suggest testing
[15:13:26 CET] <kierank> why does CC=/usr/local/bin/afl-clang-fast ./configure not work
[15:13:29 CET] <kierank> it uses gcc
[15:13:51 CET] <nevcairiel> i dont think configure respects CC, you need to use --cc=
[15:14:48 CET] <wm4> fuck conventions!
[15:17:02 CET] <atomnuker> I actually like to set the compiler using arguments because at least I 100% know it's going to workk
[15:17:26 CET] <atomnuker> sometimes some configuration scripts silently ignore and override it
[15:18:45 CET] <wm4> like ffmpeg's
[15:22:01 CET] <J_Darnley> I swear some want CC=... before ./congfigure (so an env. var.) and some want it after (an argument)
[15:22:15 CET] <J_Darnley> There is no convention.
[15:23:46 CET] <JEEB> yeah :/
[15:24:36 CET] <wm4> sucks
[15:43:02 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:4a9af07a4929: avcodec/smacker: Check that the data size is a multiple of a sample vector
[15:43:02 CET] <cone-707> ffmpeg 03Rainer Hochecker 07master:2d8c2f1a2807: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec
[15:51:06 CET] <Daemon404> "- vc1 encoder"
[15:51:14 CET] Action: Daemon404 does not fathom
[15:51:47 CET] <Daemon404> ubitux, some of these text comments dont make much sense to me
[15:51:53 CET] <Daemon404> as in i cant figure out what they mea
[15:51:54 CET] <Daemon404> n
[15:52:29 CET] <ubitux> yeah, that was my issue while bulking
[15:54:24 CET] <Daemon404> - ts segmenting optim for hls <-- how old was this btw
[15:54:32 CET] <Daemon404> as of two weeks ago overhead should be far less.
[15:54:45 CET] <nevcairiel> its slightly older
[15:55:05 CET] <ubitux> Daemon404: maybe i badly reworded some though
[15:55:11 CET] <ubitux> want the full data?
[15:55:16 CET] <Daemon404> not especially =p
[15:55:18 CET] <ubitux> :)
[15:55:28 CET] <Daemon404> i think a bunch of the replies are a bit silly
[15:55:48 CET] <ubitux> sure
[15:55:56 CET] <nevcairiel> when I looked at the graph to question 2, the answer i got from that was "they want everything"
[15:56:04 CET] <ubitux> :D
[15:56:15 CET] <ubitux> you should look at the % in the table
[15:56:23 CET] <Daemon404> nevcairiel, they also want ffmpeg to do everything
[15:56:26 CET] <Daemon404> even when it makes no sense
[15:56:26 CET] <Daemon404> ;P
[15:56:27 CET] <ubitux> maybe i didn't pick the appropriate device
[15:56:38 CET] <ubitux> s/device/widget/
[15:56:44 CET] <ubitux> why did i say device
[15:56:50 CET] <ubitux> my brain is a mystery sometimes.
[15:57:25 CET] <nevcairiel> more upstreaming
[15:57:28 CET] <nevcairiel> what does that even mean
[15:57:36 CET] <Daemon404> nevcairiel, that is what i was refering to earlier
[15:57:41 CET] <Daemon404> no idea.
[15:57:49 CET] <wm4> "ffplay hwaccel"
[15:58:11 CET] <nevcairiel> that probably wouldnt even be that hard by using the ffmpeg_<hwaccel> modules
[15:59:02 CET] <ubitux> nevcairiel: no idea, maybe libav call?
[15:59:15 CET] <Daemon404> BS
[15:59:19 CET] <Daemon404> kierank is the one true upstream
[15:59:30 CET] <ubitux> wm4: it might actually be a good opportunity to provide an hwaccel "example"
[15:59:41 CET] <wm4> it's going to be a mess with sdl
[15:59:58 CET] <wm4> isn't ffmpeg's enough? (or you could just use readback in ffplay)
[15:59:59 CET] <ubitux> we should move to sdl2 anyway
[16:00:40 CET] <ubitux> (there is a gl fallback in sdl2 right?)
[16:00:54 CET] <wm4> not sure what you mean
[16:00:59 CET] <wm4> both sdl and sdl2 provide gl
[16:01:05 CET] <ubitux> ah? ok
[16:01:27 CET] <ubitux> i though th gl backend was sdl2 exclusive, but i don't really know anything about that
[16:01:35 CET] <nevcairiel> what did you think sdl1 used
[16:01:47 CET] <ubitux> no idea :)
[16:01:49 CET] <wm4> ffplay.c doesn't use gl at all though
[16:01:49 CET] <nevcairiel> X directly? :)
[16:02:06 CET] <ubitux> yeah sth like that, dunno
[16:02:09 CET] <wm4> it uses sdl's video API, which I think uses Xv on X11
[16:02:14 CET] <ubitux> ah!
[16:02:20 CET] <kierank> durandal_1707: http://paste.ubuntu.com/13283074/
[16:02:23 CET] <kierank> I started using that
[16:02:57 CET] <nevcairiel> the demux/decode example? :d
[16:03:12 CET] <wm4> ubitux: there's also a useless libavdevice thing to render video with GL (and I think it can use SDL?)
[16:03:29 CET] <nevcairiel> i think that avdevice thing is only gl
[16:03:56 CET] <wm4> using a muxer API for that, lol (freaking horrible)
[16:04:37 CET] <ubitux> could be fun to make ffplay use it
[16:04:44 CET] <ubitux> :°
[16:04:48 CET] <nevcairiel> most of avdevice is horrible like that, shoe-horning video/audio input/output into demuxer and muxer APIs
[16:05:09 CET] <wm4> ubitux: I really wouldn't... users would start to copy that and everyone would become sad
[16:05:14 CET] <ubitux> :D
[16:05:32 CET] <nevcairiel> which is how people like that guy on the ML happen, trying to "optimize" the path of the uncompressed video those "demuxers" output
[16:05:36 CET] <wm4> if you want something good, add a proper video output lib to ffmpeg or something
[16:05:56 CET] <wm4> nevcairiel: the uncoded frame shit was added for this
[16:06:18 CET] <nevcairiel> isnt that for the other end
[16:06:21 CET] <nevcairiel> output of uncompressed
[16:06:23 CET] <nevcairiel> not input
[16:06:34 CET] <wm4> all this reminds me of OSS, and how it shoehorns audio output into a file handle and ioctls
[16:06:41 CET] <nevcairiel> heh
[16:06:49 CET] <wm4> nevcairiel: no uncoded frame is for muxing
[16:06:53 CET] <wm4> there's an explicit API for it
[16:06:57 CET] <nevcairiel> thats what I said
[16:07:00 CET] <wm4> oh ok
[16:07:08 CET] <nevcairiel> his problem is "demuxing"
[16:07:13 CET] <nevcairiel> ie. lavfi input device
[16:07:27 CET] <wm4> yeah, that guy's problem
[16:28:33 CET] <cone-707> ffmpeg 03Ganesh Ajjanagadde 07master:064ced5dc147: avcodec/faandct: use more accurate constants
[16:28:34 CET] <cone-707> ffmpeg 03Ganesh Ajjanagadde 07master:0bd0af6e6836: swresample/resample: remove redundant L for floating literal
[16:34:51 CET] <wm4> why is suggesting ffserver removal "flame bait"
[16:38:13 CET] <rcombs> Daemon404: re: that HLS thing, shouldn't that use av_opt_set_int?
[16:41:35 CET] <Daemon404> rcombs, remmeber how we already discussed that for liek an hour before?
[16:52:13 CET] <rcombs> nope
[16:52:31 CET] <rcombs> I either missed it or forgot it
[16:54:35 CET] <durandal_1707> ivr demuxer is almost finished
[17:09:18 CET] <Daemon404> rcombs, tl;dr it can be changed
[17:09:22 CET] <Daemon404> but ive been on holiday
[17:09:28 CET] <Daemon404> and now im quite busy... with shovel knight
[17:09:30 CET] Action: Daemon404 runs
[17:16:45 CET] <rcombs> I might send a patch to do that, and another to do the same in segment.c
[17:52:24 CET] <nevcairiel> note that segment may be employed in more generic use-cases, so the same assumptions as with hlsenc can't generally be made
[17:52:29 CET] <nevcairiel> it even supports other containers, etc
[18:13:23 CET] <kierank> BBB: started fuzzing vp9 again with afl persistent mode (i.e using the api instead of ffmpeg.c)
[18:13:37 CET] <kierank> nevcairiel: so how did the libdca guy figure out the integer transform? RE
[18:13:41 CET] <kierank> iirc it's not in the spec
[18:14:20 CET] <BBB> \o/
[18:18:59 CET] <kierank> not sure if it's a good idea but I just put the entire fate testvector suite in the fuzz directory
[18:21:19 CET] <kierank> if I get more crashes I need to come up with a name like j00ru
[18:26:02 CET] <Daemon404> Found-by: The One True Upstream
[18:30:22 CET] <kierank> Found-by: Kieran 'The True Upstream' Kunhya
[18:31:55 CET] <wm4> obviously you should go by the name k13rank
[18:36:14 CET] Action: Compn still pronouncing it kie-rank in his head
[18:37:33 CET] <kierank> durandal_1707: "Useless comments/reviews are ignored." lol
[18:53:34 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:7ad698e24e6b: avcodec/wmaprodec: Check for overread in decode_packet()
[18:56:59 CET] <durandal_1707> kierank: how much is this afl faster then older one?
[18:57:09 CET] <kierank> dunno
[19:08:56 CET] <kierank> durandal_1707: qualitatively seems to be faster yes
[19:09:03 CET] <kierank> not sure if it's operating better or worse though
[19:25:27 CET] <cone-707> ffmpeg 03Marton Balint 07master:a01046c90c9a: fate: add concat demuxer tests
[20:36:13 CET] Action: durandal_1707 trolling
[20:40:25 CET] <ubitux> "I personally use ffplay exclusively for media playback."
[20:40:27 CET] <ubitux> aha!
[20:40:36 CET] <nevcairiel> weirdos
[20:40:36 CET] <ubitux> so not an anime fan :(
[20:40:42 CET] <nevcairiel> that player is so crappy
[20:40:52 CET] <ubitux> it's okayish
[20:43:32 CET] <ubitux> Compn: you should not encourage non programmer to paste shitty diff bulk on ffmpeg-devel
[21:05:20 CET] <Zeranoe> Just noticed this, but it looks like bootstrap.min.css and style.min.css are missing from the doc folder. The HTML generated pages are trying to link to it. Perhaps those CSS files could be include, or linked their remote location http://ffmpeg.org/css/style.min.css
[21:07:09 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:016fd413f916: avcodec/jpeg2000: Use av_image_check_size() in ff_jpeg2000_init_component()
[21:07:10 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:a1a8cbcb35ef: avcodec/jpeg2000: Check comp coords to be within the supported size
[21:40:34 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:6ef819c40bcc: avcodec/jpeg2000dec: Check SIZ dimensions to be within the supported range
[21:40:35 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:65d3359fb366: avcodec/jpeg2000dec: Fix potential integer overflow with tile dimensions
[22:24:21 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:0eb7de197368: avcodec/jpeg2000: Change coord to 32bit to support larger than 32k width or height
[23:29:56 CET] <Compn> ubitux : i'm encouraging new contributors to the project. no new contributors = dead project.
[23:30:28 CET] <Compn> i see your point though
[23:30:37 CET] <Compn> gotta start somewhere
[23:30:51 CET] <Compn> https://github.com/henern/ffmpeg4iOS
[23:30:53 CET] <Compn> that looks good
[00:00:00 CET] --- Mon Nov 16 2015
More information about the Ffmpeg-devel-irc
mailing list