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

[burek]

[00:34:31 CET] <nevcairiel> peloverde: the mp4-style -> annexb converter (which plays a similar rule as the ADTS muxer in this scenario) has a lot of magic to try to detect if the stream already has in-band headers and then doesn't insert them, not sure if such complexity might be warranted for the ADTS muxer as well, or if that would even work properly
[01:26:27 CET] <wm4> BtbN: btw. what happened to moving our nvenc headers copy to a different repo?
[01:53:39 CET] <atomnuker> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary
[02:03:45 CET] <wm4> yes, but we still have the internal headers in our repo?
[02:09:03 CET] <atomnuker> yeah, seems like they're still in the main repo
[06:39:23 CET] <deanoman_> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmpeg.exe /U)
[09:39:06 CET] <av500> bonjour
[09:40:40 CET] <wm4> bontschurr
[09:42:34 CET] <av500> would anybody know why MPEG4 timestamps are now (well, recently) being output in order? as I recall, they used to be out of order previously
[09:43:04 CET] <nevcairiel> it depends on your source
[09:43:26 CET] <av500> avi
[09:47:48 CET] <nevcairiel> which timestamp field are you looking at? pkt_pts/pkt_dts shouldnt have changed, but if you use best_effort_timestamp (or what its called), it might try to be smart about that
[09:50:07 CET] <av500> looking at an mpeg4 ASP file with B frames
[09:50:15 CET] <av500> both pts and dts are in order
[09:50:24 CET] <av500> and I dont think they were in the past
[09:52:16 CET] <wm4> well avi has only frame numbers
[09:52:25 CET] <av500> hmm
[09:52:27 CET] <wm4> not even "real" DTS
[09:52:31 CET] <av500> yes
[09:52:36 CET] <av500> maybe me recollection was wrong
[09:52:43 CET] <nevcairiel> real DTS is a matter of interpretation anyway
[09:52:43 CET] <wm4> and from what I'm aware, lavf always exported them as in order DTS
[09:52:45 CET] <av500> thing is I was using my own parser in the past
[09:52:48 CET] <nevcairiel> whats real, the mpeg description?
[09:53:00 CET] <wm4> nevcairiel: well, ffmpeg shifts them by the codec delay
[09:53:00 CET] <av500> and recently switched to lavf for avi
[09:53:19 CET] <av500> so maybe its just me reordering reordered timestamps
[09:56:02 CET] <nevcairiel> in my experience mpeg4 in avi reading pkt_pts results in out of order timestamps, well, if you have a pts anyway, avidec probably doesnt even set it
[09:56:09 CET] <nevcairiel> assuming your mpeg4 stream has re-ordering
[09:56:20 CET] <cone-051> ffmpeg 03Jorge Ramirez-Ortiz 07master:9b1ec2483504: avcodec: v4l2_context: remove unnecessary code
[09:58:24 CET] <av500> nevcairiel: yes, I think it used to output out of order timestamps
[09:58:28 CET] <av500> but now I get in order ones
[10:02:17 CET] <wm4> looks like I just use the dts and offset it by the codec reported b frame delay
[10:02:27 CET] <wm4> that's kind of shitty though
[10:03:48 CET] <av500> maybe its just noise, as said I recently switch to lavf for avi, so maybe I never noticed that before
[10:08:09 CET] <JEEB> you should see if lavf can do actual timestamps for muxing into ISOBMFF by taking a raw H.264 or HEVC stream with b-frames etc, and looking at the end result
[10:08:13 CET] <JEEB> IIRC that still fails
[10:08:53 CET] <nevcairiel> it fails unless the h264 bitstream has the delay hints
[10:09:22 CET] <nevcairiel> but creating h264 timestamps out of thin air is also quite a bit of work otherwise
[10:15:21 CET] <JEEB> sure, it's not easy but muxers like L-SMASH do handle it so when it fails most users are rather disappointed
[10:16:27 CET] <nevcairiel> users need to get over expectations some day =p
[10:16:41 CET] <nevcairiel> more importantly, learn not to save such streams without timestamps
[10:57:43 CET] <BtbN> wm4, headers are in a different repo, I have a patch that uses them in ffmpeg, but it explodes horribly in msvc, and I haven't had a chance to fix that yet.
[19:50:56 CET] <jya> anyone familiar with the Windows Media Foundation audio decoder? (in particular AAC)
[19:52:05 CET] <BtbN> why would you ever want to deal with it, specially when ffmpeg is involved?
[19:54:02 CET] <nevcairiel> i dont actively use it anymore, but i have some basic experience with it
[19:54:49 CET] <wm4> I once wrote a ffmpeg wrapper for it
[19:55:19 CET] <nevcairiel> the feature support of the aac decoder is pretty low, so there really wasnt a point
[19:55:38 CET] <nevcairiel> although it can do one thing ffmpeg cant do, it can transform LATM/LAOS to ADTS
[19:55:59 CET] <nevcairiel> (although that was only a curiosity, not that i ever needed that)
[20:01:02 CET] <jya> BtbN: I don't have the luxury to use ffmpeg here unfortunately
[20:01:19 CET] <jya> was disappointed to see that ffmpeg didn't write a WMF backend I could copy :)
[20:01:28 CET] <jya> seeing you guys had done a CoreAudio one
[20:01:37 CET] <BtbN> That's what ffdshow is for?
[20:02:26 CET] <jya> I want to retrieve the channel layout without have to manually decode each element (which would be patent enfringing)
[20:03:45 CET] <nevcairiel> have it decode the extradata (in case of raw) or the first frame (in case of adts) and read MF_MT_AUDIO_CHANNEL_MASK ?
[20:04:03 CET] <jya> there's a MF_MT_AUDIO_CHANNEL_MASK attribute, but it seems to only be used for me to set the value
[20:04:06 CET] <jya> not retrieve
[20:04:16 CET] <jya> nevcairiel: that was my first attempt 
[20:04:36 CET] <jya> that attribute also isn't an IMFSample attribute
[20:05:20 CET] <nevcairiel> i dont think it even supports PCEs, so it probably only has one channel layout per channel count anyway
[20:05:49 CET] <jya> https://msdn.microsoft.com/en-us/library/windows/desktop/dd317906(v=vs.85).aspx "In an audio media type, specifies the assignment of audio channels to speaker positions. " so seems that it's for defining what we want on the output side
[20:05:52 CET] <jya> rather useless
[20:06:15 CET] <nevcairiel> you would call GetOutputCurrentType and then probe that for MF_MT_AUDIO_CHANNEL_MASK
[20:06:30 CET] <jya> hmm, got idea.. let me see
[20:06:40 CET] <jya> damn, my 3yo wants me to read his book... bbl
[20:07:38 CET] <nevcairiel> mft->GetOutputCurrentType(0, &mt); uint32_t mask = MFGetAttributeUNIT32(mt, MF_MT_AUDIO_CHANNEL_MASK, 0);
[20:07:40 CET] <nevcairiel> or such
[20:08:03 CET] <nevcairiel> minus typo in the function names
[20:08:41 CET] <wm4> I don't think the MF API makes it easy or even possible to retrieve the "native" channel layout in most cases, but I don't remember
[20:10:48 CET] <nevcairiel> i only use video decoders currently through MF,  and at least those properties can all be retrieved through the same API
[20:12:09 CET] <wm4> yeah, video was different
[20:19:20 CET] <jya> nevcairiel: what do you mean by MF? Media Foundation? 
[20:19:28 CET] <nevcairiel> of course
[20:19:31 CET] <jya> that's what we use, MFT (T for transform)
[20:19:35 CET] <nevcairiel> noone calls it WMF =p
[20:19:55 CET] <jya> oh I misread, video decoders
[20:19:55 CET] <jya> right
[20:20:09 CET] <jya> we also use it for AAC and MP3
[20:24:04 CET] <jya> nevcairiel: that worked
[20:24:25 CET] <jya> mDecoder->GetOutputMediaType(type); then query type
[20:26:13 CET] <nevcairiel> i dont recognize that particular function name though, its not one on IMFTransform
[20:26:28 CET] <nevcairiel> unless thats a wrapper of yours
[20:28:19 CET] <jya> nevcairiel: you're right, this is our wrapper around GetOutputCurrentType
[20:29:52 CET] <jya> it's a wrapper around our ref counted (similar to std::shared_ptr but mscom aware) pointers
[22:24:32 CET] <cone-031> ffmpeg 03Jacob Trimble 07master:9f07cf7c00f3: avutil/aes_ctr: Add method to set 16-byte IV.
[22:24:32 CET] <cone-031> ffmpeg 03Michael Niedermayer 07master:94d4237a7a29: avcodec/hevc_cabac: Move prefix check in coeff_abs_level_remaining_decode() down
[22:24:32 CET] <cone-031> ffmpeg 03Michael Niedermayer 07master:6e1a167c5564: avcodec/dxtory: Fix bits left checks
[22:53:00 CET] <SortaCore> what's the status of nvenc so far?
[22:53:16 CET] <nevcairiel> "working fine"?
[22:57:00 CET] <BtbN> nvenc is pretty feature complete right now I'd say
[23:03:02 CET] <SortaCore> d3d11 working?
[23:03:05 CET] <SortaCore> I saw talks about it
[23:05:21 CET] <wm4> I once tried to feed d3d11 to mediafoundation encoders - would have been nice if that had worked
[23:06:31 CET] <nevcairiel> setting up surface input to MF is a bit tricky
[23:07:57 CET] <nevcairiel> anyhow d3d11 input to nvenc works fine
[23:08:12 CET] <wm4> didn't get it to work, nor did I see anyone else getting it to work - though surface output with decoders worked fine
[23:08:38 CET] <nevcairiel> might depend on the specific MFT in question i guess
[23:08:45 CET] <nevcairiel> its probably not that strictly specified
[23:09:30 CET] <SortaCore> all my commandlines for nvenc encoding so far have 0% GPU usage
[23:09:51 CET] <SortaCore> is it like QSV, where it can use a software implementation instead of hardware?
[23:09:52 CET] <nevcairiel> its not supposed to have gpu usage, it uses separate hardware to do the work afterall
[23:09:56 CET] <BtbN> that's not surprising, given that nvenc does not use the gpu.
[23:10:16 CET] <nevcairiel> if you're on windows 10 fcu, the taskmanager can show the video engine usage
[23:10:31 CET] <SortaCore> I was watching with Process Explorer
[23:11:02 CET] <nevcairiel> process explorer can also differentiate between gpu (3d) usage and encode usage, although one needs to know how to do that
[23:11:49 CET] <SortaCore> task manager: Not Responding x100
[23:12:10 CET] <SortaCore> ah, I see it on task manager
[23:14:29 CET] <SortaCore> ...briefly drifted to 1%
[23:16:26 CET] <BtbN> nvenc does cause significant video engine load
[23:16:50 CET] <SortaCore> I'm not rousing anything out of it atm
[23:17:10 CET] <SortaCore> I get a tiny spike at the start then nothing
[23:19:39 CET] <SortaCore> can I have an idiot's full cmdline so I know I'm using it properly
[23:23:42 CET] <SortaCore> I've tried dxva2, d3d11va2 hwaccel inputs, and given it a strict lossless preset, 5.1 and high profile, nothing
[23:24:49 CET] <jkqxz> What are you even trying to do?  Get the GPU load to go up?
[23:25:04 CET] <SortaCore> well, atm yes
[23:25:05 CET] <jkqxz> Try doing something which uses the GPU, like CUDA or something.  NVENC doesn't use the GPU.
[23:25:24 CET] <SortaCore> I just want to know it's using hardware and not some fallback CPU thing
[23:25:32 CET] <jkqxz> It uses separate hardware on the same chip, which shares memory and some other stuff but not the GPU.
[23:25:48 CET] <jkqxz> NVENC doesn't have a software fallback as far as I know.
[23:26:02 CET] <SortaCore> yea, I was directed to Task Manager which is showing me graphs for video encode/decode, but they're all 0% with brief spikes of 1% at the start of the encoding only
[23:26:33 CET] <SortaCore> so I want to put it under some heavy load so I know it's being used properly
[23:27:28 CET] <sfan5> the nvidia-smi tool (linux) differs between Graphics and Compute, using nvenc via e.g. OBS shows a process using compute and raises gpu load 0% -> 26%
[23:27:44 CET] <sfan5> i wouldn't rely on the windows task manager showing you exactly what you want anyway
[23:28:47 CET] <BtbN> It shows video engine load, it works fine
[23:38:00 CET] <nevcairiel> the task manager since fcu shows pretty detailed and pretty accurate gpu loads of all sorts of various internal sections of the gpu
[23:39:52 CET] <nevcairiel> using a trivial ffmpeg -i file.mkv -c:v h264_nvenc test.mkv shows an average of ~40% encode usage with spikes to nearly 100% at the end of the file
[23:39:56 CET] <nevcairiel> doesnt get simpler then that
[23:41:35 CET] <BtbN> you can easily make it hit 100% with testsrc
[23:42:37 CET] <nevcairiel> i was going to test with d3d11 input now, that can probably do that as well
[23:42:57 CET] <nevcairiel> but i need to recompile since my build was actually quite old
[23:43:02 CET] <nevcairiel> so that takes a while on windows =p
[23:43:39 CET] <wm4> on another channel we just discussed how the rpi is a not so good device because it takes 25 mins to compile ffmpeg
[23:43:55 CET] <wm4> and then someone said it takes as much on a modern Intel CPU with windows
[23:43:57 CET] <BtbN> 25 min for compiling on a Pi seems very optimistic
[23:44:08 CET] <nevcairiel> yeah i dont think it finishes in that time
[23:44:12 CET] <wm4> I think a rpi3 can reach that
[23:45:00 CET] <atomnuker> that's not bad, my old laptop took that long
[23:45:08 CET] <jkqxz> On Windows you can't even configure in that time...
[23:45:45 CET] <atomnuker> takes 35 on my rpi3 iirc
[23:46:47 CET] <SortaCore> I think my input source was too wimpy
[23:47:33 CET] <SortaCore> 6fps at 704x480
[23:48:19 CET] <atomnuker> jkqxz: hey what happened to the mjpeg hwaccel?
[23:48:22 CET] <SortaCore> plus it was a stream, so the gpu had a lot of spare time between frames, instead of the muxer doing as many as possible
[23:48:43 CET] <nevcairiel> one of these days i should finish figuring out how to do a build through wsl to avoid this waiting
[23:48:52 CET] <wm4> I think Chloe did that
[23:49:00 CET] <nevcairiel> its not like its hard
[23:49:01 CET] <wm4> and it was indeed faster
[23:49:04 CET] <nevcairiel> i'm just lazy
[23:49:17 CET] <nevcairiel> and i have plenty stuff  to do while shit compiles in the background
[23:49:36 CET] <jkqxz> atomnuker:  I was hoping that YUVJ would FOAD.  But it hasn't, so I'll actually have to work out what to do with that stuff.  Maybe at some point.
[23:50:03 CET] <wm4> like sword fighting with coworkers?
[23:50:20 CET] <nevcairiel> i wish, i work from home =p
[23:50:32 CET] <atomnuker> maybe if we bother durandal_1707 a bit more he'll repost the patches with the fixes he already has
[23:51:48 CET] <jamrial> jkqxz: you could just ignore yuvj and only implement yuv + color_range
[23:52:10 CET] <jamrial> it's not like yuvj was going to be removed right away. deprecation periods and all that
[23:52:38 CET] <SortaCore> oddly on QSV, 40% GPU "3D" usage, 10% Video Decode usage, and no sign of a Encode usage...
[23:52:59 CET] <SortaCore> how would I know if my GPU supports encoding?
[23:53:06 CET] <jamrial> unless you mean that the yuvj stuff not being unfucked actually makes it harder
[23:53:27 CET] <wm4> does the utils.c code translate yuvj to normal pixfmt+color_range?
[23:56:27 CET] <nevcairiel> why would utils.c do that
[23:59:22 CET] <wm4> nevcairiel: why not... at least if the pixfmts array contains no J formats
[00:00:00 CET] --- Wed Jan 24 2018