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

[burek]

[00:04:39 CEST] <killown> the issue is -c copy
[00:06:27 CEST] <killown> not the issue also
[00:06:32 CEST] <killown> still only copying 1.mp4
[00:15:38 CEST] <fahadash> I have 3 clips exact same frame width and height that I am trying to concat using -f concat and -safe 0; The result has the first one sped up. I also see the following in the errors
[00:15:49 CEST] <fahadash> https://www.irccloud.com/pastebin/d2o5Woai/
[00:18:41 CEST] <killown> can anyone help me?
[00:21:00 CEST] <tdr> it pob the syntac of the multiple files, can't yo uuse put them in a list and: ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.mp4 ?
[00:22:04 CEST] <tdr> got that from:  https://trac.ffmpeg.org/wiki/Concatenate
[00:24:14 CEST] <fahadash> That is what I am doing
[00:24:34 CEST] <fahadash> If I don't use -c copy, then I see the actual error message
[00:29:09 CEST] <BtbN> The concat protocol is basically like cat 1.mp4 2.mp4 ... > new.mp4
[00:29:22 CEST] <BtbN> that doesn't work with mp4, it will only "see" the first file
[00:30:24 CEST] <tdr> on that page, it says "If you have MP4 files, these could be losslessly concatenated by first transcoding them to MPEG-2 transport streams. With H.264 video and AAC audio, the following can be used: ...."
[00:30:52 CEST] <BtbN> well, remux, not transcode
[00:31:13 CEST] <tdr> ok i just copied from the page
[00:31:25 CEST] <BtbN> the page is wrong then and should be fixed
[00:37:12 CEST] <killown> fahadash I have the sema issue
[00:37:34 CEST] <killown> tdr, i did what you said and worked
[00:37:44 CEST] <killown> but now some parts is playing very fast
[00:40:31 CEST] <tdr> you mean using them via a list?  they may need remux'd first or whatever.  not sure, but BtbN agreed with that the page said about mp4 (even if the wording was off)
[00:41:19 CEST] <BtbN> If the files are not all 100% identical, you cannot concat them without transcoding
[00:41:45 CEST] <BtbN> you will at least have to transcode the file with the lower framerate
[00:41:50 CEST] <BtbN> to match the other ones
[00:46:17 CEST] <killown> BtbN, can you teach me how to do that?
[00:46:21 CEST] <killown> transcoding
[00:46:53 CEST] <BtbN> not at 1am, no
[00:49:03 CEST] <killown> here is still 19:48
[00:49:05 CEST] <killown> hehehe
[01:03:55 CEST] <Hello71> atomnuker: why wlstream is not work? wlstream 22 drm /dev/dri/renderD128 libx265 bgr0 12 /tmp/a.mkv gives "Failed to get hw device constraints!"
[01:04:11 CEST] <Hello71> I think drm literally doesn't have that function
[01:04:37 CEST] <Hello71> hm... what happens if I hardcode something stupid
[01:05:07 CEST] <Hello71> but why is there no software encoding option
[01:08:57 CEST] <killown> can anyone help me transcode videos to look all the same to later concatenate them?
[01:54:41 CEST] <fahadash> I guess killown and I are looking for same thing
[02:04:17 CEST] <fahadash> killown: I usually rotate 360 degrees and save as a different format and it transcodes for me :)
[02:51:49 CEST] <Hello71> wat
[03:20:37 CEST] <killown> lol
[03:50:42 CEST] <killown> this is my issue http://wpbin.io/1vjs7k
[03:51:05 CEST] <killown> the command is this ffmpeg -y -i 4.mp4 -r 25 -s 300x500 -c:v libx264 -b:v 3M -strict -2 -movflags faststart 4.mp4
[06:00:22 CEST] <fella> killown: Whoops, looks like something went wrong. <-- ( http://wpbin.io/1vjs7k )
[10:10:00 CEST] <GuiToris> hey, can I safely suspend an ffmpeg convertion by ctrl z?
[12:11:08 CEST] <njoyce> Hi, I am building a custom RTMP server and am at the point where I have the separate video/audio streams. I want to use ffmpeg to consume the video stream and figure what the metadata of the video is (width, height, format, etc.) rather than relying on the RTMP client metadata. Can someone point me in the right direction of what ffmpeg api I can use to achieve this?
[12:28:45 CEST] <matteo> which one should I prefer between nasm and yasm?
[13:05:33 CEST] <durandal_1707> matteo: nasm
[13:35:57 CEST] <GuiToris> durandal_1707,  can I safely suspend an ffmpeg convertion by ctrl z or it'll mess it up
[13:35:58 CEST] <GuiToris> ?
[13:39:09 CEST] <durandal_1707> you can suspend it, it should not mess up
[13:39:59 CEST] <GuiToris> thank you durandal_1707
[16:34:10 CEST] <King_DuckZ> hi, my code has problems reading frames from a webm file -> https://alarmpi.no-ip.org/kamokan/cs?colourless
[16:35:26 CEST] <King_DuckZ> one function gets a request for a specific frame, in my case 161, then it converts that number to a pts and tries to find the corresponding frame in the source file but it misses it
[16:40:04 CEST] <w1kl4s> try to search for frame nearest the timestamp
[16:40:18 CEST] <w1kl4s> generally timestamps and exact frame timings don't like each other
[16:40:22 CEST] <w1kl4s> learned it the hard way
[16:40:53 CEST] <JEEB> King_DuckZ: if you need frame exact access use something like ffms2
[16:40:57 CEST] <King_DuckZ> this is the conversion functions I have https://alarmpi.no-ip.org/kamokan/ct?cc
[16:41:47 CEST] <w1kl4s> multiplying frame rate by timestamp won't get you anywhere
[16:41:47 CEST] <King_DuckZ> JEEB: I do, the whole interface works with "give me frame <X>"
[16:41:51 CEST] <King_DuckZ> whats ffms2?
[16:42:08 CEST] <JEEB> https://github.com/FFMS/ffms2
[16:42:15 CEST] <w1kl4s> Avisynth/Vapoursynth black magic
[16:42:15 CEST] <JEEB> it's a frame-exact layer on top of FFmpeg's libraries
[16:42:22 CEST] <JEEB> no need for avs/vapoursynth
[16:42:27 CEST] <JEEB> it's also just a C library
[16:42:29 CEST] <King_DuckZ> w1kl4s: I know, if I don't round up it breaks at frame 2 or 3, if I do round up it breaks at 161
[16:42:50 CEST] <w1kl4s> JEEB yeah but it's still black magic
[16:42:56 CEST] <JEEB> suit yourself
[16:43:11 CEST] <w1kl4s> I still try to install vapoursynth on linux with 2 goddamn plugins and it fails
[16:43:24 CEST] <w1kl4s> i have like 3 lines of code why can't it just work
[16:43:32 CEST] <w1kl4s> reee
[16:44:52 CEST] <w1kl4s> However i think i got an idea what's wrong. If it fail with it again, do you mind if i PM you JEEB?
[16:44:53 CEST] <King_DuckZ> interesting library, I'll give it a try thanks!
[17:16:03 CEST] <King_DuckZ> before I pull in a new dependency, is there any risk in just choosing the closest PTS match?
[17:17:00 CEST] <King_DuckZ> like in my case wanted_pts = 5339, I've got 5338 then 5371, so 5338 would be selected
[20:01:31 CEST] <alexmarkley> so hey, everybody, here's a protip on something that just cost me like 6 hours of hair-tearing-out madness
[20:01:41 CEST] <alexmarkley> if you're breaking up your audio and video decoders into separate threads
[20:01:53 CEST] <alexmarkley> make sure you remember to give them their own AVFrame
[20:01:58 CEST] <JEEB> uhh
[20:02:03 CEST] <alexmarkley> because... otherwise it won't work at all
[20:02:05 CEST] <JEEB> how do you even end up with the same AVFrame?
[20:02:05 CEST] <JEEB> :D
[20:02:12 CEST] <alexmarkley> haha it was, um, an oversight
[20:02:15 CEST] <JEEB> same stack thing?
[20:02:22 CEST] <JEEB> called from multiple threads or something like that?
[20:02:29 CEST] <JEEB> I dunno how stack allocation works technically :P
[20:02:36 CEST] <alexmarkley> i'm working in c++ and i have one big FFmpeg class
[20:03:00 CEST] <alexmarkley> so i was pulling all of the per-decoder state into child classes and splitting the threaded worker in two
[20:03:20 CEST] <alexmarkley> and i looked at `AVFrame *frame;` and i thought, "that's just for the video decoder, right?"
[20:03:22 CEST] <alexmarkley> nope
[20:03:30 CEST] <JEEB> lol
[20:03:32 CEST] <alexmarkley> total brain fart
[20:03:37 CEST] <JEEB> well, it happens
[20:03:44 CEST] <JEEB> also as another protip, I recommend you use the newer APIs
[20:03:51 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[20:03:57 CEST] <alexmarkley> valgrind had zero concerns about this situation
[20:04:03 CEST] <JEEB> :D
[20:04:14 CEST] <JEEB> you at least had valgrind around
[20:04:29 CEST] <alexmarkley> i would have caught it eventually with helgrind but it never actually managed to run out to that point
[20:04:44 CEST] <alexmarkley> so when you say "new APIs" you mean the refcounting frame stuff?
[20:04:55 CEST] <JEEB> the push/pull stuff
[20:04:59 CEST] <JEEB> where the two are separate
[20:05:04 CEST] <JEEB> for decoding and encoding
[20:05:09 CEST] <alexmarkley> yeah i wrote this code pretty recently, so i think i am using that
[20:05:13 CEST] <JEEB> ok, cool
[20:05:19 CEST] <JEEB> I linked to the doxygen page for that API
[20:05:20 CEST] <JEEB> :)
[20:05:49 CEST] <alexmarkley> ex. avcodec_receive_frame() right
[20:05:50 CEST] <alexmarkley> ?
[20:05:56 CEST] <JEEB> yup
[20:06:01 CEST] <alexmarkley> and avcodec_send_packet()
[20:06:05 CEST] <JEEB> yup
[20:06:08 CEST] <alexmarkley> yeah that's how i built this app
[20:06:13 CEST] <JEEB> alrighty then
[20:06:31 CEST] <alexmarkley> https://github.com/markleybros/yer-face
[20:06:47 CEST] <alexmarkley> i'm trying to get it as close to realtime as possible
[20:07:05 CEST] <alexmarkley> (although it also has an offline processing mode for prerecorded video)
[20:07:39 CEST] <alexmarkley> previously i was using an ffmpeg process to multiplex audio/video from hardware into a NUT container which i piped into my program
[20:08:20 CEST] <alexmarkley> but in the quest for lower latency i am eliminating the separate ffmpeg process (and thus all the overhead of a needless muxing / demuxing process, plus whatever buffering unix pipes add)
[20:09:15 CEST] <alexmarkley> the thing that shocks me, about accidentally sharing an AVFrame * between two threads, is that it never managed to corrupt a frame visibly or audibly
[20:09:29 CEST] <alexmarkley> it just got really unstable :-P
[22:43:36 CEST] <ahoo> hey there
[22:43:46 CEST] <ahoo> i'm recording 720P from my webcam
[22:44:12 CEST] <ahoo> i tried using x264 and x265 and both give good compression but very ugly quality (blurry, artifacts)
[22:44:27 CEST] <BtbN> set a lower crf
[22:47:50 CEST] <ahoo> oh yes, that fixes it. thanks bra
[22:51:27 CEST] <ahoo> are there hardware encoders ffmpeg can use and take advantage of?
[22:51:57 CEST] <ahoo> (except CPU/GPU features)
[22:52:05 CEST] <furq> yes but if you care about quality then they're not going to help you
[22:52:30 CEST] <ahoo> no, quality is fine with a lower crf
[22:52:56 CEST] <ahoo> it's just&  my cpu is barely managing to do the job
[22:53:31 CEST] <ahoo> and i thought maybe you can outload the whole compression process into a hardware implementation of h264/5
[22:54:12 CEST] <ahoo> so what features are there? and what piece of hardware is required for it?
[22:54:44 CEST] <ahoo> i remember back in the days when i had a video capturing card that, when recording live tv, there was almost null load on the CPU
[22:54:48 CEST] <furq> nvenc and quicksync are supported
[22:54:58 CEST] <furq> and amd's thing is sort of supported now
[22:55:23 CEST] <BtbN> you don't just put x264 in hardware
[22:55:34 CEST] <BtbN> all the hw encoders have a notably worse quality/bitrate ratio
[23:02:57 CEST] <ChocolateArmpits> ahoo, have you tried using  the -preset parameter to adjust performance?
[23:04:26 CEST] <ahoo> ultrafast is the only preset that doesn't make ffmpeg drop frames continually
[23:05:11 CEST] <ChocolateArmpits> ahoo, drop frames? What are you trying to do?
[23:05:19 CEST] <ChocolateArmpits> oh webcam input
[23:06:14 CEST] <ChocolateArmpits> maybe use some other type of realtime encoding that better fits your hardware, like mpeg2?
[23:06:45 CEST] <ChocolateArmpits> do it at a high enough bitrate and you can transcode to h264 afterwards
[23:06:52 CEST] <ChocolateArmpits> to save some space
[23:07:32 CEST] <BtbN> ultrafast x264 is probably still better than mpeg2 by far
[23:07:52 CEST] <BtbN> But if your CPU is shit enough to not handle 720p at veryfast, might as well use nvenc
[23:08:02 CEST] <iive> maybe x264 have been compiled without simd?
[23:08:18 CEST] <BtbN> Or it's a really bad CPU
[23:08:36 CEST] <ChocolateArmpits> well if his CPU isn't up to the cast then I doubt he has a GPU that can encode anyhow
[23:08:44 CEST] <ChocolateArmpits> task*
[23:13:49 CEST] <ahoo> i3-6100
[23:16:51 CEST] <ahoo> cool. according to wikipedia my GT 1030 supports nvenc.
[23:17:45 CEST] <BtbN> GT1030 only supports nvdec, no encoding.
[00:00:00 CEST] --- Tue Oct  9 2018