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

[burek]

[00:02:50 CET] <andrewrk> so, ffmpeg has a chromaprint muxer, but chromaprint depends on ffmpeg
[00:25:08 CET] <nevcairiel> i dont think thats the only of those circular deps
[01:34:06 CET] <rcombs> andrewrk: both deps are optional
[01:34:29 CET] <rcombs> andrewrk: I recommend building chromaprint without ffmpeg support
[01:34:40 CET] <rcombs> it's just for an example program iirc
[01:35:34 CET] <rcombs> when I added the chromaprint "muxer", the ffmpeg code in chromaprint actually didn't build against ffmpeg master because it used ancient deprecated stuff that'd been removed
[01:35:52 CET] <rcombs> I think they've fixed that since but eh who cares just turn it off
[01:46:14 CET] <andrewrk> rcombs, are you sure the chromaprint internals don't depend on ffmpeg?
[01:46:20 CET] <andrewrk> for fft
[01:46:29 CET] <rcombs> andrewrk: they can, optionally
[01:46:38 CET] <rcombs> they support a few FFT libs
[02:10:46 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:6b7ce0ea0d62: avformat/avio: Fix unknown protocol handling
[03:45:02 CET] <Shiz> ~/w 13
[07:29:30 CET] <JEEB> ugh the mkv "cropping" field which was only meant for rewriting avc parameter set values in realitt
[07:30:11 CET] <JEEB> even the matroska standardization thing was struggling with it due to how badly it was defined
[08:09:53 CET] <wm4> JEEB: lol
[08:12:10 CET] <JEEB> I would guess it came out of Haali noticing that some AVC streams had broken cropping values in the parameter sets
[08:12:21 CET] <JEEB> thankfully, those could be "easily" replaced in DShow in the splitter
[08:12:43 CET] <JEEB> so you got a feature that promised much more but was supposed to be this simple thing :P
[08:13:05 CET] <JEEB> and then people started using it to crop 4:3 things encoded in 16:9 with borders for blu-ray :P
[08:20:21 CET] <wm4> really, did they
[08:21:19 CET] <wm4> never noticed any such file
[08:22:28 CET] <JEEB> there's some users that do that at least, I've always replied with E_NOT_GONNA_FIX where such have come around, although VLC has added support for it
[08:22:31 CET] <JEEB> lol
[08:25:35 CET] <wm4> until ffmpeg gets cropping rects there's no way I'd add support
[08:40:35 CET] <TD-Linux> I would be all for removing the crop rect feature entirely, but some people want it to preserve the overscan areas
[08:42:05 CET] <TD-Linux> the real question is, if you have an avc file with cropping, inside a mkv with cropping, are they cumulative?
[08:48:47 CET] <nevcairiel> there never has been a clear specification of how container and codec cropping interact, not even to start with cases where the video stream changes cropping info mid-stream or even size
[08:59:11 CET] <JEEB> yeah
[08:59:17 CET] <JEEB> that stuff would have to be clearly specified
[09:27:05 CET] <JEEB> hmm, how did you set lavf protocol parameters again?
[09:27:13 CET] <JEEB> I mean on the cli
[09:27:29 CET] <JEEB> it seems like some network protocols like TCP have custom parsing from the URL
[09:27:38 CET] <JEEB> I tried adding a timeout functionality to file://
[09:28:06 CET] <nevcairiel> why would a file have a timeout
[09:29:30 CET] <JEEB> files that are still being written?
[09:29:54 CET] <JEEB> there's already logic for retrying until the rw_timeout is over in the IO stuff
[09:30:20 CET] <JEEB> I just have to make reads return AVERROR(EAGAIN)
[09:30:29 CET] <JEEB> when read returns 0
[09:30:53 CET] <JEEB> that way you can have lavf trying to read for another N amount of time after it first reached EOF
[09:31:25 CET] <wbs> JEEB: I actually happen to have a patchset that does _exactly_ this
[09:31:47 CET] <JEEB> lol
[09:32:03 CET] <wm4> seems like a questionable feature
[09:32:15 CET] <JEEB> better than -re methinks?
[09:32:19 CET] <wm4> also could be done as nested protocol
[09:32:23 CET] <wbs> JEEB: -re does something _completely_ different
[09:32:30 CET] <JEEB> yes, -re reads the timestamps
[09:32:36 CET] <wbs> no, -re throttles the input
[09:32:38 CET] <JEEB> and tries to limit itself to real time
[09:32:39 CET] <wbs> yes
[09:32:43 CET] <JEEB> yes
[09:33:41 CET] <wbs> JEEB: have a look at https://github.com/mstorsjo/libav/commits/read-follow; some of the commits may be unrelated to your thingie, and it's obviously based on libav
[09:33:48 CET] <JEEB> danks
[09:33:58 CET] <JEEB> I already have some code written but it will probably look rather similar
[09:34:27 CET] <JEEB> also I got tired from having to stare at a hex editor so I implemented tfxd in L-SMASH's boxdumper
[09:34:30 CET] <JEEB> http://up-cat.net/p/7085f7a9
[09:34:53 CET] <wbs> nice, is it upstreamed?
[09:36:21 CET] <JEEB> I once accidentally upstreamed it into a branch (it was 3 in the morning...) but for now it's still WIP so it's only in my fork's branch for now
[09:36:46 CET] <JEEB> well, I wrote the parsing literally last night
[09:37:00 CET] <JEEB> so give me a bit and I will make a pull request to have it reviewed by VFR Maniac
[09:37:08 CET] <JEEB> https://github.com/jeeb/l-smash/tree/jeeb/feature/tfxd_box
[09:37:16 CET] <JEEB> is the current code
[09:37:59 CET] <JEEB> L-SMASH lacks support for non-generic UUID boxes so I had to hack things into the UUID parsing part of code :D
[09:38:17 CET] <JEEB> "oh btw, if the UUID is this, just set this box type plz"
[09:39:23 CET] <JEEB> also I'm way breaking pointer aliasing rules with https://github.com/jeeb/L-SMASH/commit/abcd8edf3af73c46a242d96214a2369ae3de9ea7#diff-7ea05f1bf2450357f73142a6db5e468dR102
[09:40:00 CET] <JEEB> reinterpreting uint8 array's points as uint32_t pointers and then taking their value :P
[09:40:32 CET] <nevcairiel> i find it rather odd that you write one BE and three LEs
[09:40:46 CET] <JEEB> I was looking at how boxdumper printed it out...
[09:40:53 CET] <JEEB> it was incorrect unless I did it like that
[09:41:38 CET] <nevcairiel> maybe you are supposed to print it byte-wise
[09:42:25 CET] <JEEB> possibly, but I didn't want to poke a completely unrelated generic UUID printing code
[09:42:48 CET] <JEEB> so I just switched reading the UUID so that I could just memcmp it against the tfxd UUID
[09:43:10 CET] <JEEB> and then made sure I copied it over to whatever boxdumper was using in case of generic UUID box :)
[10:37:48 CET] <JEEB> wee, it seems to work
[10:38:06 CET] Action: JEEB is using curl (limited to 300kbps) +ffmpeg to test this thing
[11:21:59 CET] <JEEB> wm4: so you would oppose a patch that doesn't change default behavior but does add a timeout parameter for file reads?
[11:22:31 CET] <JEEB> since this thing seems to work rather well with curl limited to 300kbps
[11:23:31 CET] <wm4> a mode to read from an file being appended sounds fine, but having a timeout for this sounds sketchy at best
[11:24:33 CET] <JEEB> yeah, not sure if the timeout is actually needed
[11:24:55 CET] <JEEB> I just don't like unlimited retries
[11:26:46 CET] <JEEB> the timeout logic is already there in the IO stuff so I was just using that
[11:32:13 CET] <wbs> wm4: any better way of exiting when the written file stops being written to?
[11:32:40 CET] <wm4> there's no way to detect this, so I'd say the user has to do that
[11:34:42 CET] <JEEB> for network streams timeout+retries is used it seems
[11:34:50 CET] <JEEB> so I thought it'd be convenient to use the same logic
[11:38:34 CET] <JEEB> and yes, in a perfect world you have one app tell the other that "hey, btw, I've finished writing to this file"
[11:38:37 CET] <JEEB> :)
[11:39:47 CET] <wbs> JEEB: it could also be shared network storage
[11:39:50 CET] <JEEB> but so far I can see it being useful to have retries with a timeout, esp. since we already have the IO reading rw_timeout
[11:39:53 CET] <JEEB> wbs: yeah
[11:40:13 CET] <wbs> so timeout seems to me like the only sensible option unless you want user intervention (which wasn't an option for the case I built it for)
[11:40:43 CET] <JEEB> yup
[11:40:54 CET] <JEEB> and I have noted this on another channel and people were already seeing uses for it
[11:41:04 CET] <wm4> anyway, I still think this should be a recursive protocol
[11:41:10 CET] <wm4> rather than hacking it into file
[11:41:37 CET] <JEEB> I don't see it being a hack since it's already done the same way for network protocols?
[11:42:01 CET] <wbs> wm4: you mean the timeout, or the option for allowing different handling of "EOF"?
[11:42:21 CET] <wbs> the timeout is all in the general avio/urlcontext code, none of it within the file protocol itself
[11:42:35 CET] <JEEB> yeah
[11:43:05 CET] <wm4> the retry thing, then
[11:43:17 CET] <wbs> the retry thing is _also_ in avio/urlcontext general code
[11:43:43 CET] <wbs> if a network protocol returns AVERROR(EAGAIN), the framework will retry up until the given timeout, or infinitely
[11:43:58 CET] <JEEB> yeah, the only change other than adding the avoption is that read() will return AVERROR(EAGAIN) if timeout is enabled and read() returned 0
[11:44:09 CET] <wm4> then... make it an option that works for all protocols?
[11:44:10 CET] <JEEB> that way default behavior won't change
[11:44:34 CET] <wbs> wm4: that doesn't make much sense though
[11:44:49 CET] <wbs> only local files has got the property that once you've reached EOF and read() returns 0, you can retry later
[11:44:50 CET] <JEEB> those protocols that support it already have the "timeout" avoption
[11:45:06 CET] <JEEB> which set the rw_timeout
[11:45:10 CET] <wbs> imagine http, if you reach the end of the file, you can't just try to read again in a little while to see if there's more, that'd require you starting a fully new request
[11:45:35 CET] <JEEB> I saw tcp and ftp using it at least
[11:45:43 CET] <JEEB> git grep 'rw_timeout' basically
[11:46:59 CET] <wbs> so the logic for EOF -> don't close but pretend it's EAGAIN, only works for files and thus that option is within the file protocol
[11:47:22 CET] <JEEB> well you could say that the option is already global :P
[11:47:26 CET] <JEEB> since rw_timeout is already global
[11:47:38 CET] <JEEB> so those protocols that support it can set it through their AVOptions
[11:47:51 CET] <wbs> JEEB: it's not about the timeout, wm4 already was ok with that
[11:47:55 CET] <JEEB> ah,ok
[11:48:03 CET] <wm4> then just ignore me
[11:48:15 CET] <wbs> he argues that the eof->egain thing should also be a generic option, not specific to file, which I say isn't a good idea
[12:47:23 CET] <petru> Hi there! I have a doubt. How can I add a selftest to makefile. For example, I would like to do "make fate-display" but the display-test.* files are not generated
[12:48:19 CET] <petru> Briefly, I am trying to do something like "make fate-pixelutils"
[12:50:43 CET] <petru> this is to generate an executable file pixelutils-test
[12:53:21 CET] <wm4> petru: we have a bunch of such tests, did you look at them?
[12:56:06 CET] <petru> yeah, I added "#ifdef TEST" to display.c. I modified the tests/fate/libavutil.mak but I can't make the executable display-test
[13:04:49 CET] <petru> the problem is that when I do "make diplay-test" Make throws me the following error: "No rule to make target `libavutil/display-test', needed by `fate-display'". Do you know which Makefile I need to modify to make "display-test"?
[13:05:06 CET] <nevcairiel> libavutil/Makefile probably
[13:05:32 CET] <petru> ok, I will take a look. Thanks :)
[13:08:39 CET] <nevcairiel> generally the makefile in the directory the file is in is responsible for it
[13:12:26 CET] <petru> Yes, you were right. I needed to add to make the "display" executable. Thanks for your help :)
[13:35:34 CET] <jkqxz> nevcairiel:  I didn't pursue further than observing the failure in ff_hevc_split_packet() and fixing it there.  (I was hoping the bug would be more interesting than that, tbh.)
[13:40:19 CET] <wm4> there are plenty of interesting bugs to pick from
[13:42:14 CET] <jkqxz> It would probably be worth having a stream full of zeroes as a FATE test; maybe I'll have a go at handcrafting something nasty.  (For H.264 at least you could just use intra4x4 vertical without cabac everywhere and the stream would be full of emulation prevention.)
[13:42:53 CET] <nevcairiel> well zeros within the NALs are supposed to be escaped and shouldnt be a problem, but those zeros are part of the AnnexB syntax and not escaped
[13:44:44 CET] <nevcairiel> strictly speaking just skipping zeros is more correct, but on the other hand the rbsp parser would consider any non-zeros to be part of the NAL anyway, unless they are preceeded by zeros again =p
[13:46:01 CET] <nevcairiel> it seems harmless to downgrade the error to a warning if it could extract some valid NALs, to me anyway
[13:46:17 CET] <jkqxz> So a new patch which just changes the return to only be an error if pkt->nb_nals == 0?
[13:47:11 CET] <nevcairiel> some day i should make it use the optimized start code finding function
[13:47:58 CET] <nevcairiel> but yes, thats what I would suggest
[15:21:12 CET] <cone-092> ffmpeg 03James Almer 07master:626b6b769ced: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct
[15:21:12 CET] <cone-092> ffmpeg 03James Almer 07master:f875ba48739f: libwebpenc_animencoder: print library messages in verbose log levels
[15:47:38 CET] <Daemon404> hmm
[15:47:45 CET] <Daemon404> erankor is not on irc, correct?
[15:47:49 CET] <Daemon404> (the cenc guy)
[16:22:02 CET] <JEEB> Daemon404: I don't think he is
[16:29:54 CET] <mohak> Hi everyone, I'm Mohak. I was interested in two of ffmpeg's gsoc projects. I know I"m a little late; but I hope to submit a good proposal before the deadline with a little guidance.
[16:31:31 CET] <durandal_170> proposal is void without completed qualification task
[16:37:01 CET] <mohak> Right. I just wanted a little help choosing from the 2 projects and then start working on the qualification task. Is it ok to ask my questions over irc or should I instead use the mailing list?
[16:37:12 CET] <mohak> Sorry. I'm a bit new to irc.
[16:37:37 CET] <durandal_170> you can ask on both
[16:38:27 CET] <durandal_170> you will get answer if mentor for project is available on irc
[16:42:53 CET] <mohak> Alright. In that case I should probably use the mailing list or directly email the mentors assigned to those projects. Thanks durandal_170!
[17:00:20 CET] <cone-092> ffmpeg 03Michael Niedermayer 07master:7660c135a30e: avformat/segment: Fix "occured" typo
[17:00:21 CET] <cone-092> ffmpeg 03Michael Niedermayer 07master:83df0a84a99d: avcodec/motion_est_template: Fix map cache use in qpel_motion_search()
[17:38:11 CET] <cone-092> ffmpeg 03James Almer 07release/2.7:c5e12dc10de8: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct
[17:38:12 CET] <cone-092> ffmpeg 03James Almer 07release/2.7:d2161b8a6daf: libwebpenc_animencoder: print library messages in verbose log levels
[17:38:13 CET] <cone-092> ffmpeg 03James Almer 07release/2.8:76c157cfd754: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct
[17:38:14 CET] <cone-092> ffmpeg 03James Almer 07release/2.8:175110a04128: libwebpenc_animencoder: print library messages in verbose log levels
[17:38:15 CET] <cone-092> ffmpeg 03James Almer 07release/3.0:20d89a3a3271: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct
[17:38:16 CET] <cone-092> ffmpeg 03James Almer 07release/3.0:373bc77a356a: libwebpenc_animencoder: print library messages in verbose log levels
[18:04:21 CET] <Compn> mohak : well you can ask here too
[18:04:26 CET] <Compn> what projects were you interested in ?
[18:06:09 CET] <mohak> Oh, ok. I'm interested in 1. MPEG-4 Audio Lossless Coding (ALS) encoder and 2. Improve the tee muxer
[18:13:23 CET] <Compn> mohak : do you have any experience with rice or other algorithms needed for writing an als encoder ?
[18:13:44 CET] <Compn> i think atomnuker knows about the als encoder project. its going to be very very difficult
[18:25:09 CET] <mohak> No I do not. I thought the major part of the project would be porting the existing encoder at https://github.com/justinruggles/FFmpeg-alsenc. 
[18:30:25 CET] <Daemon404> thats very incomplete isnt it
[18:39:30 CET] <wm4> rcombs: someone asking about hw encoding on RPI, maybe you could link him your old patch or so? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191672.html
[18:39:58 CET] <rcombs> I don't even know where the old stuff is, and my current branch is very broken
[18:40:28 CET] <wm4> yeah, thought it'd be something like this
[18:41:23 CET] <wm4> wait why does this guy have a gcc.gnu.org email address
[18:53:25 CET] <kierank> time to quickly shoot down that gsoc project
[18:53:37 CET] <kierank> before certain people approve it
[19:23:45 CET] <jamrial> kierank: i agree with you, but you should at least give a reason when you shoot it down. either the student or someone else will inevitably ask for one
[19:24:28 CET] <Daemon404> Hi,
[19:24:30 CET] <Daemon404> Get bent.
[19:24:33 CET] <Daemon404> - Derek
[19:24:35 CET] Action: Daemon404 runs
[19:31:27 CET] <durandal_170> what happened?
[19:55:11 CET] <Compn> durandal_170 : new project idea from student.
[19:55:34 CET] <Compn> why would you need a mouse control using camera + hand signals on a touchscreen android phone ?
[19:56:06 CET] <Compn> samsung has 'air gestures' so maybe this would be an open source version of that
[19:56:14 CET] <atomnuker> because the last person who tried it obviously did it badly
[19:56:43 CET] <atomnuker> or probably did not realize it's a crappy input mechanism
[19:57:08 CET] <Compn> although i dont use air gestures.
[19:57:30 CET] <Compn> cant even get my phone screen to go on or off when it auto dims to take a phone call
[19:57:40 CET] <Compn> i am not good with computer how did i get here
[19:59:41 CET] <Compn> oh i guess the air gesture uses proximity sensor, not camera. my bad.
[20:01:22 CET] <TD-Linux> it's also been implemented 1000 times with OpenCV by this point
[20:02:52 CET] <phh> Compn: well rather than android phones, on Android TV
[20:03:10 CET] <TD-Linux> including by gstreamer
[20:03:23 CET] <Compn> so then basically 'kinect' 
[20:03:58 CET] <phh> I think kinect is a bit too short range for that
[20:06:57 CET] <wm4> gstreamer implements mouse gestures?
[20:15:31 CET] <Compn> mouse gestures are useful in web browsing. dunno about hand > mouse gestures
[20:16:11 CET] <Compn> e.g. hold left click then hit right click means go forwards. hold right and click left goes back. 
[20:16:47 CET] <Compn> never got into voice control, although i've tried it
[20:16:55 CET] <Compn> aside from voice google searches
[20:17:16 CET] <Compn> anyone use voice control on computer ?
[20:25:58 CET] <TD-Linux> wm4, well, it's more of an example of how to make opencv based gstreamer plugins
[00:00:00 CET] --- Fri Mar 18 2016