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

[burek]

[00:01:56 CEST] <BtbN> BBB, I'm doing both now, with an #if to check for big endian
[00:02:03 CEST] <BtbN> so it uses the fast native variant on LE
[00:02:16 CEST] <BtbN> and the slow AV_WL one on BE
[00:02:57 CEST] <DHE> shouldn't you be able to just use an existing macro like htonl (wrong endianness here?) and not worry about it yourself?
[00:04:45 CEST] <BtbN> DHE, if I use the existing macro(which is exactly what AV_WL16 is), the resulting code is significantly slower.
[00:04:52 CEST] <BtbN> Like, it takes almost double the time for one pass
[00:05:27 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/484ef960da65f0d28c3bd0b84b8a62661311a7fa this has both versions
[00:14:31 CEST] <iive> BtbN: aren't AV_W* macro slower, because they allow unaligned access on strict alignment systems?
[00:15:01 CEST] <BtbN> No idea
[00:15:35 CEST] <BtbN> but it's so slow that it's no longer able to run in real time
[00:16:24 CEST] <BtbN> I'd be fine with just dropping the AV_WL16 variant and offering only the native one
[00:16:44 CEST] <BtbN> but it's impossible to make fate happy than, because the direct copy has slightly diffrent results than the indirect copy
[00:16:57 CEST] <BtbN> so if the fate hashes work on le systems, they will be broken on be ones, or vice versa.
[00:19:00 CEST] <cone-982> ffmpeg 03Timo Rothenpieler 07master:1c37be6e95ba: configure: check for dlsym as well
[00:19:01 CEST] <cone-982> ffmpeg 03Timo Rothenpieler 07master:39f75645c801: swscale: add unscaled copy from yuv420p10 to p010
[01:26:47 CEST] <rcombs> so a particular FATE test has me a bit confused
[01:26:49 CEST] <rcombs> looking at fate-suite/gapless/102400samples_qt-lc-aac.m4a
[01:27:31 CEST] <rcombs> the test runs "ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i fate-suite/gapless/102400samples_qt-lc-aac.m4a -flags +bitexact -fflags +bitexact -map 0:a -c:a aac -f ipod -y tests/data/fate/gaplessenc-itunes-to-ipod-aac.out-1"
[01:27:39 CEST] <rcombs> this is fate-gaplessenc-itunes-to-ipod-aac
[01:29:02 CEST] <rcombs> 1. 102400samples_qt-lc-aac.m4a does not appear to actually contain 102400 samples
[01:29:29 CEST] <rcombs> instead, 105472
[01:29:54 CEST] <rcombs> so 3 packets beyond what the filename indicates
[01:31:25 CEST] <rcombs> and then, when we reencode for the test, the last packet has a duration of 1984 in the MP4, but gets decoded to a frame with 1024 samples, and the 1984 value is weird to begin with since the original file has a multiple of 1024 (the normal frame size) samples anyway?
[01:58:36 CEST] <bofh__> rcombs: 2112 - 2048 = 64. 64 + 1984 = 2048.
[01:58:54 CEST] <rcombs> oh, so padding?
[01:58:56 CEST] <bofh__> 2112 being the preroll delay at the start that qtaac adds
[01:59:15 CEST] <rcombs> ahhh
[01:59:16 CEST] <bofh__> because apparently that's what the bulk of encoders had for a max delay, from a doc on apple's site
[01:59:48 CEST] <bofh__> I can only assume the reason it's not 2048 (min. delay is 2048: forward & inverse MDCTs each add a frame of delay) is to do window lookahead.
[02:01:02 CEST] <bofh__> either that or some encoder decided that it really needed to be absolutely able to encode the first two blocks ONLY_LONG | LONG_START
[02:03:41 CEST] <bofh__> anyway: you can get the delay out of the iTunSMPB mp4 metadata atom
[02:04:23 CEST] <bofh__> also if it's doing what you said it's doing and decoding a small final frame, that's incorrect. it's all initial delay, so what you need to do is drop the first two frames and then start outputing 64 sampes into the third.
[02:04:30 CEST] <bofh__> (this is relevant for A/V sync).
[02:04:53 CEST] <rcombs> so, the other weird thing is that there's inconsistency with the same encode between if it's muxed to ADTS or BMFF
[02:05:24 CEST] <rcombs> in BMFF I get that last 1984-sample frame out of the demuxer; in ADTS the parser lists it as 1024 (as usual)
[02:05:43 CEST] <rcombs> s/frame/packet/
[02:07:18 CEST] <rcombs> so in ADTS the parser agrees with the decoder, and in BMFF neither is applicable and we just get the value from the container
[02:14:50 CEST] <bofh__> ADTS lacks any facility for metadata, so presumably ffmpeg defaults to dropping no samples.
[02:15:25 CEST] <bofh__> (which is partly reasonable, it should always drop the first 2048 (or 4096 if SBR) IMO since it's safe to assume those will always be silence).
[06:46:20 CEST] <rcombs> what was that, AT&T<->Level3?
[09:56:25 CEST] <DSM_> hi everyone
[11:55:33 CEST] <durandal_1707> why is static SoftFloat_IEEE754 av_mul_sf_ieee754(SoftFloat_IEEE754 a, SoftFloat_IEEE754 b) static?
[13:29:38 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:cef5bc0e6e23: lavc/mjpegdec: Do not skip reading quantization tables.
[13:40:01 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:91842005fe79: lavf/img2dec: Skip DQT segment when auto-detecting jpg.
[13:58:45 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:8f0bd1d9bad5: lavf/httpauth: Do case-insensitive http header checks.
[14:19:46 CEST] <cone-578> ffmpeg 03Michael Niedermayer 07master:e57d99dd4e0d: swscale/swscale_unscaled: Try to fix Rgb16ToPlanarRgb16Wrapper() with slices
[14:19:47 CEST] <cone-578> ffmpeg 03Michael Niedermayer 07master:b4d7c1f84b02: swscale/swscale_unscaled: Try to fix bayer_to_yv12_wrapper() with slices
[14:24:01 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:e82b181f8096: lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.
[14:24:02 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:a6a453ccd1cd: Cosmetics: Reindent after e82b181f.
[14:32:19 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:2dfd0f4b9eed: lavf/webm_chunk: Print an error if no header filename was provided.
[15:19:18 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:3c821a1a7bf2: lavf/udp: Do not use MCAST_* for multicast on tvOS.
[15:42:44 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07release/3.0:17035c8d2eb3: lavc/mjpegdec: Do not skip reading quantization tables.
[15:42:46 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07release/3.1:677ea4a49b2e: lavc/mjpegdec: Do not skip reading quantization tables.
[16:50:29 CEST] <BtbN> hm, so do the lower 6 bits of P010 really not matter, or what is carl on about? The format seems to be defined as lower 6 bits zeroed.
[16:53:52 CEST] <nevcairiel> it should be zeroed, but in reality its probably irrelevant
[16:56:30 CEST] <peloverde> https://github.com/Netflix/vp9-dash/blob/master/DASH-Samples/Fountain_2997_0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv seems broken
[16:56:56 CEST] <peloverde> (in FFmpeg?)
[16:57:11 CEST] <JEEB> ugh
[16:57:15 CEST] <JEEB> wtf
[16:57:21 CEST] <JEEB> VP9 in MSS
[16:57:29 CEST] <JEEB> who do I slap for doing that q_q
[16:57:35 CEST] <JEEB> (is that even supported by MS)
[16:58:01 CEST] <peloverde> Netflix created the file
[16:58:07 CEST] <cone-578> ffmpeg 03James Almer 07master:4fed4aca0c20: avcodec/utils: print initial and trailing paddings only in verbose levels
[16:58:08 CEST] <cone-578> ffmpeg 03James Almer 07master:d2e74315e5be: avcodec/utils: print only the padding values that are set
[17:06:11 CEST] <JEEB> peloverde: also did FFmpeg support VP9 in ISOBMFF?
[17:06:39 CEST] <TD-Linux> JEEB, Edge currently only implements VP9 in WebM.
[17:07:10 CEST] <JEEB> TD-Linux: MS generally has killed MSS support in the sense that they only support old stuff
[17:07:18 CEST] <JEEB> they add new stuff to DASH/WebM only
[17:07:22 CEST] <JEEB> AFAIK
[17:07:37 CEST] <TD-Linux> JEEB, the file linked is just a fragmented mp4, btw
[17:07:54 CEST] <JEEB> yes, it's a slight fork of fragmented ISOBMFF
[17:08:08 CEST] <JEEB> it lacks proper fragmented mp4 timestamps and instead uses MSSspecfic boxes
[17:08:15 CEST] <JEEB> which is why it makes little JEEB cry at night
[17:08:24 CEST] <JEEB> (without looking at the file, but ismv is like that)
[17:13:51 CEST] <philipl> BtbN: adding 10bit support to cuvid? :-)
[17:14:15 CEST] <JEEB> cuvid will not likely get 10bit
[17:14:20 CEST] <JEEB> unfortunately
[17:14:24 CEST] <JEEB> DXVA2 is what uses P010
[17:14:40 CEST] <BtbN> cuvid does not support 10bit output... only NV12
[17:14:48 CEST] <philipl> Even the new version?
[17:14:52 CEST] <BtbN> "Just" 10bit input for nvenc
[17:14:52 CEST] <philipl> "nvdecode"
[17:14:58 CEST] <philipl> ah.
[17:15:00 CEST] <JEEB> yup
[17:15:05 CEST] <BtbN> I couldn't find anything named like that, it's still just cuvid.
[17:15:22 CEST] <BtbN> Would have been mildly upset with them if they renamed all the functions and structs.
[17:15:27 CEST] <philipl> Heh. indeed.
[17:15:45 CEST] <BtbN> Got a 1060 now, so I can finally test all that shit.
[17:16:22 CEST] <philipl> Fun. I'm still aspiring to adding playback support to mpv for it, given that vdpau progress is completely stalled.
[17:16:23 CEST] <BtbN> Turns out the YUV420 format nvenc wants is P010, for which there was no output support in swscale. So that's what I'v been doing the last few days.
[17:16:44 CEST] <philipl> I'm amazed we got this far without it
[17:16:50 CEST] <BtbN> CUDA playback should be dead simple with GL output.
[17:17:28 CEST] <philipl> In theory, but wiring everything up in the right place isn't trivial. I think getting the cuda stuff where it needs to be breaks some assumptions on how hw accel is done in mpv
[17:17:47 CEST] <JEEB> philipl: IIRC there really isn't much time given for VDPAU development decoding-wise
[17:18:08 CEST] <BtbN> map cuda buffers to texture, apply YUV->RGB shader(you can steal that from kodi or OBS), and you're good.
[17:18:09 CEST] <JEEB> so I'd be surprised if the 10bit stuff gets done soon'ish
[17:18:35 CEST] <philipl> JEEB: Indeed, I'd be very surprised too. The guy who was working on it left (to work at my company, although I had nothing to do with it)
[17:19:18 CEST] <philipl> BtbN: mpv already has the shader - they added a GL playback path for vdpau that bypasses the mixer.
[17:21:20 CEST] <philipl> BtbN: I don't need the cuda 8 rc to get full use out of cuvid, right?
[17:21:49 CEST] <BtbN> I never used or even looked at that. So if anything new is in there, it's not implemented yet.
[17:22:03 CEST] <BtbN> I did look at the one in the v7 NVENC SDK though. And it's the same.
[17:22:27 CEST] <philipl> cool
[17:22:50 CEST] <BtbN> It even has VP9 decoding support, which vdpau is also still lacking?
[17:22:56 CEST] <philipl> yep. still lacking.
[17:29:42 CEST] <peloverde> JEEB are they even allowed to use compatible_brand dash MSS boxes instead of fragmented mp4 timestamps?
[17:30:29 CEST] <JEEB> I would be surprised methinks? so if they're using the dash compatible_branch then lulz
[17:30:53 CEST] <RiCON> last time i checked, nvenc just needs the nvencodeapi.h header, but cuda/cuvid/npp need cuda sdk installed to compile and run
[17:33:00 CEST] <philipl> annoyingly, the ubuntu packages for cuda 7.5 don't include libnvcuvid. sigh.
[18:12:16 CEST] <jamrial> ubitux: if you're converting ffmpeg to codecpar http://pastebin.com/YKcEFcQ4 may help you
[18:12:19 CEST] <jamrial> it combines all five relevant commits that were noop'd during merges
[18:18:50 CEST] <philipl> BtbN: Ok, I'm an idiot, clearly. I can't find libnvcuvid anywhere. I downloaded the full cuda 7.5 installer. Not there. Not in the video sdk either.
[18:19:48 CEST] <BtbN> it's part of the nvidia driver i think
[18:19:58 CEST] <philipl> Yes, I just remembered. *sigh*
[19:29:10 CEST] <philipl> BtbN: So, if I force the cuvid decoder in mpv, it will use the nv12 path and sort of works. Complains of lack of video pts but I see frames on screen
[19:29:59 CEST] <philipl> Burns 25% of a core doing frame copies for 4K content but I can confirm the decoder is in use.
[19:39:33 CEST] <BtbN> it should output propper timestamps though
[19:40:16 CEST] <philipl> That is what the code says.
[19:40:40 CEST] <philipl> Oh, and there is a small header difference in cuviddec.h from the 7.0 sdk, it has a field for specifying bit depth - I assume that's how you feed it main10/12 content.
[19:42:05 CEST] <philipl> Hmm. Some files are working.
[19:43:21 CEST] <philipl> Ok, that might just be desync on 4k content due to bottlenecking on copies
[20:00:42 CEST] <roxlu> Hey, I'm looking into avcodec to encode some PCM audio into AAC. I receive audio from the microphone (buffers with 1024 samples). When I want to feed them into the encoder I have to fill a AVFrame. I was wondering: can I simple set the nb_samples, format, channel_layout etc.. everytime I receive an audio buffer? 
[20:33:16 CEST] <BtbN> roxlu, wrong channel. But can't you just use lavdevice, and get a frame from there, and then just pass it to lavcodec?
[21:24:33 CEST] <philipl> BtbN: the missing pts seems to be a vp9 thing
[21:24:44 CEST] <philipl> and i got desync on 4k hevc content while h.264 was fine
[21:41:39 CEST] <philipl> BtbN: and setting the bit depth field correctly makes decoding hevc main10 work.
[00:00:00 CEST] --- Sun Sep  4 2016