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

[burek]

[00:21] <cone-504> ffmpeg.git 03Arwa Arif 07master:4c38e960d0ca: avfilter: Port mp=eq/eq2 to lavfi
[00:26] <jamrial> the license.md file should be updated with vf_eq.c
[00:53] <michaelni> jamrial, fixed
[00:53] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:f994000dc5e4: LICENSE.md: add vf_eq
[05:59] <cone-701> ffmpeg.git 03Carl Eugen Hoyos 07master:af39b8fec46b: Fix creation of ffprobe-test.nut on remote targets.
[06:17] <cone-701> ffmpeg.git 03James Almer 07master:f4f061932754: fate: add Camellia test
[10:40] <ubitux> i have issues with lavfi and palettegen
[10:40] <ubitux> i'm currently pushing the last frame only on request_frame()
[10:41] <ubitux> but this makes flushing not work in various cases
[10:41] <ubitux> for instance with ./ffmpeg -f lavfi -i "movie=foo.mp4,palettegen" out.png
[10:41] <ubitux> because there is no final explicit pulling
[10:41] <ubitux> basically my understanding is that i need to push it from filter_frame()
[10:42] <ubitux> but how am i supposed to know that's EOF?
[10:50] <ubitux> i can also likely reproduce with the filtering example
[10:51] <ubitux> but i have no idea what to do in the filter itself to fix that
[10:51] <saste> ubitux, i remind nicolas musing on that
[10:51] <saste> i mean about the problem related to EOF signallin
[10:51] <ubitux> didn't he just fixed it in ffmpeg only?
[10:51] <saste> signalling*
[10:52] <saste> let me see the log, I remind that he pushed the patchset
[10:52] <ubitux> i mean, even with ffplay we have that problem
[10:53] <ubitux> so i probably need to do something at the filter level itself
[10:53] <ubitux> https://github.com/ubitux/FFmpeg/commit/0103b517d4640dfd07806d8395c675f6876d2b4b#diff-b6bc062287c2efb89f813fb89e1a641dR316
[10:54] <ubitux> i have FF_LINK_FLAG_REQUEST_LOOP so basically the request_frame() could return 0
[10:54] <ubitux> (which is the case)
[10:54] <ubitux> maybe i could write the loop form itself
[10:54] <ubitux> to see if it helps
[10:55] <cone-701> ffmpeg.git 03Paul B Mahol 07master:7ccd625a46c5: avfilter/vf_eq: fix leak of input frame
[10:56] <ubitux> i can actually reproduce with ffplay foo.jpg -vf tile
[10:56] <ubitux> typically
[10:56] <ubitux> while it actually works with ffmpeg
[10:57] <nevcairiel> isnt the user-code required to flush the filter graph at eof
[10:57] <nevcairiel> i know my code does that
[10:57] <ubitux> nevcairiel: ffplay doesn't, lavfi device code doesn't, our filtering code doesn't, ... 
[10:57] <ubitux> but yeah, probably
[10:57] <ubitux> (filtering code example*)
[10:59] <nevcairiel> in my usecase i just call av_buffersrc_write_frame with a NULL frame, and that somehow does it .. not sure how that works if your source is actually inside the filter graph
[11:00] <ubitux> you mean av_buffersink_get_frame()?
[11:00] <ubitux> ah, well
[11:00] <nevcairiel> no, i mean what i write :d
[11:00] <ubitux> mmh
[11:00] <ubitux> so you write until get_frame() gives you a EOF?
[11:00] <ubitux> instead of just pulling?
[11:01] <nevcairiel> i write a NULL once and then query get_frame until it errors out
[11:01] <nevcairiel> that seems to work fine
[11:01] <ubitux> (ignoring EAGAIN?)
[11:01] <ubitux> i wonder if the NULL write is necessary
[11:01] <ubitux> but ok
[11:02] <nevcairiel> EAGAIN means it needs more input, so ignoring that when i dont have more input seems kinda pointless
[11:02] <ubitux> i see, ok
[11:03] <nevcairiel> buffersrc has some checks to set eof flags when you feed it a NULL frame, I just figured from that, that I should be sending it one NULL
[11:04] <nevcairiel> otherwise continous pulling with get_frame might not flush frames from the middle of the graph, ie. with yadif which would not process a frame because it waits for the next one to process
[11:05] <nevcairiel> you would get EAGAIN and frames are stuck somewhere
[11:05] <nevcairiel> somehow yadif needs to knwo that there is no more input, and it cant wait for the next frame to do temporal deinterlacing
[11:08] <ubitux> ok
[11:08] <ubitux> thank you :)
[11:08] <nevcairiel> (lack of docs had me read the source of buffersrc and buffersink more than once when writing this)
[11:09] <nevcairiel> you notice lost frames quite quickly if you try to deinterlace single frames, ie. from a dvd menu background image :d
[11:11] <nevcairiel> I figure if you use movie src in a graph, it would figure out on its own when the file EOF's, and can let the downstreams in the graph know all by itself?
[11:13] <ubitux> dunno
[11:13] <ubitux> still have issues here
[11:13] <nevcairiel> well if it could, it would work :D
[11:13] <ubitux> so i get a bunch of EAGAIN, and after flushing i just get a EOF
[11:13] <ubitux> and no frame
[11:13] <ubitux> :(
[11:15] <nevcairiel> softpulldown is the only mp filter left now? we're so close to ditching the whole thing now!
[11:16] <saste> nevcairiel, yes, probably today
[11:16] <saste> ubitux, from what I understand, there is no way to know a frame is the last one in filter_frame()
[11:16] <nevcairiel> softpulldown was the thing that took soft telecine and made it hard telecine?
[11:17] <ubitux> saste: yeah, ok
[11:17] <ubitux> but then i wonder if my logic is correct
[11:17] <ubitux> in the filter, and in the app side
[11:18] <ubitux> like EAGAIN, EAGAIN, ..., EAGAIN, EOF
[11:18] <ubitux> i just get no frame at all :p
[11:18] <nevcairiel> yadif handles the eof logic in request_frame apparently
[11:18] <nevcairiel> so shove it there!
[11:19] <saste> ubitux, i don't think you can do nothing at the filter level
[11:19] <saste> that is, I don't think the palettegen logic can be improved
[11:20] <saste> it sounds more like a generic problem
[11:20] <ubitux> ffmpeg is able to deal with it, so i guess yeah the filter logic might be able to deal with
[11:20] <ubitux> but then following nevcairiel advice, it's not enough
[11:21] <cone-701> ffmpeg.git 03Stefano Sabatini 07master:0ca5c4daded0: lavfi/mp: drop mp=eq and mp=eq2
[11:24] <ubitux> :)
[11:25] <ubitux> too bad such a filter is gpl though
[11:26] <nevcairiel> as all the legacy mplayer stuff, yea
[11:26] <ubitux> i don't mind about the others
[11:27] <ubitux> anyway.. why i don't get any frame...
[11:27] <saste> maybe someone wants to bother and asks the original contributors?
[11:27] <nevcairiel> you know how long those lists of people get with all these old mplayer things
[11:28] <ubitux> maybe i need AV_BUFFERSRC_FLAG_PUSH...
[11:37] <ubitux> doesn't help, wtf...
[11:49] <ubitux> alright
[11:49] <ubitux> it works if i change the filter like this: http://pastie.org/9861751
[11:50] <ubitux> but it's strange because ffmpeg works anyway without that
[11:51] <ubitux> oh well.
[12:07] <saste> ubitux, glad you fixed it :-)
[12:30] <wm4> <ubitux> too bad such a filter is gpl though <- could have been trivially rewritten?
[12:30] <wm4> I mean what the hell
[13:02] <durandal_1707> saste: is arwa going to port softpulldown?
[13:02] <saste> durandal_1707, I don't think so
[13:02] <saste> I think the plan was to get rid of softpulldown
[13:02] <saste> i'm not the telecine guru so someone should comment on that
[13:06] <cone-701> ffmpeg.git 03Carl Eugen Hoyos 07master:fe47cba7e8da: Decode Prores 4444 XQ with the existing Prores decoder.
[13:06] <saste> also carl was telling me that we lack an inverse telecine filter
[13:07] <durandal_1707> what fieldmatch+decimate and pullup do then?
[13:23] <durandal_1707> i'm going to port softpulldown and remove then mp
[13:23] <cone-701> ffmpeg.git 03Paul B Mahol 07master:5a919ced0d3c: avfilter/libmpcodecs: remove unused headers
[13:36] <BtbN> Good job Thunderbird. Failed to copy the mail to the Sent folder, so it sends the mail again.
[13:36] <j-b> yes, lovely, right?
[13:45] <wm4> why would it send the mail again
[13:53] <nevcairiel> because its just not that smart
[14:31] <cone-701> ffmpeg.git 03Paul B Mahol 07master:e44a4c1f5fcb: avfitler/vf_fieldmatch: fix typo
[14:33] <ubitux> durandal11707: ah, i missed "avfitler", is it on purpose?
[14:33] <ubitux> ;)
[14:33] <durandal11707> nope
[14:33] <durandal11707> i'm blind
[14:36] <wm4> avhitler
[14:36] Action: wm4 runs
[15:00] <cone-701> ffmpeg.git 03rogerdpack 07master:c55fa2f09bda: dshow: add properties dialog for tv tuners
[15:00] <cone-701> ffmpeg.git 03rogerdpack 07master:ce1bbb08f127: dshow: alert as to ramifications of switching crossbar routing
[15:00] <cone-701> ffmpeg.git 03rogerdpack 07master:7c2e26270124: dshow: crossbar dialog was frequently being displayed twice, split up option so it can be just once
[15:00] <cone-701> ffmpeg.git 03rogerdpack 07master:61974c7dcca8: dshow: tweak logging
[15:00] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:fcb18ab8d03d: Merge remote-tracking branch 'rdp/dshow_tv_tuner'
[15:03] <j-b> Seriously, how fucking hard is it to ask authors to have a correctly set git name?
[15:03] <j-b> Roger Pack has been in the community for years...
[15:06] Action: compn hides behind wm4
[15:07] <av500> j-b: I guess it passed review on the ml.....
[15:40] <cone-701> ffmpeg.git 03Timo Rothenpieler 07master:914fd42b8ac5: avcodec/nvenc: Fix b-frame parameter handling
[16:22] <ubitux> saste: would you mind documenting in doc/examples or somewhere why AVFilterInOut pointers seems swapped?
[16:23] <ubitux> i mean the inputs being the "out"/sinks and the outputs being the "in"/sources
[16:23] <saste> ubitux, ping me if I don't do it by tomorrow morning
[16:23] <ubitux> it's very confusing and while you explained that to me one or two years ago, i can't figure it out again
[16:23] <ubitux> thank you :)
[16:27] <saste> ubitux, did I explain it? I remind you figured it out by yourself (note: I'm puzzled every time I read that piece of code after a while, so yes it needs some explanations in the comments)
[16:27] <ubitux> i think you did, but maybe i was smarter a while ago
[16:28] <wm4> is there a way to get a unique id per packet? I tried the file position, but it obviously doesn't work
[16:28] <Daemon404> md5sum(packet)
[16:28] Action: Daemon404 runs
[16:29] <nevcairiel> i was going to suggest that, but i decided not to troll!
[16:29] <wm4> Daemon404: doesn't work, different packets can have identical contents
[16:29] <Daemon404> the least painful thing to do might be struct wm4packet { AVPacket; uid; }\
[16:30] <wm4> the hard part is making lavf return wm4packets
[16:30] <Daemon404> why does lavf need to return them
[16:41] <wm4> I'm trying to resume the demuxer from an arbitrary position
[16:41] <wm4> basically, seek back, restart demuxing, and skip packets the decoder has already seen
[16:47] <Daemon404> i see.
[16:48] <Daemon404> i do that too, but only for the first N packets
[16:48] <Daemon404> i used a packet queue system
[16:51] <wm4> in this case, I ant to get packets I didn't get before (deselected streams)
[16:51] <wm4> *want
[16:51] <Daemon404> to what end?
[16:52] <wm4> daster stream switching during playback
[16:52] <wm4> *faster
[16:53] <Daemon404> it sounds a bit funky... wouldnt you have to keep a record of every packet ever seen then?
[16:55] <wm4> no, approximately seeking to the position where your packet queue "starts" works pretty well so far
[16:56] <Daemon404> so if you already have a queue system, why is it so hard to add a uid to that queue system
[16:56] <Daemon404> it seems like putting it in teh avpacket itself is a bad idea
[16:56] <wm4> (I could also just decode everything again, but that'd be noticably slower)
[16:56] <wm4> that's not the problem
[16:57] <Daemon404> oh, cmp.
[16:57] <wm4> I have my buffered packets, right? then, when I seek back, I get new packets from lavf
[16:57] <wm4> and then I need to check whether a lavf packet is already in the queue, or if it's "new"
[16:57] <Daemon404> if this is for stream switching, why cant you just check stream_index
[16:57] <wm4> anyway, I guess this approach is just too fragile
[16:57] <nevcairiel> also, why doesnt pos work?
[16:58] <nevcairiel> shouldnt it be unique for every packet?
[16:58] <wm4> nevcairiel: split packets from parsres
[16:58] <Daemon404> nevcairiel, nope
[16:58] <nevcairiel> well i guess the parser screws those up, but you could just ignore those
[16:58] <wm4> Daemon404: on stream switching, I seek backwards to get packets for the "new" stream
[16:59] <wm4> Daemon404: but I must also continbue to feed correct packets to the decoders associated with already selected streams
[16:59] <Daemon404> sure... but you know which streams are selected
[16:59] <Daemon404> and which were previously not
[16:59] <Daemon404> why cant you check the index
[17:00] <wm4> it's not enough... after seeking back with lavf, lavf will return old packets for streams which were already selected too
[17:00] <wm4> and feeding those to the decoder would fuck up everything
[17:01] <wm4> unless I actually reset the decoder and decode everything again
[17:01] <Daemon404> checkign pos + stream index should mostly always work
[17:01] <Daemon404> except if you changed streams exactly between some parsed packets
[17:01] <Daemon404> which you should simpyl disallow
[17:01] <wm4> that can and does happen
[17:01] <wm4> adds a delay
[17:01] <Daemon404> ONE WHOLE PACKET
[17:01] <Daemon404> HOLY SHIT SLOW
[17:02] <wm4> it's also kind of hard to do
[17:02] <Daemon404> while (pos == prevpos) feed_packet(); ?
[17:03] <wm4> ok, maybe...
[17:04] <wm4> assuming lavf doesn't try to reinterleave packets coming from aprsers or some bullshit
[17:04] <wm4> *parsers
[17:05] <Daemon404> i dont think it does
[17:05] <wm4> still, it's awfully fragile
[17:05] <wm4> I wonder how other players solve this
[17:05] <Daemon404> they dont rice like you
[17:06] <wm4> how is it ricing
[17:06] <wm4> let the user wait for a second after switching audio tracks?
[17:06] <Daemon404> open a new decoder and decode future packets only
[17:07] <Daemon404> kill the old one in the bg
[17:07] <wm4> that would mean decoding from the start again
[17:07] <wm4> for both audio and video
[17:07] <wm4> probably not that bad
[17:17] <durandal_1707> the softpulldown filter in libmpcodecs actually does not work correctly
[17:19] <kierank> quelle surprise
[17:19] <kierank> let's be honest libmpcodecs filters are there for show
[17:25] <jamrial> time to finally rm -rf libmpcodecs then?
[17:26] <durandal_1707> i'm trying to make my port not segfault
[17:28] <wm4> kierank: freakshow?
[17:37] <kierank> myra: would you be interested in working on aes-ni?
[17:38] <cone-701> ffmpeg.git 03James Almer 07master:b8f3b0703c32: tools/crypto_bench: add Camellia support
[17:42] <myra> kierank : I haven't done much programming in x86 language. But I would love to do it and learn if it's not urgent. 
[17:50] <durandal_1707> wm4: in mpv softpulldown dmpi is never returned only modified
[17:59] <wm4> yeah, looks very broken
[18:00] <wm4> I'll delete it later
[18:01] <wm4> don't think anyone even tried to use it
[18:01] <cone-701> ffmpeg.git 03Kevin Wheatley 07master:7b6f4191763a: avformat/movenc: Add simplistic 'colr' tag writing support to mov container
[18:32] <cbsrobot_> jpeg2000 can have multiple layers with different compression rates - would it be accepted to pass the quality and no. of layers in command line like this: 0,10,20,30 ? 
[18:32] <cbsrobot_> or has anyone a better idea ?
[19:44] <compn> cbsrobot_ : you just want to know what escape character to use ? or if it should be read from a file or something?
[19:44] <compn> but: i dont know the answer anyways. :)
[21:16] <llogan> http://ffmpeg.gusari.org/viewtopic.php?f=13&t=1902&p=5379#p5379
[21:16] <llogan> I should have him write news releases, tweets, etc.
[21:20] <kierank> llogan: lol
[21:22] <llogan> kierank: no reply from BL.
[21:22] <kierank> :(
[21:23] <llogan> i'll prod them again in a week or so
[21:24] <llogan> kierank: can you find an existing user?
[21:25] <kierank> nope
[21:56] <cone-701> ffmpeg.git 03Andreas Cadhalpun 07master:7e857cd57108: configure: use ar and ranlib in deterministic mode
[23:05] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:5a1e524ba7e5: Revert "configure: use ar and ranlib in deterministic mode"
[00:00] --- Tue Jan 27 2015