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

[burek]

[00:14:22 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:29b09233249e: avcodec/h264_slice: Silence pointer type warnings
[00:14:23 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:6323647c3550: avcodec/h264_slice: Reformat IN_RANGE() uses to be readable
[00:53:12 CEST] <cone-389> ffmpeg 03Rostislav Pehlivanov 07master:d71935f8833d: aac: add additional fields needed by the encoder for intensity stereo
[01:07:20 CEST] <cone-389> ffmpeg 03Ludmila Glinskih 07master:86fb20324690: api-flac-test: Fix the bug of comparing zero bytes
[02:57:31 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:f01028bf58b8: avcodec/jpeg2000: Avoid one shift in ff_jpeg2000_ceildivpow2()
[02:57:32 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:cd1a9908b5de: avcodec/jpeg2000: support >32bit in ff_jpeg2000_ceildivpow2()
[02:57:33 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:d62657eb4abb: configure: Also create tests/api
[04:57:27 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:317be53ca626: avcodec/jpeg2000: Support 32 decomposition levels
[11:20:10 CEST] <thardin_> hum-hum.. what do I need to build ffplay again?
[11:24:34 CEST] <thardin_> sdl-gfx-dev and/or sdl-image-dev it seems
[11:30:43 CEST] <cone-658> ffmpeg 03Andreas Cadhalpun 07master:f9883a669c3d: wavpack: use get_bits_long to read up to 32 bits
[11:48:24 CEST] <cone-658> ffmpeg 03Anton Khirnov 07master:d3ea79e8a65d: FATE: drop the last truncated frame from the wma lossless test
[11:48:25 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:fb2eeebf662e: Merge commit 'd3ea79e8a65ddad4da11813bb43c46701295f68c'
[12:07:05 CEST] <cone-658> ffmpeg 03Anton Khirnov 07master:441e8ae5efd6: FATE: drop the last truncated frame from the wmapro tests
[12:07:06 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:3d2267019cd7: Merge commit '441e8ae5efd681055e5af6f4317fb60110de9dd0'
[12:07:07 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:0940169743aa: tests/fate/wma: use the existing reference files for wmapro tests
[13:05:27 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:da0616985095: avformat/riffdec: Forward error code from avio_read() in ff_get_guid()
[13:41:49 CEST] <cone-658> ffmpeg 03Alexandra Hájková 07master:b08569a23948: lavf: Replace the ASF demuxer
[13:41:50 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:30b8f3e7dcd0: Merge commit 'b08569a23948db107e5e6175cd4c695427d5339d'
[14:06:10 CEST] <cone-658> ffmpeg 03Luca Barbato 07master:8a26ae5f94e6: mpjpeg: Check stream allocation
[14:06:11 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:a57ee6cca10d: Merge commit '8a26ae5f94e613dbf7eb8e3c60462e966e409cdc'
[14:39:04 CEST] <cone-658> ffmpeg 03Rostislav Pehlivanov 07master:02dbed6e71e7: aacpsy: Add energy spread for each band
[14:51:44 CEST] <cone-658> ffmpeg 03Andreas Cadhalpun 07master:9a345802edf7: huffyuvdec: validate image size
[15:04:12 CEST] <Daemon404> asfdec_kostya.c
[15:06:09 CEST] <wm4> michaelni: the asf merge is just bullshit
[15:07:22 CEST] <Daemon404> 'carl says it's better;
[15:07:28 CEST] <nevcairiel> if anything there should be a discussion and disclosure of tests performed that yielded that decision,  not a dumb "carl said"
[15:09:03 CEST] <nevcairiel> I'm sure I could try to be as biased as I wanted if i performed some closed-door test, and find overwhelming evidence that the new one is 100 times better =p
[15:09:38 CEST] <Daemon404> oh so youve worked for the broadcast industry?
[15:11:01 CEST] <Daemon404> by all reports, ive heard the new asf demuxer fixes many files
[15:12:15 CEST] <wm4> carl doesn't agree
[15:12:19 CEST] <wm4> (apparently)
[15:12:49 CEST] <Daemon404> by accounts i do not mean 'libav' fwiw
[15:12:56 CEST] <Daemon404> but users on doom9, and ffms2 bug tracker
[15:13:10 CEST] <nevcairiel> he is worse than some of the libav people, he will just dislike and distrust it because it comes from libav
[15:17:05 CEST] Action: Daemon404 is childish and laughs at 'PNS'
[15:17:55 CEST] <nevcairiel> ...
[15:19:20 CEST] Action: Daemon404 throws nevcairiel's ellipsis back at him
[15:19:28 CEST] <nevcairiel> speaking about PNS, fancy prints of spectral results are nice and all, but I do wonder how the audible effect is
[15:23:53 CEST] <nevcairiel> although i should probably stop caring and just move towards using opus
[15:24:16 CEST] <Daemon404> right now opus-in-mp4 not being final is what stops me
[15:24:32 CEST] <nevcairiel> i could probably even use mkv
[15:24:49 CEST] <nevcairiel> although ts muxing support in ffmpeg would be nice
[15:25:53 CEST] <michaelni> which tickets are fixed by using the rewritten asf demuxer ?
[15:30:25 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:96e73fa64941: avcodec/jpeg2000dec: Merge i_stepsize/2 decoder special case into dequant
[16:13:58 CEST] <atomnuker> nevcairiel: there's a big difference at low bitrates (below 100ish kbps)
[16:34:35 CEST] <cone-658> ffmpeg 03Paul B Mahol 07master:f76d7d4b01e8: avfilter: add showvolume filter
[16:50:45 CEST] <cone-658> ffmpeg 03Rodger Combs 07master:7d0a19757e0b: lavc/adpcm: THP: set approx_nb_samples correctly
[17:08:14 CEST] <cone-658> ffmpeg 03Andreas Cadhalpun 07master:2a4700a4f032: wmavoice: limit wmavoice_decode_packet return value to packet size
[17:37:14 CEST] <Daemon404> i image C-E yelling out loud
[17:37:18 CEST] <Daemon404> "LIBAV CANT MELT STEEL BEAMS"
[18:05:20 CEST] <RiCON> there's a lack of concrete samples from both sides of the argument though
[18:06:47 CEST] <jamrial> do we really need TWO asf demuxers?
[18:07:25 CEST] <wm4> RiCON: I've asked the Libav side, but no reply yet
[18:09:00 CEST] <Daemon404> any g2m or mss2 sample should do
[18:12:51 CEST] <BBB> hm...
[18:12:56 CEST] <BBB> is c-e online?
[18:13:43 CEST] <Daemon404> of course not
[18:13:54 CEST] <Daemon404> hes one of those 'email only' sort of people
[18:13:55 CEST] <Daemon404> usually.
[18:14:26 CEST] <Daemon404> i havent read the thread yet, but i assume it's something like this:
[18:14:34 CEST] <Daemon404> everyone: we should investigate more, be reasonable
[18:14:45 CEST] <Daemon404> carl: LIBAV IS EVIL WE CANT TRUST THEM TO TEST, LIBAV DID 9/11
[18:22:34 CEST] <BBB> well Im not gonna flame any further
[18:22:42 CEST] <BBB> but I recall working on our existing asf demuxer at some point
[18:23:07 CEST] <BBB> and (michaelni please pay attention) its the most horrific piece of utter shit bullshit spaghetti nonsense code Ive ever had the misfortune of working with
[18:23:20 CEST] <BBB> if we were to delete it, I would be extremely happy
[18:23:25 CEST] <BBB> and I say that not having looked at the new code
[18:24:39 CEST] <wm4> but it must be good because of the man-years of maintenance!
[18:34:02 CEST] <durandal_1707> technically mplayer demuxer is better than both of them
[18:35:01 CEST] <Daemon404> its gpl isnt it
[18:36:03 CEST] <durandal_1707> yea
[18:37:56 CEST] <nevcairiel> BBB: thats really one of the major reasons libav decided to re-write it entirely, the old one is horrible code based on years of hackery and reverse engineering, while the new one is a clean implementation based on the spec (which wasn't available for the first one)
[18:39:29 CEST] <nevcairiel> I find it funny that carl basically admitted though that he didnt test anything, so the comment in the commit is just a lie
[18:40:48 CEST] <Daemon404> people wouldnt lie on the internet, nevcairiel 
[18:43:50 CEST] <jamrial> he didn't test it yet he lobbied against merging it?
[18:43:57 CEST] <nevcairiel> its from libav
[18:44:16 CEST] <nevcairiel> and the old one must be good, its been maintained for years already
[18:44:20 CEST] <nevcairiel> thats basically the two arguments
[18:45:13 CEST] <nevcairiel> i should sit down and sift through a bunch of samples
[18:47:41 CEST] <kierank> wm4, BBB: re my latest email - what do we do with API timestamps being different to ffmpeg.c
[18:51:16 CEST] <nevcairiel> ffmpeg.c has boat loads of timestamp magic
[18:51:30 CEST] <nevcairiel> i dont even know off-hand how many -async and -vsync options there are
[18:54:32 CEST] <BBB> kierank: I dont know
[18:55:35 CEST] <BBB> kierank: if the goal is to reuse the test code as a mini-ffmpeg.c (not MiNi; just small) between codecs, then its all fine with me
[18:55:47 CEST] <kierank> yes
[18:55:49 CEST] <BBB> I just found the naming convention kind of weird since theres nothing flach264 specific int he tests
[18:56:01 CEST] <BBB> so if thats just a temp state, its all fine
[18:56:19 CEST] <kierank> the goal is to make sure that at least from an output perspective the output of ffmpeg.c is the same as the api
[18:56:24 CEST] <kierank> AND to test things ffmpeg.c doesnt test
[18:56:25 CEST] <BBB> and yes the timestamp magic in ffmpeg.c and even embedded in the api has annoyed me forever
[18:56:39 CEST] <wm4> BBB: yeah, the entire idea is that we don't just test a single API user
[18:56:43 CEST] <BBB> I think api tests are good, but they still dont totally help us understand wtf is going on in utils.c
[18:56:58 CEST] <BBB> (Im not saying you should fix that; the stated goal of api tests is fine)
[18:57:07 CEST] <BBB> (Im just expressing a personal frustration :) )
[18:57:24 CEST] <kierank> What I don't want to see as a result of this is ffmpeg.c timestamp hacks going into utils.c
[18:57:29 CEST] <kierank> because that's what some people want
[18:57:36 CEST] <BBB> muhahahah you just wait :(
[18:57:50 CEST] <nevcairiel> i think we're enough to veto that =p
[18:57:53 CEST] <BBB> I mean I agree with you, basically
[18:58:13 CEST] <nevcairiel> if they want they can shove that into its own api that people can use, but not automatically in the demuxer
[18:58:30 CEST] <BBB> but my point was more orthogonal to that, I think Im fine with magic code living in utils.c, if theres particular ways to test that code, have it be documented, easily understood what it does, why it does it, etc.
[18:58:40 CEST] <BBB> I think the timestamp code in utils.c is one of these busfactor=1 pieces of code
[18:58:48 CEST] <nevcairiel> there is a flag to disable the magic, if you really wanted to
[18:59:08 CEST] <wm4> which flag?
[18:59:25 CEST] <BBB> wm4: I think he means a hypothetical flag that we could add in the future
[18:59:28 CEST] <BBB> wm4: not one that exists today
[18:59:34 CEST] <nevcairiel> it exists
[19:00:00 CEST] <nevcairiel> AVFormatContext->flags set AVFMT_FLAG_NOFILLIN
[19:00:02 CEST] <BBB> ohryl
[19:00:16 CEST] <wm4> I wonder what happens if I use that with my code
[19:00:20 CEST] <nevcairiel> then it will not run the magic info generation code
[19:02:22 CEST] <Daemon404> [17:57] <+nevcairiel> i think we're enough to veto that =p <-- dir listing api says different
[19:02:52 CEST] <nevcairiel> i think we might raise more of a stink if it impacts core APIs instead of just adding more noise
[19:03:13 CEST] <Daemon404> time shall tell
[19:37:41 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:ecbd111768c7: avcodec/jpeg2000dec: Remove unused variables
[21:32:28 CEST] <cone-658> ffmpeg 03Rostislav Pehlivanov 07master:305859c0d41d: aaccoder: add intensity stereo coding support for the trellis quantizer
[21:32:29 CEST] <cone-658> ffmpeg 03Rostislav Pehlivanov 07master:55397b0e76a4: aaccoder: add intensity stereo support to encode_window_bands_info quantizer
[23:22:35 CEST] <Jumbt> https://trac.ffmpeg.org/ticket/2439#no1 has any progress been made on this? would be very useful
[23:23:45 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:4b0a475846a1: avformat/asfdec: Reduce FRAME_HEADER_SIZE to 11
[23:23:46 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:a5f617e9ec8e: avformat/asfdec: Print a warning if data is skiped due to less than a frame header being left
[23:30:16 CEST] <durandal_1707> Aha, so asf_o is better for that sample
[23:37:08 CEST] <cone-658> ffmpeg 03George Boyle 07master:c78b82f4da74: tests/Makefile: Fix missing trailing slash for API tests dir target
[23:40:14 CEST] <Compnn> theres some other fun stuff in asf , binary codecs? truespeech maybe
[23:48:57 CEST] <anoop_r> well i know its not the place to say but forgive me.with all your support i had succeded in my project
[23:49:09 CEST] <anoop_r> if anybody have windows + .net 4.5 and kind heated enough to test my software please
[23:49:16 CEST] <anoop_r> http://www.qfs.mobi/f2403835
[23:50:29 CEST] <anoop_r> you can provide feedback to keepitsimplepltd at yandex.com also if i violated anything inform me
[00:00:00 CEST] --- Mon Jun 29 2015