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

[burek]

[01:53:18 CET] <net|> ffmpeg -y -i /dev/video1 -c:v libvpx -pix_fmt yuv420p -video_size 1280x720  -quality realtime -speed 5 -threads 2 -crf 10 -segment_time 00:00:40  -c:a libvorbis  -f pulse -ac 2 -i default -f segment -reset_timestamps 1  ./authd/output%01d.webm   when i try this it says default no such process
[01:53:40 CET] <net|> ffmpeg -video_size 1024x768 -framerate 25 -i /dev/video1 -f pulse -ac 2 -i default output.mkv  this works though
[01:56:19 CET] <another> try putting the inputs before any output options
[01:57:25 CET] <another> because the order matters
[02:03:39 CET] <furq> some of those are input options
[02:03:50 CET] <furq> -video_size needs to be before -i /dev/video1 for starters
[03:28:12 CET] <net|> furq i found that on https://trac.ffmpeg.org/wiki/Capture/Desktop
[03:31:25 CET] <furq> yeah that one is fine
[03:31:28 CET] <furq> the other command you posted is all wrong
[03:32:17 CET] <furq> ffmpeg [input1 options] -i input1 [input2 options] -i input2 [output1 options] output1 [output2 options] output2
[03:32:20 CET] <furq> etc
[04:11:53 CET] <net|> ffmpeg -y -i /dev/video0 -c:v libvpx -crf 10 -c:a libvorbis -f pulse -ac 2 -i default -fs 1M output.webm   says same thing here default no such process
[05:03:06 CET] <another> net|: you're command line is still wrong. see furq's comment above
[05:07:04 CET] <another> ffmpeg -i /dev/video0 -f pulse -ac 2 -i default -c:v .... -c:a ... output.webm
[05:23:43 CET] <net|> that worked good, its a little choppy but i might be able to do something with it
[16:24:42 CET] <intrac> is there a way to get ffmpeg to quit if it doesn't receive any more data over an rtsp stream in a given timeframe?
[16:25:13 CET] <intrac> (but the connection may remain open)
[16:26:25 CET] <JEEB> I think RTSP goes down towards UDP or TCP, so you'd have to check if the I/O timeout goes towards that. TCP I think has a timeout by default? UDP has a value of zero set by default, which maens it will just sit there even if it doesn't get any bits in
[16:29:26 CET] <intrac> I'm using the -rtsp_transport tcp flag, so I don't know if that changes anything.
[16:29:50 CET] <intrac> I'll need to get wireshark running and see what's actually going on.
[16:32:09 CET] <intrac> I've just noticed there's a stimeout 'Set socket TCP I/O timeout in microseconds.'
[16:32:13 CET] <intrac> will give that a try
[17:08:40 CET] <faLUCE> is there a way to make ffplay to NOT sync audio and video ?
[17:16:46 CET] <kepstin> faLUCE: why do you want to do that?
[17:18:05 CET] <kepstin> i mean, if you really want to desync your audio and video, you could always throw a setpts filter in there to offset one of the streams :)
[17:18:30 CET] <faLUCE> kepstin: I want to display audio + video frames got with udp as soon as they arrive
[17:18:50 CET] <kepstin> ok, so that's a different thing from synced audio and video
[17:19:07 CET] <faLUCE> kepstin: in fact I asked about ffplay....
[17:19:09 CET] <faLUCE> not ffmpeg...
[17:19:15 CET] <kepstin> i assume you still want the audio and video to be matched up, you just want them to play at the speed when packets arrive?
[17:19:21 CET] <faLUCE> kepstin: yes
[17:19:21 CET] <kepstin> ffplay can use filters.
[17:20:05 CET] <faLUCE> kepstin: so do I have to use the setpts filter for ffplay too?
[17:20:05 CET] <kepstin> faLUCE: ok, there is an ffplay option to cause it to play inputs at the speed they're received. Use "-sync ext"
[17:20:25 CET] <kepstin> faLUCE: no, why would you do that? that would cause your audio and video not to be synced.
[17:20:52 CET] <aruns> Hi, is it possible to remove a solid background from an MP4 so that it is transparent?
[17:21:22 CET] <faLUCE> kepstin: I don't want to play inputs at the speed they're received... I want that audio and video must be indipendent
[17:21:34 CET] <faLUCE> so that I can play as soon as they arrive
[17:21:50 CET] <kepstin> faLUCE: ffplay does not support that. Run two separate players or use a different player or write a player yourself.
[17:22:16 CET] <kepstin> faLUCE: ffplay does support playing inputs at the speed they arrive, but keeps audio and video aligned according to relative timestamps.
[17:22:57 CET] <faLUCE> kepstin: I thought there was a way to avoid that... with gstreamer I could made two indipendent subpipes from the same source
[17:23:14 CET] <kepstin> faLUCE: sure, but ffplay is a simple demo player not intended for any production use
[17:23:43 CET] <kepstin> faLUCE: and this is a weird circumstance to start with, so general players won't do it :/
[17:23:47 CET] <faLUCE> kepstin: I see... unfortunately other players don't seem to support that
[17:24:00 CET] <faLUCE> kepstin: yes... that's the problem :-(
[17:24:00 CET] <kepstin> players put a lot of effort into making sure the audio and video *are* in sync
[17:24:42 CET] <kepstin> aruns: https://www.ffmpeg.org/ffmpeg-filters.html#colorkey
[17:25:20 CET] <kepstin> aruns: note that very few video codecs can save transparent video, so this is mostly useful if you're doing overlays within a single ffmpeg command.
[17:25:27 CET] <faLUCE> kepstin: ok, I could arrange to play two indipendent streams with two ffplay instances. For audio, I don't have any buffer with -fflags nobuffer, but for video it seems that I still have some buffer even with that option
[17:26:13 CET] <kepstin> faLUCE: check your encoder settings - if you're using b-frames then the decoder needs a reorder buffer?
[17:26:15 CET] <faLUCE> (but I could be wrong, let me check again)
[17:26:27 CET] <JEEB> slice threads should take care of decoder delay unless there's b-frames
[17:26:28 CET] <faLUCE> kepstin: I set b-frames to 0
[17:26:32 CET] <kepstin> faLUCE: also note that ffplay is kinda iffy on buffer configuration.
[17:26:39 CET] <faLUCE> let me check, I could be wrong
[17:26:53 CET] <JEEB> as opposed to frame threads which are faster but incur latency
[17:27:01 CET] <JEEB> (and thus default)
[17:31:03 CET] <faLUCE> kepstin: just checked. I set  max_b_frames=0, but ffprobe shows that video packets are collected with some delay. I don't have that delay with audio packets
[17:31:18 CET] <faLUCE> I don't know if it's a udp buffer size
[20:51:00 CET] <retal> faLUCE, hi
[20:51:50 CET] <retal> finally i installed cuda from scatch and compile with --enable-cuda-nvcc
[20:53:04 CET] <retal> but didnt found how to use nvcc for resizing
[20:56:20 CET] <BtbN> scale_cuda should be pretty selfexplanatory
[21:03:36 CET] <retal> BtbN, tryng -vf scale_cuda=1920:1080 , but recieve error
[21:31:25 CET] <retal> Guys, how to use cuda scale ?
[21:31:53 CET] <retal> my ffmpeg compiled with cuda-nvcc
[21:48:37 CET] <BtbN> With the lack of information, it pretty much boils down to "by using it correctly"
[22:04:12 CET] <retal> BtbN, thank you for help
[22:07:15 CET] <kepstin> retal: sometimes when you read errors, they'll tell you about what's going wrong.
[23:02:54 CET] <faLUCE> is it possible to force the input format of ffplay to mpegts + h264, so it doesn't have to probe it?
[23:03:38 CET] <faLUCE> there are lot of options while grepping "format", so I don't understand which one to use
[23:09:24 CET] <DHE> I'm going to guess no. while you can use '-f mpegts' I don't think it'll speed it up that much when avformat's input detection fires anyway and wants to read enough audio and video to produce one of those info screens you normally see in ffmpeg/ffprobe output
[23:09:25 CET] <faLUCE> I tried with  "ffplay -fflags nobuffer -f mpegts -codec h264 "   <--- format is accepted but the "-codec h264" is not recognized
[23:10:02 CET] <faLUCE> DHE: the problem is that with probe_info I have one frame latency
[23:10:11 CET] <faLUCE> (for h264)
[23:10:17 CET] <faLUCE> I wonder if is there a way to avoid that
[23:12:12 CET] <DHE> wouldn't rely on it for mpegts. the PAT & PMT only come periodically, so if you're joining a live stream you may have playable content but no codec info yet. not sure how the demuxer handles that...
[23:53:56 CET] <faLUCE> DHE: thnks
[23:54:37 CET] <faLUCE> well, I'm seeing that avformat_open_input() (demuxing) buffers input data and doesn't return immediatly. Is there away to avoid that?
[23:55:24 CET] <faLUCE> at least, is there a way to flush the buffer?
[23:55:42 CET] <faLUCE> (without allocating a custom aviocontext)
[00:00:00 CET] --- Thu Mar 28 2019