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

[burek]

[00:43:35 CEST] <cone-199> ffmpeg 03Michael Niedermayer 07master:1cacecce7953: avcodec/libutvideoenc: Fix memleak
[01:46:48 CEST] <cone-199> ffmpeg 03Michael Niedermayer 07master:8ce564ea280b: avformat/mov: Mark avio context of decompressed atoms as seekable
[03:17:28 CEST] <chrisjunkie> (should have posted this here first instead of #ffmpeg) Hey all, I've been eagerly waiting QuickSync to appear in FFMpeg's main repo, this looks like its the case. Obviously its not in a current release (as I can't find any documentation) but is there a group thats working on this? Happy to provide testing help and offer fixes when I can
[03:17:38 CEST] <chrisjunkie> Also wondering if its working on Linux 8=)
[03:22:23 CEST] <Compn> which quicksync ?
[03:22:37 CEST] <Compn> is that intel hwaccel or something ?
[03:29:57 CEST] <chrisjunkie> Yeah, Intel QuickSync. Its in all their CPUs now (almost all of them)
[03:30:44 CEST] <chrisjunkie> its libavcodec/qsv* in git
[03:31:43 CEST] <Timothy_Gu> chrisjunkie: well, as I understand it's pretty much "done," and no additional work is underway
[03:32:04 CEST] <Timothy_Gu> chrisjunkie: of course if you can provide testing or other kinds of feedback that would be great
[03:32:34 CEST] <Timothy_Gu> we also might use a wiki page or some documentation on any quirks you've found :)
[03:32:52 CEST] <chrisjunkie> Yeah ok cool, wheres the best place for that? Just create a new page in Trac?
[03:33:17 CEST] <chrisjunkie> Would be good to document whats required to install and use it etc
[03:33:20 CEST] <chrisjunkie> Happy to do that
[03:33:28 CEST] <Timothy_Gu> yep http://trac.ffmpeg.org/wiki/Encode/QuickSync for example
[03:33:52 CEST] <Timothy_Gu> yes. Thanks!
[03:34:12 CEST] <chrisjunkie> It can also do decoding so maybe just one page for btoh
[03:34:46 CEST] <Timothy_Gu> Or maybe http://trac.ffmpeg.org/wiki/HWAccel/QuickSync would do
[03:35:17 CEST] <chrisjunkie> OK Timothy_Gu - will see what I can mock up
[03:35:34 CEST] <Timothy_Gu> cool! if there's any problems feel free to ping me
[03:36:24 CEST] <Compn> thanks for helping chrisjunkie :)
[03:36:57 CEST] <chrisjunkie> No worries - FFMpeg has helped me immensly over the past few years so the least I can do is contribute back right! Thats the power of open source :-)
[03:41:30 CEST] <chrisjunkie> http://trac.ffmpeg.org/wiki/HWAccel/QuickSync is now officially a page - I'll add to it later
[03:41:53 CEST] <chrisjunkie> Thanks guys, will be back later
[05:22:02 CEST] <cone-873> ffmpeg 03Michael Niedermayer 07master:e4c2ec879b11: avcodec/put_bits: Update size_in_bits in set_put_bits_buffer_size()
[05:22:02 CEST] <cone-873> ffmpeg 03Michael Niedermayer 07master:561d3a57aaa9: avcodec/mpegvideo_enc: Update the buffer size as more slices are merged
[05:22:02 CEST] <cone-873> ffmpeg 03Michael Niedermayer 07master:8f5ffed183e0: avcodec/put_bits: Assert that there is enough space left in skip_put_bytes()
[05:22:02 CEST] <cone-873> ffmpeg 03Michael Niedermayer 07master:291ad5cc9cf8: avcodec/bitstream: Assert that there is enough space left in avpriv_copy_bits()
[09:52:33 CEST] <j-b> 'morning
[10:34:32 CEST] <durandal_1707> good morning
[11:50:55 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:bd46e78aa4e7: avcodec/put_bits: Assert that size in set_put_bits_buffer_size() does not cause integer overflows
[12:40:15 CEST] <ubitux> rcombs: so, do you have some fancy Dialogues to share?
[12:54:37 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:2ce6e419113f: ffmpeg_opt: Set the video VBV parameters only for the video stream from -target
[12:54:38 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:73f71799242e: avformat/mpegenc: Do not use floats for vcd_padding_bitrate
[13:35:06 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:343654c288d0: avformat/mpegenc: Replace *0.7 by *7/10
[13:35:07 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:cf401cd12b79: avformat/rmenc: Avoid floats in duration calculation
[15:03:47 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:00f3bb2ef2bb: avcodec/mpegvideo: Factor ff_mpv_reallocate_putbitbuffer() out
[15:03:48 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:c50904fd7899: avcodec/mjpegenc_common: Use ff_mpv_reallocate_putbitbuffer()
[16:10:50 CEST] <cone-894> ffmpeg 03Andreas Cadhalpun 07master:e48a9ac9af5f: libshine: fix support for shine 3.0
[20:03:47 CEST] <Zeranoe> Is libmfx faster/better than the internal H.264 decoder?
[20:04:05 CEST] <BtbN> Isn't libmfx the qsv encoder?
[20:05:17 CEST] <Zeranoe> I thought it was Intel's H.264 hardware decoder?
[20:06:29 CEST] <BtbN> They do that via dxva on windows i think
[20:16:35 CEST] <Compn> Zeranoe : most hardware h264 decoders dont do 10bit (or didnt back in the day, no idea about now)
[20:18:03 CEST] <Daemon404> they still do not
[20:20:46 CEST] <JEEBsv> some weird people say that some tegras support it but AFAIK that's mostly people not noticing the decode errors from decoding 10bit stuff as 8bit, or them really believing the marketing bullshit of some android video players
[20:21:03 CEST] <JEEBsv> where they market hardware YCbCr->RGB in the same group as hw decoding
[20:21:40 CEST] <JEEBsv> professional AVC ASICs probably support 10bit 4:2:2 AVC (intra only)
[20:21:55 CEST] <JEEBsv> and since pegasys added support, possibly 4:4:4 all intra 10bit
[20:22:27 CEST] <JEEBsv> HEVC is the first thing where 10bit support with 4:2:0 is going to end user priced hardware
[20:39:03 CEST] <philipl> JEEBsv: But it's ok, the anime people will have moved to 12bit by then.
[20:39:52 CEST] <rcombs> eh, I'd expect severe diminishing returns on compression efficiency going from 10 to 12-bit
[20:39:56 CEST] <rcombs> assuming it helps at all
[20:39:58 CEST] <JEEBsv> ye
[20:40:20 CEST] <philipl> I don't think the anime argument has much rationality behind it.
[20:40:52 CEST] <cone-894> ffmpeg 03Niklesh 07master:9aabc926ca14: Improve upon dynamic arrays- movtext subtitles
[20:40:58 CEST] <rcombs> Zeranoe: isn't the general pattern that hardware video decoding is only significantly faster if you're not copying back to CPU memory?
[20:41:01 CEST] <JEEBsv> 10bit movement waited 10 months for lavc to support it and that was pretty rational :P
[20:41:29 CEST] <philipl> The perceived benefits, if any, don't outway the inability to use hardware decoders.
[20:42:09 CEST] <philipl> rcombs: Yes. Hardware decoders are mostly useless if you're not trying to display the video in realtime.
[20:42:23 CEST] <rcombs> philipl: or re-encode
[20:42:41 CEST] <philipl> You get lower CPU consumption at realtime frame rates but you will be frame-rate limited trying to do transcoding.
[20:43:09 CEST] <philipl> The hardware simply isn't designed to be fast.
[20:44:01 CEST] <rcombs> can be faster than doing it on the CPU in cases of lower-end Intel, or ARM, CPUs
[20:44:22 CEST] <JEEBsv> intel's and AMD's recent ASICs are pretty damn quick in decoding
[20:44:31 CEST] <JEEBsv> I remember seeing numbers of ~400fps
[20:44:42 CEST] <philipl> With copy back to system memory?
[20:44:44 CEST] <JEEBsv> and 1080p60 has been possible since after the 9000 series from ~2008
[20:45:57 CEST] <philipl> Sure, you can do 60fps all day if that's your goal, but on a high end system, you'll get faster transcoding, with higher CPU cost, using software.
[20:46:20 CEST] <philipl> rcombs: There is a set of scenarios with low end CPUs where you might end up net faster using hardware for the decode.
[20:46:21 CEST] <JEEBsv> that was mostly noting the age :P
[20:47:01 CEST] <philipl> Of course, ideally you'd want to fast-path between the decoder and encoder hardware (a la shadowplay) but I don't think anyone's investigated that.
[20:47:11 CEST] <philipl> nvidia explicitly don't support it between vdpau and nvenc. Shame.
[20:48:26 CEST] <JEEBsv> anyways, trying to think that for anime fansubs in general hardware decoding was anywhere on the table at all as a priority is a rather mistaken way of thought :P AVC was adopted a year or two after nero and things came around, and 10bit was adopted by the non-braindead part as soon as lavc got support
[20:48:58 CEST] <philipl> I know that anime mindside considers hardware decoding to be a peasent's sport. That doesn't mean they're right.
[20:49:20 CEST] <philipl> s/mindside/mindset/
[20:49:45 CEST] <JEEBsv> it's not a priority, and I don't see there being anything right or wrong about that
[20:50:03 CEST] <JEEBsv> and it's not like there wasn't plenty of decode'able content who really wanted it
[20:50:10 CEST] <JEEBsv> for their devices
[20:50:30 CEST] <philipl> If one is obsessed with quality, why re-encode at all? Just distribute the original h.264 stream. Rather than dicking around with 10bit.
[20:50:31 CEST] <wm4> to be fair, I haven't seen any real reason yet to use hardware decoding on the desktop
[20:50:38 CEST] <nevcairiel> philipl: both intel and recent nvidia can do >400fps on 1080p with copy-back
[20:50:59 CEST] <wm4> it's either about netbooks (lol), power saving for laptops (who plays video on battery?), or because they simply "want" it for no reason
[20:51:05 CEST] <philipl> nevcairiel: Huh. I'm out of date.
[20:51:10 CEST] <nevcairiel> wm4: hevc has somewhat of a reaosn as software decoders are still terribly slow
[20:51:19 CEST] <wm4> probably
[20:51:29 CEST] <wm4> 4K probably had the same justification years ago
[20:51:31 CEST] <nevcairiel> nvidias hevc 10-bit decoder is pertty nice
[20:51:36 CEST] <JEEBsv> yeah
[20:51:36 CEST] <nevcairiel> 4k 10-bit at ~100 fps
[20:52:03 CEST] <rcombs> philipl: I haven't tested it, but I think full GPU->GPU (no-copy) transcoding should work for VAAPI, and definitely should for MMAL (Raspberry Pi)
[20:52:21 CEST] <rcombs> wm4: I do, on airplanes and shit
[20:52:28 CEST] <rcombs> re: "who plays video on battery?"
[20:52:48 CEST] <philipl> nevcairiel: Where is that available? VDPAU only exposes 8bit. Do they expose more through DXVA?
[20:53:00 CEST] <nevcairiel> yes
[20:53:06 CEST] <nevcairiel> vdpau is just behind like always
[20:53:23 CEST] <wm4> vdpau did get higher bit depth support
[20:53:36 CEST] <rcombs> wm4: for HEVC?
[20:53:36 CEST] <philipl> Yeah, the API has 10bit hevc but the driver doesn't expose it.
[20:53:49 CEST] <philipl> I'm still working on exposing the HEVC decoding support in ffmpeg.
[20:53:55 CEST] <wm4> maybe, but there's no hevc vdpau support in lavc
[20:54:05 CEST] <philipl> I've got video on screen but it's not looking right.
[20:54:06 CEST] <nevcairiel> that probably shouldnt be too hard
[20:54:09 CEST] <rcombs> newer Intel GPUs do 10-bit HEVC as well
[20:54:14 CEST] <nevcairiel> i already made all the required changes to the hevc decoder
[20:54:19 CEST] <nevcairiel> so you just need to fill in the structs
[20:54:23 CEST] <philipl> "Just" :-)
[20:54:28 CEST] <rcombs> there's apparently one series that does 8-bit but not 10-bit
[20:54:41 CEST] <nevcairiel> strictly speaking, no intel gpu does hevc yet
[20:54:51 CEST] <nevcairiel> on windows they have a opencl hybrid accelerator
[20:55:12 CEST] <nevcairiel> (well, one exception, i think the newest Atom x5/x7 do hevc)
[20:55:27 CEST] <JEEBsv> nevcairiel: btw I noticed my recent HEVC test encodes crash lavc DXVA2. want to check them as I haven't gotten to building lavc with MSVC for debug symbols yet? The streams are technically nonstandard (since all levels except for 8.5, which is unusable in every profile except for the still ones, limit refs to 8 or so) but a crash is still a crash.
[20:55:30 CEST] <philipl> nevcairiel: Right now it's displaying as twice as tall as it should with black lines between each picture line and then it wraps around and so the top half overlays the bottom half.
[20:55:36 CEST] <rcombs> I've seen some vainfo output listing "VAProfileHEVCMain               :	VAEntrypointVLD"
[20:55:39 CEST] <philipl> I can't comprehend the error condition.
[20:55:55 CEST] <nevcairiel> philipl: that sounds like a very bizzare problem
[20:56:10 CEST] <philipl> This is with an intra-only sample with no scaling lists or tiling.
[20:56:20 CEST] <philipl> So there's really no ambiguous metadata for me to mis-interpret.
[20:56:38 CEST] <philipl> I've been in contact with one of the nvidia guys but he's on holiday this weekend so waiting for a response.
[20:56:51 CEST] <nevcairiel> JEEBsv: maybe its overflowing some ref list? not sure those are bound-checked
[20:56:59 CEST] <JEEBsv> https://fushizen.eu/u/jeeb/2015-05-15-ngnl_op/2135kbps/hevc_ngnl_op_crf19.mkv
[20:57:03 CEST] <JEEBsv> one of the files
[20:57:58 CEST] <JEEBsv> I do like the fact that hevc added an "unlimited" level (8.5), but the fact that it's effectively unusable is kind of meh
[20:58:48 CEST] <nevcairiel> doesnt seem to crash here, but also doesnt output any picture at all :)
[20:58:55 CEST] <JEEBsv> oh
[20:59:05 CEST] <rcombs> JEEBsv: "playable on a universal turing machine"
[20:59:49 CEST] <JEEBsv> rcombs: it's not much different from --ref 16 encodes in AVC, so I'm kind of "huhwhat" at why they limited it
[21:00:04 CEST] <nevcairiel> ref 16 is possible in some profiles, isnt it?
[21:00:12 CEST] <nevcairiel> and some hardware even does it
[21:00:17 CEST] <rcombs> damn, I need a second season of NGNL
[21:00:18 CEST] <JEEBsv> with AVC, sure
[21:00:37 CEST] <JEEBsv> HEVC specifically limits all levels except 8.5 to 8 refs
[21:00:48 CEST] <rcombs> wat
[21:00:49 CEST] <JEEBsv> and then every profile in the spec except for intra only
[21:00:57 CEST] <JEEBsv> doesn't let you use level 8.5
[21:01:10 CEST] <rcombs> even for 1080p?
[21:01:14 CEST] <JEEBsv> yes
[21:01:15 CEST] <nevcairiel> that makes sense, more refs are likely never making much sense :p
[21:01:26 CEST] <JEEBsv> nevcairiel: that I do kind of agree with
[21:01:28 CEST] <JEEBsv> it's still weird
[21:01:40 CEST] <rcombs> so& lower memory requirements than AVC?
[21:02:14 CEST] <rcombs> (in some cases?)
[21:02:30 CEST] <nevcairiel> hm i really need an option to select the GPU i want in my decoder
[21:02:37 CEST] <nevcairiel> my primary GPU doesnt to hevc 10-bit
[21:02:51 CEST] <nevcairiel> i keep editing the source for testing <.<
[21:04:04 CEST] <nevcairiel> JEEBsv: i think its hitting the assert i put in there to make sure the lists dont overflow :D
[21:04:08 CEST] <JEEBsv> :D
[21:05:07 CEST] <nevcairiel> since the spec doesnt allow more than 8 refs in anything, the lists in the dxva struct are only 8 elements in size
[21:05:26 CEST] <JEEBsv> yeh, that makes sense
[21:05:42 CEST] <BtbN> 8 refs max sounds quite small
[21:05:47 CEST] <nevcairiel> nah
[21:06:02 CEST] <nevcairiel> i think someone tested that with avc before, and anything over 6 or so didnt yield much of a benefit at all
[21:06:36 CEST] <JEEBsv> yeah, except for some very specific cases. in general you're going into diminishing returns if any
[21:08:17 CEST] <nevcairiel> you can actually have 16 frames in the DPB (current frame + 15 others), but only 8 can be active refs  for the current frame
[21:08:30 CEST] <nevcairiel> so you can shuffle them around a bit if you really wanted to
[21:08:36 CEST] <JEEBsv> yeh
[21:08:45 CEST] <JEEBsv> only NumPicTotalCurr is limited
[21:15:47 CEST] <nevcairiel> the video sure looks interesting when it attempts to decode it but half the frames fail on account of too many refs
[21:16:13 CEST] <JEEBsv> CUVID IIRC output something
[21:16:28 CEST] <nevcairiel> dxva now does too
[21:16:31 CEST] <nevcairiel> looks funky
[21:17:01 CEST] <JEEBsv> :D
[21:17:10 CEST] <nevcairiel> maybe i should change the loops to fill based on their own sizhe, and not the dpb size
[21:17:13 CEST] <nevcairiel> like the h264 code works
[21:25:59 CEST] <Zeranoe> So how is libmfx different than any other encoder, seeing it seems to be using the CPU?
[21:27:40 CEST] <BtbN> It's the intel hardware encoder library.
[21:28:17 CEST] <BtbN> The hardware encoder is inside of the CPU, but it doesn't use CPU time.
[21:33:33 CEST] <Compn> Zeranoe : are you wanting to put libmfx in ffmpeg or something ?
[21:33:45 CEST] <Zeranoe> Already done, for the Windows FFmpeg builds
[21:33:47 CEST] <nevcairiel> there is a libmfx encoder in ffmpeg
[21:33:51 CEST] <nevcairiel> its called qsvenc
[21:36:27 CEST] <Zeranoe> It looks like https://github.com/lu-zero/mfx_dispatch is using a pretty old Intel Media SDK. If I get some time I might try to update to the 6.0.0.349 version released this month. Still, it's better than nothing.
[21:36:57 CEST] <BtbN> It propably uses the last free one. Or is it still free on windows?
[21:37:28 CEST] <Zeranoe> You can dl the SDK from their site, just have to give them your email
[21:40:34 CEST] <nevcairiel> the dispatcher is part of the SDK
[21:40:47 CEST] <nevcairiel> that github project juist slapped some scripts on top
[21:41:39 CEST] <Zeranoe> nevcairiel: The dispatcher uses VS project files, so that project actually turned it into cmake/autotools
[21:49:53 CEST] <BBB> Timothy_Gu: that patch of yours is really weird, but I guess if thats the recommended way, then its ok& does it make sense to define __SECT__ in x86inc.asm or so, so that we dont have to put this in each file that uses structs?
[21:50:05 CEST] <BBB> Timothy_Gu: Im not against it btw, but its a little ugly to put __SECT__ in each .asm file
[21:50:13 CEST] <BBB> so Im wondering if theres something easier...
[21:50:42 CEST] <nevcairiel> JEEBsv: i hope people dont start encoding such videos, right now its impossible to detect that its such a crazy-pants encode
[21:51:18 CEST] <nevcairiel> doesnt signal profil or level :(
[21:51:26 CEST] <nevcairiel> profile*
[21:51:33 CEST] <JEEBsv> yeah
[21:51:45 CEST] <JEEBsv> I would have preferred x265 to have signalled 8.5 >_>
[21:52:11 CEST] <JEEBsv> which is out of spec but better than... not using the "unlimited" level
[21:53:11 CEST] <nevcairiel> are you sure that exceeding the 8 refs is even in spec for that level
[21:53:23 CEST] <nevcairiel> it seems like a rather fundamental codec limit to me
[21:54:27 CEST] <JEEBsv> the wording is "when the specified level is not 8.5, ... f) the value of NumPicTotalCurr shall be less than or equal to 8"
[21:54:59 CEST] <JEEBsv> (and the profiles then prevent you from using level 8.5 in them, except for the still image one as far as I can see)
[21:55:44 CEST] <nevcairiel> the way i read the spec, 8.5 is just meant to encode all sorts of still images, as digital cameras produce extremely large images tehse days, which means it only is really designed to exceed picture size limits
[21:56:10 CEST] <JEEBsv> well yeah, that's what I gathered
[21:56:21 CEST] <nevcairiel> my spec must be old, it d oesnt have that
[21:56:55 CEST] <JEEBsv> A.4.1 general tier and level limits
[21:57:37 CEST] <nevcairiel> my spec is 2014.10 .. probably old by now
[21:57:41 CEST] Action: nevcairiel looks for new one
[21:58:16 CEST] <JEEBsv> this is the same one as far as I can see
[21:58:23 CEST] <JEEBsv> H.265-201410
[21:58:54 CEST] <nevcairiel> there is a 2015.04 anyway!
[21:59:03 CEST] <JEEBsv> not yet published IIRC
[21:59:09 CEST] <JEEBsv> will be in a couple of months, IIRC
[21:59:15 CEST] <JEEBsv> unless you mean ISO/IEC side
[21:59:17 CEST] <nevcairiel> hm right, its not available to ordinary users on the website
[21:59:33 CEST] <JEEBsv> it's funny how ISO/IEC rev2 is ITU-T's rev3
[21:59:41 CEST] <JEEBsv> how the hell did they end up mismatching
[21:59:51 CEST] <nevcairiel> ITU calls it "in force (prepublished)" .. odd wording
[22:40:25 CEST] <cone-894> ffmpeg 03Steve Lhomme 07master:d8039ef8d221: D3D11va: add a Direct3D11 video decoder similar to DXVA2
[22:40:26 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:947b74ee7da7: Merge commit 'd8039ef8d221ea273aa4f1e62e5df21bf618c772'
[22:40:27 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:94d07b314aa5: avcodec/dxva2: Fix build without D3D11
[23:25:17 CEST] Action: rak[2] likes ffmpeg.. thanks to contributers :)
[23:32:50 CEST] <Timothy_Gu> BBB: Hmm good idea
[23:33:10 CEST] Action: Timothy_Gu wonders why he didn't think of that
[23:41:47 CEST] <cone-894> ffmpeg 03Carl Eugen Hoyos 07master:860ac0a5bbbf: lavf/riff: Add 0x729A as TwoCC for G.729.
[23:53:16 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:3232ac4bac05: configure: d3d11va is auto-detected like the others
[00:00:00 CEST] --- Tue May 26 2015