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

[burek]

[01:25:43 CEST] <kierank> awww he quit
[01:25:46 CEST] <kierank> can't review my code now :(
[02:40:02 CEST] <kierank> jdarnley: so that command you posted
[02:40:04 CEST] <kierank> what does it show
[03:20:32 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:42d26145e956: lavf: move avpriv function definition to internal.h
[03:20:33 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:db85d657faab: lavf/allformats: remove left-over index decrement
[03:20:34 CEST] <cone-486> ffmpeg 03Jun Zhao 07master:9b125826ed7e: cmdutils: fix new API break the "ffmpeg -muxers/demuxers"
[03:40:31 CEST] <Chloe> wm4: why do you need to change AV_PIX_FMT_FLAG_PSEUDOPAL to FF_PSEUDOPAL, can you not just define AV_PIX_FMT_FLAG_PSEUDOPAL to 0 directly?
[04:03:51 CEST] <wm4> Chloe: no that would require breaking ABI just to build with the thing disabled
[04:05:58 CEST] <wm4> at least according to how we do this normally, it's probably necessary
[04:06:15 CEST] <wm4> if it were after me we'd just make PSEUDOPAL non-functional immediately
[04:06:23 CEST] <Chloe> wm4: I mean the ABI changes when you build with it disabled right?
[04:08:24 CEST] <wm4> depends if you consider that palette allocation as part of the ABI
[04:23:18 CEST] <cone-486> ffmpeg 03James Almer 07master:f1805d160d66: avfilter: bump version for the latest API change
[04:39:34 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:85bf89885a97: Revert "avformat/format: temporarily use old next api"
[04:39:35 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:d1221f335183: lavf/format: use const AVInputFormat for iteration
[04:39:36 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:89029bd2c7f3: lav*,tests: remove several register_all calls
[04:39:37 CEST] <cone-486> ffmpeg 03Josh de Kock 07master:e0f32286861d: lavf/img2dec: use new iteration API
[05:50:13 CEST] <cone-486> ffmpeg 03James Almer 07master:860086ee1688: avcodec/avpacket: add av_packet_make_refcounted()
[05:50:14 CEST] <cone-486> ffmpeg 03James Almer 07master:de0526070eb1: avcodec/frame_thread_encoder: remove usage of av_dup_packet()
[05:50:15 CEST] <cone-486> ffmpeg 03James Almer 07master:e61d8b82a2ca: avcodec/encode: use av_packet_make_refcounted to ensure packets are ref counted
[05:50:16 CEST] <cone-486> ffmpeg 03James Almer 07master:38fa61b94766: avdevice/decklink_dec: use av_packet_make_refcounted to ensure packets are ref counted
[05:50:17 CEST] <cone-486> ffmpeg 03James Almer 07master:265ec55983bf: avcodec/bsf: use av_packet_make_refcounted to ensure packets are ref counted
[05:50:18 CEST] <cone-486> ffmpeg 03James Almer 07master:02ae52db8727: avformat/utils: use av_packet_make_refcounted to ensure packets are ref counted
[09:26:01 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:22a878ecd1c1: avcodec/scpr: check for possible out of array access
[09:49:27 CEST] <rcombs> nevcairiel: can't you tell the difference between MPEG-2 and MPEG-4 AAC at decode-time based on presence of& what was it, PNS?
[09:49:36 CEST] <rcombs> and maybe another one or two tools?
[09:49:46 CEST] <nevcairiel> sure, but thats not as simple as some profile integer
[09:49:53 CEST] <rcombs> yeah, but neither is anything in AAC
[09:50:28 CEST] <nevcairiel> the adts header has a flag too, which one could use if you are actually playing adts
[09:50:36 CEST] <rcombs> love me some backwards* compatibility**
[09:50:58 CEST] <rcombs> I mean, like, LC vs HE vs HEv2 is all "presence of a particular set of coding tools"
[09:50:58 CEST] <nevcairiel> which is probably the thing he is seeing if he is talking about MediaInfo
[09:51:34 CEST] <rcombs> heh
[09:51:53 CEST] <rcombs> does anything actually produce MPEG-2 AAC anyway
[09:52:02 CEST] <nevcairiel> we can
[09:52:11 CEST] <rcombs> well, in actual practice
[09:52:17 CEST] <rcombs> do people use it in the wild
[09:52:42 CEST] <nevcairiel> i do in some legacy profiles, because some old DLNA streamers like the PS3 did not like mpeg4
[09:52:52 CEST] <rcombs> oh lol the PS3!?
[09:53:14 CEST] <rcombs> that might explain some weird PS3 DLNA issues from years ago
[09:53:16 CEST] <nevcairiel> its probably not that relevant anymore
[09:53:24 CEST] <rcombs> I don't think we saw that on WebMAF though
[09:53:28 CEST] <nevcairiel> but the guy in that ticket apparently has some device
[09:53:46 CEST] <rcombs> I'd be curious about building an MPEG-2-only version of the decoder (since it's expired globally now) if it turned out that MPEG-2 AAC files actually existed in the wild much
[09:54:21 CEST] <rcombs> but I don't have metrics on that since lavc doesn't report it, and my assumption is that they're quite rare outside that sort of streaming scenario (in which case they wouldn't be anywhere I needed to worry about decoding them)
[10:55:31 CEST] <durandal_1707> wtf, sample that previously decoded fine now does not decode at all, even using first decoder version does not help
[10:59:57 CEST] <jdarnley> kierank: if you mean the ffplay command then it should show a completely grey picture except for where the differences are.  The differences are in the top left corner where the numbers are and another bit towards the right.
[11:45:04 CEST] <durandal_1707> i have really strange issue:
[11:45:31 CEST] <durandal_1707> checkouting old ffmpeg version, file decodes ok
[11:46:01 CEST] <durandal_1707> checkouting latest ffmpeg version + old decoder file, file does not decode ok
[12:08:13 CEST] <durandal_1707> huh, it is because linesize changed
[12:35:16 CEST] <wm4> does anyone want to stop me from pushing the pseuopal stuff?
[12:39:33 CEST] <durandal_1707> why you want that change?
[13:02:46 CEST] <wm4> durandal_1707: see commit message
[13:36:26 CEST] <Chloe> wm4: I think it's fine
[13:40:12 CEST] <kierank> jdarnley: it's weird because the picture looks ok
[13:49:17 CEST] <durandal_1707> there is no way to force linesize?
[13:51:51 CEST] <nevcairiel> not really, why would you want to
[13:52:40 CEST] <atomnuker> rcombs: you can just skip pns and live with the loss in quality
[13:53:10 CEST] <atomnuker> since its only used in high frequencies for a few frames at a time
[13:53:15 CEST] <kierank> rcombs: yes I've thought about the same thing
[14:09:40 CEST] <jdarnley> kierank: It is very subtle
[14:09:44 CEST] <cone-359> ffmpeg 03Kieran Kunhya 07master:699fa8f38270: simple_idct: Template functions to support an input bitdepth parameter
[14:09:44 CEST] <cone-359> ffmpeg 03Kieran Kunhya 07master:f9d3841ae614: mpeg4video: Add support for MPEG-4 Simple Studio Profile.
[14:10:12 CEST] <jdarnley> You might be able to see it more if you switch from testsrc2 to testsrc and look at where the circle meets the top edge
[14:10:43 CEST] <kierank> jdarnley: is this single level?
[14:11:02 CEST] <jdarnley> Do you mean the wavelet_depth option?
[14:11:02 CEST] <kierank> or is it when you add iterative transforms?
[14:11:22 CEST] <jdarnley> The error is much less at depth 1
[14:11:26 CEST] <kierank> Is it a result of 25a0f or 963c68a7
[14:11:30 CEST] <kierank> ah
[14:11:30 CEST] <jdarnley> but still present
[14:29:37 CEST] <kierank> durandal_1707: thanks
[15:36:16 CEST] <Chloe> jamrial: ok my bad didnt realise wasnt meant to go in changelog
[16:08:56 CEST] <cone-359> ffmpeg 03Paul B Mahol 07master:324954cf960e: avcodec/scpr: fix decoding of prev+top-topleft prediction in keyframes
[16:22:18 CEST] <cone-359> ffmpeg 03Paul B Mahol 07master:5710fdaeae09: avcodec/aic: fix decoding of videos which height is not multiple of 16
[18:07:01 CEST] <wyatt8740> Should I ask about API changes here or in the ffmpeg user support channel?
[18:07:08 CEST] <wyatt8740> (for using ffmpeg with third-party programs)
[18:07:23 CEST] <nevcairiel> usage of ffmpeg and the libraries is user support
[18:07:53 CEST] <wyatt8740> OK, wasn't sure if 'user support' just covered the binary executables
[18:07:54 CEST] <wyatt8740> ty
[18:18:18 CEST] <durandal_1707> anybody want to fuzz clearvideo P frames support?
[18:36:24 CEST] <atomnuker> if I had a xeon machine, an abundant amount of rackspace and free power I'd give you access to set up afl
[18:42:23 CEST] <kierank> durandal_1707: yes
[18:49:35 CEST] <kierank> durandal_1707: let me know what to run and I'll do it
[18:49:41 CEST] <kierank> otherwise we can use our own fuzz infrastructure
[19:17:02 CEST] <durandal_1707> kierank: do you have code that does fuzzing by not checking demuxer code?
[19:17:24 CEST] <kierank> durandal_1707: https://github.com/openbroadcastsystems/fffuzz
[19:20:21 CEST] <kierank> durandal_1707: feel free to fork
[19:20:23 CEST] <kierank> and send PR
[19:45:36 CEST] <durandal_1707> how to make my mail address on ml is @ffmpeg.org ?
[19:46:35 CEST] <BtbN> have an overly aggressive mailserver
[20:20:21 CEST] <durandal_1707> kierank: see 2nd patch for clear video inter frame decoding on ml
[20:20:33 CEST] <durandal_1707> apply it and fuzz it
[20:20:54 CEST] <kierank> durandal_1707: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227632.html ?
[20:20:57 CEST] <kierank> ok I will do it later
[20:21:05 CEST] <kierank> where are samples
[20:23:41 CEST] <durandal_1707> kierank: no, patch from today
[20:24:13 CEST] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/date.html
[20:24:15 CEST] <kierank> I don't see it
[20:24:35 CEST] <durandal_1707> kierank: samples are here http://trac.ffmpeg.org/ticket/6842 and here http://samples.ffmpeg.org/V-codecs/UCOD/
[20:24:51 CEST] <durandal_1707> kierank: it should appear soon, i just posted it
[20:25:00 CEST] <kierank> hmmm lots of coverity stuff
[20:26:33 CEST] <kierank> I think false positive on one at least
[20:28:08 CEST] <klaxa> atomnuker: i thought about what kind of qualification task i could do and i came up with: create a separate branch or repo for my ffserver implementation and start "porting" my mkvserver to use libavutil stuff and use av_log() and such instead of printf()s. for the time being it should be completly self-contained, as you stated it should only be "merged" after a substantial amount of features have been implemented
[20:29:01 CEST] <klaxa> i'm not sure how much hassle it is for other developers on the ML to review it then though
[20:30:09 CEST] <kierank> durandal_1707: ok I will do later, I think some of the small samples on the ml will be good
[20:30:18 CEST] <atomnuker> klaxa: yeah, that sounds fine, just don't hold out on it being merged, since one of the reasons for ffserver being removed was the cludgy public API that had to be created
[20:31:05 CEST] <JEEB> well that was because ffserver had its legacy
[20:31:08 CEST] <atomnuker> eventually we should create a separate repo for the program in github and on videolan
[20:31:15 CEST] <JEEB> yes
[20:31:31 CEST] <klaxa> oh well, then we could do that right from the start, no?
[20:58:29 CEST] <cone-176> ffmpeg 03Marton Balint 07master:37d472a906bd: avformat/concatdec: only set output stream index before returning packet
[21:18:25 CEST] <kierank> durandal_1707: can you send me patch as file
[21:18:28 CEST] <kierank> I get errors copy and paste from ml
[21:21:31 CEST] <durandal_1707> kierank: https://github.com/richardpl/FFmpeg/commit/52fc62a44275da7e671eb8804743656ca61ffdaf.patch
[21:30:05 CEST] <kierank> durandal_1707: as usual api is broken
[21:30:08 CEST] <kierank> so can't build fffuzz
[21:30:45 CEST] <kierank> hmm maybve not
[21:37:15 CEST] <kierank> durandal_1707: none of the .rm files work
[21:38:38 CEST] <durandal_1707> kierank: what error you get?
[21:39:08 CEST] <kierank> just invalid data
[21:39:40 CEST] <durandal_1707> kierank: is that 32bit or 64bit OS?
[21:39:52 CEST] <kierank> linx 64
[21:39:53 CEST] <kierank> u
[21:40:43 CEST] <durandal_1707> kierank: not even first frame decodes?
[21:40:49 CEST] <kierank> nope
[21:41:07 CEST] <kierank> clv1_50kbps.rm: Invalid data found when processing input
[21:41:12 CEST] <kierank> looks quite small
[21:41:44 CEST] <durandal_1707> all of them decodes fine here
[21:42:18 CEST] <kierank> strange
[21:45:46 CEST] <durandal_1707> kierank: perhaps that is because of rm demuer?
[21:46:06 CEST] <kierank> maybe but I am just using git head and your patch
[21:47:05 CEST] <durandal_1707> ffmpeg -i ~/clv1_50kbps.rm -c:v copy -f null -
[21:47:06 CEST] <kierank> doing dumb fuzzing with zzuf
[21:47:21 CEST] <durandal_1707> kierank: does that errors out?
[21:47:47 CEST] <kierank> yes
[21:48:34 CEST] <durandal_1707> then that is stupid freaking crappy demuxer - RM not portable and buggy and stinks
[21:55:54 CEST] <atomnuker> klaxa: sure, though let's get something a bit more user friendly and stable first, no?
[21:56:32 CEST] <klaxa> then where do i send patches for review and where will they be stored?
[21:57:18 CEST] <klaxa> i mean still the ffmpeg-devel ml i guess, since this is gsoc, but who will be in charge of what gets commited and what not and where will that be managed?
[21:58:36 CEST] <kierank> the ffmpeg-devel mailing list as with all patches
[22:00:38 CEST] <klaxa> hmm ok, maybe i'm thinking too technical here and i should spend the time i'm thinking about this writing code instead
[22:08:49 CEST] <nevcairiel> doesnt that also require technical thinking? :)
[22:15:39 CEST] <klaxa> yes, but focused somewhere else, hopefully more useful right now :)
[22:18:08 CEST] <durandal_1707> kierank: pastebin -v debug output of .rm file when demuxing
[22:18:43 CEST] <kierank> https://www.irccloud.com/pastebin/4sopXgfN/
[22:22:31 CEST] <durandal_1707> kierank: are you sure rm demuxer is not disabled?
[22:22:45 CEST] <kierank> does it need dependencies?
[22:24:56 CEST] <durandal_1707> kierank: what: ffmpeg -h demuxer=rm
[22:24:59 CEST] <durandal_1707> gives?
[22:25:10 CEST] <kierank> Demuxer rm [RealMedia]:
[22:45:14 CEST] <cone-176> ffmpeg 03Paul B Mahol 07master:46129b40446a: avformat/rmdec: make use of avio_get_str()
[22:48:08 CEST] <durandal_1707> kierank: does fate rm tests pass for you?
[22:52:03 CEST] <kierank> durandal_1707: running now
[23:05:36 CEST] <kierank> still running
[23:05:43 CEST] Action: kierank doesn't trust multithreaded fate
[23:05:49 CEST] <kierank> multiprocess*
[23:07:04 CEST] <kierank> durandal_1707: fate passes
[23:15:13 CEST] <durandal_1707> kierank: try this: https://paste.ubuntu.com/p/gsCWKzjhWC/ 
[23:16:20 CEST] <kierank> durandal_1707: still 
[23:16:21 CEST] <kierank> bad
[23:16:25 CEST] <kierank> I will make distclean and rebuild
[23:17:27 CEST] <durandal_1707> why? that is not needed
[23:20:39 CEST] <kierank> still bad
[23:23:27 CEST] <durandal_1707> kierank: have ssh shell setup?
[23:23:45 CEST] <kierank> not easily
[23:23:54 CEST] <kierank> I could maybe try on my nuc at home
[23:24:20 CEST] <durandal_1707> only if that machine does not parse that rm files :)
[23:27:30 CEST] <cone-176> ffmpeg 03James Almer 07master:877aff2beacb: avcodec/libaomenc: remove references to gbrp pixfmt
[23:27:31 CEST] <cone-176> ffmpeg 03James Almer 07master:4897c80cc6eb: avcodec/libaomdec: remove references to gbrp pixfmt
[23:28:59 CEST] <cone-176> ffmpeg 03Jun Zhao 07master:c6c20249e724: avformat/options_table: Change the seek2any location in opt table.
[23:29:00 CEST] <cone-176> ffmpeg 03Michael Niedermayer 07master:d52be5d4e918: avcodec/cscd: Error out when LZ* decompression fails
[23:29:01 CEST] <cone-176> ffmpeg 03Michael Niedermayer 07master:197a4e8feed4: avcodec/aacdec_fixed: Fix integer overflow in apply_independent_coupling_fixed()
[23:29:34 CEST] <kierank> durandal_1707: ok this is my fault
[23:29:56 CEST] <kierank> I wgetted the html page
[23:30:00 CEST] <durandal_1707> lol
[23:30:10 CEST] <kierank> I thought links on trac were direct download
[23:30:39 CEST] <durandal_1707> should ask for hash right then...
[23:31:04 CEST] <durandal_1707> otherwise I would not touch rmdec.c again
[23:32:35 CEST] <kierank> yes I was about to make hash
[23:32:38 CEST] <kierank> then realised file was 5KB
[23:32:57 CEST] <kierank> ok doing dumb zzuf fuzzing
[23:33:04 CEST] <kierank> can't get fffuzz to build for some reason
[23:34:10 CEST] <durandal_1707> kierank: afl-fuzz -i ifuzz/ -o ofuzz/ -- ./ffmpeg -i @@ -vframes 3 -f null - ?
[23:34:24 CEST] <kierank> sure but then it fuzz demux
[23:34:35 CEST] <kierank> and probing
[23:34:46 CEST] <kierank> beauty of fffuzz is that it forces codec
[23:35:35 CEST] <durandal_1707> it does not much, i fixed crash with 16x16.rm that way
[23:36:36 CEST] <kierank> ok waiting for slow configure to fix
[23:36:57 CEST] <durandal_1707> you are on windows?
[23:37:14 CEST] <durandal_1707> configure is slow only there...
[23:38:46 CEST] <durandal_1707> anyway, the only place it can crash is in extended_edges or in copy blocks
[23:39:00 CEST] <durandal_1707> and i think i covered all cases there
[23:45:06 CEST] <kierank> linux
[23:45:12 CEST] <kierank> [-] PROGRAM ABORT : Fork server crashed with signal 11
[23:45:13 CEST] <kierank> weirf
[23:45:56 CEST] <Chloe> kierank: is this target_dec_fuzzer or something/
[23:46:04 CEST] <kierank> no
[23:46:08 CEST] <kierank> that one is google's one
[23:46:28 CEST] <Chloe> oh ok
[23:46:49 CEST] <Chloe> kierank: did I break something here? is it related to the new API/
[23:46:55 CEST] <kierank> no
[00:00:00 CEST] --- Tue Apr  3 2018