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

[burek]

[00:09:51 CEST] <philipl> BtbN: So what do you want to do here? I'm happy to work on using the video sdk headers this weekend. Are you interested in pushing the new API stuff even if it doesn't work for transcode. I obviously find the media player usage compelling.
[00:10:56 CEST] <BtbN> I plan on pushing those changes, yes. They don't regress anything, only add new features, that just happen to not work with ffmpeg.c.
[00:15:01 CEST] <BtbN> It might also be possible to avoid the whole counting, and make a safe quess based on the queue size
[00:17:04 CEST] <philipl> Ok. Just remember that vp8/9 will regress without that fix.
[00:17:12 CEST] <philipl> (or a counter alternative)
[01:47:28 CEST] <cone-597> ffmpeg 03Michael Niedermayer 07master:fa0780d644c6: avcodec/avrndec: Remove obsolete FIXME
[01:47:28 CEST] <cone-597> ffmpeg 03Mark Reid 07master:d8d433321796: avformat/mxfdec: use first valid sourceclip found if material track has multiple components
[01:47:28 CEST] <cone-597> ffmpeg 03Mark Reid 07master:6419b4c0cb15: test/fate: add multi component mxf test
[06:40:11 CEST] <philipl> BtbN: Patches sent for bundling headers.
[10:39:16 CEST] <nevcairiel> how does one access the things again people uploaded to  upload.ffmpeg.org? the url i had times out :(
[11:47:01 CEST] <ubitux> should i apply the codecpar patchset and move on to the bsf stuff?
[11:51:56 CEST] <BtbN> I don't see why not. Waiting with it isn't going to help. If something breaks, it can just be fixed.
[11:52:29 CEST] <JEEB> and FATE passes I think?
[11:52:42 CEST] <JEEB> so +1 from me even though I'm a pesky limited contributor
[11:57:43 CEST] <cone-717> ffmpeg 03Paul B Mahol 07master:9d16e46d9eb4: avfilter/drawutils: allow drawing opaque text on transparent background
[12:04:01 CEST] <ubitux> michaelni: any last breakage?
[12:27:52 CEST] <michaelni> ubitux, i cant find any breakages except mkv changes which i did not look further at as i assume its the intended interlace change, just the 2 trivial nitpicks for the patch i just spoted & posted remain
[12:28:56 CEST] <ubitux> i checked the mkv, it was the same issue, 0x00 (unknown) ’ 0x02 (progressive) in the interlace field
[13:44:35 CEST] <cone-717> ffmpeg 03Paul B Mahol 07master:257fbc3af4cb: avcodec/dds: add support for 4bpp format
[13:47:32 CEST] <ubitux> what's the state of e7ac968f60dddd24c681101d5b9351c53ebc42f6?
[13:47:40 CEST] <ubitux> (post codecpar)
[14:24:13 CEST] <omerjerk> Hi!
[14:24:30 CEST] <omerjerk> I remember there was a command to run a particular fate test. 
[14:24:34 CEST] <omerjerk> What was that?
[14:25:00 CEST] <Chloe> make fate-testname
[14:25:07 CEST] <omerjerk> oh thanks!!
[14:25:11 CEST] <omerjerk> let me check
[14:25:13 CEST] <durandal_17> make fate-als
[14:25:50 CEST] <omerjerk> got it.
[14:26:13 CEST] <omerjerk> ah. my patch has broken all fate tests.
[14:29:15 CEST] <BtbN> that's not an easy thing to achive
[14:29:35 CEST] <durandal_17> omerjerk: what you changed?
[14:29:56 CEST] <Chloe> Yes, that does sound fairly impressive
[14:31:54 CEST] <omerjerk> I did make a hack in the decoder to get things working. I think that is the reason for this.
[14:32:09 CEST] <omerjerk> I'll make sure first.
[15:08:57 CEST] <cone-717> ffmpeg 03Paul B Mahol 07master:187c4273351f: avcodec/on2avc: add 0x500 stereo support and improve 0x500 mono support
[15:43:04 CEST] <cone-717> ffmpeg 03Clément BSsch 07master:955b818cf947: ffmpeg: switch to codecpar
[15:43:51 CEST] <ubitux> new bsf now... apparently it breaks stuff
[15:55:24 CEST] <jamrial> ubitux: \o/
[15:55:37 CEST] <JEEB> yayifications
[15:55:53 CEST] <ubitux> i have no idea what i'm doing with the bsf stuff
[15:57:02 CEST] <ubitux> btw, iiuc, i have to merge in this order:
[15:57:08 CEST] <ubitux> 4426540f0c3ee516662f79d0a6ab5b95503b6611 // avconv: switch to the new BSF API
[15:57:10 CEST] <ubitux> 35c858066840352d6d43385bbc728467c5150974 // avconv: stop using AVStream.codec
[15:57:12 CEST] <ubitux> 80fb19bc234a3f2350d891adf39f3738a8e4849f // avconv: fix a check for av_bsf_get_by_name() return value
[15:57:14 CEST] <ubitux> fe7b21c8f148493c6fbceb7f887a77531dd1ae0e // avconv: fix parsing bitstream filters
[15:57:16 CEST] <ubitux> ?
[15:57:18 CEST] <ubitux> missing any skipped one?
[15:57:29 CEST] <jamrial> afaik, that's all
[15:57:37 CEST] <jamrial> the last three can be squashed into one, though
[15:57:40 CEST] <ubitux> i pointed out e7ac968f60dddd24c681101d5b9351c53ebc42f6 previously; is that chunk still relevant?
[15:57:52 CEST] <jamrial> since the last two are just fixes for mistakes in 35c85806
[15:58:16 CEST] <ubitux> aren't the last two fix for the first one instead?
[15:59:05 CEST] <jamrial> ubitux: yeah, looks like, my bad
[16:00:07 CEST] <jamrial> ubitux: that subframe warning seems to be related to the port to the new decode api, which we haven't done yet
[16:00:09 CEST] <jamrial> so i guess it can wait
[16:01:34 CEST] <ubitux> ah, so that's another thing we skipped?
[16:02:38 CEST] <ubitux> we need to maintain doc/libav-merge.txt (bottom list)
[16:02:41 CEST] <ubitux> at least.
[16:03:28 CEST] <BtbN> Oh, libav already migrated to that? Nice
[16:05:58 CEST] <ubitux> braindead addition of the new bsf patch from libav to ffmpeg @ https://github.com/ubitux/ffmpeg/compare/ffmpeg-new-bsf
[16:06:09 CEST] <ubitux> failing at least with mpeg4-bsf-unpack-bframes currently
[16:07:07 CEST] <ubitux> [avi @ 0x2036760] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[16:07:10 CEST] <ubitux> heh...
[16:07:20 CEST] <ubitux> maybe the future is now
[16:07:22 CEST] <philipl> BtbN: you ok with the headers?
[16:08:19 CEST] <ubitux> there is a one byte difference
[16:08:34 CEST] <ubitux> (0x70 ’ 0x00)
[16:09:12 CEST] <ubitux> is this the effect of mpeg4_unpack_bframes?
[16:12:26 CEST] <nevcairiel> if its only one byte, maybe thats the effect of not processing the last frame or something
[16:18:12 CEST] <ubitux> it's at the beginning of the file
[16:21:36 CEST] <BBB> I Was alexander strange was still here
[16:21:42 CEST] <BBB> wish*
[16:22:15 CEST] <jamrial> ubitux: maybe change the test to output mov, mkv or something that can be analized, to know what that byte is about
[16:22:25 CEST] <jamrial> BBB: why?
[16:22:37 CEST] <BBB> I think he had a pretty good mpeg4 understanding
[16:22:43 CEST] <BBB> michaelni probably knows that stuff too
[16:22:52 CEST] <BBB> unpack_bframes is to allow frame threading btw
[16:22:55 CEST] <BBB> iirc
[16:23:06 CEST] <jamrial> ah
[16:23:31 CEST] <ubitux> BBB: he's on freenode, also #libav-devel
[16:23:51 CEST] <ubitux> but it's probably unrelated to bframes itself
[16:24:03 CEST] <ubitux> i guess it's a one field lost somewhere
[16:24:26 CEST] <jamrial> or maybe extradata related, again
[16:36:20 CEST] <ubitux> yeah it's a byte in the extradata
[16:37:29 CEST] <ubitux> the bsf filter probably doesn't filter it (or the wrong one or whatever forgotten copy)
[16:38:09 CEST] <nevcairiel> the mixture of codecpar and avctx is really quite confusing now
[16:38:57 CEST] <ubitux> yeah
[16:39:15 CEST] <jamrial> supposedly can't do anything about it until the new parser stuff is written
[16:39:33 CEST] <nevcairiel> unfortunately
[16:39:45 CEST] <nevcairiel> i told anton as much, but he didnt seem interested to move the parser stuff along at the time
[16:39:46 CEST] <jamrial> in any case, maybe 35c858066840352d6d43385bbc728467c5150974 should be squashed into this as well. it removes one fixme
[16:39:50 CEST] <nevcairiel> not sure if anything happened in the meantime
[16:41:24 CEST] <ubitux> mmh wait
[16:41:30 CEST] <ubitux> the bsf seems to work now
[16:41:33 CEST] <ubitux> while it wasn't previously
[16:41:37 CEST] <ubitux> unless i'm missing something
[16:42:15 CEST] <ubitux> yeah, it's fixing the reference
[16:42:28 CEST] <ubitux> [AVBSFContext @ 0x39a3980] Updating DivX userdata (remove trailing 'p') in extradata.
[16:42:30 CEST] <nevcairiel> yay for squashings?
[16:42:31 CEST] <ubitux> this wasn't done previosuly
[16:42:33 CEST] <ubitux> now it is
[16:43:07 CEST] <ubitux> 0x70 = 'p', now there is a 0x00 in the extradata
[16:43:11 CEST] <ubitux> so that's probably what we want
[16:45:17 CEST] <ubitux> ok, onto the next breakage, fate-adtstoasc_ticket3715
[16:49:22 CEST] <cone-717> ffmpeg 03Michael Niedermayer 07master:0a2ca417a1d7: avcodec/mlz: Remove 'l' postfixes from numbers
[16:49:23 CEST] <cone-717> ffmpeg 03Michael Niedermayer 07master:47ffcddaefee: avcodec/mlz: Check output chars before using it
[17:34:10 CEST] <BtbN> hm, cuvid is still crashing because of the h264 decoder assumption.
[17:34:50 CEST] <BtbN> need to figure out how to force the "probe decoder"
[18:16:23 CEST] <ubitux> http://sprunge.us/cMKK
[18:16:28 CEST] <ubitux> what's this missing information?
[18:16:53 CEST] <ubitux> "DecoderConfigDescriptor" broken extradata then?
[18:17:00 CEST] <jamrial> yeah
[18:17:10 CEST] <jamrial> try to change the test to output to matroska
[18:17:26 CEST] <ubitux> what for?
[18:17:26 CEST] <jamrial> it will give you "Error parsing AAC extradata, unable to determine samplerate."
[18:17:29 CEST] <nevcairiel> the adts bsf should produce extradata for it
[18:17:31 CEST] <ubitux> ok
[18:17:35 CEST] <jamrial> because extradata is null
[18:17:47 CEST] <ubitux> indeed
[18:17:49 CEST] <jamrial> for that matter, this also happens with avconv
[18:18:09 CEST] <ubitux> ah
[18:18:10 CEST] <nevcairiel> producing extradata with bsf has always been a problem
[18:18:16 CEST] <jamrial> so it seems they didn't have a fate test for aac_adtstoasc :p
[18:18:17 CEST] <ubitux> so it's not something i broke in the merge?
[18:18:20 CEST] <nevcairiel> thats why auto-bsf was developed
[18:18:22 CEST] <jamrial> apparently not
[18:18:23 CEST] <nevcairiel> because it has more power
[18:18:30 CEST] <ubitux> erm
[18:18:47 CEST] <nevcairiel> it only works with mov "by accident" because mov reads the extradata at the end of muxing
[18:18:59 CEST] <nevcairiel> if it were to read the extradata at the beginning, say like mkv, then it would always fail
[18:19:25 CEST] <nevcairiel> or well, used to, i guess
[18:19:35 CEST] <ubitux> so i need to keep the extradata copy somehow
[18:19:36 CEST] <jamrial> matroska uses the autobsf and applies aac_adtstoasc on its own, and it works fine with it. it only crashes and burns if you force it with -bsf
[18:20:06 CEST] <nevcairiel> the problem probably is that there is a fake avctx in between, and not a pure codecpar path
[18:20:07 CEST] <ubitux> i'm going away, if anyone wants to look at this, my github branch is up-to-date
[18:20:07 CEST] <jamrial> so the ffmpeg.c/avconv.c code is wrong somewhere, because extradata is lost
[18:20:08 CEST] <nevcairiel> i think
[18:20:24 CEST] <ubitux> (ffmpeg-new-bsf)
[18:24:00 CEST] <ubitux> afaict that's the only failing test
[18:24:24 CEST] <nevcairiel> honestly i dont think there is a proper clean way to fix this, the manual bsfs are just not designed to work like that, thats why we implemented the new bsf thing in avformat which can actually deal with a bsf that produces extradata
[18:24:45 CEST] <nevcairiel> only plan would be to remove the bsf stuff from ffmpeg entirely and just make it add a new bsf to the list avformat runs
[18:24:56 CEST] <nevcairiel> which was a plan for the future anyway
[18:27:32 CEST] <jamrial> can we just remove it like that?
[18:27:56 CEST] <jamrial> in a way, nobody uses -bsf unless ffmpeg fails and emits an error saying "use -bsf to fix this"
[18:28:15 CEST] <jamrial> which technically shouldn't happen anymore if autobsf is applied to every muxer that needs it
[18:28:28 CEST] <ubitux> that's exactly what happens here
[18:28:33 CEST] <ubitux> [mov @ 0x2bd5740] Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg)
[18:28:34 CEST] <cone-717> ffmpeg 03Timo Rothenpieler 07master:3b24020b54a9: avcodec/cuvid: implement new send_packet/receive_frame api
[18:28:35 CEST] <cone-717> ffmpeg 03Timo Rothenpieler 07master:0b420886a441: avcodec/cuvid: add support for hardware deinterlacing
[18:28:43 CEST] <ubitux> it will raise this if you don't add the filter
[18:28:47 CEST] <jamrial> mov should use autobsf. i wonder why it isnt'...
[18:29:04 CEST] <nevcairiel> mov autobsf had some issues with dash i think
[18:29:10 CEST] <nevcairiel> not sure what happened to the patchset
[18:29:15 CEST] <nevcairiel> rcombs would hopefully know
[18:30:48 CEST] <nevcairiel> its kinda silly that mov worked before just due to sheer luck of mov writing the header at write_trailer
[18:30:55 CEST] <nevcairiel> and not earlier
[18:44:52 CEST] <BtbN> michaelni, what do you think about introducing a new codec cap, "don't probe with this codec", and then checking for that in avformat/utils.c find_decoder?
[18:45:35 CEST] <BtbN> on top of that, it needs a hard-wired check to force the native h264 decoder for h264, as other code assumes it's using this decoder.
[18:47:37 CEST] <michaelni> BtbN, a new codec cap would be an option
[18:48:09 CEST] <BtbN> it probably affects a lot of other codecs too. Like, all the other ones cuvid supports. Probing with the native decoder would be better.
[18:50:29 CEST] <michaelni> yes,  it seems a good idea to add such cap
[18:51:11 CEST] <BtbN> the h264 hardcoding still has to happen though
[18:51:56 CEST] <BtbN> I'll submit that first to fix the crash, and then work out the cap
[18:58:49 CEST] <philipl> BtbN: if we're using bundled headers, I should just drop the check_type calls, right?
[18:59:18 CEST] <BtbN> yeah, no point in checking
[19:02:15 CEST] <BtbN> philipl, also, in the patchset I just sent, I gave up on the frame counter entirely.
[19:03:12 CEST] <BtbN> counting that feels like a dead end. There are so many special cases were it might not add up, that it seems like an endless source of problems
[19:03:53 CEST] <BtbN> for example, cuvid can duplicate a frame if it feels like it.
[19:03:57 CEST] <philipl> BtbN: Yeah. As soon as you need codec specific special cases, you're losing.
[19:04:27 CEST] <BtbN> even without that
[19:04:43 CEST] <philipl> what's the right way to do a check_lib test with an in-tree header?
[19:05:16 CEST] <BtbN> nvenc does it somewhere.
[19:05:27 CEST] <BtbN> I think you just specify -I$source_dir or something like that.
[19:05:51 CEST] <BtbN> I also notices this, in the ParserDispInfo in cuvid: int repeat_first_field; // Number of additional fields (1=ivtc, 2=frame doubling, 4=frame tripling, -1=unpaired field)
[19:06:06 CEST] <BtbN> it's allways 0...
[19:09:27 CEST] <philipl> what fun.
[19:13:20 CEST] <philipl> BtbN: configure patch sent
[19:13:29 CEST] <BtbN> The "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" is not caused by cuvid doing something wrong, is it? That's purely a (de)muxer issue, right?
[19:13:52 CEST] <philipl> I guess so, but I'm far from the expert.
[19:16:52 CEST] <jamrial> ubitux, nevcairiel: so av_bitstream_filter_filter(), which we used but libav didn't, updated extradata per packet
[19:16:53 CEST] <BtbN> hm, it is caused by cuvid not setting the dts
[19:17:02 CEST] <jamrial> after this bsf port commit that's apparently not happening anymore
[19:18:01 CEST] <jamrial> interestingly enough av_bitstream_filter_filter() uses the new bsf api alongside some compat code to work with the old, so maybe relevant extradata handling bits could be copied to ffmpeg.c
[19:19:36 CEST] <cone-717> ffmpeg 03Philip Langdale 07master:7447ec91b5a6: crystalhd: Use up-to-date bsf API
[19:24:25 CEST] <philipl> BtbN: patch as applied looks good with mpv
[19:26:40 CEST] <BtbN> it might run into edge cases if some api user actually fillt it up until it returns EAGAIN
[19:26:51 CEST] <BtbN> but if it's just one frame, and then read until EAGAIN, it's fine.
[19:27:11 CEST] <BtbN> and even then, during normal usage, it should work.
[19:27:15 CEST] <philipl> Yeah.
[19:27:22 CEST] <BtbN> Only if at flush, it decides to dump out 10 extra frames...
[19:27:45 CEST] <philipl> Well, flush kills the decoder, so that shouldn't happen.
[19:27:58 CEST] <BtbN> no, flush as in EOS signaling
[19:28:12 CEST] <philipl> ah, yes.
[19:28:25 CEST] <BtbN> it just sends all remaining frames at once then for some reason
[20:03:03 CEST] <jamrial> ubitux, nevcairiel: this fixes fate-adtstoasc_ticket3715 http://pastebin.com/3DC3HyVD
[20:03:09 CEST] <jamrial> but it's mainly a proof of concept since 99% chances it crashes and burns in other scenarios
[20:03:29 CEST] <jamrial> since it's not even considering there being more than one bsf in the chain
[20:04:10 CEST] <jamrial> i basically copy-pasted what av_bitstream_filter_filter() used to do
[20:21:30 CEST] <jamrial> ubitux, nevcairiel: fate passes now
[20:21:57 CEST] <nevcairiel> looks familiar
[20:22:07 CEST] <nevcairiel> like the shit we hacked in when changing bsf a pi
[20:22:18 CEST] <nevcairiel> but meh static? :)
[20:22:34 CEST] <jamrial> yeah, the static int sucks, i know :p
[20:22:42 CEST] <jamrial> as is said, it's not meant to be applied like this
[20:23:21 CEST] <jamrial> should be a matter of adding it to the OutputStream context, i simply copy pasted stuff to see if that'd fix the issue
[22:17:33 CEST] <kode54> cute, someone spamming this signature in their posts to the libav-users mailing list
[22:17:36 CEST] <kode54> Disclaimer :- This e-mail and any attachment may contain confidential, proprietary or legally privileged information. If you are not the original intended recipient and have erroneously received this message, you are prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sende
[22:17:36 CEST] <kode54> r. Newgen Software Technologies Ltd (NSTL) accepts no responsibilities for loss or damage arising from the use of the information transmitted by this email including damages from virus and further acknowledges that no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of NSTL. 
[00:00:00 CEST] --- Thu Sep 22 2016