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

[burek]

[00:00:27 CET] <cone-679> ffmpeg 03Anton Khirnov 07master:b53569e0681f: h264_cabac: remove now unnecessary H264Context function parameters
[00:00:28 CET] <cone-679> ffmpeg 03Anton Khirnov 07master:c28ed1d74344: h264: move [uv]linesize to the per-slice context
[00:00:29 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:a6cb0534e2b5: Merge commit 'b53569e0681ff7bc99103ab4c961dbac3cc0fce6'
[00:00:30 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:fa7c08d5e192: Merge commit 'c28ed1d743443e783537d279ae721be3bbdf7646'
[00:00:31 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:141b9d5c3b4d: avcodec/h264_slice: update slice context linesizes when a new picture is allocated
[00:00:48 CET] <kierank> yayoi: hi
[00:01:13 CET] <yayoi> oh hi
[00:01:26 CET] <yayoi> i was not sure who is online and how is not
[00:01:47 CET] <yayoi> who is not sorry
[00:03:44 CET] <yayoi> do we have a test suit for API right now?
[00:03:54 CET] <kierank> no but we have a test suite for ffmpeg.c
[00:03:59 CET] <kierank> yayoi: see my latest email
[00:03:59 CET] <yayoi> right
[00:04:05 CET] <yayoi> i've never used fate or anything
[00:04:11 CET] <kierank> I am not 100% sure you can apply with outreachy
[00:04:15 CET] <yayoi> it seems like it runs some test when I ran make though
[00:04:33 CET] <yayoi> its okay to be honest 
[00:04:44 CET] <kierank> can you do gsoc?
[00:04:44 CET] <yayoi> i gonna submit application
[00:04:50 CET] <yayoi> no i can't i am not a student
[00:04:55 CET] <kierank> :(
[00:05:41 CET] <yayoi> if i do not get it, i am still happy to do it i just can't dedicate quite for 3 month full time unless something else happens 
[00:06:03 CET] <yayoi> (which is possible to but that doesn't involve bother your guys fortunately.) 
[00:07:31 CET] <yayoi> where is the test for ffmpeg.c?
[00:07:44 CET] <yayoi> also what kind of testing framework you have in your mind?
[00:08:14 CET] <cone-679> ffmpeg 03Anton Khirnov 07release/2.5:742d7e9a6e4e: hevc: make the crop sizes unsigned (cherry picked from commit c929659bdd7d2d5848ea52e685a3164c7b901bb0)
[00:08:15 CET] <cone-679> ffmpeg 03Michael Niedermayer 07release/2.5:d0599a3516c5: avcodec/hevc_ps: Check cropping parameters more correctly
[00:08:16 CET] <yayoi> if you do not have super specific in your mind, i can look up the code and i can think of something and i send it to you
[00:08:20 CET] <yayoi> and you can tell me what you think
[00:09:16 CET] <kierank> basically I would like to see fate use code similar to the examples:
[00:09:17 CET] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;h=a805a992b1372fdbdc89a0ee723466fcaabd050e;hb=HEAD
[00:09:28 CET] <kierank> because ffmpeg.c is a huge thing that almost certainly hides bugs
[00:10:20 CET] <yayoi> ya i can imagine
[00:11:45 CET] <yayoi> do you want cunit?
[00:12:04 CET] <yayoi> I've never looked at ffmpeg.c
[00:12:09 CET] <kierank> you don't need to
[00:12:20 CET] <kierank> basically the fate tests either output audio/video/timestamps
[00:12:28 CET] <kierank> and they are compared to reference material
[00:12:48 CET] <kierank> (e.g does h264 decode in a bitexact way to a known decoder)
[00:12:49 CET] <yayoi> i see
[00:14:01 CET] <yayoi> so you want to do the same thing but not ./ffmpeg but through API?
[00:14:11 CET] <kierank> yes that's a nice place to start
[00:14:18 CET] <yayoi> I've never used API& 
[00:14:23 CET] <yayoi> i need to look at that first...
[00:14:32 CET] <yayoi> okay
[00:14:32 CET] <kierank> they are in the examples directory
[00:14:38 CET] <yayoi> oh i see
[00:14:39 CET] <kierank> that i pasted above
[00:14:44 CET] <yayoi> oh i see
[00:16:00 CET] <kierank> I think the easiest is something like h264 video
[00:16:01 CET] <yayoi> okay i will read them and i ask you questions 
[00:16:09 CET] <yayoi> okay
[00:16:29 CET] <kierank> h264 is easiest because it is bitexact
[00:16:32 CET] <yayoi> so i should look up how ./ffmpeg test for h264 video?
[00:16:49 CET] <kierank> yes - you should be able to run make fate V=1
[00:16:57 CET] <kierank> https://www.ffmpeg.org/fate.html
[00:18:53 CET] <kierank> if i recall correctly the video outputs are compared with the md5sum of a yuv file per frame
[00:20:25 CET] <yayoi> yeah i remember did that for slicing patch
[00:24:53 CET] <yayoi> i am running make fate V=1.. a lot of stuff for the output& it may fails because subtitle stuff& hmmm i guess i should have done at separate branch& 
[00:25:59 CET] <kierank> yes there are lots of tests
[00:26:25 CET] <yayoi> but for now i only need to have concern for& h264?
[00:27:02 CET] <kierank> yes i think you should try to integrate the decode example into fate to decode one of the h264 samples
[00:27:21 CET] <kierank> or if you want to do another format
[00:27:52 CET] <yayoi> decode example is a link above?
[00:28:01 CET] <yayoi> no it is fine i look h264
[00:33:05 CET] <yayoi> okay i got a vague idea what to do. I will ask you more questions then. Thank you!
[00:35:54 CET] <kierank> yayoi: decode example is in here: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/decoding_encoding.c;h=80da66431b8fc9042f884ad54709292de174c9d6;hb=HEAD
[00:36:03 CET] <yayoi> make fate didn't give me any error.. i guess it didn't care the fact that I destroyed subtitles..
[00:37:07 CET] <yayoi> oh thank you
[00:37:21 CET] <yayoi> i will read it too them
[00:38:12 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:0346783c9886: avcodec/h264.h: Drop unused macro
[01:30:41 CET] <BBB> heres a very confusing thing
[01:30:46 CET] <BBB> if I build ffmpeg with --disable-all
[01:30:51 CET] <BBB> it builds libavutil only right?
[01:31:02 CET] <BBB> now, if I build enable-libavcodec enable-codec=xyz
[01:31:07 CET] <BBB> it doesnt actually build avcodec
[01:31:12 CET] <BBB> because it thinks avutil is missing
[01:31:15 CET] <BBB> even though IT DOES BUILD IT
[01:31:49 CET] <BBB> so I have to enable-avutil enable-avcodec enable-codec=xyz to get it to work
[03:17:56 CET] <cone-679> ffmpeg 03Michael Niedermayer 07n2.5.5:HEAD: avcodec/h264.h: Drop unused macro
[03:49:01 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:7ebb3022297a: swscale: Check memory allocation
[03:49:02 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:324067d18bf2: Merge commit '7ebb3022297aa00afda6800105684b8303f2608e'
[04:01:13 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:d3aa307da076: rmenc: Check memory allocation
[04:01:14 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:d450cb07d91e: avplay: Check memory allocation
[04:01:15 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:93c1b04abfc0: mms: Check memory allocation
[04:01:16 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:a3f5a8c3e06f: Merge commit 'd3aa307da076e8820298b2c59ec5d6ff01a5e374'
[04:01:17 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:a821617b5a09: Merge commit 'd450cb07d91ef39ad1d39bd7ca0cfce4bd7b13e7'
[04:01:18 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:c75681aba343: Merge commit '93c1b04abfc0dd31211a18bf2c0041d69cd16919'
[04:12:33 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:27aa1ff35a13: oggdec: Check memory allocation
[04:12:34 CET] <cone-679> ffmpeg 03Federico Tomassetti 07master:cfe64613923a: avfilter: Document avfilter_graph_alloc return value
[04:12:35 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:cff55cfe17ec: Merge commit '27aa1ff35a13bc471c6e0a9cc496ec3f62f1574f'
[04:12:36 CET] <cone-679> ffmpeg 03Michael Niedermayer 07master:aa65ff2adffa: Merge commit 'cfe64613923a2d47644a87386146ada1f9f6b659'
[04:52:07 CET] <rcombs> was there a vapoursynth lavfi filter at one point or am I tripping
[04:53:07 CET] <nevcairiel> i think Daemon404 talked about it at some point, but he might have just ended up trolling lavfi
[04:54:08 CET] <rcombs> I'm assuming vapoursynth has a C API that you can shove frames into and it'll give you frames back
[13:38:00 CET] <Daemon404> nevcairiel, 3 years ago
[13:40:02 CET] <durandal_1707> What?
[13:53:08 CET] <Daemon404> context: [03:52] <+nevcairiel> i think Daemon404 talked about it at some point, but he might have just ended up trolling lavfi
[14:48:43 CET] <wm4> rcombs: mpv has one
[14:48:51 CET] <wm4> rcombs: but by now it uses mechanisms not present in lavfi
[14:49:22 CET] <wm4> (an artifact of vapoursynth dataflow being the polar opposite of lavfi dataflow)
[14:51:40 CET] <rcombs> heh, how so?
[14:53:22 CET] <wm4> vapoursynth can asynchronously ask for new input
[14:53:34 CET] <wm4> while lavfi is basically a statemachine
[14:53:52 CET] <Daemon404> vapoursynth has concurrency baked in is why
[14:54:00 CET] <wm4> yep
[14:55:03 CET] <Daemon404> i mean you could hook it up to lavfi if you wanted to block
[14:55:07 CET] <Daemon404> but that would be horrible
[14:55:09 CET] <Daemon404> and stupid
[14:56:07 CET] <wm4> that's what the mpv filter bridge does
[14:56:10 CET] <rcombs> lavfi doesn't have an EAGAIN return or something like that?
[14:56:12 CET] <wm4> and it's indeed horrible
[14:56:28 CET] <wm4> rcombs: yes, but it's synchronous
[14:56:34 CET] <Daemon404> wm4, wouldnt you lose a lot of vapoursynth's benefits that way
[14:56:54 CET] <wm4> Daemon404: yes, but what else can you do?
[14:57:01 CET] <Daemon404> not use lavfi
[14:57:40 CET] <wm4> the mpv filter chain works like lavfi, because both are derived from mplayer's
[14:57:56 CET] <rcombs> (and I guess it probably doesn't matter much if vapoursynth is the rate-limiting step anyway)
[14:57:58 CET] <Daemon404> im so sorry
[14:58:03 CET] Action: Daemon404 consoles wm4
[14:58:23 CET] <wm4> most video player filter chains probably do
[14:58:27 CET] <wm4> except gstreamer's
[14:58:36 CET] <wm4> in gstreamer every filter is apparently a thread
[14:58:38 CET] <Daemon404> i much prefer vapoursynth's
[14:58:42 CET] <wm4> so vapoursynth would fit in well
[14:58:42 CET] <Daemon404> it's actually... designed
[14:58:53 CET] Action: Daemon404 shrugs
[15:00:02 CET] <Daemon404> [13:57] <+wm4> in gstreamer every filter is apparently a thread <-- entirely different model
[15:00:16 CET] <wm4> the worst part about lavfi is the graph building and configuration IMO
[15:00:22 CET] <wm4> not the dataflow
[15:00:34 CET] <Daemon404> ofc
[15:01:03 CET] <Daemon404> iirc christopher said my lavfi thread from 2012 was still relevant ;)
[15:01:14 CET] <wm4> so what are the difference in gstreamer's and vapursynth's dataflow handling? I don't know both very well
[15:01:15 CET] <Daemon404> (according to people who actually tried to use it)
[15:01:28 CET] <Daemon404> wm4, id need to look closer at gstreamer
[15:01:37 CET] <Daemon404> but it fails in other fundemental ways so i dont bother
[15:02:56 CET] <Daemon404> side note: what a glorious pulsevideo and gstreamer future
[15:03:14 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:563a8b4aac5d: avcodec/h264_cabac: Drop local_ref_count
[15:03:14 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:797ba4d53b08: avcodec/h264_cavlc: Drop local_ref_count
[15:06:55 CET] <wm4> Daemon404: pulseaudio is a polished api, but it's funny how it does stupid shit all the time
[15:07:04 CET] <wm4> and you can't find out whether it's a bug and a feature
[15:07:13 CET] <Daemon404> pulsevideo is a real thing
[15:07:17 CET] <Daemon404> not a joke i just made up
[15:07:29 CET] <wm4> oh misread
[15:07:44 CET] <wm4> maybe I'll switch to windows at some point
[15:07:56 CET] <wm4> when freedeskshit takes over everything
[15:07:56 CET] <JEEB> enjoy vsync and wasapi
[15:08:02 CET] <wm4> can't win
[16:42:58 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:76f4b117807c: avformat/flvenc: Allow muxing video codecs which are not explicitly supported by the muxer
[16:49:36 CET] <Daemon404> im sure j-b will LOVE that commit
[16:50:51 CET] <wm4> creating broken files is ffmpeg tradition
[16:50:57 CET] <wm4> don't go against good traditions
[17:01:03 CET] <durandal_1707> Michaelni: why?
[17:03:19 CET] <kierank> I need to make a list of all the crap commits
[17:04:46 CET] <kierank> to be fair it was on the ml
[17:06:35 CET] <michaelni> yes i posted it and hopes people would comment but noone did, also how can i create a broken file with this ? ( i mean a functional command line)
[17:07:08 CET] <michaelni> hopeD
[17:07:16 CET] <kierank> but what's the point of the patch
[17:07:47 CET] <michaelni> stream copy flv->flv
[17:08:06 CET] <kierank> but why would the video codec not be allowed?
[17:08:31 CET] <michaelni> we had similar code in flv for audio and it allowed copying nellymoser before we had real support for it with encoder and decoder
[17:08:58 CET] <michaelni> i am not against reverting the patch if people prefer
[17:09:08 CET] <kierank> I don't understand the goal
[17:09:45 CET] <michaelni> assume theres a new video codec in flv the patch might allow to stream copy it
[17:10:49 CET] <kierank> i don't think it's a good idea
[17:11:09 CET] <michaelni> ok, anyone else has any opinon ? if not then ill revert it
[17:12:15 CET] <wm4> michaelni: what made you write the patch?
[17:12:26 CET] <wm4> is there any existing use-case that is broken?
[17:12:30 CET] <wm4> not just theoretical stuff
[17:13:04 CET] <michaelni> its just theoretical from reading the code
[17:16:25 CET] <wm4> then it sounds like a worthless feature
[17:31:04 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:14bc7aaa860e: Revert "avformat/flvenc: Allow muxing video codecs which are not explicitly supported by the muxer"
[17:38:53 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:3a23ec0daa28: avfilter/vf_setfield: Change enum to int, which is accessed via AVOption as int
[17:38:54 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:74097e09023c: avfilter/vf_signalstats: Change enum to int, which is accessed via AVOption as int
[18:19:36 CET] <Daemon404> hmm i didnt see that on the ml
[18:19:39 CET] <Daemon404> i should pay closer attention
[18:43:16 CET] <j-b> Daemon404: WHY WHY WHY do they do that?
[18:43:26 CET] <j-b> Daemon404: it's fucking not hard to do correctly, is it?
[18:43:45 CET] <j-b> Use 0xFF to have a MOAR codecs option
[18:43:52 CET] <j-b> and define a table of those
[18:43:58 CET] <j-b> and that'd be a new standard
[18:45:29 CET] <Daemon404> j-b, it was reverted at least.
[18:45:43 CET] <j-b> I understand that they want to mux more
[18:45:50 CET] <j-b> but make it in a good way
[19:29:28 CET] <sourabh> can any tell me about ipersiststream?
[19:29:35 CET] <sourabh> and its uses
[19:30:32 CET] <wm4> about what?
[19:34:04 CET] <sourabh> i am  trying to capture video using capture devices using graphedit, now each of the filter that i have added to the graph,when i right click on them have "set option" category.
[19:34:28 CET] <wm4> oh, so it's a directshow thing?
[19:34:31 CET] <sourabh> most of them su[pport the way of "saving" those options
[19:34:48 CET] <sourabh> yeah
[19:35:23 CET] <sourabh> so the task is how to " save" those option.
[20:27:13 CET] <ninten> durandal_1707,  ping
[20:29:21 CET] <wm4> what's the decision making process for gsoc projects?
[20:29:30 CET] <durandal_1707> nineteen: pong
[20:31:07 CET] <durandal_1707> ninten: pong
[20:32:18 CET] <kierank> wm4: consensus
[20:32:33 CET] <ninten> i was going through the MPEG-4 als encoder codebase , so one of my project goal is to enhancethe rudimentary feature set of the encoder
[20:32:57 CET] <wm4> kierank: my impression is it's "someone edits the wiki page"
[20:33:12 CET] <kierank> there's a mailing list
[20:34:14 CET] <ninten> durandal_1707,  so can you give me some idea on what feature should i work so that i can benefit the most to the codebase  
[20:36:16 CET] <durandal_1707> Didn't you worked on float ALS code
[20:37:18 CET] <ninten> durandal_1707,  yeah that i submitted to the mentor
[20:38:40 CET] <durandal_1707> But it is better to send to ffmpeg-devel mailing list
[20:39:36 CET] <ninten> durandal_1707,  fine i will make a patch and mail it to devel
[20:40:20 CET] <durandal_1707> Are you subscribed?
[20:41:00 CET] <ninten> durandal_1707,  so since i have better idea of floating point support i should put as one of feature that i will implement in my proposal 
[20:41:44 CET] <durandal_1707> For the encoder?
[20:42:03 CET] <ninten> durandal_1707,  yes i am subscribed from last 1 month .  Yeah for the encoder ??
[20:43:11 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:a089d567f10e: avcodec/jpeglsdec: support PAL1-PAL7
[20:58:43 CET] <nevcairiel> I find it always funny to see people have strong words on the ML, and I've never ever seen their name before
[21:06:37 CET] <BBB> jamrial: do you think it makes sense to backport yesterdays patch to branches that have ffvp9+optimizations in it?
[21:06:54 CET] <BBB> (I dont know which branches that would be)
[21:06:57 CET] <jamrial> i already did to 2.4 onwards
[21:07:17 CET] <jamrial> 2.3 could use it as well, but since that one isn't "maintained" i didn't bother
[21:08:11 CET] <BBB> oh ok
[21:08:11 CET] <BBB> ty
[21:08:20 CET] <BBB> very forward-thinking :)
[21:10:44 CET] <nevcairiel> or backwards, as it may be!
[22:15:29 CET] <BBB> why is side-data not reference-counted?
[22:16:11 CET] <BBB> I think av_frame_ref() is a very evil function in that it actually copies, not reference-incs, the side-data
[22:19:23 CET] <kierank> i guess it was assumed that side data was small compared to video data
[22:20:13 CET] <kierank> but I don't see why the side data can't be referenced too
[23:07:03 CET] <BBB> Ill prepare a patch
[23:10:45 CET] <nevcairiel> i think the argument was that many side data is smaller than the management fields needed to keep track of all the buffers
[23:36:26 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:7517e932ffac: avcodec/snow: fix support for odd dimensions
[00:00:00 CET] --- Mon Mar 23 2015