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

[burek]

[02:02:38 CEST] <cone-069> ffmpeg 03Michael Niedermayer 07master:c4fad0277991: avformat/matroskaenc: Undo bits_per_coded_sample change as bits_per_raw_sample is available again
[02:02:38 CEST] <cone-069> ffmpeg 03Michael Niedermayer 07master:60517c3ad66f: avfilter/af_hdcd: Fix informations typo
[02:29:06 CEST] <rcombs> atomnuker: how do PCEs work in ADTS AAC-LC?
[02:29:33 CEST] <rcombs> or, actually, specifically ER AAC-LC
[02:30:52 CEST] <rcombs> looks like it's just not supported in the decoder afaict
[02:31:26 CEST] <rcombs> (no I don't have a sample, just looking through the code and noticed there's no handling for it in that code path)
[02:34:21 CEST] <atomnuker> for adts they should work just normally
[02:37:30 CEST] <rcombs> there's PCE handling in aac_decode_frame_int, but I don't see any in aac_decode_er_frame
[02:37:55 CEST] <atomnuker> yeah, seems ER only uses channel tags
[02:38:36 CEST] <atomnuker> could be just that it's not implemented though
[02:38:39 CEST] <rcombs> does PCE in ER just not exist, or isyeah
[02:38:45 CEST] <atomnuker> I'll take a look at the specs
[02:39:16 CEST] <rcombs> cool
[02:43:01 CEST] <atomnuker> rcombs: nope, seems like they're not supported
[02:43:12 CEST] <rcombs> cool, thanks
[02:43:41 CEST] <atomnuker> "Please note, that due to this modification coupling_channel_element(), data_stream_element(), program_config_element(), and fill_element() are not supported within the error resilient bitstream payload syntax."
[04:17:39 CEST] <jamrial> nice, release candidate for gcc 6
[04:17:48 CEST] <jamrial> and it doesn't miscompile ffmpeg :p
[04:17:53 CEST] <jamrial> final should be out next week
[13:27:12 CEST] <Daemon404> [22:07] <+rcombs> Daemon404: nevcairiel: how far out do you suppose the new BSF API is? <-- when someone helps me figure out merge stuff for hevc/h264 and maybe help port
[13:27:15 CEST] <Daemon404> (its in a branch)
[13:27:37 CEST] <rcombs> maybe I'll take a look
[13:27:42 CEST] <rcombs> tomorrow or so
[13:27:47 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/commits/bsf
[13:28:41 CEST] <Daemon404> its not a ton of work, but i dont have the best grasp on bsfs.
[13:28:45 CEST] <wm4> what's still missing? I also wanted to take a look
[13:29:02 CEST] <Daemon404> todo is in the commit message for the two top commits there
[13:29:09 CEST] <Daemon404> (the only 2 new ones)
[13:35:23 CEST] <nevcairiel> I'll look at h264 and hevc, it should be no big trouble
[13:35:57 CEST] <wm4> uh then I guess I'll continue being lazy and useless
[13:36:56 CEST] <Daemon404> wm4, feel free to port shit
[13:37:04 CEST] <Daemon404> saturdays are fairly busy for me
[13:37:09 CEST] <Daemon404> (chore day, yay)
[14:02:51 CEST] <nevcairiel> Daemon404: i came up with an evil plan, remove the stupid argument from the bsfs themself and instead hack it into the compat layer for the old API, that way it magically dies with it one day
[14:18:14 CEST] <Daemon404> .. lulz
[14:18:40 CEST] <Daemon404> perverted.
[14:48:40 CEST] <nevcairiel> i may have fixed h264 and a few others, but still a bunch left that may need attention
[14:49:07 CEST] <JEEB> nice
[16:28:02 CEST] <durandal_170> can someone backport my apedec fix to all other branches?
[16:40:59 CEST] <cone-603> ffmpeg 03Tobias Rapp 07master:2aad631a818c: avfilter: add readvitc filter
[17:06:14 CEST] <nevcairiel> BBB: do we have a fate test for vp9_superframe?
[17:06:25 CEST] <BBB> not that I know
[17:06:49 CEST] <BBB> ffmpeg -i anyvp9file -c:v copy out.ivf
[17:06:52 CEST] <BBB> should suffice
[17:17:07 CEST] <nevcairiel> guess it works post-conversion then
[17:17:11 CEST] <nevcairiel> produces identical output in any case
[17:17:26 CEST] <nevcairiel> i should probably break it to see if it even affects the output =p
[17:18:42 CEST] <nevcairiel> oh ok it immediately crys about broken timestamps if the bsf isnt used, suppose thats "normal"?
[17:18:52 CEST] <BBB> right, thats what the bsf fixes
[17:19:08 CEST] <BBB> not the timestamps, but the splitting of a superframe into two subframes with identical timestamps
[17:19:22 CEST] <BBB> the bsf merges them back together so you have one frame with a unique timestamp (instead of two frames with the same tS)
[17:20:11 CEST] <nevcairiel> feel like looking over https://github.com/dwbuiten/FFmpeg/commit/0895961d15e2ecf24845c7444fe2128e869d80df ? its kinda inflated due to changing the name of the context variable to a "standard" that every bsf now uses, so meh..
[17:20:19 CEST] <nevcairiel> the real changes are only how input and output works
[17:21:57 CEST] <nevcairiel> i wonder if it should return something special when it "eats" a packet
[17:22:03 CEST] Action: nevcairiel checks the API more
[17:22:24 CEST] <BBB> the rename is a little confusing
[17:22:26 CEST] <BBB> but it looks ok
[17:22:47 CEST] <BBB> make sure that after -c:v copy, decoding the source and dest file both give identical framemd5s
[17:22:55 CEST] <BBB> e.g. ffmpeg -i in -c:v copy out
[17:23:00 CEST] <BBB> ffmpeg -i in -f framemd5 a
[17:23:04 CEST] <BBB> ffmpeg -i out -f framemd5 b
[17:23:08 CEST] <BBB> diff -q a b
[17:23:11 CEST] <nevcairiel> i diffed the output file bit-wise and it was identical to before
[17:23:11 CEST] <BBB> or so
[17:23:19 CEST] <BBB> ok thats good enough
[17:23:19 CEST] <BBB> tnx
[17:24:56 CEST] <nevcairiel> i think its supposed ro return EAGAIN when it has no output
[17:24:59 CEST] Action: nevcairiel changes
[17:27:14 CEST] <wm4> yes it is
[17:28:33 CEST] <nevcairiel> its the only filter that does this, amazing that the libav api definition even cared for that case =p
[17:29:06 CEST] <nevcairiel> after these changes we should really improve fate coverage of bsf
[17:29:10 CEST] <nevcairiel> its barely tested at all
[17:30:09 CEST] <Daemon404> yep
[17:30:14 CEST] Action: Daemon404 home now
[17:30:41 CEST] <JEEB> it even has one bug that makes some things actually fail when used in real life, unless the prefix length issue got fixed
[17:30:51 CEST] <JEEB> (the h264 bsf at least)
[17:31:07 CEST] <nevcairiel> well fate tests dont find bugs, they just prevent regressions
[17:31:48 CEST] <nevcairiel> Daemon404: i left mp3_header_decompress for you, ima go grab foodz noaw
[17:34:18 CEST] <nevcairiel> and the aac bsf with its extradata is still broken, i can look at that after food
[17:34:35 CEST] <Daemon404> ok
[17:34:41 CEST] <nevcairiel> should probably pick the test rcombs wrote for that into master quickly, it should be independent from the remainder of his set
[17:35:06 CEST] <Daemon404> i might wait till after dinner too to poke
[17:35:12 CEST] <Daemon404> but ill look now
[17:35:23 CEST] <nevcairiel> the mp3 one is probably not hard
[17:35:28 CEST] <nevcairiel> didnt even open the file yet
[17:37:36 CEST] <Daemon404> sure
[20:23:03 CEST] <nevcairiel> Daemon404: pushed a fix for aac as well
[20:24:12 CEST] <Daemon404> ok
[20:24:17 CEST] <Daemon404> im just about to eat
[20:24:23 CEST] <Daemon404> so i havent poked mp3 yet
[20:30:31 CEST] <nevcairiel> we should really work on migrating the internal components that use bsf to the new api after, so many hacks accumulating for it
[20:31:40 CEST] <nevcairiel> at least autobsf
[21:01:25 CEST] <petrurares> Hi there! I want to save a new frame side data, concretely AVMasteringDisplayMetadata. I tried to put some random data in doc/examples/decoding_encoding.c example but I can't retrieve back such data
[21:03:03 CEST] <petrurares> any idea how to do this? I want to make a test but firstly I need to know how to do that. Thanks :)
[21:11:09 CEST] <petrurares>  /msg nickserv register naturis psincraian at gmail.com
[21:47:39 CEST] <Compn> petrurares : stick around, i think the devs are all sleeping atm
[21:47:42 CEST] <Compn> doh
[21:51:45 CEST] <petrurares> lol :') Thanks Compn, for today I'm done
[00:00:00 CEST] --- Sun Apr 17 2016