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

[burek]

[00:26:03 CEST] <cone-836> ffmpeg 03Paul B Mahol 07master:0a9e781b8818: avcodec/sheervideo: fix predictions for c82p format
[00:42:28 CEST] <Compn> durandal_1707 : awesome work on sheer decoder btw :)
[00:42:55 CEST] <Compn> another codec down...
[00:43:18 CEST] <durandal_1707> Pay me!
[00:43:32 CEST] Action: j-b gives 2¬ to durandal_1707  :)
[00:43:34 CEST] Action: j-b runs
[00:45:19 CEST] <durandal_1707> Run, run, meet you at vdd
[00:48:17 CEST] <j-b> oh noes! :D
[04:16:39 CEST] <prelude2004c> good evening everyone.. i wanted to say thank you to DHE and andrey_turkin for the work done to fix both A53CC with nvenc & the 26.5 hour problem with PTS wrap.. everything is working well on all fronts and finally things are stable
[04:17:16 CEST] <prelude2004c> only thing left to do is to get cuvid working so we don't need xorg running and we can use the decoding capabilities of the cards without requiring X .. of course this is no rush as i simply have X running
[04:35:06 CEST] <DHE> nice
[09:54:19 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:c156420bce9e: avcodec/sheervideo: fix prediction for ybyr format
[10:24:55 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:bb5bc08ba6f8: MAINTAINERs cleanup (remove myself from things i de facto dont maintain)
[10:39:06 CEST] <BtbN> prelude2004c, cuvid has no idea about that CC hack.
[10:39:25 CEST] <BtbN> It's entirely unsupported, only one who could change that is Nvidia.
[10:39:43 CEST] <BtbN> Otherwise, it works great.
[11:26:48 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:2ed8baa61483: avcodec/sheervideo: add support for 10-bit interlaced YCbCr(A) 4:4:4(:4)
[12:56:50 CEST] <durandal_1707> whats about merging?
[13:09:52 CEST] <durandal_1707> can I get review for gbrap10?
[14:10:25 CEST] <durandal_1707> nobody here?
[14:12:32 CEST] <durandal_1707> I will start to manually pick interesting commits from downstreams, as usual
[14:13:36 CEST] <ubitux> durandal_1707: the merge is hard
[14:13:39 CEST] <ubitux> help welcome
[14:13:50 CEST] <ubitux> commit is mostly merged but there are a bunch of unsolved issues
[14:14:26 CEST] <durandal_1707> the h264 thing?
[14:14:34 CEST] <ubitux> yes
[14:14:41 CEST] <ubitux> https://github.com/ubitux/FFmpeg/commit/5cb25f94ffb5e096bac6156097c93cdba5c95078
[14:22:14 CEST] <durandal_1707> asked michaelni for help, I'm not into h264 right now
[14:22:23 CEST] <durandal_1707> ?
[14:46:08 CEST] <cone-598> ffmpeg 03Pedro Arthur 07master:b5deacfb1fec: swscale: fix crash with swscale-test when using slices
[14:46:09 CEST] <cone-598> ffmpeg 03Pedro Arthur 07master:e616e9a4b8fd: swscale: fix ring buffer size when scaling slices of a frame
[14:46:22 CEST] <ubitux> durandal_1707: michael is busy, and i'm not into h264 either :p
[15:12:26 CEST] <atomnuker> psignd is evil and will zero out elements in dst if src is 0
[15:21:01 CEST] <durandal_1707> ok to push gbrap10?
[15:32:23 CEST] <BBB> atomnuker: why is that not ok?
[15:32:41 CEST] <BBB> atomnuker: isnt the purpose of psignd to be used in accordance with src and tmp=pabsd(src)?
[15:33:46 CEST] <BBB> atomnuker: it saves an instruction for the common case; in any other case, just use psrad sign, src, 31, pxor tmp, sign and psubd tmp, sign
[15:39:11 CEST] <atomnuker> well, the thing is the simd I'm writing is for dequant
[15:39:28 CEST] <atomnuker> which is just (coef * qfactor + qscale) >> 2
[15:39:48 CEST] <atomnuker> so coef can be zero but the result might not be zero if qscale is large enough
[15:40:18 CEST] <atomnuker> so when I do psignd with my original register of coeffs the non-zero dequantized values get zeroes
[15:46:36 CEST] <iive> if src < 0 then dst=-dst
[15:46:43 CEST] <iive> if src == 0 then dst=0
[15:46:50 CEST] <iive> if src > 0 then dst=dst
[15:53:20 CEST] <atomnuker> grr, for some reason doing a psrad, pxor and psubd still doesn't match
[15:55:44 CEST] <michaelni> durandal_1707, gbrap10 is probably ok but i just briefly looked and it passes fate
[15:56:43 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:24f513619680: avcodec/mpegvideo: Do not clear the parse context during init
[16:05:39 CEST] <prelude2004c> BtbN , thank you sir.. i get it. cuvid would not work correctly with A54CC .. is it not open source ?
[16:05:59 CEST] <BtbN> Uhm, it's from nvidia?
[16:06:03 CEST] <prelude2004c> the idea is to use the decoding power of the nvidia card .. also what about using the code from NvDecoder ? 
[16:06:25 CEST] <prelude2004c> its open source. " BtbN> It's entirely unsupported, only one who could change that is Nvidia. " 
[16:06:42 CEST] <BtbN> cuvid is not open source.
[16:07:51 CEST] <prelude2004c> ic.. well NvTranscoder is . and NvEncoder is.. ( the sample code that is provided by nvidia ), I am sure the code on the decoder can be ported and a new variable like " -hwaccel nvdec " can be used to call in the decoder code.. and that code is open source and can be placed into ffmpeg with the cc stuff.
[16:08:10 CEST] <prelude2004c> then it would support 100% and would not require anything else... just an idea 
[16:08:40 CEST] <BtbN> And what would that change about cuvid being part of the cuda libraries?
[16:09:14 CEST] <prelude2004c> not sure if is has anything to do with that.. only reason  i am thinking about it is to get around the whole Xorg thing.. but other then that right now it works well with Xorg
[16:09:39 CEST] <prelude2004c> i am certain that even Xvfb might work too.. so
[16:30:06 CEST] <andrey_turkin> NvTranscoder doesn't support A53 either so
[16:31:37 CEST] <andrey_turkin> either Nvidia would do something about it (which is doubtful) or someone would need to go around cuvid to fetch captions from the bitstream and reorder them
[16:31:53 CEST] <BtbN> reordering wouldn't be too hard
[16:32:04 CEST] <Illya> Does anyone have some 'mod' samples?
[16:32:18 CEST] <BtbN> the parser does it, and the timestamps you give it are just passed through. So you could pass an array index as timestamp, and store stuff there.
[16:32:30 CEST] <Illya> I'm looking for single, dual, and quad channel samples.
[16:33:28 CEST] <andrey_turkin> Illya: modarchive.org?
[16:35:33 CEST] <andrey_turkin> BtbN: IIRC parser also gives bitstream for the frame. Shouldn't be hard to extract SEI data (if parser doesn't strip that) and store it elsewhere
[16:35:43 CEST] <Illya> andrey_turkin: I'll try that, thanks
[16:36:09 CEST] <BtbN> andrey_turkin, parsing the CC out of that would be a massive code duplication from the h264 parser.
[16:36:14 CEST] <BtbN> I don't think that's worth it.
[16:38:04 CEST] <andrey_turkin> I thought searching for NAL unit wasn't that hard
[16:39:11 CEST] <nevcairiel> we dont support such parsing from any other hardware decoders, so i dont think hacking that into there is a particular wise or accepted idea
[16:39:56 CEST] <kierank> cc needs reordering anyway
[16:39:59 CEST] <kierank> so won't work
[16:40:13 CEST] <BtbN> What reordering? From dts in pts order?
[16:40:14 CEST] <kierank> though vlc hacks the reordering
[16:40:16 CEST] <andrey_turkin> yes, provided we can also reorder
[16:40:16 CEST] <nevcairiel> he wants to hack in reordering as well
[16:40:23 CEST] <nevcairiel> its one giant hackjob
[16:40:26 CEST] <andrey_turkin> yep
[16:40:28 CEST] <nevcairiel> i wouldnt ok such a patch imho
[16:41:48 CEST] <andrey_turkin> I wonder if getting rid of video decoder at all would be cleaner. Say, separate "subtitles" decoder which takes whole bitstream in and outputs just CC data in correct order
[16:42:27 CEST] <kierank> would need to understand a complex b-frame pattern
[16:42:27 CEST] <kierank> etc
[16:42:32 CEST] <nevcairiel> knowing how to re-order i nthat seems impossibly complex
[16:42:54 CEST] <andrey_turkin> if it is framed and each frame has a pts wouldn't be as easy as that?
[16:43:20 CEST] <BtbN> How do you know at which point no lower pts is going to show up?
[16:43:28 CEST] <kierank> 3:40 PM <"nevcairiel> i wouldnt ok such a patch imho
[16:43:33 CEST] <kierank> yes but any hacky crap gets in these days
[16:43:45 CEST] <nevcairiel> its gotten better lately kierank
[16:44:22 CEST] <andrey_turkin> BtbN: ok that is a fair point. Spill on key frames?
[16:44:35 CEST] <BtbN> how do you know what's a key frame?
[16:44:36 CEST] <andrey_turkin> that that can introduce some massive delay with longer GOPs
[16:45:41 CEST] <andrey_turkin> isn't it signalled by demuxer?
[16:45:55 CEST] <BtbN> maybe. Maybe not.
[16:50:25 CEST] <andrey_turkin> well then it wouldn't work with such demuxers
[16:52:22 CEST] <BtbN> Anyway. The base cuvid decoder and hwaccel are fine how they are now. Going to rebase them. Should hopyfully not take any manual work.
[17:04:32 CEST] <BtbN> ok, still works fine.
[17:05:39 CEST] <cone-598> ffmpeg 03Timo Rothenpieler 07master:88e8aef9e935: avcodec/cuvid: add cuvid decoder
[17:05:40 CEST] <cone-598> ffmpeg 03Timo Rothenpieler 07master:d865e74e6d78: ffmpeg: Add cuvid hwaccel support
[17:28:03 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:8100426fe4ba: avutil: add 10-bit planar RGB with alpha
[17:28:04 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:9d30690f2034: swscale: add input support for gbrap10 pixel format
[17:28:05 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:f0e7b0645335: avcodec/sheervideo: fix argx format support
[17:28:06 CEST] <cone-598> ffmpeg 03Paul B Mahol 07master:9e9286e9edfb: avcodec/sheervideo: add support for 10-bit interlaced YCbCr(A) 4:2:2
[18:40:53 CEST] <Illya> I'm getting a really weird problem trying to write the libopenmpt demuxer, hitting a SIGABRT on av_frame_alloc stuff, which as far as I can tell doesn't touch the new code. log: http://sprunge.us/caAV
[18:46:45 CEST] <durandal_1707> Illya: code you wrote?
[18:48:36 CEST] <Illya> oh right ofc. here's he patch: http://sprunge.us/IZMJ I know that the strings in configure, and the classes are incorrect, but that shouldnt affect the code
[19:17:10 CEST] <durandal_1707> Illya: s16 takes 2 bytes
[19:17:39 CEST] <durandal_1707> so packet allocation is too small
[22:08:36 CEST] <Compn> vio ?
[22:09:01 CEST] <Compn> oh avio
[22:09:12 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:056a4ae771b0: avcodec/cfhd: Set dimensions unconditionally
[22:35:06 CEST] <cone-598> ffmpeg 03Mark Thompson 07master:d4cd8e7f6a49: vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31
[23:05:36 CEST] <ubitux> so i've updated the merge-libav branch with the merge commit done with 3-way mode so the diff is more readable (https://github.com/ubitux/FFmpeg/commits/merge-libav) after a suggestion by michael
[23:05:56 CEST] <ubitux> or well, not really more readable but less error prone i'll say
[23:14:21 CEST] <nevcairiel> it shows the pre-libav version additionally, i guess?
[23:14:32 CEST] <nevcairiel> pre-commit that is
[23:16:58 CEST] <ubitux> the 3 sections are pre-ours, pre-theirs, post-theirs
[00:00:00 CEST] --- Sat Jun 11 2016