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

[burek]

[00:07:33 CEST] <RiCON> reopening the rgb(a)10 encodes on qt just shows black, lol
[00:08:14 CEST] <RiCON> https://i.fsbn.eu/pub/cube-rgb10.mov https://i.fsbn.eu/pub/cube-rgba10.mov
[00:14:10 CEST] <durandal_170> yes, I thought its bug in lavc
[00:17:39 CEST] <durandal_170> RiCON: using latest utvideo?
[00:20:14 CEST] <JEEB> the utvideo author is pretty coal so if you have questions regarding the format I recommend poking him
[00:33:54 CEST] <durandal_170> I just need files
[00:39:04 CEST] <RiCON> durandal_170: yes, 16.1.0
[01:03:09 CEST] <RiCON> durandal_1707: https://i.fsbn.eu/pub/ball-utvideo-rgba_1.mov with rgba10 with after effects
[01:03:17 CEST] <RiCON> now it does open in quicktime at least
[01:05:07 CEST] <RiCON> https://i.fsbn.eu/pub/ball-utvideo-rgb10.mov
[01:09:05 CEST] <cone-749> ffmpeg 03Paul B Mahol 07master:84efdabc9425: avcodec/utvideodec: add support for UQRG and UQRA formats
[01:12:42 CEST] <jamrial_> utvideodec now has full 10bit support? time to nuke libutvideo wrapper :P
[01:13:18 CEST] <JEEB> cool
[03:27:08 CEST] <Illya> how do I tell ffmpeg that I've finished demuxing? I'm returning AVERROR(EOF) in read_packet
[03:30:38 CEST] <Illya> ah, it's AVERROR_EOF not AVERROR(EOF)
[03:45:09 CEST] <DHE> the EOF macro is from stdio.h
[04:38:52 CEST] <michaelni> ubitux, i redid the merge to check if you made some major erros but your work is good i came up with very similar code and bugs, debuging them here are the fixes: http://pastebin.com/BStce2ZP
[08:18:13 CEST] <omerjerk> does anybody know the alternative of this attribute in the new api ? - https://github.com/justinruggles/FFmpeg-alsenc/blob/alsenc/libavcodec/alsenc.c#L3123
[08:18:37 CEST] <omerjerk> I've to merge an old codec into the new codebase. 
[08:18:56 CEST] <omerjerk> any help appreciated. :)
[08:45:57 CEST] CTCP VERSION:  from fnodeuser (fnodeuser!02568958 at gateway/web/freenode/ip.2.86.137.88) to #ffmpeg-devel
[12:24:41 CEST] <ubitux> michaelni: oh, thanks a lot!
[12:25:10 CEST] <ubitux> i'm going to integrate them in my branch and test
[12:29:36 CEST] <nevcairiel> the parser sei change looks like we should clean that up later, if one of the libav merges doesnt already do that
[12:30:50 CEST] <ubitux> yes the sei chunk will probably go away
[12:31:03 CEST] <ubitux> there is a large commit dealing with sei later
[12:32:51 CEST] <ubitux> michaelni: in the case of SPS unavailable in decode_picture_timing, shouldn't we return AVERROR_INVALIDDATA?
[12:34:16 CEST] <nevcairiel> makes no huge difference, the return value of sei parsing is only checked under ef_explode
[12:34:20 CEST] <nevcairiel> but probably yes
[12:35:04 CEST] <michaelni> ubitux, maybe, i had first changed the return and then fixed the order, the return 0 may be unneeded. It was a try because the calling code skips later SEI if one fails 
[12:36:11 CEST] <michaelni> (that skip later on fail should be revisited as it doesnt seem optimal and trivial to change) but thats unrelated 
[12:38:57 CEST] <ubitux> which chunk makes #631 not need the -flags2 +chunk option?
[12:40:32 CEST] <cone-291> ffmpeg 03Paul B Mahol 07master:1a57b464cf16: avcodec/sheervideo: add 10-bit interlaced RGB(A) support
[12:50:04 CEST] <michaelni> ubitux, the "we cant fail if SPS isnt set this breaks current skip_frame code"  commit
[12:50:59 CEST] <ubitux> thanks
[12:51:54 CEST] <ubitux> we should probably have a fate test for this one
[12:51:54 CEST] <michaelni> posted a patch for not stoping after a SEI error
[12:52:39 CEST] <ubitux> the sample is 4MB
[12:52:46 CEST] <ubitux> it could be reduced i guess
[12:53:21 CEST] <michaelni> does it also work with some truncated piece of it ?
[12:53:53 CEST] <ubitux> the moov is at the end unfortunately
[12:54:27 CEST] <ubitux> but maybe a remux will still trigger the bug
[13:01:32 CEST] <michaelni> ubitux, smallest flle i could cut it to with remux is 1.2mb
[13:02:10 CEST] <michaelni>  -ss 6 -i ~/tickets/631/attachment.mp4 -t 11 -codec copy
[13:02:22 CEST] <nevcairiel> that should be fine for a test
[13:04:09 CEST] <michaelni> ok ill upload
[13:05:55 CEST] <ubitux> so i will merge https://github.com/ubitux/FFmpeg/commit/8ad7cb7f02fbdfb7b1b7ab774be56093d368ebf6 with master again properly and push this squashed
[13:06:02 CEST] <ubitux> unless there are remaining objections
[13:06:22 CEST] <ubitux> tell me when it's good to go so i don't do it two times
[13:06:40 CEST] <ubitux> i can wait for a test for #631
[13:06:42 CEST] <nevcairiel> all the issues are resolved now? neat
[13:06:51 CEST] <ubitux> yeah michael solved all the remaining ones
[13:11:43 CEST] <michaelni> file uploaded, you can add a fate test in 24h
[13:12:16 CEST] <michaelni> (or earlier if you dont mind a small number of fate clients failing for a few hours)
[13:13:38 CEST] <ubitux> it's fine it can wait
[13:14:56 CEST] <ubitux> i'll start preparing the merge in 5m
[13:34:30 CEST] <cone-291> ffmpeg 03Anton Khirnov 07master:3176217c60ca: h264: decouple h264_ps from the h264 decoder
[13:34:31 CEST] <cone-291> ffmpeg 03Clément BSsch 07master:1534ef87c74c: Merge commit '3176217c60ca7828712985092d9102d331ea4f3d'
[13:35:05 CEST] <ubitux> i'm going to do a few more (as long as they are easy)
[13:39:10 CEST] <cone-291> ffmpeg 03Clément BSsch 07master:83163577e297: lavc/h264: remove unused ff_h264_init_dequant_tables prototype
[14:34:45 CEST] <JEEB> wait what
[14:35:08 CEST] <JEEB> michaelni: are you really wishing that the timestamp wrapping logic would be *outside* mpeg-ps/ts demuxers?
[14:36:17 CEST] <JEEB> even though only the demuxer(s) themselves have the knowledge if this is a valid wrapping case or not
[14:37:47 CEST] <JEEB> also I think regarding seeking my opinion would almost be that with MPEG-TS seeking you can't really do better than with byte-based seeking if we're talking of things longer than ~26 hours
[14:38:51 CEST] <JEEB> and no, I didn't take a further look at the patch yet - just that I saw your comment regarding either having the wrapping logic in the using application (!?) or general lavf code (!?) - the latter of which is where some sort of generic piece of code currently resides?
[14:39:40 CEST] <nevcairiel> i dont think expecting avformat to simply output information as it is in the file is a bad thing
[14:40:32 CEST] <JEEB> but we do not export the information with which the user can decide whether or not the wraparound is correct or not?
[14:40:51 CEST] <JEEB> because at that point you'd be poking at the values @ the MPEG-TS packets
[14:41:19 CEST] <JEEB> and yes, you can end up with a different timestamp than you'd expect with wraparound + seeking anyways
[14:41:26 CEST] <nevcairiel> the patch doesnt really use any information beyond the pts
[14:41:32 CEST] <JEEB> ok
[14:41:57 CEST] <JEEB> in any case, for me it just seems... weird to want to have a generic library handle very format specific things, that's all
[14:43:02 CEST] <JEEB> I mean, having the user of the library or a generic piece of the library handle it
[14:43:08 CEST] <kierank> bencoh: more problems you solved in upipe ^
[14:44:42 CEST] <JEEB> was this the case where the library exports three timestamps?
[14:45:07 CEST] <kierank> yes upipe has different types of timestamp 
[14:45:33 CEST] <kierank> original (as coded), prog (with wrap), sys (aligned to system clock)
[14:46:04 CEST] <JEEB> yeah
[14:52:20 CEST] <michaelni> JEEB, iam not against doing some of the logic inside the demuxer if its needed/uses something thats not conveniently available outside
[15:08:10 CEST] <cone-291> ffmpeg 03Petru Rares Sincraian 07master:b78b077c91a7: fate: add afade test
[15:58:09 CEST] <cone-291> ffmpeg 03Anton Khirnov 07master:113aeee6aed3: h264_parser: move the H264DSPContext to the parser context
[15:58:10 CEST] <cone-291> ffmpeg 03Clément BSsch 07master:65d5f32fd7d2: Merge commit '113aeee6aed35cb786a9f6d69b0cb210f498b9da'
[16:28:46 CEST] <ubitux> michaelni, nevcairiel, can you test if this build for you? https://github.com/ubitux/FFmpeg/commits/merge-libav
[16:29:01 CEST] <ubitux> (it's hard to check if there is a need for updates in dxva etc)
[16:32:43 CEST] <nevcairiel> ubitux: testing
[16:33:02 CEST] <ubitux> thanks
[16:37:53 CEST] <nevcairiel> ubitux: builds fine here
[16:38:31 CEST] <ubitux> thanks, i'll wait a little more, and merge/squash
[18:29:47 CEST] <omerjerk> hey what's the alternative of avctx->coded_frame in the new api ?
[18:29:54 CEST] <omerjerk> https://github.com/justinruggles/FFmpeg-alsenc/blob/alsenc/libavcodec/alsenc.c#L3471
[18:30:15 CEST] <omerjerk> I have to change this code to support the new ffmpeg apis
[18:50:08 CEST] <durandal_170> please don't use coded_frame
[18:50:29 CEST] <durandal_170> Use frame directly
[18:57:13 CEST] <omerjerk> durandal_170: I'm not really sure what you mean. Can you give me some example from the code please ?
[18:57:51 CEST] <durandal_170> see other audio encoders
[18:57:59 CEST] <durandal_170> flacenc.c
[18:59:50 CEST] <omerjerk> okay. I'm having a look at it.
[19:03:55 CEST] <cone-763> ffmpeg 03Anton Khirnov 07master:c8dcff0cdb17: h264: factor out calculating the POC count into a separate file
[19:03:55 CEST] <cone-763> ffmpeg 03Clément BSsch 07master:bd3fd467febe: Merge commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8'
[19:04:22 CEST] <ubitux> hopefully i didn't break any hwaccel compilation
[19:04:27 CEST] <ubitux> poke me if i did
[19:33:03 CEST] <jamrial> ubitux: dxva2 compiles fine
[19:36:39 CEST] <jamrial> ubitux: and ffmpeg -hwaccel dxva2 still works it seems
[19:43:05 CEST] <Illya> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195230.html what does carl mean with his first comment? Should I add a macro which changes the result to EXTENSION + 1 instead of  based on 32/64bit?
[19:45:43 CEST] <jamrial> Illya: no, 32bits as in you're only checking four bytes out of the probe buffer. probe_max should be used when you test enough data that it's virtually impossible the file is anything else
[19:47:01 CEST] <Illya> oh right, thanks
[19:49:14 CEST] <Illya> what is EXTENSION? Doesnt seem to be a defined macro
[19:55:26 CEST] <jamrial> Illya: AVPROBE_SCORE_EXTENSION
[20:05:27 CEST] <ubitux> Illya: isn't libopenmpt supposed to recognize all kind of tracker formats?
[20:10:39 CEST] <ubitux> mmh anyone on darwin to test if http://sprunge.us/CMSV  fixes vda compilation?
[20:31:17 CEST] <cone-763> ffmpeg 03Michael Niedermayer 07master:c3ad63c6a3d5: avcodec/iff: Fix bytestream advance
[20:57:17 CEST] <cone-763> ffmpeg 03Clément BSsch 07master:82d79970edb1: lavc/vda_h264: fixes compilation after 1534ef87
[20:57:18 CEST] <cone-763> ffmpeg 03Clément BSsch 07master:4df944920c2b: lavc/videotoolbox: fixes compilation after 1534ef87
[20:57:19 CEST] <cone-763> ffmpeg 03Clément BSsch 07master:aafdad1b454c: lavc/videotoolbox: fix sps/pps mistake introduced in 1534ef87
[21:15:54 CEST] <DHE> anyone following the mpegts timestamp thing in the mailing list. I feel like I'm beating my head into a wall trying to explain it to Carl
[21:26:03 CEST] <durandal_170> just ignore Carl
[21:27:02 CEST] <JEEB> DHE: most people have such experiences
[21:27:35 CEST] <JEEB> (I had my first one with regards to multimedia frameworks that aren't lavc/lavf)
[21:28:59 CEST] <DHE> insert llamas with hats joke here
[22:23:01 CEST] <atomnuker> rcombs: hey what happend with those patches to bring the mkv demuxer to feature parity with mpv's demuxer you had?
[22:23:12 CEST] <rcombs> atomnuker: they're still sitting here
[22:23:27 CEST] <rcombs> at some point I need to make them a bit more robust and maybe faster
[22:24:03 CEST] <atomnuker> maybe it would be worth sending them to the ML as RFC
[22:24:10 CEST] <DSM_> durandal_170: hi
[22:24:46 CEST] <rcombs> sure, I'll rebase and send
[22:25:05 CEST] <durandal_170> DSM_: hi
[22:25:33 CEST] <atomnuker> rcombs: thanks
[22:26:04 CEST] <rcombs> also I don't think there's anything blocking my autobsf patches but am not quite confident enough to push them
[22:27:21 CEST] <atomnuker> resend them
[22:29:33 CEST] <rcombs> sure
[22:30:49 CEST] <DSM_> durandal_170: are we gonna share MVs through frame side data? -vf "mestimate, minterpolate"
[22:31:27 CEST] <DSM_> durandal_170: what about other data like block size?
[22:31:35 CEST] <jamrial> rcombs: something needs to be done about the memleak before 3.1 is released, though
[22:32:01 CEST] <durandal_170> they are shared, mvs from one filter goes to another
[22:32:41 CEST] <durandal_170> DSM_: minterpolate uses mvs from mestimate
[22:32:45 CEST] <DSM_> durandal_170: block size?
[22:33:40 CEST] <durandal_170> you need to have same block size for all frames
[22:34:20 CEST] <DSM_> durandal_170: what about block size? 
[22:34:30 CEST] <DSM_> (i hate this internet connection)
[22:34:38 CEST] <cone-763> ffmpeg 03James Almer 07master:8fdad638f922: avformat/redspark: remove av_malloc usage
[22:34:39 CEST] <cone-763> ffmpeg 03James Almer 07master:15f9189b9cc8: avformat/redspark: deobfuscate header decrypt code
[22:35:42 CEST] <durandal_170> DSM_: check that its same for two frames between which you interpolate?
[22:36:41 CEST] <DSM_> if we implement halfpel accuracy motion estimation, that requires interpolation of the sub-pixels (in a temp frame) while estimation, and also while interpolating new frame. so we have to do same thing twice. 
[22:37:18 CEST] <DSM_> that's like encoding (partially) in mestimate and decoding in minterpolate
[22:39:07 CEST] <DSM_> durandal_170: if any algorithm of motion esitmaion require slightly different step (for optimization) there's no way of telling which one mestimate used
[22:40:47 CEST] <DSM_> so, i was thinking to share methods for both filters?
[22:41:41 CEST] <DSM_> i don't know where else motion vectors generated by mestimate filter will be used? so why do we need two filters? why not merge them?
[22:42:12 CEST] <durandal_170> sharing functiond is possible, just put it into separate file
[22:42:48 CEST] <durandal_170> and use headers and modify makefile
[22:43:01 CEST] <DSM_> yeah, that way minterpolate will be independent filter
[22:43:08 CEST] <DSM_> of mestimate
[22:44:50 CEST] <DSM_> durandal_1707: where else the vectors will be useful?
[22:47:27 CEST] <durandal_1707> for minterpolate and codecview, and any other filter that needs them
[22:49:23 CEST] <rcombs> durr; sent broken patches
[22:53:52 CEST] <DSM_> durandal_1707: okay
[22:54:29 CEST] <atomnuker> rcombs: what do you mean, the patches are broken or the ML lagged and failed to group them?
[22:55:04 CEST] <rcombs> atomnuker: the former; there was a conflict in the rebase that I failed to fix before sending
[22:59:00 CEST] <atomnuker> ah well, happens, just send a reply to the broken ones with a fix
[23:00:46 CEST] <rcombs> yeah, just verifying I've fixed them properly
[23:01:02 CEST] <rcombs> remind me how I confirm that the VP9 superframe BSF is working properly?
[23:01:26 CEST] <rcombs> the test output changed and I need to confirm the new output is still correct before updating the hash
[23:02:50 CEST] <atomnuker> BBB?
[23:02:54 CEST] <nevcairiel> if it changes, how is it correct
[23:03:41 CEST] <rcombs> I assumed there was some other change (MKV muxer?) that's causing the output hash to change, but I'm not sure thus want to confirm
[23:05:12 CEST] <atomnuker> it had something to do with feeding in a raw .ivf and muxing it to a matroska IIRC
[23:05:32 CEST] <atomnuker> or was it the other way around
[23:05:32 CEST] <rcombs> it changed when I rebased the patch adding the test (from a couple months back) on latest master
[23:06:06 CEST] <rcombs> atomnuker: in this case it demuxes matroska, feeds through the BSF, and muxes matroska
[23:07:31 CEST] <rcombs> I verified the output was correct when I first added the test, but I forget how
[23:07:57 CEST] <nevcairiel> you would get muxing errors when it doesnt work, afaik
[23:08:33 CEST] <rcombs> well "muxes successfully" doesn't necessarily == "correctly generated superframes"
[23:08:36 CEST] <nevcairiel> and you should be able to check by doing framecrc on the original and the remux and verify all frames are present and accounted for
[23:08:42 CEST] <rcombs> ahh
[23:08:59 CEST] <rcombs> well, that's halfway
[23:10:05 CEST] <rcombs> (framecrcs do indeed match)
[23:11:37 CEST] <rcombs> ah yeah, superframes being created is indicated by multiple packets with the same PTS, right?
[23:11:51 CEST] <nevcairiel> well you would get that without the superframe bsf
[23:11:54 CEST] <nevcairiel> which errors
[23:13:02 CEST] <rcombs> well I'm seeing that both in input and output
[23:13:48 CEST] <BBB> rcombs: there is a fate test
[23:14:30 CEST] <rcombs> BBB: other than the one I'm talking about verifying?
[23:14:40 CEST] <rcombs> (fate-vp9-autobsf-superframe, which isn't in master yet)
[23:14:47 CEST] <BBB> rcombs: fate-matroska-remux
[23:14:52 CEST] <BBB> which does the same thing
[23:15:36 CEST] <rcombs> oh someone added a test for it while I wasn't looking
[23:15:41 CEST] <BBB> that was me
[23:15:45 CEST] <rcombs> ah, thanks
[23:15:56 CEST] <rcombs> it's nearly identical to the one I'm poking at, so I'll just remove mine from the patchset
[23:16:09 CEST] <BBB> ok
[23:18:23 CEST] <BBB> durandal_1707: hm, 4 months
[23:18:34 CEST] <BBB> durandal_1707: why 4? why not 1, or 12?
[23:26:49 CEST] <rcombs> Marton Balint doesn't hang around here, does he?
[23:31:15 CEST] <nevcairiel> dont think so
[23:39:59 CEST] <Illya> ubitux: err, I think so. however libopenmpt's probe hangs for a very long time unless the effort is set really low.
[23:40:21 CEST] <Illya> ubitux also, vda seems to compile without the patch
[00:00:00 CEST] --- Mon Jun 13 2016