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

[burek]

[00:31:07 CET] <rcombs> ubitux: lavf exports a eia_608 stream
[00:31:25 CET] <rcombs> I'm looking at that and getting not much of use
[00:32:02 CET] <rcombs> (`ffmpeg -i sample.wtv -f ass -`)
[00:32:51 CET] <michaelni> Hi everyone, ive switched trac DNS over to the telepoint server, it should all just work like before in theory, if something breaks tell me (we can also easily switch back quickly if there are non trivial problems)
[00:33:21 CET] <michaelni> as long as the old server is alive with its disk that is ...
[00:33:27 CET] <kierank> it has raid 1
[00:33:32 CET] <kierank> it'll survive
[00:33:43 CET] <michaelni> yes
[00:34:59 CET] <kierank> how are you syncing the two severs?
[00:36:41 CET] <Timothy_Gu> michaelni: https://github.com/FFmpeg/FFmpeg/pull/178/files is ok right?
[00:37:01 CET] <ubitux> rcombs: yeah, extracting cc doesn't work that way
[00:37:10 CET] <michaelni> kierank, rather primitively, running beastds bak-daily script (which does all he hot copy magic) then plain rsync of that and same manual fixup 
[00:37:20 CET] <ubitux> rcombs: you need to use the trick i used above (see ())
[00:37:31 CET] <michaelni> this should work fine both directions btw
[00:37:36 CET] <ubitux> rcombs: don't ask me why it's done that way, it's probably because of bad reasons
[00:38:27 CET] <rcombs> ubitux: so why does lavf expose a stream at all, then?
[00:38:34 CET] <rcombs> ubitux: and it outputs packets
[00:38:48 CET] <rcombs> (the CC decoder doesn't like those packets, but it does output them)
[00:39:45 CET] <ubitux> really?
[00:40:06 CET] <rcombs> also I'd imagine it's because of the subtitle data being embedded in the H.264 bitstream and output from the decoder as side data, but that's awful design at every level
[00:40:23 CET] <ubitux> yeah
[00:40:28 CET] <ubitux> but what are these packets then?
[00:40:38 CET] <michaelni> Timothy_Gu, if it builds, yes
[00:40:40 CET] <rcombs> that was my question
[00:42:32 CET] <rcombs> gotta run now, though
[00:43:22 CET] <Timothy_Gu> michaelni: yeah it builds. Ill push it soon
[00:46:05 CET] <cone-479> ffmpeg 03Reto Kromer 07master:f8d685270e58: avienc: Remove unused variable 'ret'
[00:48:38 CET] <ubitux> rcombs: so it looks like they're missing encapsulation somehow
[02:27:55 CET] <atomnuker> ubitux: what happened with the patch that set thread names?
[03:45:43 CET] <cone-479> ffmpeg 03Mats Peterson 07master:a51d82b85c83: lavf/avienc: Add palette after BITMAPINFOHEADER
[03:45:44 CET] <cone-479> ffmpeg 03Michael Niedermayer 07master:bb629792a275: avformat/avienc: Fix assertion failure with 256 palette entries
[04:02:26 CET] <cone-479> ffmpeg 03Mats Peterson 07master:100167451af5: lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette
[05:07:31 CET] <michaelni> We still need more backup mentors: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016
[07:20:15 CET] <rcombs> ubitux: that stream allegedly works in Windows Media Center
[09:46:27 CET] <jya> is there a documentation slightly more expansive for libavfilter than https://ffmpeg.org/libavfilter.html ? i found one on libav.org but I get parsing error when I follow it
[09:47:58 CET] <nevcairiel> easiest probably is reading the example
[09:48:34 CET] <jya> nevcairiel: and where would that example be ? :)
[09:48:46 CET] <nevcairiel> doc/examples/filtersomething
[09:49:01 CET] <nevcairiel> filtering_video.c
[09:49:05 CET] <nevcairiel> or audio
[09:49:08 CET] <nevcairiel> whichever you like
[09:49:23 CET] <jya> avfilter_graph_parse2 looked like quite easy to use, all done through a string. more so than creating each filter and input / output manually and linking them
[09:50:07 CET] <nevcairiel> thats how the examples work too, they declare input/output explicitly and then use graph parsing to connect them
[09:52:53 CET] <jya> ok, i must be looking at something else then.. I had started with the doc there: https://libav.org/documentation/libavfilter.html#yadif not realising that it was the libav.org 
[10:31:49 CET] <ubitux> atomnuker: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188334.html
[10:36:26 CET] <jya> nevcairiel: LOL, my code didn't work because I had never called avfilter_register_all
[12:57:43 CET] <jya> is it expected that regardless of the yadif filter mode set, you always need to pass two frames to get one out ? after the first one I always get EAGAIN
[13:02:09 CET] <iive> jya: are you sure it is yadif issue? not b-frame decoder lag?
[13:02:40 CET] <nevcairiel> yadif is temporal, it always works on more frames
[13:02:54 CET] <nevcairiel> if you only have one frame overall, you can EOF the filtergraph and get it out
[13:03:04 CET] <jya> iive: i passed decoded yuv420 frames (from an mpeg2 recordings)
[13:04:20 CET] <jya> my aim is only to replace avpicture_deinterlace.
[13:04:45 CET] <jya> the replacement provided is a million times more complicated to use (this is to generate the preview picture of a recording)
[13:05:10 CET] <jya> nevcairiel: thanks, i'll try eof the thing then
[13:05:27 CET] <jya> (after i found out how it is i can do that)
[13:08:57 CET] <jya> nevcairiel: the yadif filter doc states "Output one frame for each frame. " ; it's a bit misleading
[13:09:19 CET] <nevcairiel> that doesnt mean there is no delay
[13:09:51 CET] <ubitux> aaaand i'm done
[13:10:56 CET] <atomnuker> ubitux: so is there really no way to test for whether the functions exist reliably?
[13:11:13 CET] <ubitux> i didn't find a way
[13:11:36 CET] <atomnuker> mpv has had that feature for a while
[13:11:38 CET] <ubitux> there is probably a solution
[13:11:54 CET] <ubitux> feel free to give it a try :)
[13:12:07 CET] <jya> nevcairiel: to send EOF to the filter, do you use avfilter_graph_queue_command ?
[13:12:21 CET] <nevcairiel> no you just feed NULL frames through the graph
[13:12:24 CET] <nevcairiel> like flushing a decoder
[13:12:31 CET] <jya> oh I see.
[13:13:13 CET] <jya> only one null to send?
[13:16:57 CET] <ubitux> no, as much as you can
[13:17:17 CET] <ubitux> frames can be stuck in batches anywhere in the graph
[13:19:17 CET] <jya> ubitux: so I feed this to the graph until I can read one out ?
[13:20:57 CET] <nevcairiel> one NULL frame is enough
[13:21:07 CET] <nevcairiel> buffersrc wont accept anymore
[13:21:13 CET] <nevcairiel> it just sets the EOF flag anyway
[13:21:19 CET] <ubitux> oh wait i thought you wanted to flush
[13:21:29 CET] <ubitux> and get all the remaining frames
[13:21:49 CET] <nevcairiel> you send one NULL frame and then keep polling buffersink until it stops giving you frames
[13:21:50 CET] <jya> ubitux: i have one frame (interlaced) to feed, and just want one out.
[13:22:04 CET] <jya> the image out is rather small anyway, just to display in the list of recordings made
[13:29:23 CET] <michaelni> kierank, your trac server is timing out, i wanted to check some configs on it
[13:30:04 CET] <michaelni> ssh: connect to host fftrac-gb.ffmpeg.org port 22: Connection timed out
[13:34:24 CET] <jya> nevcairiel: thank you for your help, I have my picture now.. Was just about to give up and copy the old code of avpicture_deinterlace
[13:37:19 CET] <kierank> michaelni: I pressed reset
[13:41:24 CET] <michaelni> ok login works again, thanks
[14:34:53 CET] <durandal_1707> kierank: whats happening with your servers?
[14:35:09 CET] <kierank> durandal_1707: disk failure
[14:36:04 CET] <durandal_1707> how old?
[15:01:11 CET] <iive> single disk?
[15:02:08 CET] <cone-318> ffmpeg 03Oliver Collyer 07master:a2f8beef2dfa: ffserver&ffm: Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming.
[15:02:08 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:0910488a1621: avformat/riffenc: Also check codec tag before setting raw_pal_avi
[16:08:23 CET] <ubitux> Timothy_Gu: MongoError: document is larger than the maximum size 16777216
[16:08:29 CET] <ubitux> seems i can't submit to fate anymore :P
[16:08:33 CET] <ubitux> (drd)
[16:08:44 CET] <JEEB> so we got mongo and no proper db?
[16:08:59 CET] <ubitux> no idea
[17:28:15 CET] <durandal_1707> why vc2enc includes ffversion.h?
[17:28:47 CET] <durandal_1707> its getting recompiled all the time
[17:30:19 CET] <atomnuker> durandal_1707: to output the ffmpeg version as a comment to the bitstream
[17:32:29 CET] <jamrial> shouldn't you use libavcodec version instead?
[17:32:54 CET] <JEEB> that isn't generally as useful
[17:32:55 CET] <rcombs> call av_version_info()?
[17:33:04 CET] <JEEB> and yes, av_version_info() could be a better one
[17:33:13 CET] <JEEB> unless it has too much info
[17:33:16 CET] <JEEB> or whatever
[17:33:24 CET] <rcombs> literally returns FFMPEG_VERSION
[17:33:38 CET] <atomnuker> will replace it in a few minutes
[17:33:39 CET] <rcombs> i.e. the contents of ffversion.h
[17:34:43 CET] <rcombs> alternately, lavc/utils.c provides `const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;`
[17:35:45 CET] <jamrial> i insist, the library is what encoded the video. why should the bitstream report the git repo revision (or the ffmpeg version if it's a release) instead of avcodec's version?
[17:36:18 CET] <atomnuker> jamrial: that's what I'd like to use too
[17:36:26 CET] <atomnuker> but I couldn't find a header which provides that version
[17:37:01 CET] <jamrial> LIBAVCODEC_IDENT
[17:37:08 CET] <rcombs> ^
[17:37:23 CET] <jamrial> libavcodec/version.h
[17:37:25 CET] <rcombs> <lib>/version.h
[17:37:45 CET] <jamrial> plenty of macros for different needs. stringified or not
[17:41:29 CET] <cone-318> ffmpeg 03Rostislav Pehlivanov 07master:dc0481f2fbae: vc2enc: use LAVC_INDENT instead of FFMPEG_VERSION for encoder comment
[17:41:33 CET] <atomnuker> done
[17:51:27 CET] <jamrial> great, thanks
[17:54:35 CET] <jamrial> atomnuker: this should for that matter be hardcoded to "Lavc" when bitexact output is requested
[17:54:55 CET] <jamrial> for when you add vsynth tests
[18:32:21 CET] <cone-318> ffmpeg 03James Almer 07master:778439b69a63: avcodec/webp: move exif_metadata outside of WebPContext
[19:19:19 CET] <Timothy_Gu> ubitux: you can ignore that error
[19:19:41 CET] <ubitux> sounds good to me
[19:21:19 CET] <Timothy_Gu> ubitux: I started migrating data to a mongo db so that when I want to extract some data i don't have to write a CSV parsing function every single time
[19:24:56 CET] <Timothy_Gu> and so far it's only your DRD (and TSan) instances that's causing this error :P
[19:25:46 CET] <ubitux> drd, helgrind, and tsan yes
[19:25:59 CET] <ubitux> mongo is not reliable though... but whatever
[19:26:11 CET] <ubitux> not sure why you want to write your own csv parsing lib
[19:26:31 CET] <Timothy_Gu> because right now every report is stored as two different CSV files
[19:26:42 CET] <Timothy_Gu> one has all the metadata
[19:27:21 CET] <Timothy_Gu> the other is called "report" and contains all the tests in the format "<testname>:<status>:<base64-encoded diff>:<base64-encoded stderr"
[19:27:29 CET] <Timothy_Gu> (report is xz'd)
[19:27:41 CET] <ubitux> i mean csv parsing libs already exist and are probably less overkill than mongo
[19:29:08 CET] <Timothy_Gu> well say I want to see which commit broke a commit, in a shell. It's either a line of mongo query or a well-thought out line of xz+grep+awk/cut
[19:29:41 CET] <Timothy_Gu> plus mongo is about 7x smaller than the existing architecture
[19:43:48 CET] <beastd|2> Timothy_Gu: I am not arguing because I don't understand what you wnat to accomplish. But if your CSV data (is strictly restricted, never needs quoting) just decompress and awk should be quite effective. In other cases using a real CSV tool/module to process the files might make more sense.
[20:09:30 CET] <cone-318> ffmpeg 03Alex Agranovsky 07master:6dc1d5f87ced: lavf/mpjpeg: probe should not depend on Content-Length MIME header being present
[20:09:31 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:0028da36cdb9: avformat/mpjpegdec: add AVFMT_NOTIMESTAMPS
[20:28:43 CET] <jamrial> j-b: why haven't you guys removed the ffmpeg libavcodec blacklist on vlc yet? the hwaccel change has been reverted on git head for a few weeks now and made it on time for ffmpeg 3.0
[20:40:36 CET] <ubitux> what's the purpose of the sws alpha config?
[20:40:50 CET] <ubitux> why wouldn't you want alpha support?
[20:41:03 CET] <ubitux> just smaller binary size?
[20:51:25 CET] <wm4> jamrial: troll payback, maybe
[20:59:01 CET] <Gramner> jamrial: go poke courmisch
[21:27:30 CET] <jamrial> wm4: for what?
[21:35:11 CET] <cone-318> ffmpeg 03Paul B Mahol 07master:2b5b0011823c: doc/filters: fix nnedi typos
[22:07:15 CET] <j-b> jamrial: see the ticket.
[22:15:44 CET] <jamrial> j-b: yes, i see it's being tracked. my question is why it hasn't been done already. five days since the trac task was added is more than enough to revert a single commit, or change the version check range if deemed necessary
[22:15:58 CET] <jamrial> distros are doing crazy stuff to workaround this, like Arch who nows ships both ffmpeg 2.8 and 3.0 and forces vlc 2.2.2 to use the former when it shouldn't be necessary
[22:16:27 CET] <j-b> jamrial: sorry, but I do not care
[22:17:08 CET] <j-b> The ticket is quite clear why the current situation is worse than before
[22:18:28 CET] <j-b> "That does not make much difference. This is even worst. Now instead of failing, the application will execute unsupported code. (And users will file bugs here that VLC triggers warnings.) "
[22:18:38 CET] <jamrial> i don't agree. the hwaccel infrastructure is now the same as it was months ago, except it now emits a warning
[22:19:17 CET] <jamrial> said "unsupported code" was executed before, and it would be executed now
[22:19:26 CET] <j-b> it was not unsupported before.
[22:19:28 CET] <j-b> now it is.
[22:19:36 CET] <j-b> and now any commit can break it.
[22:19:53 CET] <j-b> and your answer will be "it's unsupported, we don't care"
[22:20:14 CET] <jamrial> no, i'm not among the people that give that kind of answer
[22:22:01 CET] <j-b> maybe not you, but other will
[22:23:01 CET] <jamrial> j-b: we rolled back a change for the sole purpose of undoing a downstream breakage. it's disingenuous to assume we would carelessly break it again
[22:24:00 CET] <j-b> If it is now unsupported, it means it's ok to break it
[22:25:06 CET] <wm4> well who cares, vlc can stay on 2.8 forever
[22:25:12 CET] <jamrial> if it were ok to break it, we wouldn't have rolled back anything to being with
[22:25:18 CET] <wm4> clearly they're not interested in actually solving this situation
[22:26:04 CET] <j-b> jamrial: then what is this warning about?
[22:26:46 CET] <j-b> wm4: indeed, who cares?
[22:27:30 CET] <ubitux> unless i'm mistaken, it just means vlc is doing something it shouldn't do, so it's now warning, just like we would emit a warning for use of deprecated stuff
[22:27:42 CET] <jamrial> j-b: a request for downstreams to do the right thing. but if they don't, it's clear after the revert commit that the intention is not to break people's shit
[22:27:58 CET] <j-b> jamrial: ubitux just said the opposite.
[22:28:05 CET] <j-b> either it works or it does nto
[22:28:26 CET] <ubitux> where did i say it doesn't work?
[22:28:45 CET] <j-b> You just said VLC shouldn't do that.
[22:28:56 CET] <ubitux> that doesn't mean it doesn't work
[22:28:58 CET] <j-b> So, disabling the feature sounds correct to me.
[22:29:06 CET] <jamrial> it shouldn't, like it shouldn't have done it since hwaccel was first implemented. it doesn't mean it will not work
[22:29:13 CET] <jamrial> since it has always worked
[22:29:40 CET] <j-b> It's funny, it's exactly not what the people who implemented hwaccel in the first place said, but fine
[22:29:59 CET] <cone-318> ffmpeg 03Zalewa 07master:2ac5a1a28ece: ffserver: NoVideo and NoAudio flags weren't cleared between streams.
[22:30:18 CET] <wm4> vlc gives bullshit attitude == we don't have to care
[22:30:50 CET] <j-b> sorry, I don't really see what's the bullshit about.
[22:31:00 CET] <j-b> but if you want to believe this, sure. no pb for me.
[22:36:59 CET] <nevcairiel> j-b: nowhere in the  message does it even say "unsupported", in fact BBB even went out of his way to make sure it works in the vp9 hwaccel, but the fact remains that its not a recommended mode because it adds certain constraints which can easily result in bugs
[22:38:34 CET] <wm4> plus it's not any different in ffmpeg 2.8, LOL
[22:38:45 CET] <j-b> "its use is discourage"
[22:39:20 CET] <j-b> nevcairiel: agreed.
[22:39:28 CET] <Compn> j-b : you want someone to document the feature and mark it supported?
[22:39:31 CET] <Compn> that can be arranged.
[22:39:34 CET] <Compn> jamrial : right ?
[22:39:56 CET] <j-b> Compn: tbh, I don't really care about Linux anymore, as I already told you.
[22:40:08 CET] <Compn> i dont remember this, but ok
[22:40:27 CET] <Compn> i'm not a big fan of distro stuff anyway :P
[22:40:35 CET] <jamrial> dxva2 is not linux
[22:40:55 CET] Action: Compn doesnt remember saying word 'linux'
[22:41:25 CET] <j-b> IIRC, the problem is that when you ask for hw accel, it can fallback to software, but you can't know that in advance (which is expected).
[22:42:30 CET] Action: Compn only looking for solution to problem
[23:27:11 CET] <jkqxz> Is there some way to indicate to lavc that it /must/ use the hwaccel you've given it, and return an error rather than falling back to software if it can't?
[23:27:56 CET] <cone-318> ffmpeg 03Marton Balint 07master:3a4232a1a025: avformat/asfenc: write group_mutual_exclusion_objects for audio on multiple languages
[23:30:21 CET] <jkqxz> (Working around the hwaccel/threading problem, given slightly more effort from the user to close and reinit in their preferred software-only mode after getting the error return from a decode call.)
[00:00:00 CET] --- Mon Feb 22 2016