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

burek burek021 at gmail.com
Thu Apr 13 03:05:03 EEST 2017


[00:01:04 CEST] <ubitux> so i was looking at the big files on my disk
[00:01:07 CEST] <ubitux> when suddenly
[00:01:09 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-04-12-000054_282x445_scrot.png
[00:01:48 CEST] <nevcairiel> staticly linked examples, eh
[00:02:04 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:7182fbc47182: doc/examples/decode_video: Fix format string vulnerability
[00:02:05 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:83e6a4a32b75: Revert "mjpegenc: disable huffman coding with AMV"
[00:02:06 CEST] <cone-782> ffmpeg 03Rostislav Pehlivanov 07release/3.3:72e038acaf4d: mpegvideo_enc: disable optimized huffman coding with AMV or slice threads
[00:02:07 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:0c188bc595c1: avcodec/mjpegenc_huffman: Assert length in ff_mjpegenc_huffman_compute_bits()
[00:02:08 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:c30d0ace656d: avcodec/pixlet: Reorder rlen check
[00:02:09 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:707d4c7fb5ce: avformat/oggparseogm: Check available data before reading global header
[00:02:09 CEST] <wm4> nice bloat
[00:02:10 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:4f325589f95c: avformat/oggparseogm: Check ff_alloc_extradata() for failure
[00:02:43 CEST] <jamrial> why do the stripped binaries weigh the same as the _g ones?
[00:02:53 CEST] <ubitux> because of --disable-stripping i suppose
[00:03:07 CEST] <jamrial> ah right
[02:22:04 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07master:5b441d2981f3: doc/APIchanges: Fill in missing fields
[02:36:30 CEST] <cone-782> ffmpeg 03James Almer 07master:f1d80bc63052: x86/float_dsp: add ff_vector_fmul_reverse_avx2
[04:18:28 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:ad37fb86d79f: doc/APIchanges: Fill in missing fields
[04:18:29 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:37589e64435d: Update for 3.3
[04:18:30 CEST] <cone-782> ffmpeg 03Michael Niedermayer 07release/3.3:07e7ebf52de9: add release notes based on release 3.2
[05:24:11 CEST] <KGB> [13FFV1] 15ablwr opened pull request #55: updates instances of colorspace to "color space" for consistency (06master...06ab/colorspace) 02https://git.io/vS1AP
[06:12:41 CEST] <rcombs> has the SSH key for source.ffmpeg.org changed?
[06:14:23 CEST] <jamrial> rcombs: yes
[06:14:41 CEST] <jamrial> rcombs: https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html
[06:15:08 CEST] <rcombs> ah, cool
[06:15:55 CEST] <rcombs> what could one do by impersonating a git server anyway
[09:18:18 CEST] <ubitux> atomnuker: http://fate.ffmpeg.org/report.cgi?time=20170412004204&slot=x86_64-archlinux-gcc-valgrind
[09:18:32 CEST] <ubitux> does this look like a false positive to you?
[09:18:59 CEST] <ubitux> afaict it showed up when i started using --disable-optimizations, haven't confirmed yet
[09:39:53 CEST] <JEEB> does anything implement the text part of DVB subtitle spec?
[10:05:58 CEST] <durandal_170> JEEB: there is such thing?
[10:16:22 CEST] <JEEB> yea, I remember reading in the spec that there's a mode like that
[10:16:33 CEST] <JEEB> which was quite honestly a surprise for me
[12:04:27 CEST] <wm4> wtf
[12:04:37 CEST] <wm4> --disable-decoders --disable-encoders
[12:04:40 CEST] <wm4> Enabled decoders:
[12:04:40 CEST] <wm4> h263			mjpeg_cuvid		mpeg2video		vc1_cuvid
[12:04:40 CEST] <wm4> h264			mpeg1_cuvid		mpeg4			vp8_cuvid
[12:04:40 CEST] <wm4> h264_cuvid		mpeg1video		mpeg4_cuvid		vp9
[12:04:40 CEST] <wm4> hevc			mpeg2_cuvid		vc1			vp9_cuvid
[12:04:42 CEST] <wm4> hevc_cuvid
[12:04:45 CEST] <wm4> on almost-master
[12:05:12 CEST] <wm4> why are there random codecs enabled despite explicitly disabling all
[12:06:49 CEST] <wm4> only this disables all codecs: ./configure --disable-decoders --disable-encoders --disable-vdpau --disable-cuvid --disable-vaapi
[12:07:19 CEST] <ubitux> there were a bunch of configure/build commits merged
[12:07:33 CEST] <ubitux> we're "in the middle" of a wave of these basically
[12:07:50 CEST] <ubitux> something may have been fucked some way or another, and might have been fixed "soon" later on
[12:08:01 CEST] <ubitux> we're still at that av*synth commit
[12:08:17 CEST] <ubitux> no ones know what to do so it's in standby i guess
[12:08:35 CEST] <ubitux> i can go back to merge as soon as there is something done about it
[12:08:37 CEST] <wm4> the same happens in the 3.3 branch
[12:08:44 CEST] <ubitux> i guess that's older then
[12:08:49 CEST] <ubitux> not sure.
[12:10:35 CEST] <mateo`> ~mpeg la conspiraticy~, they'll make you to pay for hevc even if you don't want to
[12:11:03 CEST] <wm4> it's because of that broken hwaccel autodetection
[12:11:22 CEST] <wm4> I think I mentioned it to diego, so it's actually more likely merging more will fix them
[12:25:39 CEST] <atomnuker> wm4: disable bitstream filters as well if you want no video decoders
[12:29:03 CEST] <wm4> I didn't have to
[12:46:20 CEST] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vSMgf
[12:46:20 CEST] <KGB> 13FFV1/06master 14908ca9b 15Dave Rice: add self as co-author
[12:46:20 CEST] <KGB> 13FFV1/06master 146467005 15Jérôme Martinez: add self as co-author
[12:46:48 CEST] <KGB> [13FFV1] 15michaelni closed pull request #53: add self as co-author (06master...06add-self-as-co-author) 02https://git.io/vD7rW
[16:03:40 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170412041932&slot=x86_64-archlinux-gcc-threads-misc
[16:03:42 CEST] <ubitux> strange failure&
[16:05:42 CEST] <wm4> "[fifo @ 0x224a040] Recovery successful
[16:05:42 CEST] <wm4> [fifo @ 0x224a040] Recovery failed: Connection timed out"
[16:05:43 CEST] <wm4> wat
[16:06:26 CEST] <ubitux> note: it happened only once in all the runs so i don't know if it's a regression or a one in N failure
[16:25:08 CEST] <nevcairiel> fifo is one those weird parts that i dont even know wtf its for
[16:27:04 CEST] <nevcairiel> the doc reads like its some hack either to avoid improving ffmpeg.c threading, or ones own codes threading
[16:29:38 CEST] <wm4> lol
[16:39:49 CEST] <ubitux> speaking of threading, tsan still spots hevc and h264 races in some runs
[18:06:33 CEST] <atomnuker> jamrial: do you think unaligned versions of float dsp functions should be in codecs or as separate functions in lavu float dsp?
[18:08:44 CEST] <atomnuker> so far I only know of opus and dolby's new thing which run on not very nice at all frame sizes
[18:08:57 CEST] <atomnuker> (and mp3)
[18:19:19 CEST] <wm4> did they patent odd frame sizes yet?
[18:19:30 CEST] <kierank> yes they have a patent on that iirc
[18:19:36 CEST] <kierank> alignment of audio frame to video frame
[18:19:46 CEST] <wm4> and I thought I was making a joke
[18:20:46 CEST] <atomnuker> they're odd in the sense they're not a power of two but are still even (they do this to get an integer amount of packets per second)
[18:21:11 CEST] <kierank> it allows for easier dash segmenting
[18:21:36 CEST] <atomnuker> I guess, you'd need less side packets to tell you when to cut the last frame
[18:21:51 CEST] <atomnuker> I thought it was because networks and switches and stuff
[18:33:30 CEST] <nevcairiel> what do they do to match ntsc frame rates? alternate 41 and 42ms frames? =p
[18:35:11 CEST] <nevcairiel> 41.70833ms audio frames seems a bit uncomfortable
[18:38:48 CEST] <atomnuker> that's generally what I've seen, they alternate
[18:43:10 CEST] <wm4> everyone sane does fragmented dash with separate audio and video streams anyway
[18:43:51 CEST] <nevcairiel> probably yea
[19:03:19 CEST] <jamrial> atomnuker: add it to codecs. lavu's float_dsp exists because those functions are also used by libavfilter
[19:22:27 CEST] <kierank> nevcairiel: they have a fixed frame rate and resample
[20:19:53 CEST] <rcombs> what happens if a decoder writes to avctx->time_base during init
[20:30:23 CEST] <wm4> rcombs: that's invalid
[20:30:38 CEST] <wm4> or wait, was that this special case
[20:30:48 CEST] <wm4> which nobody (and I mean nobody) understands
[20:30:55 CEST] <rcombs> some of them definitely do
[20:31:00 CEST] <rcombs> but I have no idea what happens
[20:31:11 CEST] <rcombs> like, h264dec adjusts the time_base
[20:31:11 CEST] <wm4> this "codec time base" nonsense
[20:31:35 CEST] <wm4> some of those ffmpeg bullshit things you probably can't get rid of
[20:31:56 CEST] <nevcairiel> meaning of time_base for decoders is totally undefined anyway
[20:32:33 CEST] <wm4> michaelni: seems like these opus mp4 patches didn't address some of the earlier review comments, why did you push them or is this false?
[20:33:01 CEST] <wm4> nevcairiel: except libavformat or ffmpeg.c probably reads that field
[20:34:21 CEST] <nevcairiel> well avformat cant really anymore, outside depreacted code, but otherwise its not really well defined what happens with it
[20:36:29 CEST] <rcombs> what happens if a codec rescales timestamps internally
[20:36:48 CEST] <michaelni> wm4, which opus patches ?
[20:37:01 CEST] <BtbN> cuvid can double the framerate. And at least with ffmpeg.c, a mess happens.
[20:37:18 CEST] <durandal_1707> michaelni: recently pushed
[20:38:22 CEST] <jamrial> wm4: the decoder patch was fixed after my review. were there other unadressed comments?
[20:38:54 CEST] <wm4> michaelni: the ones you pushed
[20:39:09 CEST] <michaelni> durandal_1707, wm4  these 2 patches where posted almost a month ago, the author has asked multiple times for feedback
[20:39:10 CEST] <wm4> jamrial: I don't know, but it seemed like he was displeased
[20:40:04 CEST] <jamrial> wait, who was displeased?
[20:42:15 CEST] <jamrial> wm4: there was a review by daemon404 for the first version sent a year ago, which was addressed in this new version just pushed and sent a month ago
[20:42:23 CEST] <jamrial> then there was my review that was also addressed
[20:42:33 CEST] <jamrial> i can't find any other review that could have been ignored
[20:42:59 CEST] <wm4> ok then
[20:43:14 CEST] <wm4> maybe he didn't actually post then
[20:44:20 CEST] <michaelni> wm4, for the "Add experimental support for Opus in ISO BMFF" patches i see only 1 prior version which got a reply from james, which was taken care of. if theres another it has a diferent subect and i mised it
[20:45:45 CEST] <RiCON> the one from felicia (add channel mapping 2 support) is still unanswered
[21:06:44 CEST] <cone-729> ffmpeg 03Marton Balint 07master:51948b9d9e97: avfilter/vf_framerate: always request input if no output is provided in request_frame
[21:06:44 CEST] <cone-729> ffmpeg 03Marton Balint 07master:c92abd0c0e4d: tests/fate/filter-video: fix framerate filter tests
[21:06:44 CEST] <cone-729> ffmpeg 03Marton Balint 07master:1f9419753667: ffprobe: only use custom logging callback if -show_log is set
[21:24:53 CEST] <cone-729> ffmpeg 03Marton Balint 07release/3.3:ecdf52745f8d: avfilter/vf_framerate: always request input if no output is provided in request_frame
[21:24:54 CEST] <cone-729> ffmpeg 03Marton Balint 07release/3.3:af43c7092cf2: tests/fate/filter-video: fix framerate filter tests
[21:24:55 CEST] <cone-729> ffmpeg 03Marton Balint 07release/3.3:69e35db80d0f: ffprobe: only use custom logging callback if -show_log is set
[22:49:29 CEST] <cone-729> ffmpeg 03Carl Eugen Hoyos 07master:a081acc44082: configure: Fix decklink license dependency.
[22:51:26 CEST] <cone-729> ffmpeg 03Carl Eugen Hoyos 07release/3.3:0ed4f26cf20a: configure: Fix decklink license dependency. (cherry picked from commit a081acc44082e4124a11747139b9a329fe01736e)
[22:53:44 CEST] <cone-729> ffmpeg 03Carl Eugen Hoyos 07master:d89ac691c9cf: lavf/isom: Remove codec point for WMAv2 that has never worked.
[23:00:30 CEST] <cone-729> ffmpeg 03Carl Eugen Hoyos 07master:c1616b454dc0: lsws/utils: Make gray10 and gray12 full-scale like gray8 and gray16.
[23:13:13 CEST] <cone-729> ffmpeg 03Matthew Gregan 07master:b905ba5bc18c: avformat/movenc: Fix potential leak of sgpd_entries array.
[00:00:00 CEST] --- Thu Apr 13 2017


More information about the Ffmpeg-devel-irc mailing list