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

Mon Dec 4 03:05:02 EET 2017

[00:04:51 CET] <[-T-]> pp
[03:03:42 CET] <jlozadad> hello, anyone knows if they are any other rpms that are needed installed to build from source? i'm getting "libmfx not found using pkg-config" I'm on fedora 27
[03:04:06 CET] <jlozadad> I have libmfx and libmfx-devel installed
[03:04:27 CET] <JEEB> see ffbuild/config.log for details
[03:05:31 CET] <tdr> jlozadad, the -dev package for that so it has the headers, it could be a version issue too
[03:07:32 CET] <jlozadad> so i'm trying to ffmpeg-3.3.5-2 from fedora 27. I was following a guide and it made me get the source rpm for that unpack it and work from there. Is that the right approach? sorry new to this and trying to learn
[03:08:14 CET] <tdr> sure if you use the srpm it should give you a spec file that does the rpm building
[03:08:57 CET] <jlozadad> ok i'll look at it
[03:08:59 CET] <jlozadad> thanks
[03:09:01 CET] <tdr> but it probably will not satisfy all the deps so you'll need to pay attention to what it cannot find (or what is/is not enabled) when its running autoconfigure (./configure part)
[03:10:08 CET] <jlozadad> ok, I will verify it ty! appreciate the help
[03:10:11 CET] <tdr> many times "not found" is just the dev package not found, but you said you had it for that one
[03:10:41 CET] <tdr> jlozadad, are you using rpm to build it or doing it manually?
[03:11:17 CET] <tdr> jlozadad, be aware if its trying to build it multilib you'll need the .686 packages too if they exist for the deps
[03:12:24 CET] <jlozadad> yes, trying to run ./configure then make make install
[03:12:58 CET] <tdr> you should prob just use rpm on an rpm based distro
[03:13:31 CET] <jlozadad> alright :) I guess also a good learning exp :) ty for the help
[03:15:29 CET] <tdr> only because rpm based distros dont always put headers etc in the usual places or do things "normal"
[03:16:17 CET] <furq> do you actually need libmfx on linux
[03:16:28 CET] <furq> i'm pretty sure vaapi is the recommended way to use qsv now
[03:17:58 CET] <jlozadad> was trying to follow this guide but, its mostly in ubuntu and i'm trying to translate it to fedora wise https://www.gamingonlinux.com/articles/using-nvidias-nvenc-with-obs-studio-makes-linux-game-recording-really-great.8417
[03:18:48 CET] <furq> you definitely don't need mfx for nvenc
[03:19:20 CET] <furq> you also don't really need fdk any more
[03:19:24 CET] <furq> the builtin aac encoder is fine now
[03:20:48 CET] <furq> if the fedora packaged version is recent then nvenc and aac should just work out of the box
[03:20:51 CET] <furq> the nvenc stuff is builtin now
[03:22:01 CET] <jlozadad> so I don't need to build it like its mentioning in the guide?
[03:22:44 CET] <furq> probably not
[05:18:29 CET] <hiihiii> hello. I'm trying to encode an input with two audio channels, have each channel normalized differently, then resample to mono
[05:19:43 CET] <hiihiii> currently I'm just doing -i input -c:a aac -af "loudnorm,aformat=channel_layouts=mono" output
[05:22:40 CET] <hiihiii> I know I could just split audio, normalize the two separately, then join them again
[05:23:10 CET] <hiihiii> but I'm more interested to know how to access the channel streams
[05:41:01 CET] <hiihiii> ah 0:a:0 and 0:a:1
[07:38:12 CET] <mistym> When writing a muxer for libavformat, is there a way in AVOutputFormat to indicate that more than one `audio_codec` is possible?
[07:56:19 CET] <traw> There can be any problem if av_register_all is called twice?
[07:59:43 CET] <atomnuker> nope
[07:59:55 CET] <atomnuker> not even if they're called from different threads at the same time
[08:00:52 CET] <traw> ok
[08:04:14 CET] <traw> I'm using webrtc-native with ffmpeg support, which have implementation for h264 decoder, decoder internally calls av_register_all, but in that case av_guess_format fails to find any format
[12:40:02 CET] <durandal_1707> mistym: no, you need to add default codec, for all rest you need manually check if it is supported
[12:40:50 CET] <mistym> durandal_1707: OK, thanks!
[14:23:14 CET] <zyme> Good Morning ppl (depending on where you are). Any one awake yet/or/still?
[14:24:29 CET] <sfan5> the probability of all 407 other people in this channel being asleep right now is quite small
[14:27:58 CET] <zyme> I would hope but I've seem plenty bigger channels go on for days+ without a word.
[14:28:13 CET] <TheRock> o
[14:28:15 CET] <TheRock> im here
[14:28:23 CET] <TheRock> but i am gonna watch a porn now
[14:28:24 CET] <TheRock> afk
[14:29:28 CET] <zyme> Sorta like a digital crack house, lol - eveyones passed out for days on end in an intentail coma/paralized like state. anyways...
[14:33:40 CET] <zyme> I was wondering two things if they have an answer, the first is when encoding/transcoding into h264 (and probably some others) theres usually a handful of options for amount of CPU usage, the desctiption stating that higher settings are both higher quality and smaller in size at the say time (so I assume its when using a lossy type method) -
[14:34:19 CET] <TheRock> im uout the question is too difficult
[14:34:44 CET] <zyme> Im only half done typing it =P
[14:35:56 CET] <zyme> assuming with ffmpeg your not specifying a bitrate, why isn't it possible to set highest possible cpu usage towards quality with lowest possible cpu usage for compression?
[14:37:43 CET] <zyme> I want it done as fast as possible and space wasted doesn't matter I just want it to be high quality - as close to lossless as lossy mode can get under the maximum bitrate for L4.1
[14:38:11 CET] <sfan5> -b:v <what ever is max for L4.> -preset ultrafast
[14:38:14 CET] <jkqxz> Just set it to the maximum bitrate for level 4.1.
[14:38:23 CET] <JEEB> uhh
[14:38:31 CET] <zyme> (which is something like 52mbit/s I think? or maybe something slightly higher?)
[14:38:39 CET] <jkqxz> If the input is simple enough that it encodes losslessly with less than that then it will.
[14:39:02 CET] <zyme> thats fine too
[14:39:03 CET] <pafurijaz> Hi, I can't compile anymore ffmpeg. The first error was this "libopencore_amrnb is version3 and --enable-version3 is not specified. " and I solved it. now, however, it gives me this error. "ERROR: libmp3lame >= 3.98.3 not found"
[14:39:40 CET] <zyme> in that case I want my cpu to idle a bit if anything, lol
[14:39:42 CET] <JEEB> generally people don't need their streams to follow all the limitations of level 4.1 (the maxrate/bufsize)
[14:39:47 CET] <JEEB> and also
[14:39:50 CET] <JEEB> there's a misconception
[14:39:57 CET] <JEEB> there's two levers
[14:40:01 CET] <zyme> which is?
[14:40:11 CET] <JEEB> one controls the rate control, and then there's one that sets how much time x264 utilizes for compression
[14:40:37 CET] <JEEB> rate control is either CRF (default is CRF=23) or bit rate, and presets are presets
[14:41:49 CET] <JEEB> so if you want to utilize the minimum amount of time for encoding, you set the preset to the fastest value that is fast enough for you, and then you set CRF to some low value. for level 4.1 you can set "-level 4.1" or "-level 41"
[14:42:37 CET] <sfan5> yeah that also works
[14:42:56 CET] <sfan5> there's more restrictions than just bitrate for the different levels anyway
[14:43:41 CET] <zyme> so is there some preset I need to change? because I keep trying to transcode and, not caring if the new format should be able to make the same image smaller losslessly - I don't mind it being several times the size in output but speed is an issue because its being done with segmented outputs that are played in a refreshing playlist of sorts for streaming purposes.
[14:43:42 CET] <JEEB> the bit rate is anyways something that most decoders don't care too much about, and you don't limit it with the -b:v bit rate general param
[14:43:48 CET] <jkqxz> Does level do anything in CRF mode?  I thought it just set level_idc and didn't really care otherwise.
[14:44:07 CET] <JEEB> jkqxz: it does nowadays limit refs in libavcodec/libx264.c
[14:44:20 CET] <JEEB> which is the important thing in levels (memory usage)
[14:47:25 CET] <zyme> I feel like I should use an older codec would suit my needs better but the hardware decoder I have while handeling most h.264 L4.1 and lower - well I've found that undocumentedly it will play h.263 in from DIVX encoder (as long as its mkv or mp4) but not XVID or most other h.263's...
[14:48:34 CET] <zyme> I actually have a registered copy of Divx but it doesn;t exactly have a ffmpeg cli equivalent I;m aware of,
[14:49:17 CET] <zyme> is it possible to encode to divx's h.263 with ffmpeg using any special compile options for ffmpeg?
[14:50:11 CET] <sfan5> doesn't xvid work too if you just set a different fourcc?
[14:50:12 CET] <zyme> (since I noticed its not in the list of encoding options avalible in the precompiled downloads linked from the ffmpeg site)
[14:50:26 CET] <sfan5> (https://trac.ffmpeg.org/wiki/Encode/MPEG-4)
[14:50:28 CET] <furq> yeah xvid and divx should both produce compatible bitstreams
[14:50:32 CET] <furq> so it's probably a fourcc thing
[14:50:44 CET] <zyme> whats fourcc?
[14:51:41 CET] <furq> https://www.fourcc.org/fourcc.php
[14:51:47 CET] <sfan5> but i don't see a good reason for restricting yourself to 263 if your hw can do 264
[14:51:56 CET] <furq> yeah
[14:52:10 CET] <furq> i wouldn't be surprised if h264 superfast was faster and better quality
[14:52:13 CET] <furq> er, x264
[14:52:40 CET] <zyme> (keeping in mind this is a hardware decoder that works with divx h.263 even though it's not supposed to - it just supports h.264..)
[14:55:12 CET] <zyme> furq: you were right the first time, x264 is by no means near the only h.264 compliant encoder/decoder.
[14:55:42 CET] <zyme> oh, it might be the bases for "superfast" though
[14:56:20 CET] <JEEB> zyme: x264 is generally more optimized than libxvid and the internal mpeg4 encoder I bet
[14:56:31 CET] <JEEB> and dealing with H.264 HW decoders is much simpler than MPEG-4 Part 2
[14:56:32 CET] <JEEB> trust me
[14:57:11 CET] <JEEB> so -c:v libx264 -preset veryfast|superfast -crf 15 -level (4.1|41)
[14:57:24 CET] <JEEB> I don't remember which format if not both were accepted
[14:57:27 CET] <JEEB> for level
[14:57:36 CET] <furq> 41
[15:01:55 CET] <zyme> 4cc is just an identification code? then if two codecs are compatible/compliant then shouldn't you be able to forge (Lie) about what the 4cc is?
[15:02:40 CET] <JEEB> but many plastic boxes only support one or two for a specific format
[15:02:45 CET] <zyme> If I got that wrong blame the very vague discription on that 4cc url lol.
[15:02:49 CET] <DHE> that has happened. MPEG4 (part-2) has several different 4cc that are mostly compatible
[15:03:01 CET] <JEEB> yea
[15:03:01 CET] <DHE> but only "mostly". there are minor differences that have caused problems
[15:03:07 CET] <JEEB> huh
[15:03:13 CET] <JEEB> aren't they all mpeg-4 part 2 :P
[15:03:23 CET] <DHE> wasn't there some xvid compatibility issues at one point? I could have sworn there was
[15:03:33 CET] <JEEB> maybe there were but man that was ages ago
[15:03:41 CET] <JEEB> but generally the issue was the fact that many IDs were made up
[15:03:49 CET] <JEEB> instead of keeping for a single thing for a format
[15:04:08 CET] <JEEB> also AVI was time when each *implementation* used its own four-char identifier
[15:04:13 CET] <JEEB> instead of each *format*
[15:04:18 CET] <DHE> divx, xvid, fmp4
[15:04:27 CET] <JEEB> so each time a new encoder came onto the scene the clients would have to be updated
[15:04:38 CET] <JEEB> whic of course is just wee-wee talk with plastic boxes
[15:05:02 CET] <JEEB> although with mpeg-4 part 2 I think that was your smallest problem because the HW decoders didn't genearlly support the default enabled feature set or something
[15:05:04 CET] <DHE> or people would fake the ids
[15:05:18 CET] <JEEB> and there were no clearly defined compatibility limits
[15:05:21 CET] <JEEB> in the HW decoders
[15:07:01 CET] <JEEB> while with H.264 the major containers got properly specified identifiers
[15:07:26 CET] <zyme> theres already a bunch of "compatible" codecs that are encoded without corruption and are suppedly compliant but always freeze in the same place on my decoder if I don't use software that detects it's error-state and attempts to continue on past that point automaticly at the first working point (other players I just restart, then skip to 30sec/1min after the freeze point manually) - I try to use a different encoding or
[15:07:27 CET] <zyme> transcode what I have for my saved files collection to avoid it in the future but still....
[15:08:10 CET] <JEEB> zyme: ouch... and you have no idea where your decoder has a glitch in the H.264 side of things?
[15:08:14 CET] <JEEB> or is that MPEG-4 Part 2?
[15:12:21 CET] <zyme> It doesn't exactly give much if any error feedback to me, but it was dirt cheap and for a long while I used a server program that did a very simple transcode h264 -> h264 AVC with a couple specified output settings Just-In-Case, and it used less cpu power to stream then to play on a computer
[15:13:08 CET] <JEEB> well, yea. I didn't expect it to tell you :)
[15:13:23 CET] <JEEB> zyme: but all of those are within some profile/level?
[15:14:53 CET] <zyme> it's a tad bit dependent on checking in with the dev's server  when it loads and verifying file hash's + latest version / approved usable version - and the latest updates don't work nearly as efficiently (it wants to use much more cpu power on its encode settings then it use to).
[15:16:05 CET] <JEEB> uhh, I wasn't talking about the encoder, just the decoder since you started off wanting to encode with libx264 here (and thus feed your plastic box the stream) :)
[15:16:58 CET] <zyme> so if I don't notice the quality is less then I like I used that program most the time, if I want to squeeze a little more quality then I play native decoding, if I know from experience the file works with it - or I want to chance it.
[15:20:46 CET] <zyme> I slid off subject a bit to explain how I live with such unreliable hardware decoder: a server that does very minor transcoding with nearly impossible to detect degradation from once codec to the same one at a tiny cpu req (say 10% of one of my cores).
[15:24:21 CET] <zyme> I should just fix my broken ipad mini and use an hdmi adapter, since its already my remote - but the adapter itself is tons more money then my little plastic unreliable plastic box lol.
[15:29:35 CET] <zyme> iPad  Story: I dunno if it's fixable though, It got a little water damage  a few years ago and recently it started saying my battery was dead whenever the temperature drops below a certain amount. as long as its running and doing something thats usally enough, but if I take it anywhere then sometimes it isn't - so for now the ipad sits next to the cpu fan exhaust on my laptop, and if it ever does the fake dead battery
[15:29:36 CET] <zyme> error message thing I hold it in front of the space heater for a couple minutes and it starts right up and reads full battery charge at 85% of its original max capacity. one of these I'll chance taking the screen off and examining it.
[15:30:22 CET] <Kam_> Hi, I'm trying to cross-compile (GCC-MinGW64 FreeBSD to Win64) FFmpeg with a very recent git-version and it fails when linking avformat-58.dll with: libavformat/hlsenc.o:hlsenc.c:(.text+0x384): undefined reference to `ff_http_do_new_request'.  It works with an older git-version from about begging of November.
[15:33:41 CET] <Kadigan> Hey... swscaler is having an issue with me - I'm trying to crop and rescale video, but the video has black/inaccurate boundaries, so I need to cut off a few pixels here and there (4 from the left, 5 from the bottom). I made it 4 and 6, to be 2-divisible... do I need to make the resultant crop 16-divisible? It's barking that "data is not aligned! This can lead to a speedloss" (the vf I'm using is crop=476:354:4:0,scale=640:360,setdar=16:9")
[15:34:19 CET] <Kadigan> (yes, I'm trying to fix an improperly compressed video, where a HD source was compressed to 4x3 and resulted in a 'squeezed' picture)
[15:36:01 CET] <Kadigan> The closest crop that satisfies /2 and /16 would be 448x336, and I obviously don't want to cut off so much.
[15:38:38 CET] <furq> i've always just ignored that message
[15:38:59 CET] <Kadigan> It's weird... as soon as I set crop's X to 0, ie. crop=476:354:0:0
[15:39:02 CET] <Kadigan> it stops complaining.
[15:39:07 CET] <Kadigan> As soon as it's non-zero, it complains.
[15:39:32 CET] <furq> the speed loss won't be measurable compared to encoding anyway
[15:39:48 CET] <furq> but iirc crop,copy,scale will silence that warning if x isn't mod16
[15:39:57 CET] <furq> will it make it faster? who knows
[15:40:11 CET] <Kadigan> Oh. I did some googling and came to the conclusion that "speedloss" it claimed would be an A/V desync.
[15:40:15 CET] <Kadigan> Not an encoding speed loss.
[15:40:18 CET] <furq> i only know that because zscale will straight up segfault if x isn't mod 16
[15:41:05 CET] <furq> also that doesn't seem likely but i'm not an swscale developer so listen to someone more qualified if they show up
[15:41:08 CET] <Kadigan> The notification is confusing, then. If it said "This can lead to encoding speed loss." from the beginning, I wouldn't have bothered.
[15:41:56 CET] <Kadigan> But, as we both know, there's a number of solid ways to screw up the a/v sync... and I didn't want to be on the receiving end of my own ignorance ._.
[15:42:49 CET] <furq> i'm pretty sure it's telling you that it can't use SSE2
[15:42:55 CET] <furq> which would mean an encoding speed loss, not a sync problem
[15:43:19 CET] <Kadigan> Since it was SD, it was going at a healthy 300fps even then, so I guess I didn't mind.
[16:02:36 CET] <Mandevil\splat> Hello... I am using -r option to convert variable framerate video to constant framerate... but nothing is really happening. This is the command line> ffmpeg -i PICT0001.AVI -an -c:v mjpeg -r 50 temp.avi
[16:03:10 CET] <Mandevil\splat> Isn't -r supposed to drop/duplicate frames to hit the target fps?
[16:04:13 CET] <Kadigan> Mandevil\splat: last time I checked, the only way to reliably convert VFR to CFR is to decompress to an interim uncompressed, and then recompress w/ constant frame rate.
[16:04:56 CET] <Kadigan> (had the same issue w/ "Bleach", an action anime that has the talking parts in 15fps, or so)
[16:05:15 CET] <Mandevil\splat> Not sure why decompressing achieves anything.
[16:06:11 CET] <Kadigan> If I recall, it was so that it decodes the video at a constant rate, producing frames as required. Not sure why it can't be done in one step, I don't recall.
[16:06:33 CET] <Mandevil\splat> Hm.
[16:06:45 CET] <Kadigan> Maybe you can pipe the output of one into another, I never tried that.
[16:06:54 CET] <Mandevil\splat> What should I use as codec to get uncompressed video?
[16:07:15 CET] <Kadigan> If memory serves, -f rawvideo (be prepared to handle several GBs of data)
[16:07:54 CET] <Mandevil\splat> I'm sure rawvideo doesn't contain any signalling info...
[16:08:49 CET] <Kadigan> All I remember (vaguely) is that if you try to do it in one step, you'll end up with a host of problems (stretching/compressing video speed, desync, wrong timestamps etc.)
[16:10:02 CET] <sfan5> tried -vf fps=50 ?
[16:11:02 CET] <Mandevil\splat> Let me try.
[16:11:11 CET] <furq> -r is an alias for -vf fps
[16:11:32 CET] <sfan5> makes sense, wasn't sure about that
[16:11:36 CET] <Mandevil\splat> Oddly enough, -vf fps=NN actually works!
[16:11:45 CET] <furq> fun
[16:12:14 CET] <Mandevil\splat> Yes, it does the right job (duplicating frames in my case)
[16:12:32 CET] <Kadigan> Hm... Though using videofilters will slow the processing down, I assume.
[16:12:42 CET] <Mandevil\splat> My source is rather tiny.
[16:12:48 CET] <Mandevil\splat> It's SD DVR recording.
[16:12:53 CET] <Kadigan> I guess it's still faster than decoding and encoding.
[16:12:54 CET] <Mandevil\splat> Just the DVR is really really crummy.
[16:13:29 CET] <Kadigan> I have some 2TB of source material to fix VFR in. I never really ended bothering, since I can't be sure it'll work always, and I don't have the time to watch every single output before committing to storage. And I don't have 2TB around to keep both versions until I do.
[16:14:49 CET] <Mandevil\splat> Why does anyone use VFR anyway?
[16:14:53 CET] <Kadigan> (and yes, I do have a proper reason - using something called SVP, which tweens frames up to screen speed w/ smooth motion - it expects a smooth stream, changing framerates discards the buffer which results in a 2-3s delay in playback, and it's annoying if it happens every few seconds)
[16:15:05 CET] <Mandevil\splat> If there's nothing changing in the image, the codes will squash it anyway.
[16:15:12 CET] <Mandevil\splat> codec
[16:15:28 CET] <Kadigan> Assuming it will.
[16:15:34 CET] <sfan5> not necessarily
[16:16:05 CET] <Kadigan> It may also not be strictly required. If the source material is VFR, and the encoding <can> do VFR, and the player also <can> play VFR, why go to the trouble of making it CFR?
[16:16:16 CET] <sfan5> (keyframes, ref limits)
[16:16:37 CET] <Kadigan> In most cases it's not an issue, and professional editors will deal with it anyway.
[16:16:47 CET] <Kadigan> Or should, in theory.
[16:17:05 CET] <Kadigan> So you only see issues when you're doing stream processing that expects a smooth stream, like in my case. Or in yours, I don't know.
[16:17:48 CET] <Kadigan> In my case it works perfectly well, only there's a delay because the expectation is for it to be real-time - an assumption that isn't necessarily true in playback.
[16:18:24 CET] <Mandevil\splat> Kadigan: The problem is that my source _claims_ it is 25 fps, but in reality it varies around 17-16 fps.
[16:18:36 CET] <Mandevil\splat> Kadigan: And that causes desync in editor.
[16:18:36 CET] <Kadigan> If I recall, FPS is ever only estimated.
[16:19:09 CET] <Kadigan> (in fact, if SVP could be "fixed" to account for VFR by some look-ahead that'd preallocate the buffers as required for a smooth transition, I wouldn't <need> to recode my VFR sources)
[17:38:31 CET] <Tatsh> really like these filters my GPU can do
[17:38:32 CET] <Tatsh> --vf=vdpaupp:denoise=1:hqscaling=1:deint=yes:deint-mode=first-field:denoise=1:pullup
[17:38:39 CET] <Tatsh> this is for mpv; how can i pass these into ffmpeg?
[17:41:11 CET] <BtbN> I don't know of any vdpaupp in ffmpeg.
[17:45:26 CET] <furq> isn't that an mpv thing
[18:12:41 CET] <neverminder> Hi, I'm trying to record both video and audio simultaneously, but it doesn't work
[18:13:19 CET] <neverminder> This is the closest I've got so far that doesn't throw any errors: ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default video.mp4
[18:14:30 CET] <neverminder> output gets stuck on frame 1 and produces 0 bytes file: https://pastebin.com/uW7jL7EB
[18:17:37 CET] <TAFB> can anyone help me get my ip 4k30 camera working smooth plz? https://www.youtube.com/c/Skyviewelectronics/live and the puter specs http://tafb.xxx/4k_stream_puter.png and the ffmpeg command https://pastebin.com/GdNL7tcw
[18:17:59 CET] <TAFB> camera is perfectly smooth if I play it in vlc or internet explorer :(
[18:20:24 CET] <JEEB> 1) the ID is shown in the screenshot 2) just for reference you can stop using 44.1kHz and LAME for audio (-c:a aac -b:a 128k should be enough with any recent FFmpeg) 3) try writing into a file first
[18:20:38 CET] <JEEB> also you only set bufsize but not maxrate?
[18:21:03 CET] <JEEB> into a file like test.flv instead of rtmp://...
[18:21:09 CET] <JEEB> then try playing that FLV file
[18:21:26 CET] <JEEB> it really sounds though that you are not getting nice timestamps from the input
[18:21:31 CET] <JEEB> and decoding that input fixes that
[18:21:40 CET] <JEEB> (because teh decoder handles all the re-ordering etc)
[18:21:41 CET] <TAFB> JEEB, the stream has no audio, but if I try and live stream it without audio it stops after a few seconds
[18:21:54 CET] <JEEB> no, I mean you don't need to specify 44.1kHz and MP3
[18:22:03 CET] <JEEB> if you use AAC you can use any audio rate
[18:22:08 CET] <JEEB> that's in the FLV specs :P
[18:22:25 CET] <JEEB> the FLV specs say that for AAC any player should just trust the AAC headers
[18:22:45 CET] <JEEB> and that 44.1kHz should be written as a placeholder. this was implemented in FFmpeg in like 2011 or 2012 or so
[18:23:05 CET] <JEEB> but yea, your real problem might be with -c:v copy not getting proper timestamps with rtsp
[18:23:18 CET] <JEEB> which then passing those packets into a decoder (like playback) fixes
[18:23:31 CET] <TAFB> no doubt timestamps are a mess
[18:23:32 CET] <JEEB> I've had issues with that with both raw H.264 input as well as MPEG-TS
[18:23:42 CET] <TAFB> how can I make FFMPEG do a big bugger and spit out the frames at a perfect 30fps?
[18:23:49 CET] <TAFB> big buffer
[18:23:57 CET] <JEEB> uhh
[18:24:02 CET] <JEEB> you're thinking of a different thing
[18:24:10 CET] <TAFB> mjpeg?
[18:24:14 CET] <TAFB> f'ing loved mjpeg :(
[18:24:43 CET] <furq> for starters, you probably want to get rid of -re
[18:24:54 CET] <JEEB> and that too. it's a hack for non-realtime inputs
[18:25:08 CET] <JEEB> for an rtsp stream not really required
[18:25:10 CET] <TAFB> if I get rid of -re then youtube stops live streaming after a second or two (I assume from the huge flood of frames it gets at the start)
[18:25:13 CET] <JEEB> unless you hit a bug with EOF
[18:25:25 CET] <JEEB> uhh, your input is realtime so how would that heppen?
[18:25:35 CET] <JEEB> although borked timestamps from the rtsp input can do a lot of stuff :P
[18:25:55 CET] <JEEB> TAFB: please output some of that stuff into a file first to see how fucked up the thing is
[18:25:57 CET] <TAFB> always when I start ffmpeg without -re it always starts around 120fps and trickles down to 30fps
[18:26:07 CET] <furq> i take it you can't just force the input framerate with rtsp
[18:26:20 CET] <TAFB> JEEB: okies, will do, without -re, just raw, and post up a file, 1 sec.
[18:26:29 CET] <TAFB> mp4 or flv?
[18:26:32 CET] <JEEB> flv
[18:26:37 CET] <JEEB> since that's what RTMP contains
[18:27:01 CET] <SortaCore> Is there a way to use Unicode paths in file outputs?
[18:27:02 CET] <JEEB> TAFB: the "high" frame rate at first is just how it looks basically since ffmpeg.c buffers the input for a while so it can probe its contents
[18:27:12 CET] <TAFB> I have to use "-rtsp_transport tcp" otherwise it's a complete mess, 1 sec.
[18:27:26 CET] <JEEB> that is due to your internal network most likely
[18:27:36 CET] <JEEB> the default is UDP
[18:27:49 CET] <JEEB> and UDP RTSP/multicast is often hated by routers :P
[18:29:13 CET] <TAFB> 60 seconds of video good?
[18:29:32 CET] <JEEB> should be a plenty. also you should check how that plays yourself first
[18:29:42 CET] <TAFB> will do
[18:29:45 CET] <JEEB> also I recommend utilizing -v verbose -debug_ts with ffmpeg
[18:29:47 CET] <JEEB> for additional information
[18:30:13 CET] <JEEB> if you're on windows you can also write stderr into a file with 2> stderr.log or so
[18:33:06 CET] <neverminder> Can ffmpeg record video and audio simultaneously or only one at the time?
[18:33:17 CET] <TAFB> neverminder: it for sure can
[18:33:24 CET] <JEEB> it can have N inputs but synchronizing them can be "fun"
[18:33:44 CET] <JEEB> unless the inputs have some sort of timestamps on the same time base
[18:34:39 CET] <neverminder> TAFB - Any idea why this doesn't work?  ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default video.mp4
[18:35:03 CET] <JEEB> neverminder: you get nothing on the logs with -v verbose or -v debug with -debug_ts ?
[18:35:23 CET] <JEEB> verbose gives you some things, debug_ts shows you the exact timestamps ffmpeg.c passed around
[18:35:33 CET] <JEEB> and debug is "enable really verbose stuff everywhere"
[18:35:54 CET] <JEEB> neverminder: also I bet a person on windows doesn't hav too many ideas on v4l2 or pulse :)
[18:37:04 CET] <JEEB> TAFB: anyways most likely your issue with -c:v copy is basically lack of timestamps which should come apparent with -v verbose -debug_ts. libavformat has an issue with calculating/fixing timestamps from containers/protocols that don't really have them
[18:37:11 CET] <neverminder> JEEB - this is the output I get with -v verbose: https://pastebin.com/5hHKvULP
[18:37:13 CET] <JEEB> and people generally don't notice because they decode the input
[18:37:18 CET] <TAFB> JEEB: files uploading now, 1 sec .
[18:37:20 CET] <neverminder> gets stuck and frame 1 and no idea why
[18:37:32 CET] <JEEB> TAFB: have you tried playing the file with mpv or vlc?
[18:37:42 CET] <JEEB> windows builds for mpv can be found @ https://mpv.srsfckn.biz/
[18:37:43 CET] <TAFB> cpu isn't even close to fast enough to encode 4k live, so -c copy will have to do
[18:37:53 CET] <JEEB> well yea, I'm not recommending you do that
[18:37:59 CET] <JEEB> I'm just saying where I'm feeling the issue might be at :P
[18:38:41 CET] <JEEB> because I've had similar issues trying to -c:v copy H.264 from MPEG-TS to MPEG-TS
[18:39:42 CET] <JEEB> neverminder: up to that point that looks OK as far as the logs go :P
[18:40:57 CET] <neverminder> JEEB - just ran it with -v debug and it's a mess: https://pastebin.com/GqkVR7ZH
[18:41:22 CET] <JEEB> oh yes, debug_ts might be more useful there :P
[18:41:31 CET] <neverminder> What does "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" mean?
[18:41:32 CET] <JEEB> but yes, you can clearly see it's not happy with the timestamps it's getting
[18:41:41 CET] <TAFB> JEEB: http://tafb.xxx/test.flv and http://tafb.xxx/test.txt :) I'm downloading them now to try and play them (they are captured on a remote machine).
[18:43:17 CET] <TAFB> plays a little strange
[18:43:56 CET] <JEEB> I bet it plays a little strange
[18:44:53 CET] <JEEB> you can just look at those -debug_ts outputs
[18:45:12 CET] <TAFB> the "[flv @ 000001e1f618c020] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" line? :)
[18:45:23 CET] <JEEB> that was visible before, too - and gave you some hints :)
[18:45:33 CET] <TAFB> so here's my thinking
[18:45:48 CET] <JEEB> "demuxer -> " is what lavf read, demuxer+ffmpeg is after ffmpeg.c mucks with the timestamps
[18:45:58 CET] <TAFB> can FFMPEG not make it's own timestamps? Just make a big 10 second buffer, as complete frames arrive, stamp them, spit them out at a flawless 30fps
[18:46:00 CET] <TAFB> no!?
[18:46:41 CET] <JEEB> not sure if there's code for that - a lot of those solutions have been focused around video filters which of course you can't run on non-raw things :D
[18:46:51 CET] <JEEB> and "muxer <- " is what gets fed into the FLV muxer
[18:47:40 CET] <JEEB> so the first feed is NOPTS/0, then you have 0/0, 54/54
[18:48:41 CET] <JEEB> for for straight 30fps that'd be +33 for each picture if there are no B-frame shenanigans
[18:48:58 CET] <JEEB> (b-frames can make the presentation time stamp go out of order)
[18:49:52 CET] <TAFB> when I search on re-writing timestamps without re-encoding it looks like mp4box can do it. Question is can it do it live :)
[18:50:09 CET] <JEEB> nah, you can't just stick it into ffmpeg
[18:50:27 CET] <JEEB> also nothing stops from ffmpeg.c from doing it, the thing's just not there yet
[18:50:37 CET] <JEEB> I'm more interested in WTF are these timestamps and how did they end up like that :P
[18:51:11 CET] <TAFB> no-name chinese ip camera that their techs thought could "improve" h264 implementation no doubt
[18:51:27 CET] <JEEB> nah, I wouldn't even put blame there yet
[18:51:45 CET] <JEEB> 'cause I know we have issues with things that don't give Really Nice timestamps
[18:52:00 CET] <JEEB> such as raw H.264 or MPEG-TS
[18:52:03 CET] <JEEB> as just some examples
[18:52:11 CET] <JEEB> (which I have felt on my own skin)
[18:52:50 CET] <JEEB> anyways, some timestamps are generated as you can see from the muxer <- lines
[18:52:57 CET] <JEEB> that's what ends up being fed to the FLV muxer
[18:53:19 CET] <furq> you might actually be able to do it in a really awful hacky way
[18:53:22 CET] <JEEB> also is this camera supposed to be CFR or VFR
[18:53:48 CET] <JEEB> this jump from 3000 (still looks OK) to 7900 is weird
[18:53:51 CET] <furq> ffmpeg -i rtsp://... -c copy -f h264 - | ffmpeg -f h264 -r 30 -i - -c copy rtmp://...
[18:53:58 CET] <JEEB> :D
[18:54:05 CET] <furq> i warned you
[18:54:26 CET] <TAFB> I can make it CFR or VFR
[18:55:58 CET] <TAFB> furq: I'll give it a try, so first ffmpeg streaming it as udp:127.0.0.1:1234 and the second ffmpeg -i the udp?
[19:00:07 CET] <JEEB> no, it's just output into stdout
[19:00:12 CET] <JEEB> and the second reads from the stdin
[19:00:14 CET] <JEEB> piping
[19:00:20 CET] <TAFB> on windows?
[19:00:24 CET] <JEEB> works fine
[19:00:32 CET] <TAFB> never knew that :)
[19:00:32 CET] <JEEB> unless in powershell, that one tries to buffer the stdout
[19:00:58 CET] <TAFB> i always run two (or more) copies of ffmpeg and use udp 127.0.0.1 to send it between
[19:00:59 CET] <TAFB> 1 sec.
[19:02:25 CET] <JEEB> furq: also I remember that if you have b-frames the h264 demuxer doesn't calculate the timestamps right
[19:02:30 CET] <ayum> Hi, I have a question above ffmpeg auto inserted scaler, my input is 1280x720 uyvy422 format,  it was scaled to 1280x720 yuv420p format. does it will lost quality in this scaler?
[19:02:50 CET] <JEEB> yes, you lose chroma
[19:02:55 CET] <JEEB> 4:2:2 to 4:2:0
[19:03:16 CET] <ayum> I only used Y plane, so lost chroma plane is okay
[19:03:17 CET] <JEEB> but often if you f.ex. are encoding H.264 the default is 4:2:0 because that's most supported in hw decoding etc
[19:09:29 CET] <TAFB> furq: https://pastebin.com/eSjEvsTb
[19:10:10 CET] <JEEB> yea, you left -f flv out
[19:10:16 CET] <JEEB> which for some reason is still needed for the protocl
[19:10:25 CET] <TAFB> ahh
[19:11:59 CET] <TAFB> ok, show's it streaming but "stream health" is red in live youtube list
[19:13:29 CET] <TAFB> i'll try writing output to file and see how it looks
[19:13:43 CET] <JEEB> debug_ts should tell you a lot to be honest
[19:13:54 CET] <JEEB> since it tells you a lot about what gets fed into the muxer
[19:16:46 CET] <TAFB> http://tafb.xxx/test2.flv
[19:16:49 CET] <TAFB> haven't seen it yet
[19:17:29 CET] <TAFB> OMG!
[19:17:32 CET] <TAFB> IT'S PERFECTLY SMOOTH!
[19:17:34 CET] <TAFB> woot :)
[19:18:18 CET] <TAFB> vlc says framerate is 1000fps :)
[19:19:58 CET] <JEEB> yea that's the time base for FLV
[19:20:15 CET] <JEEB> FLV stores time stamps with a  1/1000 time base
[19:20:25 CET] <JEEB> so in a way it's correct ;)
[19:20:36 CET] <JEEB> and yes, that also means that a lot of frame rates will not be exact in FLV
[19:21:15 CET] <TAFB> alright, so just have to figure out why youtube isn't liking it
[19:21:32 CET] <JEEB> possibly it isn't according to their buffering standards if they're passing it through as-is
[19:21:51 CET] <TAFB> i bet if we through an audio stream in with it, it'll take it
[19:22:10 CET] <JEEB> your guess is as good as mine :)
[19:22:23 CET] <furq> yeah you need a blank audio stream for youtube
[19:22:33 CET] <JEEB> anyways too bad so many services have built workflows around FLV
[19:22:38 CET] <JEEB> since FLV is now dead
[19:22:44 CET] <JEEB> and will most likely not get expanded
[19:22:50 CET] <JEEB> so HEVC, VP9, AV1...
[19:22:58 CET] <TAFB> furq: could you help me with what/where to put the audio into that command you gave me!? :)
[19:23:12 CET] <JEEB> just add the audio filter thing you had in the first one
[19:23:17 CET] <furq> add it to the right hand side of the pipe
[19:23:19 CET] <JEEB> to the second ffmpeg
[19:23:24 CET] <furq> yeah
[19:23:40 CET] <TAFB> k.
[19:24:16 CET] <furq> just -f lavfi -i anullsrc -c:a aac -c:v copy
[19:24:17 CET] <furq> should be fine
[19:24:27 CET] <TAFB> k.
[19:25:00 CET] <JEEB> also -b:a 96k to just set some bit rate :)
[19:25:08 CET] <furq> it'll default to 128k iirc
[19:25:08 CET] <JEEB> (heck you could even go lower)
[19:25:25 CET] <furq> and this is a copied 4k iptv stream so i'm guessing bandwidth isn't an issue
[19:25:48 CET] <SortaCore> rip my question
[19:25:55 CET] <SortaCore> buried alive at such a young age
[19:26:05 CET] <furq> why wouldn't you be able to use unicode paths
[19:26:15 CET] <JEEB> SortaCore: unicode paths should work just fine
[19:26:23 CET] <furq> if it's not working it's probably your shell
[19:26:50 CET] <JEEB> I don't remember how it worked with the API exactly, but as far as I can tell the cli can take in windows wide char paths just fine
[19:26:59 CET] <JEEB> API might require utf8 renditions
[19:27:04 CET] <JEEB> which it would then convert to wide char internally
[19:27:10 CET] <JEEB> for windows file access APIs
[19:27:30 CET] <SortaCore> avio_open2 takes a const char *
[19:27:41 CET] <SortaCore> utf8 * was a C++14 thing or something
[19:28:24 CET] <JEEB> nah, UTF-8 is usually passed as char *
[19:28:34 CET] <JEEB> wchar is something most people dislike
[19:28:53 CET] <TAFB> aac stream of 2kbps works, 1kbps didn't :)
[19:28:55 CET] <JEEB> but I will have to double check but I /think/ the API wants UTF-8
[19:28:59 CET] <SortaCore> u8"txt"
[19:29:11 CET] <SortaCore> well, there's nothing in avio_open2 comments about UTF-8
[19:29:22 CET] <JEEB> yea, trying to check the docs
[19:29:41 CET] <JEEB> because other API-using apps are handling it and I know we have internal code for handling windows unicode paths
[19:29:55 CET] <JEEB> have you tried using wchar to utf8 functions in windows and just passing the string?
[19:30:05 CET] <SortaCore> looks like my code does do WCHAR -> UTF8 anyway
[19:30:12 CET] <JEEB> because I bet testing it out like that should JustWork
[19:30:22 CET] <SortaCore> I'll try some weeb kanji
[19:30:23 CET] <JEEB> (or not and then we're a bit wiser
[19:31:33 CET] <JEEB> SortaCore: yea just git grep -i "utf-8"
[19:31:45 CET] <JEEB> and cmdutils.c does wchar->utf8
[19:32:03 CET] <JEEB> so I bet the API always requires UTF-8 but then internally does the additional stuff to make it work on windows
[19:32:11 CET] <JEEB> (UTF-8 back to wchar)
[19:32:18 CET] <JEEB> just to keep the interface the same between OSs
[19:32:25 CET] <JEEB> (also fuck wchar <3)
[19:33:41 CET] <SortaCore> WCHAR was doomed from the start
[19:34:03 CET] <SortaCore> I wonder who had the bright idea "1 byte char ain't big enough... let's do 2 byte, that'll definitely be future compatible"
[19:34:36 CET] <JEEB> I think at this point it's actually variable length in the end
[19:34:45 CET] <JEEB> since it has to support things that don't fit into 2 bytes
[19:35:02 CET] <SortaCore> yea, but that's even more confusing
[19:35:10 CET] <JEEB> yup
[19:35:23 CET] <SortaCore> since sizeof(char_type) is what most people are used to
[19:35:29 CET] <JEEB> yup
[19:35:32 CET] <SortaCore> then there's that multibyte weirdness
[19:36:16 CET] <SortaCore> strlen, wcslen, _mbslen :p
[19:36:23 CET] <SortaCore> then the TCHAR usefulness
[19:36:38 CET] <JEEB> oh yea
[19:36:45 CET] <JEEB> because non-unicode builds are still a thing you totally want
[19:36:52 CET] <JEEB> _T("perkele")
[19:37:22 CET] <SortaCore> I'm writing a DLL for some software dated back to 90s
[19:37:33 CET] <SortaCore> it has unicode and non-unicode
[19:37:40 CET] <JEEB> rip
[19:38:02 CET] <JEEB> reminds me of a company trying to recruit people at the mixed Qtcon/VDD
[19:38:04 CET] <SortaCore> it is slightly odd to me there's no std::tstring or std::tstringstream from MS
[19:38:39 CET] <JEEB> on the top of the recruitment thing they had "we need best C++ devs" which is generic as usual
[19:38:39 CET] <SortaCore> fortunately, the software will be getting a new codebase on next iteration
[19:39:00 CET] <SortaCore> I'm a C++ dev, but I oddly don't do anything like the new C++
[19:39:10 CET] <JEEB> but then if you actually opened the leaflet they talked about using IDA Pro to reverse engineer MS Office and doing runtime patching of the binaries
[19:39:26 CET] <SortaCore> the closest I get is lambdas
[19:39:28 CET] <JEEB> just so people can get powerpoint plugins that utilize private features <3
[19:39:40 CET] <SortaCore> that sounds... really confused
[19:39:51 CET] <SortaCore> but hey, if it works
[19:39:56 CET] <JEEB> yea
[19:40:01 CET] <SortaCore> DLL injection ftw right
[19:40:04 CET] <JEEB> and deffo it sounds different to just coding off C++
[19:40:25 CET] <JEEB> and actually admitting to RE is cool, since clean-room RE is fine
[19:40:43 CET] <JEEB> not that I necessarily want to end up doing something like that, but at least it stuck in my mind
[19:40:49 CET] <SortaCore> I've not done that, although the SDK was released with a ton more code than actually needed
[19:41:05 CET] <SortaCore> someone did create a new version of the software with the SDK though
[19:41:15 CET] <SortaCore> and it ended up a ton faster
[19:41:24 CET] <SortaCore> probably what kick-started a new iteration
[19:42:06 CET] <SortaCore> the thing is, I'm used to C#, where templates are very easy
[19:42:13 CET] <SortaCore> in C++ I get told all sorts of odd errors
[19:42:34 CET] <SortaCore> I used __asm int 3; in a define once and it started fussing about braces everywhere
[19:43:40 CET] <SortaCore> it's the equivalent of "debug break and get a debugger if there isn't one"
[19:44:34 CET] <JEEB> yea, I really know the limits of C but I'm not someone who'd be too happy of going into C++
[19:44:46 CET] <JEEB> or not know, but I acknowledge that some crap is just really bad in C
[19:45:01 CET] <JEEB> and that the language misses a lot of helper stuff you need in everyday life
[19:45:16 CET] <SortaCore> yea, then you feel like you shouldn't add it because it'll Make It Slower
[19:45:25 CET] <SortaCore> and introduce more points of failure
[19:45:46 CET] <JEEB> also not everyone minds the differences of C and C++
[19:45:54 CET] <JEEB> like checking the result of new
[19:45:56 CET] <JEEB> for nullptr
[19:46:21 CET] <SortaCore> you can replace that with a throw... but either case still looks odd
[19:46:32 CET] <JEEB> and because of being a C person instead of try/catching that I instead just added std::nothrow
[19:46:36 CET] <JEEB> :D
[19:46:52 CET] <JEEB> and suddenly the code worked because the rest of it expected a nullptr in case of failure
[19:47:02 CET] <neverminder> Any ffmpeg developers here that could help me understand what the problem is?
[19:47:06 CET] <SortaCore> heh, not the worst thing I've done
[19:47:25 CET] <JEEB> neverminder: I couldn't see anything specifically wrong with your logs
[19:47:44 CET] <SortaCore> mapping?
[19:48:02 CET] <neverminder> JEEB - this is the last one, all possible debugging enabled: https://pastebin.com/qiyR15Dn
[19:48:03 CET] <SortaCore> oh nvm
[19:48:49 CET] <neverminder> What does "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" mean? It repeats in some kind of a loop and this is where things get stuck...
[19:49:48 CET] <rajkosto> how can you guarantee lowest decode latency using the ffmpeg api (h264) ? it seems that it prefers to lag by one or two pictures even though it has all the data to decode it
[19:51:10 CET] <rajkosto> adding a null input packet sometimes gets the picture out, i'd rather not have to do this
[19:54:33 CET] <JEEB> rajkosto: the decoder in theory should require the minimum amount of latency. sometimes there's latency because of b-frame reordering etc. also are you using the old API or the new push/pull API?
[19:54:50 CET] <JEEB> this is the new one https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[19:55:28 CET] <rajkosto> just old avcodec_decode_video2
[19:55:45 CET] <JEEB> yea, that might have its overhead
[19:56:05 CET] <rajkosto> basically, i want pure software, single threaded, whatever it takes, i just want to have a frame immediately after i feed it enough NALs for one
[19:56:05 CET] <JEEB> please quickly test the "new" one (it's over a year old by now IIRC)
[19:56:45 CET] <rajkosto> i dont care if it gives me frames "out of order" since i already tag input avpackets with timestamps
[19:56:45 CET] <JEEB> yea, if you set threads to 1 or use slice threading you should get it as soon as possible with regards to b-frames
[19:57:48 CET] <JEEB> yea I think I'm not sure if you can disable that functionality
[19:58:05 CET] <rajkosto> i think it wants to reorder them itself
[19:58:10 CET] <JEEB> yes
[19:58:15 CET] <JEEB> but only if you have b-frames anyways
[19:58:24 CET] <rajkosto> https://pastebin.com/mX5qZyDN
[19:58:27 CET] <JEEB> I would first of all recommend you to poke the send/receive API
[19:59:06 CET] <JEEB> yea, that should have threads at 1
[19:59:15 CET] <JEEB> also why disabling refcount?
[19:59:20 CET] <JEEB> I don't think that adds any latency
[19:59:34 CET] <rajkosto> i dont need it, and i think its only used for threaded decode
[19:59:50 CET] <JEEB> nah, it is refcounting of the things so unnecessary memcpys are reduced
[19:59:56 CET] <JEEB> it doesn't really have anything to do with threads
[20:00:47 CET] <rajkosto> what ffmpeg do i need for this new method to work
[20:00:56 CET] <JEEB> it's pretty old by now
[20:01:05 CET] <JEEB> let me see if we have it in the API change logs
[20:01:54 CET] <JEEB> http://up-cat.net/p/66f847cc
[20:02:02 CET] <JEEB> so any release branched after that
[20:03:14 CET] <JEEB> apparently 3.1 was the first release branch to be cut after that
[20:03:28 CET] <JEEB> although I definitely recommend generally working with the latest HEAD after making sure FATE passes
[20:03:35 CET] <rajkosto> https://pastebin.com/VZxHLU00
[20:03:46 CET] <rajkosto> whatever that means, overall version just says 3.2-git
[20:04:17 CET] <JEEB> yea, that means it's a pretty old HEAD version
[20:04:21 CET] <JEEB> from after 3.1
[20:04:24 CET] <JEEB> so you have the APIs
[20:05:02 CET] <rajkosto> At the beginning of decoding or encoding, the codec might accept multiple input frames/packets without returning a frame, until its internal buffers are filled. This situation is handled transparently if you follow the steps outlined above.
[20:05:13 CET] <rajkosto> i dont want any buffering more than the minimum
[20:05:46 CET] <JEEB> yes, that is what is meant
[20:06:03 CET] <JEEB> if you have packets with parameter sets etc it will of course eat those, same for non-IRAP pictures
[20:06:11 CET] <JEEB> so if it cannot output a picture it will not output a picture :P
[20:06:22 CET] <JEEB> for the reordering there's not much you can do with that can you?
[20:06:47 CET] <JEEB> because you will have to reorder them yourself anyways
[20:07:00 CET] <JEEB> so I don't see that as any sort of latency that you can avoid
[20:07:24 CET] <JEEB> if your stream doesn't require any reordering according to the parameter sets then it should just output them
[20:07:35 CET] <JEEB> (or according to the stream itself)
[20:08:37 CET] <JEEB> so the expectation is that with the send/receive API you should be able to read a picture as soon as it is technically possible to get it in the correct presentation order
[20:09:30 CET] <JEEB> if the results are not what is expected then that is either an issue with the stream or a bug in FFmpeg's decoder
[20:24:25 CET] <rajkosto> ah
[20:24:34 CET] <rajkosto> but i always feed it enough NALs for a new picture
[20:24:44 CET] <rajkosto> and i want to get that picture in decoding order since i already tagged it with a timestamp in the avpacket
[20:24:49 CET] <rajkosto> as soon as possible
[20:25:04 CET] <rajkosto> the reordering is done in a different place, i just need to fill gpu buffers
[20:25:15 CET] <rajkosto> and i get a lag of a couple of frames whne using ffmpeg
[20:27:54 CET] <JEEB> yea that doesn't help since the decoder is built for reordering to be done there. since when you reorder you're getting latency anyways - it just gets moved to another spot
[20:28:05 CET] <rajkosto> thats fine, i have an interface to conform to
[20:28:16 CET] <rajkosto> it performs reordering later on
[20:28:27 CET] <JEEB> that said we still haven't figured if that's the thing or not that you're having an issue with :P
[20:28:37 CET] <JEEB> which is why I asked you to move to the send/receive API
[20:28:43 CET] <rajkosto> this means that using ffmpeg instead of the original hardware decoder breaks some applications that expect frames immedaitely
[20:29:10 CET] <JEEB> yes, that would be correct then
[20:29:16 CET] <JEEB> IFF that is the problem
[20:29:18 CET] <rajkosto> i doubt that moving to the new interface would change anything
[20:29:35 CET] <JEEB> yea I'm just trying to ensure that the frame reordering delay is what your issue is
[20:30:35 CET] <rajkosto> when is the decoding actually performed ? when i give it nals or when i try to get pictures out
[20:30:47 CET] <rajkosto> since i disabled threading it has to be done at one place or the other
[20:31:27 CET] <JEEB> when you send it a packet it will call decode_frame() most likely
[20:32:27 CET] <JEEB> then the decode framework has a list of available AVFrames which can have a length of 0 or more
[20:32:36 CET] <JEEB> when you try calling the receive one
[20:33:09 CET] <rajkosto> i wonder if AV_CODEC_FLAG_TRUNCATED and AV_CODEC_FLAG2_CHUNKS are doing anything useful
[20:33:13 CET] <JEEB> no
[20:33:16 CET] <JEEB> they are not
[20:33:25 CET] <rajkosto> pretty sure i need chunks if i was to feed it one NAL at a time
[20:33:48 CET] <JEEB> nope, as far as I can tell most demuxers feed it separate NALs :P
[20:33:49 CET] <rajkosto> thats why i added it
[20:33:56 CET] <rajkosto> i mean for the old interface
[20:35:25 CET] <JEEB> rajkosto: I'm pretty sure even without that flag and even with the old interface you just wouldn't get a decoded frame
[20:35:37 CET] <JEEB> until you fed all the NAL units for a single picture
[20:35:45 CET] <JEEB> *required for a single picture
[20:36:02 CET] <rajkosto> theres a reason i added it, i think it was erroring without it when i was feeding single nals
[20:36:42 CET] <JEEB> just never seen that one and I'm not 100% sure what it means in this context. but sure, it's possible that the decoder would require all NALs that are a decode'able picture
[20:36:47 CET] <JEEB> although that would be surprising to be honest :/
[20:37:13 CET] <JEEB> maybe lavf was making it nice and simple for me :P although I do remember it outputting all the parameter sets in separate AVPackets first
[20:37:53 CET] <JEEB> rajkosto: and teh reason why pushing a NULL there probably "worked" was because that started the flushing procedure
[20:38:02 CET] <JEEB> "end of stream, output what is still in the buffers"
[20:38:08 CET] <JEEB> if buf_size == 0
[20:38:11 CET] <rajkosto> yep, thats how i was able to get single frames out immediately
[20:38:20 CET] <rajkosto> but only sometimes, othertimes it would actualyl give me bad frames out
[20:39:55 CET] <JEEB> but yea, flushing the decoder requires its own resets etc so it is quite likely to break (or already is breaking)
[20:40:13 CET] <JEEB> so if you need the pictures output without reordering I think unfortunately libavcodec is not for you
[20:40:29 CET] <JEEB> or if you make a patch for that and if it gets accepted that's a possibility
[20:40:45 CET] <rajkosto> what if you need to send out the frames somewhere else immediately, not just for display
[20:41:10 CET] <JEEB> well transcoding also needs the pictures in correct order for motion estimation etc to work
[20:41:33 CET] <JEEB> so it's very limited what gets a benefit from not reordering the pictures correctly
[20:41:47 CET] <CoreX> bugting
[20:41:50 CET] <CoreX> bufting*
[20:41:53 CET] <JEEB> or at least that's how I see it, maybe there are reasons for it beyond "some HW just wants stuff asap"
[20:42:22 CET] <rajkosto> there should be a flag for it
[20:42:38 CET] <JEEB> I don't disagree, but there currently isn't such in the H.264 decoder
[20:42:51 CET] <JEEB> I mean, I don't see the use case but I don't disagree for a flag like that :P
[20:44:53 CET] <rajkosto> its because i only get limited chances to fill gpu buffers and i miss them because ffmpeg is keeping frames from me
[20:45:56 CET] <JEEB> you might want to post about that either on the trac issue tracker or ffmpeg-devel mailing list as a feature request then
[20:47:29 CET] <JEEB> there's already a flag (AV_CODEC_FLAG_LOW_DELAY)
[20:47:49 CET] <JEEB> it seems like the mpeg-2 and mpeg-4 part 2 decoders follow that in some way
[20:48:00 CET] <JEEB> but I don't see references in the H.264 one
[20:48:49 CET] <JEEB> if it does the same thing in mpeg-2 or mpeg-4 part 2 then it might make sense to request for that to be added to H.264 as well
[20:51:21 CET] <rajkosto> Note that the function will always call
[20:51:21 CET] <rajkosto>  *av_frame_unref(frame) before doing anything else.
[20:51:23 CET] <rajkosto> what does that mean
[20:51:29 CET] <rajkosto> do i need to unref it or not
[20:52:42 CET] <JEEB> it sounds like if you still have a reference to the AVFrame it will unref it when you feed it to the decoder to get a new set of data
[20:53:26 CET] <rajkosto> so if im reusing the same one i dont manually unref it, except at the end when im destroying it anyway
[20:55:01 CET] <JEEB> I'm not 100% right but that sounds about right if I read that documentation correctly.
[20:57:20 CET] <rajkosto> it seems that for mpeg4 AV_CODEC_FLAG_LOW_DELAY is only able to be set if the stream doesnt have b frames
[20:58:45 CET] <JEEB> hmm, not exactly
[20:59:02 CET] <JEEB> or wait
[20:59:19 CET] <rajkosto> because it sets has_b_frames to its opposite
[20:59:50 CET] <JEEB> yea the has_b_frames is generally utilized as an internal thing in the decoders
[20:59:54 CET] <JEEB> as a reorder amount etc
[21:00:07 CET] <JEEB> so if you set low_delay =1 then has_b_frames goes to zero
[21:00:10 CET] <JEEB> and thus zero reorder
[21:00:53 CET] <rajkosto> but doesnt it need to know that the stream has b_frames otherwise it wont be able to keep frame history properly ?
[21:01:07 CET] <JEEB> well if you want to ignore the reorder then you just force it to zero
[21:01:12 CET] <JEEB> which is what that seems to be doing :P
[21:01:26 CET] <JEEB> at least that's how it looks to me in the mpeg4 decoder
[21:01:32 CET] <JEEB> which is not the H.264 one
[21:08:20 CET] <JEEB> rajkosto: but yea, either make a patch yourself or request the feature on trac issue tracker / ffmpeg-devel ML
[21:08:57 CET] <durandal_1707> carl doesnt like feature requests on devel ml?
[21:09:05 CET] <JEEB> ok, just trac then
[21:09:17 CET] <furq> is there anything carl does like
[21:09:32 CET] <rajkosto> the cisco h264 decoder doesnt have this problem then again it only supports baseline profile :P
[21:10:30 CET] <JEEB> well yes
[21:10:40 CET] <JEEB> but on the other hand if you have no reorder requirement in sPS
[21:10:46 CET] <JEEB> it shouldn't buffer
[21:10:54 CET] <rajkosto> sometimes i do
[21:11:12 CET] <JEEB> well yea, then cisco's decoder wouldn't help you would it
[21:11:24 CET] <BtbN> How would you not want the re-ordering to happen?
[21:11:30 CET] <BtbN> A decoder seems pretty useless without it.
[21:11:49 CET] <rajkosto> BtbN, each avpacket has a timestamp field on it anyway, which is replicated in the avframe
[21:12:12 CET] <BtbN> But if you re-order them yourself, you'll inevitably re-introduce the exact same delay
[21:12:16 CET] <rajkosto> i want the decoder to just return frames even if it doesnt have the next one in presentation order
[21:12:18 CET] <teratorn> on a different timescale
[21:12:28 CET] <teratorn> well, possibly different timescale
[21:12:53 CET] <JEEB> BtbN: yea that was what I wondered :P what use cases do you have for it since you still have to reorder them to utilize them for pretty much anything
[21:13:01 CET] <JEEB> transcoding, presentation...
[21:13:06 CET] <JEEB> the latency just moves elsewhere
[21:13:10 CET] <rajkosto> the API i want to plugin ffmpeg to gives me ptr to bitstream for one frame, and gpu buffer to fill  with that decoded frame
[21:13:41 CET] <JEEB> right, so it doesn't have separate push/pull
[21:13:58 CET] <JEEB> does it kill that pointer you got after you call its API the next time?
[21:14:09 CET] <rajkosto> sometimes if i return error it knows that hte gpu buffer isnt used
[21:14:14 CET] <rajkosto> and will submit it next time
[21:14:23 CET] <rajkosto> sometimes it doesnt check error and just assumes all have frames :|
[21:14:41 CET] <JEEB> just wonder if your layer keeps the pointer
[21:14:43 CET] <BtbN> What the hell kinda API is that?
[21:14:58 CET] <rajkosto> BtbN, one that works perfectly for the hardware decoder that was avaialble when it was made on one platform
[21:16:47 CET] <JEEB> rajkosto: so basically if you keep a pointer to the buffer will be invalidate it after you call its thing again?
[21:16:51 CET] <JEEB> that's the main thing
[21:17:03 CET] <JEEB> so if you can have the buffers around in your own buffer
[21:17:05 CET] <JEEB> -34
[21:17:08 CET] <rajkosto> yes i cant keep a pointer to the buffer
[21:17:14 CET] <rajkosto> the gpu one
[21:17:20 CET] <JEEB> oh well
[21:17:21 CET] <rajkosto> its either fill it now or give it back
[21:17:41 CET] <JEEB> anyways, a shitty API and my condolences
[21:17:46 CET] <rajkosto> and users of the api that set the "give frames immediately" bool, dont even check the "give it back" sitaution
[21:18:09 CET] <rajkosto> they giv enough bitstream to decode a frame, and expect a frame
[21:19:02 CET] <JEEB> yea, the problem is that you need to do buffering elsewhere if there's reordering needed
[21:19:15 CET] <rajkosto> it parses the timestamp returned, and reorders itself
[21:19:16 CET] <JEEB> they've seemingly taken that to themselves or just don't support reordering
[21:19:28 CET] <JEEB> which then fights with 99% of all multimedia frameworks :D
[21:19:53 CET] <JEEB> I think there was like one or so which libavcodec integrates to which doesn't do reordering itself
[21:21:25 CET] <rajkosto> the thing is, there isnt a usable h264 high decoder other than ffmpeg
[21:21:42 CET] <rajkosto> other than the APIs exposed by various OSs, but those buffer way more
[21:22:22 CET] <JEEB> then your only way forward is to either rework the API you're dealing with, or add the no reorder mode to h264dec
[21:23:52 CET] <rajkosto> the tangled web of C that h264dec is wont let me do the latter
[21:24:49 CET] <JEEB> then you have the options of either fixing the API you're dealing with or requesting for the feature in h264dec
[21:35:07 CET] <neverminder> So if I can't record video and audio simultaneously into one file, is it possible to output video and audio into separate files?
[21:36:23 CET] <rajkosto> but you can !
[21:37:44 CET] <marco_> Hallo, i'm very new to ffmpeg, i need to join some clips with different formats, bitrate and other. tryed to convert with command like this ffmpeg  -i 28.avi -b 1200k -minrate 1200k  -maxrate 1200k -bufsize 1200k -ab 64k  -vcodec libx264  -acodec aac -strict -2 -ac 2  -ar 44100 -s 640x360 -y 28_test.mp4 but i've got some error and the output freeze!
[21:38:20 CET] <JEEB> first of all with any recent (early 2016 or later) version of FFmpeg the AAC decoder no longer needs the experimental flag
[21:38:27 CET] <JEEB> (-strict experimental, which is "-2")
[21:38:50 CET] <JEEB> also don't set minrate unless you explicitly need it since it's not a thing in libx264
[21:39:14 CET] <JEEB> also not sure what is joining clips in that one?
[21:39:31 CET] <JEEB> if you are joining clips I would have thought of the concat filter
[21:39:44 CET] <marco_> sorry i'm new to video editing too..
[21:40:14 CET] <marco_> so i found some example and try it..
[21:40:53 CET] <JEEB> https://trac.ffmpeg.org/wiki/Concatenate#filter
[21:41:18 CET] <JEEB> this lets you work with multiple files and you can even then normalize their resolutions etc
[21:41:22 CET] <JEEB> -45
[21:42:51 CET] <neverminder> rajkosto: no I can't, wasted countless hours on it already and nothing
[21:43:17 CET] <marco_> i have read that page, and made some test, but i don't know wich parameters are mandatory to be normalized..
[21:43:41 CET] <JEEB> neverminder: well anything you have posted has not shown any issues and I do not utilize those modules myself so I have no idea if there are any issues with them if there are any :P
[21:43:59 CET] <JEEB> but in theory what you're doing "having multiple inputs" is quite possible as long as you have them on the same time line
[21:44:59 CET] <neverminder> JEEB - thing is, I can record audio and video separately jus fine, so surely it's not the modules?
[21:45:10 CET] <JEEB> or then ffmpeg.c
[21:45:18 CET] <JEEB> I can't say anything without knowing more about the specific issue
[21:45:44 CET] <JEEB> but we've already seen multiple people here today doing separate video and audio inputs into a single output so that in general is not the problem
[21:48:27 CET] <neverminder> so this is a bug then that only affects me?
[21:49:05 CET] <JEEB> not necessarily, but you're the one who's come to this point
[21:49:28 CET] <JEEB> I mean, there's plenty of input modules and plenty of cases of where things can possibly fail
[21:49:39 CET] <JEEB> the problem is that the outputs you posted that I checked quickly didn't seem to have any signs of errors
[21:50:45 CET] <neverminder> no errors indeed, but there's an enormous loop at the end saying "cur_dts is invalid (this is harmless if it occurs once at the start per stream)"
[21:51:00 CET] <JEEB> check debug_ts output
[21:51:10 CET] <JEEB> that gives you the exact timestamps that ffmpeg.c is dealing with
[21:51:42 CET] <JEEB> what it gets out of the "demux", how it looks after ffmpeg.c has mangled the timestamps and how it looks like when things are fed/gotten to/from a decoder
[21:51:45 CET] <JEEB> and encoder
[21:51:46 CET] <JEEB> and muxer
[21:55:42 CET] <marco_> JEEB: Using mediainfo i've found this difference between 2 clips:
[21:55:42 CET] <marco_> Overall bit rate:1 344 Kbps - 1 801 Kbps
[21:55:42 CET] <marco_> Bit rate : 1 141 Kbps - 1 664 Kbps
[21:55:42 CET] <marco_> Width: 528 pixels - 520 pixels
[21:55:42 CET] <marco_> Height: 400 pixels - 390 pixels
[21:55:44 CET] <marco_> Frame rate:25.000 fps - 29.917 fps
[21:55:46 CET] <marco_> Bits/(Pixel*Frame): 216 - 274
[21:55:48 CET] <marco_> Writing library:XviD 1.1.2 (UTC 2006-11-01) - Lavc51.46.0
[21:55:50 CET] <marco_>  is possible to join?
[21:56:26 CET] <JEEB> just make the resolution the same
[21:56:32 CET] <JEEB> VFR should be possible in mp4
[22:01:38 CET] <marco_> what do you mean with resolution whdth and heigth?
[22:01:46 CET] <JEEB> yes
[22:01:50 CET] <JEEB> use the scale filter
[22:02:10 CET] <JEEB> either upscale the smaller one a bit or downscale the larger one
[22:02:21 CET] <JEEB> or if there's black borders, crop to match them up
[22:04:11 CET] <marco_> Thanks i will make some try. may be in some days i will be here again :-)
[22:09:19 CET] <neverminder> JEEB - so is it possible to output audio and video into separate files? Maybe that way I could circumvent this dead end?
[22:11:23 CET] <neverminder> I mean I literally just need to record video and audio tracks in sync, doesn't matter how.
[22:12:41 CET] <JEEB> you can but I'm not sure how to keep the sync since I have no idea how those two inputs give you timestamps to begin with?
[22:12:55 CET] <JEEB> can you not check with -v verbose -debug_ts what on earth is going on there?
[22:13:31 CET] <neverminder> I do and I did multiple times - enabling -report flag is the same as -v verbose
[22:13:49 CET] <neverminder> what do you mean by timestamps?
[22:13:51 CET] <JEEB> but not debug_ts
[22:13:54 CET] <JEEB> as far as I remember
[22:14:00 CET] <neverminder> yes, debug_ts as well
[22:14:02 CET] <JEEB> ok
[22:14:12 CET] <neverminder> https://pastebin.com/bV1ePJ2u
[22:14:14 CET] <JEEB> thank you
[22:14:24 CET] <neverminder> this is a dump with absolutely everything enabled that you mentioned
[22:14:54 CET] <JEEB> ok, so it just keeps rolling around like that using CPU or so?
[22:15:02 CET] <JEEB> with just outputting the cur_dts thing?
[22:15:15 CET] <neverminder> yep, pretty much
[22:15:21 CET] <JEEB> now that's funky
[22:15:40 CET] <neverminder> doesn't really use much CPU though, not significantly
[22:15:48 CET] <JEEB> oh
[22:15:51 CET] <JEEB> one thing I noticed
[22:16:01 CET] <JEEB> you're not going to get mpeg-1 video encoded with 3840x2160 I think?
[22:16:17 CET] <JEEB> libx264 or so recommended, preset superfast or so
[22:16:31 CET] <neverminder> what does that mean? how can I enable that?
[22:17:01 CET] <JEEB> -c:v libx264 -preset superfast
[22:17:14 CET] <JEEB> "give me libx264" "set the preset option to 'superfast'"
[22:17:24 CET] <JEEB> :v means "for the video"
[22:17:31 CET] <neverminder> can I just put it anywhere in the command string?
[22:17:38 CET] <JEEB> after the input, basically
[22:17:48 CET] <JEEB> that's the main difference in ffmpeg.c
[22:18:03 CET] <JEEB> if options go before -i [input], those are for reading/decoding
[22:18:11 CET] <JEEB> if they go after, those are for encoding/writing
[22:19:22 CET] <neverminder> so I just tried this: ffmpeg -y -report -debug_ts -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default -c:v libx264 -preset superfast video.mpg
[22:19:24 CET] <neverminder> no change
[22:19:48 CET] <JEEB> oh, mpg. try mkv
[22:20:07 CET] <JEEB> also post log
[22:20:17 CET] <JEEB> although I have a feeling that the v4l2 thing isn't read from for some reason?
[22:20:28 CET] <JEEB> wait
[22:20:38 CET] <JEEB> why are there no demuxer/demuxer+ffmpeg lines...
[22:20:42 CET] <JEEB> only encoder/muxer
[22:20:46 CET] Action: JEEB scratches his head
[22:21:12 CET] <neverminder> tried with mkv, no change: https://pastebin.com/8i3LMdgc
[22:21:42 CET] <neverminder> is there something weird going on?
[22:22:01 CET] <JEEB> weird as heck
[22:22:13 CET] <JEEB> those debug_ts lines are not supposed to just stop
[22:22:27 CET] <JEEB> can you please make a ticket about this with that output on trac?
[22:22:36 CET] <JEEB> it's as if one of the inputs is blocking the other one
[22:22:42 CET] <JEEB> because nothing's getting read
[22:22:43 CET] <neverminder> I run it, wait a little and kill it with Ctrl-C if that changes anything?
[22:23:17 CET] <neverminder> you mean a bug report with this output included?
[22:23:21 CET] <JEEB> yes
[22:23:33 CET] <neverminder> how should I describe the bug?
[22:23:39 CET] <JEEB> although I would test with the latest git HEAD as well
[22:23:56 CET] <JEEB> in case the issue is fixed there
[22:24:25 CET] <JEEB> you only need libx264, pulse, v4l2 and whatever ffmpeg.c picked for mkv
[22:24:28 CET] <JEEB> (for audio)
[22:24:35 CET] <JEEB> you don't need to install it, just build it
[22:24:57 CET] <JEEB> neverminder: a good enough description would be "ffmpeg.c stalls after N frames when capturing v4l2 video and pulse audio"
[22:25:04 CET] <JEEB> because that's how it seems like
[22:25:17 CET] <JEEB> the debug_ts stuff stops so there's some sort of stall
[22:25:41 CET] <JEEB> neverminder: if you look at the beginning there's some "demuxer -> " and "demuxer+ffmpeg ->" lines
[22:25:47 CET] <JEEB> but then they disappear
[22:25:49 CET] <neverminder> yeah I see that
[22:25:52 CET] <JEEB> which means that ffmpeg.c isn't getting things read
[22:25:55 CET] <JEEB> for some reason
[22:27:23 CET] <neverminder> ok thanks, I'll try all the stuff you recommended and get back as soon as I have something
[22:50:39 CET] <JEEB> neverminder: yea I guessed that's the initial response you'll get :D "test with current git HEAD"
[23:12:57 CET] <rajkosto> JEEB, after attempting a decode, is there something that will tell me the strema has no b-frames
[23:13:40 CET] <JEEB> yes, you can see that (among other things) in the init() function
[23:13:48 CET] <JEEB> also I think it gets updated during decoding from sps parsing
[23:15:40 CET] <rajkosto> it does, but i cant access those private codec vals from api using code
[23:17:23 CET] <JEEB> at this point it sounds better to just check what updates that value and look at adding support for that flag that's in mpeg-2 or mpeg-4 part 2 :P
[23:17:51 CET] <rajkosto> no ill just check if it has b-frames and only if it doesnt insert null frames
[23:17:55 CET] <rajkosto> packets*
[23:19:07 CET] <BtbN> I'm pretty sure randomly sending NULL frames is not supported and can lead to undefined behaviour, including crashes
[23:20:02 CET] <rajkosto> i mean packets, to the decoder, to force a flush and get a frame out
[23:22:10 CET] <BtbN> yes
[23:22:11 CET] <BtbN> https://trac.ffmpeg.org/ticket/6775#comment:14
[23:22:14 CET] <BtbN> it's not supported
[23:22:59 CET] <BtbN> The only time NULL packets are allowed and expected is after EOF to drain the decoder
[23:23:20 CET] <rajkosto> then how do i get frames out that i know are fully decoded but ffmpeg is just keeping from me
[23:23:21 CET] <BtbN> at any other time, the behaviour is undefined
[23:23:59 CET] <BtbN> I'd guess set any low-latency stuff you can find, and turn off threading, as multi-threaded decoding mandates some buffer
[23:24:16 CET] <rajkosto> i think i did
[23:33:19 CET] <rajkosto> JEEB, using the new api, giving it the null avpacket doesnt work anymore, it only works for the first frame :P
[23:33:38 CET] <JEEB> yea, because it's properly resetting the decoder :P
[23:33:45 CET] <BtbN> With the old API it also doesn't work anymore, since it was made a wrapper around the new one
[23:33:50 CET] <JEEB> yea
[23:33:54 CET] <rajkosto> im on some old 3.2 from march
[23:34:02 CET] <rajkosto> BtbN, so what, im supposed to just find another decoder to use ?
[23:34:10 CET] <JEEB> or you request/add the feature you need
[23:34:11 CET] <JEEB> yes
[23:34:33 CET] <JEEB> because you're abusing the API in ways it's not meant to be done so if it breaks unfortunately you get to keep both pieces
[23:34:50 CET] <JEEB> if you really want the "no reordering" mode you will have to request it or make it yourself
[23:35:08 CET] <BtbN> To me this sounds like you want to be a hwaccel inside of lavc.
[23:35:35 CET] <rajkosto> huh
[23:35:52 CET] <BtbN> Those site inside of the decoder, and get the raw data
[23:36:23 CET] <rajkosto> i have no clue, nor is there any documentation on how to use hwaccel modes in ffmpeg btw
[23:36:45 CET] <BtbN> An API that wants decoded frames, but not re-ordered, just makes no sense to me. Why does it want that? And why would a few frames delay hurt it so much?
[23:37:20 CET] <rajkosto> it just leads to hangs after the video is done for my api user, or hang immediately after first frame isnt output
[23:37:45 CET] <BtbN> If this is some weird real-time remote-gaming/desktop thing, you want to use I/P-only anyway, and don't have the problem.
[23:37:55 CET] <rajkosto> nope, decoding video from file
[23:38:09 CET] <rajkosto> it just expects to get a frame back if it gives it enough nals to decode af rame
[23:38:23 CET] <BtbN> "it"?
[23:38:27 CET] <rajkosto> the api user
[23:38:41 CET] <BtbN> That's not how video decoders work and that api is misdesigned then.
[23:38:57 CET] <rajkosto> not mine to change it, it worked fine when it was implemented using the platform's hardware decoder
[23:39:32 CET] <BtbN> Every higher level hardware decoder I ever worked with also does the re-ordering for you
[23:39:44 CET] <BtbN> I feel like your issue is somewhere else, some misunderstanding somewhere.
[23:40:06 CET] <rajkosto> api user sets "single frame decoding mode" to true, api user gives enough nals for a frame, api user doesnt get a frame back, api user hangs
[23:40:39 CET] <BtbN> And what are you supposed to do if you don't have the required references yet? That makes no sense.
[23:41:00 CET] <rajkosto> even when single frame decoding mode isnt true, the first few gpu buffers i return false for, it ends up not giving me enough to finish the video at the end, and since it does a timestamp comparison on the end frame, it hangs at the end
[23:42:03 CET] <rajkosto> well it clearly has the required references for that first use case i explained, since when using the old decode2 api and feeding it null packets after each packet, it works.
[23:55:58 CET] <rajkosto> actually, the first frame im giving it is a keyframe, it cannot depend on any frames, so ffmpeg SHOULD give me it back right away
[23:56:24 CET] <rajkosto> is there a guide on how to disable all the threading and acceleration to get lowest latency ? i might not have done all i can
[23:57:11 CET] <JEEB> threads=1 should be enough (or slice-based threading)
[23:57:18 CET] <JEEB> decoding really isn't too hard
[23:57:30 CET] <rajkosto> 			ffmpeg.ctx->thread_count = 1;
[23:57:44 CET] <JEEB> otherwise the reordering delay might just be globally utilized
[23:57:51 CET] <JEEB> so it doesn't care about the picture type
[23:57:56 CET] <rajkosto> it might just delay by max_b_frames in the SPS always
[23:58:01 CET] <JEEB> yes
[23:58:06 CET] <rajkosto> whereas what i need is frames as soon as possible
[23:59:21 CET] <JEEB> might want to try with a constrained baseline sample with the SPS value being at "no reordering needed"
[23:59:27 CET] <JEEB> and check the decoding with that
[23:59:50 CET] <JEEB> should be relatively simple to generate with -c:v libx264 -profile baseline -t 15 or so
[23:59:53 CET] <JEEB> with the cli
[00:00:00 CET] --- Mon Dec  4 2017