[Ffmpeg-devel-irc] ffmpeg-devel.log.20151024
burek
burek021 at gmail.com
Sun Oct 25 02:05:03 CEST 2015
[00:00:39 CEST] <nevcairiel> in any case, it also helps to ensure surfaces are free'ed in the correct order, since the decoder has a ref on the surfaces, so if i free it last, it ensures that all surfaces are free'ed in one go when all are unused
[00:00:52 CEST] <nevcairiel> since they are also allocated as one block
[00:01:04 CEST] <nevcairiel> in any case, it prevented problems =p
[00:07:55 CEST] <mateo`> nevcairiel: where (in the code) do you actually do the refcounting part ? i wonder if there's an api to do some refouncting other than the avbuffer one
[00:08:38 CEST] <nevcairiel> its in ffmpeg_dxva.c
[00:08:47 CEST] <nevcairiel> and it uses windows refcouting things
[00:08:53 CEST] <nevcairiel> avbuffer is the only thing it has
[03:40:38 CEST] <BBB> kierank: fixed (4935, that weird vp9 file that eats memory)
[04:42:14 CEST] <kierank> BBB: cool, will see if that fixes the rest of the fuzz crashes
[04:42:48 CEST] <BBB> it didnt crash
[04:42:52 CEST] <BBB> it just upsets your computer
[04:42:58 CEST] <BBB> its totally valid whats happening in fact
[04:43:12 CEST] <BBB> (in this case its not intended, but it could easily happen for a real file)
[09:34:18 CEST] <rishi_> Hello,
[09:35:06 CEST] <rishi_> I am student of computer science. I wanted to contribute in your organization how can I contribute ?
[09:35:19 CEST] <rishi_> In the past I cracked GSoC 2015
[13:02:25 CEST] <cone-146> ffmpeg 03Michael Niedermayer 07master:e06ef9aa5fe8: avcodec/dpxenc: Fix "libavcodec/dpxenc.c:250:44: warning: passing argument 3 of av_image_copy_to_buffer from incompatible pointer type"
[13:11:47 CEST] <cone-146> ffmpeg 03Carl Eugen Hoyos 07master:9c069bf71af2: lavc/hapdec: Use correct no-transparency colour space.
[14:06:54 CEST] <cone-146> ffmpeg 03Carl Eugen Hoyos 07master:a3bed3f3e1a0: lavf/ingenientdec: Add a probe function.
[16:13:30 CEST] <cone-146> ffmpeg 03Marton Balint 07master:03037a4aad8b: ffplay: use a separate struct for the rescaled YUVA AVSubtitle rectangles
[16:13:31 CEST] <cone-146> ffmpeg 03Marton Balint 07master:5e9f14e4bf3a: libzvbi-teletextdec: fix AVSubtitleRect pict compatiblity code
[16:20:10 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:683462911db5: avfilter: avoid zero arguments to variadic macro
[17:29:46 CEST] <mateo`> llllllllllllllllllllllllllllll588888888888888888888888888888888888=$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$odddddddddddddddddddddddddddddddddddddddddddçikkkkkkkkkkkkkkkkkkkkkkkkkk*****è$bùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù
[17:29:47 CEST] <mateo`> ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùy9+++++++++++++++++++++++++++++++++++++++++++++++++++
[17:29:49 CEST] <mateo`> *mlùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù)-666666666663+++ppppppp
[17:29:51 CEST] <mateo`> ôooo
[17:30:31 CEST] <JEEB> cat on the keyboard?
[17:30:41 CEST] <mateo`> mmm sorry :\, my cat tried to say something ...
[17:30:55 CEST] <JEEB> I guessed it :)
[17:31:05 CEST] <JEEB> I have seen some "catwalks" on IRC before
[17:31:17 CEST] <mateo`> JEEB: héhé :)
[18:20:29 CEST] <wm4> so why the fuck do these fragmented http streaming things not just slice the data on the byte level? it might increase the latency in some cases, but can't be so bad compared to all the other messes
[18:28:36 CEST] <kierank> wm4: slice on the byte level?
[18:29:02 CEST] <kierank> so just cut arbitrarily like an mpegts?
[18:29:18 CEST] <wm4> yes
[18:29:31 CEST] <wm4> the problem is that they want to use http CDNs to distribute the load, right
[18:29:44 CEST] <JEEB> well, I think I just got relatively correct BT.2020->BT.709 out of ffmpeg with zscale :)
[18:30:02 CEST] <kierank> wm4: yes
[18:30:12 CEST] <kierank> wm4: you can't switch bitrate segments
[18:30:16 CEST] <kierank> if the cut is arbitrary
[18:30:42 CEST] <wm4> kierank: then just switch to an entirely different stream
[18:31:08 CEST] <kierank> yes but it won't be seamless
[18:37:08 CEST] <kierank> "Picture size 262864x262752 is invalid" lol
[18:46:56 CEST] <wm4> sounds a bit high
[18:55:29 CEST] <kierank> fuzzed file
[21:09:21 CEST] <BBB> kierank: I believe any picture size where wxh>INT_MAX is invalid
[21:09:26 CEST] <BBB> kierank: thats ff_set_dimensions
[21:11:34 CEST] <wm4> the threshold is much lower, but something like this
[21:12:12 CEST] <wm4> I think it's actually INT_MAX/8
[21:12:44 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07master:52f84d82bdf1: videodsp: don't overread edges in vfix3 emu_edge.
[21:12:45 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07master:49d8a70dc51e: vp9: uses ff_set_dimensions (which sets coded_width/height).
[21:13:04 CEST] <BBB> kierank: fix pushed, vp9 should be good again
[21:14:14 CEST] Action: durandal_1707 there so many sdx2 aifc files
[21:15:52 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:4c96985af1b8: all: remove some casts of function pointer to void *
[23:59:36 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:38f4e973efef: all: fix -Wextra-semi reported on clang
[00:00:00 CEST] --- Sun Oct 25 2015
More information about the Ffmpeg-devel-irc
mailing list