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

[burek]

[02:04:14 CEST] <cpusage> Hi. I'm simply converted h264 videos to h265 videos, but the ffmpeg instance keeps shutting down by itself during the encode
[02:04:24 CEST] <cpusage> any idea why this might be happening?
[02:04:46 CEST] <pink_mist> doesn't it tell you why
[02:05:29 CEST] <cpusage> I'm running it on cmd (win10) via a batch file I made
[02:05:40 CEST] <cpusage> so, the cmd window just shuts off without notice
[02:05:51 CEST] <nicolas17> add 'pause' at the end of your batch file
[02:07:22 CEST] <cpusage> ah, good idea
[02:07:51 CEST] <pink_mist> sometimes I wish there was a ubiquitous 'pause' command on *nix too, rather than having to do a 'read' or suchlike in bash
[02:08:50 CEST] <cpusage> just writing out / copy&pasting the ffmpeg command in cmd should also keep the cmd window open
[02:09:12 CEST] <cpusage> :')  can't believe I didn't think of that
[02:09:22 CEST] <tdr> nohup your command so if it closes who cares?
[02:09:43 CEST] <pink_mist> tdr: uh, how does that help anything?
[02:11:03 CEST] <tdr> or put <ffmpeg commands here>> && do-something-else ... would be the equiv of "wait for it to get done" and something else could be "exit" or "kill -9 -1"
[02:11:45 CEST] <tdr> the "lack of pause" ... its not a lack, its the presence of options.
[02:12:24 CEST] <pink_mist> tdr: his problem was that ffmpeg kept shutting down abnormally without his console window staying open to show him why
[02:12:57 CEST] <tdr> yeah was closing during the encoding, so was it dying?
[02:13:10 CEST] <pink_mist> who knows. presumably.
[02:13:29 CEST] <tdr> or just closing the cmd window .. its winderz... it prob thought it "knew better"
[02:13:40 CEST] <pink_mist> either way, nohup is completely irrlevant, and chaining with && wouldn't work if it didn't exit cleanly
[02:14:04 CEST] <pink_mist> I'm not even sure && works in batch
[02:14:06 CEST] <tdr> yeah but it also wouldn't close due to idle
[02:14:21 CEST] <pink_mist> what
[02:14:24 CEST] <pink_mist> that's not a thing
[02:14:24 CEST] <tdr> since it would imply "wait for result"
[02:14:48 CEST] <nicolas17> what result?
[02:15:25 CEST] <tdr> of whether the command completed or died or whatever, the return value to evaluate to see if it does the && part
[02:16:07 CEST] <nicolas17> still doesn't help you see the last messages before it closes the window
[02:23:21 CEST] <WereCatf> How do I make ffmpeg copy attachments (cover-pictures and whatnot) from input MKV to output MKV? At the moment "ffmpeg -i in.mkv -map 0 -map -0:a:0 -map -0:s:0 -map -0:s:1 -map -0:s:2 -map -0:s:3 -c copy out.mkv" converts those attachments into video-streams, which is not correct
[02:26:30 CEST] <nicolas17> why are you selecting audio and subtitle streams? doesn't -map 0 select all streams in the file already?
[02:26:59 CEST] <WereCatf> I'm excluding several streams
[02:27:22 CEST] <WereCatf> Do notice that they are negative mappings
[02:27:30 CEST] <nicolas17> oh I didn't know the - was to exclude, okay
[02:51:08 CEST] <another> WereCatf: ffmpeg regard cover art as video
[02:51:30 CEST] <another> you can handle it (almost) like any other video stream
[02:53:09 CEST] <WereCatf> That doesn't help me in any way or form. Like I said, ffmpeg changes those to video-tracks when they aren't and so they show up in e.g. VLC as new video-tracks
[02:53:20 CEST] <WereCatf> The point is that I want any attachments to remain attachments
[02:55:02 CEST] <cpusage> hmm... so, it just stops in the middle of a job
[02:55:05 CEST] <nicolas17> what's your goal? just discarding some audio/sub streams and leaving everything else intact? perhaps mkvtoolnix is more suitable than ffmpeg idk
[02:55:09 CEST] <another> what kind of attachment? just coverart? attached jpeg? fonts?
[02:55:19 CEST] <WereCatf> Varying
[02:55:38 CEST] <cpusage> continuing from my previous comment, ffmpeg just stops encoding on it's own without any indications of an error
[02:56:49 CEST] <cpusage> can't seem to find out why
[02:57:59 CEST] <nicolas17> cpusage: could it be running out of memory?
[02:58:01 CEST] <another> WereCatf: see: https://ffmpeg.org/ffmpeg-all.html#Stream-selection and https://ffmpeg.org/ffmpeg-all.html#Stream-specifiers-1
[02:58:23 CEST] <WereCatf> another: as you can see, I am using "-map 0 -c copy"
[02:58:28 CEST] <cpusage> I got 32GB of memory, so should be more than enough :S
[02:58:52 CEST] <another> hold on
[02:59:15 CEST] <furq> WereCatf: https://trac.ffmpeg.org/ticket/4591
[02:59:20 CEST] <furq> so i guess in summary just use mkvmerge
[02:59:44 CEST] <cpusage> nicolas17 My memory usages doesn't go past 15%
[02:59:59 CEST] <WereCatf> I guess I don't have another choice
[03:02:00 CEST] <cpusage> even the ffmpeg command I'm running is bloody simple. just can't understand why it would just stop it's process without indicating any errors
[03:02:15 CEST] <cpusage> ffmpeg -i input.mkv -c:v libx265 -preset slow -crf 18 -x265-params no-info=1 -c:a copy output_H265.mkv
[03:04:58 CEST] <WereCatf> Windows or Linux? If Linux, you could try and see if there's anything in dmesg
[03:21:10 CEST] <cpusage> ugh, this is infuriating
[03:46:39 CEST] <ssamjh> I'm trying to overlay cfm1.png on top of the RTSP feed. cfm1.png is exactly 1920x1080, so it will fit perfectly onto the output. I believe I need to use -filter_complex, but I'm unsure how to do to, and how to send it to my mapping part. Does anyone have some suggestions? Command: https://pastebin.com/raw/eYej41Tw Output: https://pastebin.com/raw/F05dxmYq
[11:28:43 CEST] <fling> Is not there really a trick for dealing with multiple live inputs/outputs?
[11:29:41 CEST] <furq> the trick is don't use ffmpeg because it'll desync and/or die on dropouts
[11:31:18 CEST] <JEEB> fling: depends on your issues. the FFmpeg API lets you do a lot of things but ffmpeg.c is of course just one API client :P
[11:31:54 CEST] <fling> https://www.dacast.com/blog/how-to-broadcast-live-stream-using-ffmpeg/
[11:32:03 CEST] <fling> ^ it looks like it works for other people
[11:32:48 CEST] <JEEB> well, ffmpeg.c mostly works for my use cases (kind of fortunately and unfortunately)
[11:32:51 CEST] <fling> furq: I tried gstreamer but I'm getting fps followed by seconds of 0fps when muxing aac to a live rtmp stream :>
[11:33:19 CEST] <fling> JEEB: I wanted an one-liner, instead of coding in C :>
[11:33:27 CEST] <JEEB> everyone wants a one-liner
[11:33:35 CEST] <JEEB> nto everyone gets bacon
[11:33:49 CEST] <JEEB> do note that I didn't read that article you linked, I'm speaking in generalities :P
[11:34:16 CEST] <JEEB> for example, people didn't want to implement dynamic inputs in ffmpeg.c so you have a lavfi filter that takes in multiple inputs. but it can only back up to a fall-back if one dies
[11:34:19 CEST] <fling> step 3 in article is ->$ ffmpeg -re -f lavfi -i testsrc -c:v libx264 -b:v 1600k -preset ultrafast -b 900k -c:a libfdk_aac -b:a 128k -s 1920x1080 -x264opts keyint=50 -g 25 -pix_fmt yuv420p -f flv "rtmp://p.ep246802.i.akamaientrypoint.net/EntryPoint flashver=FMLE/3.020(compatible;20FMSc/1.0) live=true pubUser=123456 pubPasswd=789123 playpath=dclive_1_1 at 246802"
[11:34:22 CEST] <JEEB> it will not bring that one back up
[11:34:36 CEST] <furq> yeah that's not dealing with live inputs
[11:34:42 CEST] <furq> and only one live output
[11:34:45 CEST] <furq> that's easy
[11:34:57 CEST] <JEEB> yea, although -re can already fail if you have something with discontinuities :)
[11:35:18 CEST] <fling> furq: right, it works bad when I add aac, getting distortions in video
[11:35:23 CEST] <JEEB> (it kind of works as long as your timestamps go forwards in a normal manner)
[11:35:52 CEST] <fling> I'm not even reencoding video, I'm using preencoded h264 stream
[11:36:36 CEST] <JEEB> anyways, for a normal live input you want something not like -re because if you have an actual live input, that will not go over realtime
[11:36:43 CEST] <fling> what is lavfi filter?
[11:36:53 CEST] <JEEB> lavfi is a shorthand for libavfilter
[11:37:01 CEST] <JEEB> the library with all the filters in FFmpeg :P
[11:37:03 CEST] <fling> will it help me?
[11:37:06 CEST] <JEEB> not really
[11:37:07 CEST] <fling> oh ok
[11:37:52 CEST] <fling> maybe I should try muxing with nginx somehow
[11:37:57 CEST] <fling> rtmp -> nginx
[11:38:00 CEST] <JEEB> anyways, if you are just stream copying and getting distortions then you're breaking the data somewhere along the way :P
[11:38:02 CEST] <fling> aac -> nginx
[11:38:06 CEST] <fling> nginx -> rtmp
[11:38:29 CEST] <JEEB> also for the record, I've got bad experiences with RTMP, so if you have a basic HTTP setup I'd rather recommend the HLS writer or something over HTTP post
[11:38:30 CEST] <fling> Yes, I'm breaking it in the muxer, when adding aac to the stream
[11:38:38 CEST] <JEEB> that doesn't make sense :P
[11:38:54 CEST] <JEEB> if you are creating a normal AAC stream into FLV that does not break it
[11:39:00 CEST] <JEEB> unless the receiving part is broken
[11:39:02 CEST] <JEEB> somehow
[11:39:09 CEST] <fling> it does break
[11:39:14 CEST] <fling> It was always this way for me
[11:39:35 CEST] <fling> two live inputs/outputs work just fine
[11:39:46 CEST] <fling> adding one more live input or output breaks the muxer
[11:40:15 CEST] <JEEB> time to post the exact command lines (although it's OK to hide RTMP credentials etc in the output/input URL f.ex.) and the full terminal logs with -v verbose on a pastebin or so
[11:40:18 CEST] <JEEB> and link here
[11:40:38 CEST] <fling> need to find it
[11:40:45 CEST] <JEEB> give an example of two working, and the broken case
[11:40:51 CEST] <fling> tinkered with gstreamer mostly lately
[12:09:49 CEST] <fling> JEEB: ok, this is reproducible
[12:10:14 CEST] <fling> for rtmp first works, second breaks video stream https://bpaste.net/show/LT0X
[12:10:34 CEST] <fling> same issue with pipe output, first works, second breas video -> https://bpaste.net/show/3oUk
[12:10:39 CEST] <fling> absolutely the same way
[12:11:21 CEST] <fling> limiting input framerate to 15 using `v4l2-ctl -c exposure_auto_priority=1 -d /dev/video0` makes the second work too
[12:11:30 CEST] <fling> meaning 30fps might be too much for muxer :>
[12:11:33 CEST] <JEEB> ok, that's two inputs and one output. I thought you were talking about two or three outputs. but sure. this shows the actual parts you're using :P
[12:11:45 CEST] <JEEB> also no, the muxer should not have random frame rate limitations :P
[12:11:57 CEST] <JEEB> now please give a -v verbose log of those working/not working in a similar pastebin
[12:12:05 CEST] Action: fling doing
[12:12:38 CEST] <JEEB> and yea, the threads probably do nothing in there because you've effectivly got no decoding going on
[12:12:59 CEST] <JEEB> you're just receiving *something* from v4l2 and pulse
[12:13:16 CEST] <fling> h264 and raw
[12:13:32 CEST] <fling> should also try without aac
[12:13:47 CEST] <JEEB> I don't think the encoding should have much to do with it at all
[12:14:13 CEST] <JEEB> aac is just the encoder you use with flv because everything else it supports sucks
[12:14:22 CEST] <JEEB> but yea, more comments after there's some logs
[12:15:21 CEST] <JEEB> also I wish all these capture apis could just give you timestamps on a common clock :P
[12:15:35 CEST] <JEEB> so that the API user wouldn't have to guesstimate
[12:32:29 CEST] <fling> JEEB: https://bpaste.net/show/5BS4 https://bpaste.net/show/TQpm
[12:33:26 CEST] <fling> JEEB: first works, second broken, third works
[12:34:36 CEST] <fling> second plays for a second, then stalls for a second with h264 artifacts looking like a missing frame
[12:35:07 CEST] <fling> if I set `-framerate 30` in third it stalls the same way but without artifacts :>
[12:39:35 CEST] <JEEB> > [video4linux2,v4l2 @ 0x556254c45480] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
[12:40:29 CEST] <fling> Where do I position this option properly?
[12:40:51 CEST] <JEEB> it's an input option and specific to the v4l2 module so before that input (and after any other input)
[12:41:26 CEST] <fling> >> after any other input >> what?
[12:41:35 CEST] <JEEB> if you have any input before v4l2 that is :P
[12:42:13 CEST] <JEEB> ffmpeg -i first_input -i second_input output. if the second input is your v4l2 then it goes after first_input but before second_input
[12:42:31 CEST] <fling> ok :>
[12:42:38 CEST] <JEEB> because if the option was before first_input it would get applied to that input
[12:42:49 CEST] <fling> right
[12:43:38 CEST] <fling> `-thread_queue_size 9001 -i $video_input \`
[12:43:42 CEST] <fling> does not really help ^
[12:43:54 CEST] <fling> the corruption looks the same, I remember trying -thread_queue_size in the past
[12:44:15 CEST] <JEEB> well it also seemed to have broken timestamps at least somewhere along the way :P also not sure how big the option should be
[12:45:06 CEST] <JEEB> also there's an option at least for v4l2 to set timestamps in the avdevice
[12:45:14 CEST] <JEEB> default seems to be "utilize what you get from kernel"
[12:45:54 CEST] <JEEB> just because I don't know if `-fflags +genpts` is exactly optimal :P
[12:46:13 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=446a243cf8b7f9070ab57df1c728031b703c1f13;hb=HEAD#l1101
[12:46:17 CEST] <JEEB> the options in the v4l2 module
[12:46:24 CEST] <fling> setting it to 1000000 makes no difference, setting it to 1000000000 only works for first, triggering conversion failed for second and third :D
[12:46:49 CEST] <JEEB> ah, thread queue size is not even a v4l2 option
[12:47:04 CEST] <JEEB> ah it's an ffmpeg.c option
[12:47:15 CEST] <JEEB> fftools/ffmpeg.h:    int thread_queue_size;      /* maximum number of queued packets */
[12:47:26 CEST] <JEEB> so it's some internal queue within ffmpeg.c
[12:47:54 CEST] <JEEB> fling: I would possibly recommend checking the output with -debug_ts, it should show you at which point ffmpeg.c is pushing which stream's packets through the chain and how
[12:47:58 CEST] <JEEB> and with what kind of timestamps
[12:48:15 CEST] <JEEB> it will barf a lot more stuff of course, but you only need to make the issue happen :P
[12:48:26 CEST] <fling> this is interesting
[12:48:46 CEST] <fling> removing +genpts has some effect
[12:49:06 CEST] <JEEB> genpts is a rather crude thing, I think quite often you don't really need it
[12:49:09 CEST] <fling> without it second looks like third with fps set to 30 so no corruption
[12:49:19 CEST] <fling> but it plays for a second, then stalls for a second
[12:49:53 CEST] <JEEB> anyways, -debug_ts probably worth a look even if it logs a lot
[12:50:09 CEST] <JEEB> it should show when packets are received and handled by ffmpeg.c and what their timestamps are
[12:50:41 CEST] <fling> so I only need to run the second one without +genpts and with -debug_ts right?
[12:51:00 CEST] <JEEB> a failing one with it, sure
[12:51:04 CEST] <fling> ok
[12:51:15 CEST] <JEEB> it will barf a lot since it will output multiple lines for each video/audio frame you get
[12:51:40 CEST] <JEEB> so 2> ffmpeg.log might be worth a pre-emptive stderr redirect
[12:51:41 CEST] <JEEB> :)
[12:52:49 CEST] <JEEB> of course still much less than something like -v debug, which will enable debug logging in all modules xD
[12:53:05 CEST] <JEEB> which is why I usually just use -v verbose, since most of the stuff that gets added there is kind of useful
[13:00:44 CEST] <fling> JEEB: log -> https://ufile.io/s4p25za3
[13:02:20 CEST] <fling> command https://bpaste.net/show/3BgV
[13:02:48 CEST] <JEEB> ok, so whatever is feeding you stuff started with the pts 1417226745970
[13:02:54 CEST] <JEEB> on the v4l2 side
[13:03:53 CEST] <JEEB> which then ffmpeg.c takes as the initial offset, and starts the stream at zero
[13:04:10 CEST] <fling> What can I do?
[13:04:10 CEST] <JEEB> the "demuxer -> " and "demuxer+ffmpeg" lines
[13:04:26 CEST] <JEEB> fling: this is still in the phase of interpreting rather than saying good/bad/whatever :P
[13:04:39 CEST] <fling> Ok
[13:04:51 CEST] <JEEB> ok, your audio starts at 1567853690443172
[13:05:11 CEST] <JEEB> and gets taken as zero
[13:08:45 CEST] <fling> tried to search for `ffmpeg "discard" input pts` on the internets
[13:09:01 CEST] <fling> the first link is http://www.ffmpeg-archive.org/Copy-capturing-h264-input-while-force-rewriting-the-PTS-td4671529.html
[13:09:02 CEST] <JEEB> you don't want that
[13:09:13 CEST] <JEEB> fling: well it seems like your input device is giving incorrect timestamps at the very least in the beginning of the stream. if you see the time going a bit backwards after the initial thing. (see the demuxer+ffmpeg stuff)
[13:09:37 CEST] <JEEB> or well, you might have to do that but I'm mostly trying to make sure you're not just trying to apply random techniques from the internet :P
[13:10:11 CEST] <fling> but this is what I do
[13:10:19 CEST] <fling> if this is really the kernel issue
[13:10:30 CEST] <JEEB> now the question is, why would the v4l2 device give you suddenly backwards timestamps
[13:10:59 CEST] <JEEB> and if there's no good answer to that, you might attempt to check the timestamps/ts AVOption in the v4l2 module
[13:11:12 CEST] <fling> omg https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/video/uvc/uvc_video.c?id=66847ef0#n524
[13:11:57 CEST] <JEEB> basically I linked you the part of the v4l2 module that has the options
[13:12:06 CEST] <JEEB> there's multiple modes for the v4l2 capture module in FFmpeg to poke at timestamps
[13:12:13 CEST] <JEEB> the default seems to be "take what kernel gives you"
[13:12:18 CEST] <JEEB> which sounds sane enough
[13:12:54 CEST] <JEEB> then there's use_libv4l2 which attempts to utilize libv4l2's timestamp functionality on the kernel-returned timestamps
[13:13:01 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=446a243cf8b7f9070ab57df1c728031b703c1f13;hb=HEAD#l1101
[13:13:08 CEST] <JEEB> this is the link to the options, if you missed it
[13:14:57 CEST] <JEEB> now do note that you will probably want your other input to have a similar setup for timestamps, even though ffmpeg.c (by default) will make the first timestamp be the "zero point")
[13:15:29 CEST] <fling> JEEB: how do I set it on the command line actually? this is new for me
[13:15:38 CEST] <JEEB> which?
[13:18:30 CEST] <fling> v4l2 mode to poke at timestamps ^
[13:19:24 CEST] <JEEB> basically you know which module you want to apply the option to, and you add a dash at the beginning to it for ffmpeg.c
[13:19:45 CEST] <JEEB> ffmpeg.c will attempt to pass options as AVOptions to modules one at a time in the matching position if it doesn't know the option itself :P
[13:20:07 CEST] <JEEB> which is a funny proposition if you have an option that has the same name in ffmpeg.c, and then you are attempting to set an AVOption by the same name
[13:20:38 CEST] <fling> I'm not getting anything :D
[13:21:01 CEST] <JEEB> so when you pass an option to ffmpeg.c
[13:21:09 CEST] <JEEB> if it cannot find that named option in itself
[13:21:15 CEST] <JEEB> it will take the initial dash out
[13:21:37 CEST] <JEEB> and pass the option and the value into various modules applicable as an AVOption until it gets taken in by some module
[13:21:55 CEST] <fling> oh
[13:21:56 CEST] <JEEB> for example that input_format you're already passing
[13:22:04 CEST] <JEEB> that's an AVOption for that v4l2 input module
[13:22:11 CEST] <JEEB> you just don't even think about it while using it :P
[13:22:19 CEST] <JEEB> for you it's an option for ffmpeg.c
[13:27:07 CEST] <fling> JEEB: do I need -ts ?
[13:28:16 CEST] <JEEB> no idea: all I can see is that v4l2 is giving you initially  backwards-going timestamps, which is why I noted it might be worth while to attempt something like the use_libv4l2 value there.
[13:29:34 CEST] <pink_mist> fling: tias - try it and see :P
[13:31:12 CEST] <fling> so what would be the command line switch? I really don't understand it
[13:31:33 CEST] <JEEB> the option is defined twice, "timestamps" or "ts"
[13:31:38 CEST] <JEEB> so it has two names
[13:34:19 CEST] <fling> trying passing different values to -ts but see no difference https://bpaste.net/show/eZK0
[13:34:37 CEST] <JEEB> don't use numbers :<
[13:34:44 CEST] <JEEB> it has named parameters that I linked to you after all
[13:34:52 CEST] <JEEB> *values
[13:35:16 CEST] <fling> oh
[13:35:20 CEST] <fling> now I see it
[13:35:46 CEST] <JEEB> also oooh
[13:35:52 CEST] <JEEB> -use_libv4l2 is its own option
[13:35:52 CEST] <JEEB> sorry
[13:36:01 CEST] <JEEB> not another timestamp mode :P
[13:36:33 CEST] <JEEB> so keep away from the ts/timestamps thing, and just do -use_libv4l2 1 (it's a boolean, but 1 should work)
[13:39:07 CEST] <fling> same with -use_libv4l2 1 https://bpaste.net/show/E1qi
[13:39:35 CEST] <JEEB> did you check how the first N timestamps look like?
[13:42:09 CEST] <fling> demuxer -> ist_index:0 type:video next_dts:NOPTS next_dts_time:NOPTS next_pts:NOPTS next_pts_time:NOPTS pkt_pts:1419991608023 pkt_pts_time:1.41999e+06 pkt_dts:1419991608023 pkt_dts_time:1.41999e+06 off:-1419991608023 off_time:-1.41999e+06
[13:42:57 CEST] <JEEB> yea, look up the first N demuxer+ffmpeg things for that input stream
[13:43:29 CEST] <JEEB> if the times seem to go backwards
[13:43:57 CEST] <fling> https://bpaste.net/show/fTIS
[13:44:42 CEST] <JEEB> ok, still goes somewhat backwards :<
[13:45:09 CEST] <JEEB> I mean, that's not the end of the world, but it will create a possibly interesting result
[13:45:40 CEST] <fling> is is the command fine? ->https://bpaste.net/show/PP-R
[13:46:05 CEST] <JEEB> what is your expectation of "fine"?
[13:46:22 CEST] <fling> idk
[13:46:44 CEST] <JEEB> because at the very least you're just defining thread_queue_size twice, of which probably the last one gets picked
[13:47:53 CEST] <JEEB> also as someone who isn't actually running the command or checking anything I have no idea how that actually works for you - keep that in mind
[13:49:37 CEST] <JEEB> fling: btw if you still have issues you can attempt to set both v4l2 and pulse to wallclock. for v4l2 that would be -ts abs and for pulse it'd be -wallclock 1
[13:49:46 CEST] <JEEB> I mean, it *sucks* and you *shouldn't* be doing it
[13:50:19 CEST] <JEEB> but if the timestamps seem to be awry and seem to be the issue (which I have no idea honestly if they are), that /might/ improve it as long as you don't have b-frames or whatever in your input :P
[13:51:03 CEST] <fling> JEEB: same issue https://bpaste.net/show/xP_8
[13:51:21 CEST] <JEEB> what is teh issue at this point?
[13:51:38 CEST] <fling> distorted choppy video as always
[13:51:49 CEST] <fling> plays for a second then artifacts appear
[13:52:30 CEST] <JEEB> that sounds like broken input rather than anything else. are you really sure this works with just the video track?
[13:52:37 CEST] <JEEB> because ffmpeg.c itself doesn't touch those packets
[13:52:41 CEST] <JEEB> esp. if it is OK at first
[13:52:46 CEST] <fling> Yes, works without muxing anything to the h264 stream
[13:54:02 CEST] <JEEB> well at that point it's either the input giving you broken stuff because of different timing of requests (v4l2) or there's some buffer within ffmpeg.c that gets filled and new packets don't get put there. but that should be giving you a loud warning/error if that happens.
[13:54:19 CEST] <JEEB> ffmpeg.c itself does not bork your packets
[13:55:09 CEST] <fling> JEEB: also no issues with non-live output
[13:55:11 CEST] <fling> JEEB: https://bpaste.net/show/5G1i
[13:55:41 CEST] <fling> so replacing pipe with a file also works
[13:56:09 CEST] <JEEB> rtmp is TCP so it could be blocking if the thing you're pushing to is blocking
[13:56:21 CEST] <JEEB> but I'm not sure if ffmpeg.c would block on that or if it's as eparate thread
[13:56:41 CEST] <JEEB> not sure how ffmpeg.c uses the API in my memory :P
[13:57:14 CEST] <fling> Am I out of luck with ffmpeg? Or am I doing it wrong?
[13:57:15 CEST] <JEEB> fling: so if you push to a local FLV file it works? same copy for video and -c:aac -b:a 192k or so for audio?
[13:57:22 CEST] <JEEB> *-c:a aac
[13:57:26 CEST] <fling> I remember trying to fix this three years ago and five years ago too
[13:58:30 CEST] <JEEB> I don't have devices that give me video like that, nor do I have a use case for it right now so unfortunately I can't be testing/debugging it for you :P
[13:59:28 CEST] <JEEB> fling: also if FLV to a local file works, does output to local HLS segments work?
[13:59:40 CEST] <fling> JEEB: sure, any file output works https://bpaste.net/show/xxJP
[13:59:50 CEST] <JEEB> ok
[13:59:58 CEST] <fling> you can test it with three pipes
[14:00:00 CEST] <JEEB> that really sounds like the RTMP TCP transport is what's blocking you
[14:00:03 CEST] <fling> three pipes are also broken
[14:00:19 CEST] <fling> idk what HLS is
[14:00:31 CEST] <JEEB> it's what those CDNs usually output after they ingest RTMP :P
[14:00:45 CEST] <JEEB> since I expect you want to push live stream to something that then publishes HLS/DASH from it
[14:00:50 CEST] <JEEB> which can then be played from a browser
[14:01:01 CEST] <JEEB> (and mobiles)
[14:01:18 CEST] <fling> the only issue with file output is audio slightly out of sync and these warnings https://bpaste.net/show/fXdB
[14:02:02 CEST] <fling> it should be related to timestamps ^
[14:02:11 CEST] <fling> I've seen this with other devices
[14:02:55 CEST] <fling> but file output is broken with three live inputs :P
[14:03:11 CEST] <fling> I can't mux three input streams together into a single file
[14:04:30 CEST] <JEEB> it's never *that* simple
[14:05:26 CEST] <JEEB> fling: and yea it seems like pulse is also going backwards for some strange reason :P
[14:05:30 CEST] <JEEB> or wait that's 0:0
[14:05:33 CEST] <JEEB> that is video :P
[14:05:50 CEST] <JEEB> so yes, A/V desync might be caused by that
[14:06:29 CEST] <fling> it was always exactly _this_ simple to me haha
[14:07:25 CEST] <fling> I was able to use only up to two live inputs outputs, it never worked with three for some reason
[14:07:25 CEST] <JEEB> and now  you can start guesstimating why you at the very least had to add the "live" part there :P
[14:07:51 CEST] <fling> what?
[14:07:59 CEST] <fling> Unfortunately pipes count as live too
[14:08:58 CEST] <JEEB> I'm pretty sure if I make three named pipes and then feed a video file, audio and subtitle file to those, it should output just fine :P
[14:09:02 CEST] <JEEB> into a single matroska file with video, audio and subtitles
[14:09:19 CEST] <JEEB> this is just a guesstimate of course :P
[14:09:49 CEST] <fling> I tried two videos and one sound
[14:10:11 CEST] <fling> So what else could I try here?
[14:10:23 CEST] <fling> Is it possible to somehow drop few initial frames?
[14:10:31 CEST] <fling> together with pts and everything
[14:10:31 CEST] <JEEB> anyways, let's try to keep focused on the two live inputs and output file vs output RTMP
[14:10:44 CEST] <JEEB> since that seems to be the simplest case where you are having issues
[14:10:53 CEST] <JEEB> and on the other side (output to a file) it works
[14:10:53 CEST] <fling> rtmp and pipe works the same
[14:11:03 CEST] <fling> pipe is easier to test because of ffplay
[14:11:22 CEST] <fling> did you noticed ffplay in my examples? :P
[14:11:34 CEST] <JEEB> a pipe is probably limited to how quickly the thing reading the pipe is ingesting it
[14:11:40 CEST] <JEEB> if ffmpeg.c does blocking I/O
[14:11:52 CEST] <fling> should I stop using pipe for testing?
[14:12:15 CEST] <JEEB> pipe by itself is probably fine, like piping into a file or whatever :P
[14:12:24 CEST] <fling> oh
[14:12:27 CEST] <JEEB> anyways, jogging for me to keep myself at least in some way healthy
[14:13:10 CEST] <fling> cya
[14:20:05 CEST] <fling> furq: how do I drop few input frames?
[14:27:49 CEST] <fling> JEEB: artifacts are only at the beginning when reencoding with libx264
[14:28:09 CEST] <fling> right where it is dropping five frames probably
[14:28:10 CEST] <fling> `*** dropping frame 1 from stream 0 at ts -5`
[14:51:29 CEST] <fling> The whole idea was to _not_ reencode :D
[14:53:32 CEST] <fling> Should I use kurokesu instead? :D
[15:07:12 CEST] <fling> Should I try this patch? -> https://patchwork.kernel.org/patch/6874491/
[15:10:43 CEST] <JEEB> sounds reasonable at least seemingly fixing the first timestamp > second timestamp issue?
[15:10:59 CEST] <JEEB> but I still think your issue might be with something blocking your input if you get actual corruption
[15:12:05 CEST] <JEEB> would be probably useful to check how long the calls take and if it seems to block
[15:13:08 CEST] <fling> v4l people say the patch is already merged
[15:13:20 CEST] <JEEB> ok
[15:13:34 CEST] <fling> Also looks like this is a popular known issue with c920 where timestamps go back in time
[15:13:51 CEST] <JEEB> but that might only affect a/v desync, not actual corruption tbh
[15:14:11 CEST] <JEEB> unless the timestamps lead to AVPackets getting dropped from theo utput
[15:14:14 CEST] <JEEB> but it didn't seem to happen
[15:14:36 CEST] <fling> With reencoding I always see the same corruption but only at the beginning.
[15:14:38 CEST] <JEEB> which means that something is blocking long enough that at 30Hz ffmpeg.c is not calling read_packet often enough :P
[15:14:59 CEST] <fling> And sometimes video plays two times slower for few seconds at the beginning
[15:15:22 CEST] <JEEB> fling: yes but that seemed to be because at first some input packets got dropped or otherwise derp'd due to the timestamps as video decoding got into the mix
[15:15:35 CEST] <JEEB> basically I have a feeling that "copying" might be more affected
[15:15:37 CEST] <fling> Right.
[15:15:55 CEST] <JEEB> as in, it skips some extra threads etc
[15:16:07 CEST] <JEEB> might be bullshit but that's how it feels :P
[15:16:15 CEST] <fling> no, it looks like it
[15:16:36 CEST] <JEEB> because that's what the results feel like: works for a while at 30Hz but then something borks - and setting frame rate to 15Hz helps
[15:16:51 CEST] <JEEB> and of course lowering frame rate gives the application more time
[15:17:02 CEST] <JEEB> fling: you might want to rebuild ffmpeg.c with some extra logging with monotonic timestamps
[15:17:09 CEST] <JEEB> to get actual stats
[15:17:48 CEST] <fling> Can't I tell ffmpeg to drop everything in the input until a keyframe?
[15:17:58 CEST] <fling> including pts
[15:18:10 CEST] <JEEB> you can patch that in real quickly but I don't think that's the problem?
[15:18:28 CEST] <JEEB> if the application is just not keeping up fast enough for the input device
[15:19:03 CEST] <fling> but when reencoding everything looks fine after the first keyframe
[15:19:06 CEST] <fling> hmm
[15:19:17 CEST] <JEEB> that's with decoding and re-encoding
[15:19:26 CEST] <JEEB> as I said that probably has different threading and other things
[15:19:30 CEST] <JEEB> so don't mish-mash them too much :P
[15:19:31 CEST] <fling> right
[15:19:33 CEST] <fling> ok
[15:21:01 CEST] <JEEB> I recommend you add logging on going into and out of functions that call av_read_frame (effectively, in the beginning and end of input_thread since you have threads)
[15:21:04 CEST] <JEEB> and then write_packet
[15:21:38 CEST] <JEEB> write_packet has multiple returns so you might have to add logging where that function is called from
[15:22:06 CEST] <JEEB> then when you get entry and exit av_log lines there you should know how long those operations take and all
[15:23:07 CEST] <JEEB> apparently av_gettime_relative might be monotonic depending on the OS
[15:23:44 CEST] <JEEB> seems like on linux it should be?
[15:26:57 CEST] <JEEB> something like av_log(NULL, AV_LOG_VERBOSE, "[%"PRId64"] -> write_packet\n", av_gettime_relative());
[15:27:25 CEST] <JEEB> you can then also add input file/stream indexes to it etc
[15:31:30 CEST] <fling> hmm
[18:46:05 CEST] <fling> JEEB: < pinchartl> with the hw timestamps disabled, the timestamps are generated in software, it shouldn't have anything to do with the hardware
[18:46:09 CEST] <fling> Is it a kernel bug then?
[18:47:48 CEST] <fling> can't it be caused by libv4l somehow?
[18:47:52 CEST] <fling> going to try disabling it
[00:00:00 CEST] --- Sun Sep  8 2019