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

[burek]

[00:00:01 CET] <darrel12> Can anyone tell me why is is that when I try to make an rtp connection with ffmpeg to a remote server using port 1234 for example, netstat says that the port being used for the process is like 55590.
[00:01:41 CET] <kepstin> darrel12: there's two ports involved in any connection - the one on the local side, and the one on the remote side. Unless you specify otherwise, apps will allocate a random local high port for the local side when making a connection
[00:03:34 CET] <kepstin> so the packets being sent will say "from port 55590" and "to port 1234" if you look at them in wireshark or so
[00:04:03 CET] <darrel12> kepstin:
[00:04:03 CET] <darrel12> udp        0      0 0.0.0.0:53313           0.0.0.0:*                           6565/ffmpeg
[00:04:04 CET] <darrel12> udp        0      0 0.0.0.0:53314           0.0.0.0:*                           6565/ffmpeg
[00:04:04 CET] <darrel12> It doesn't specify the port or the actual IP. If I'm using rtp://138.9.8.254:1234 in the ffmpeg command, where would the local port be placed on here? before the ip?
[00:04:56 CET] <kepstin> darrel12: if you read https://ffmpeg.org/ffmpeg-protocols.html#rtp it tells you how to set the local port number
[00:05:37 CET] <kepstin> setting localrtpport should be sufficient, the rtcp ports default to rtp port + 1, which is normal and expected
[00:06:14 CET] <darrel12> thanks. Might you know why I can use netcat to make a udp connection between this machine and the server, but ffmpeg either isn't transmitting, or ffplay isn't intercepting it? I know that
[00:06:37 CET] <darrel12> that's sort of vague, I can supply more detail if you need it, like the whole commands
[00:06:56 CET] <kepstin> darrel12: hard to say, it would be helpful if you can pastebin the commands and output of both sides
[00:07:24 CET] <darrel12> ok thanks, I'll post that here in just a little bit
[00:17:09 CET] <darrel12> kepstin: Here's the pastebin with my commands. I stopped doing the method on the bottom for the reason stated there.
[00:17:40 CET] <Soni> how do I turn ogg into wav with ffmpeg?
[00:17:55 CET] <kepstin> Soni: "ffmpeg -i file.ogg file.wav"
[00:18:08 CET] <kepstin> that's literally the easiest possible thing to do with ffmpeg :/
[00:18:36 CET] <Soni> I haven't used ffmpeg in ages, I'm rusty
[00:19:06 CET] <kepstin> darrel12: keep in mind that getting rtp stuff right with the command line can be rather tricky - it's often better to use a file containing sdp to get everything working
[00:19:32 CET] <kepstin> (ffmpeg will print some sdp when you use rtp output, to help get you started)
[00:20:04 CET] <kepstin> it's often enough to start ffmpeg sending rtp, then save the sdp to a file, then do 'ffplay file.sdp', I think
[00:23:13 CET] <darrel12> kepstin: so I actually did that once, I started the rtp stream, copied everything after "SDP:", pasted it into a notepad and saved as a .sdp. I then opened it using ffplay on the opposite machine and had the same results - ffplay sits on 'nan'.
[00:23:13 CET] <darrel12> The SDP info if it helps, maybe it's missing something?:
[00:23:13 CET] <darrel12> v=0
[00:23:13 CET] <darrel12> o=- 0 0 IN IP4 127.0.0.1
[00:23:13 CET] <darrel12> s=Valse sentimentale (Violin and Piano)
[00:23:14 CET] <darrel12> c=IN IP4 138.9.8.254
[00:23:14 CET] <darrel12> t=0 0
[00:23:15 CET] <darrel12> a=tool:libavformat 56.40.101
[00:23:15 CET] <darrel12> m=audio 1234 RTP/AVP 14
[00:23:35 CET] <darrel12> shit
[00:23:44 CET] <darrel12> oh well, that's not my ip
[02:02:36 CET] <slalom_> anybody know how to ignore a Data streamtype when transcoding a file?
[02:03:15 CET] <slalom_> it says it's steram 0:2 but when i try to negatively map it or do anything with it says 0:2:0 and 0:2 match no streams
[02:03:22 CET] <slalom_> i want to remove it entirely
[02:03:31 CET] <slalom_> there's also no -dn
[02:05:52 CET] <DHE> well, you can just map the streams you DO want... often just -map 0:v and 0:a is sufficient...
[02:08:11 CET] <thebombzen> slalom_: try -map 0:v -map 0:a
[02:08:27 CET] <slalom_> thanks ill just try that
[02:08:31 CET] <thebombzen> but if 0:0 is video, 0:1 is audio, and 0:2 is data, then doing -map -0:2 should work
[02:08:38 CET] <thebombzen> if not then it's probably a bug
[02:08:45 CET] <slalom_> yeah i first tried -map -0:2
[02:08:47 CET] <thebombzen> what happens with you do ffmpeg -i input
[02:09:03 CET] <thebombzen> can you paste that output?
[02:09:16 CET] <slalom_> it shows Stream #0:2(eng) : Data: none with some metadata
[02:09:44 CET] <slalom_> https://gist.github.com/anonymous/0fc367742dc55cd461cb1471443187eb
[02:10:03 CET] <thebombzen> can you paste the entire output of: ffmpeg -i input -map -0:2 -c copy -f null -
[02:11:06 CET] <slalom_> https://gist.github.com/anonymous/dfbe45ae9ff4ef95546a9418fbd6727a
[02:13:58 CET] <thebombzen> ah I see
[02:14:10 CET] <thebombzen> I think that ffmpeg by default grabs the first video, subtitle, and audio stream it finds
[02:14:18 CET] <thebombzen> and nothing else
[02:14:23 CET] <thebombzen> so it's already not going to map the data stream
[02:14:25 CET] <thebombzen> unless you tell it to
[02:14:38 CET] <thebombzen> see what happens if you don't tell it anything to map
[02:29:10 CET] <slalom_> it does map it
[02:36:14 CET] <slalom_> the output file has the 0:2 data stream in it still, even with just -map 0:v -map 0:a.. and without mapping anything
[03:20:58 CET] <xtina> hey guys. i have the following command, where i specify 750kbps video bitrate and 15 FPS, but I'm generally getting 14 FPS and 850 KBPS bitrate
[03:21:02 CET] <xtina> and 0.9x speed
[03:21:04 CET] <xtina> what does that mean?
[03:21:28 CET] <xtina> cmd: http://vpaste.net/q19sk
[03:23:08 CET] <xtina> (FYI i specified the video bitrate in my raspivid command. i'm feeding that into ffmpeg, which reports a higher bitrate and lower FPS than I specified in raspivid)
[03:24:28 CET] <xtina> am i supposed to also set the ffmpeg bitrate via -b:v?
[03:31:34 CET] <DHE> xtina: it means that ffmpeg is running at not-quite-realtime speed
[03:33:23 CET] <xtina> DHE: i see. so if i set a higher video bitrate and resolution, and FFMPEG reports that it is hitting the target bitrate but is at 0.5x speed and half the target FPS
[03:33:35 CET] <xtina> what does that mean? My system is not powerful enough? Or my internet is too slow?
[03:33:57 CET] <xtina> My internet upload speed is 5Mbps
[03:34:04 CET] <xtina> but when I specify a video bitrate of 1Mbps or above,
[03:34:12 CET] <xtina> I can never hit 1x speed or my target FPS
[03:34:53 CET] <DHE> well I see you're grabbing raw data from a capture device for processing. ffmpeg probably needs very little CPU. so I would assume it's a connection problem
[03:35:20 CET] <DHE> if all goes well it should approach 1.0x
[03:35:27 CET] <xtina> my CPU usage is <20%
[03:35:36 CET] <xtina> hmm, but if my upload speed is 5Mbps, why is 1Mbps a problem for ffmpeg?
[03:35:59 CET] <xtina> is that normal?
[03:36:15 CET] <xtina> that i can only hit 20% of my max upload speed?
[03:36:45 CET] <DHE> lack of information prevents me from offering any suggestions at this time
[03:37:35 CET] <xtina> hmm, gotcha. i could share my debug level ffmpeg log if that helps?
[03:45:19 CET] <xtina> DHE: what confuses me is that if I specify 1Mbps upload rate, ffmpeg *can* hit it, but then the FPS and speed are 2/3rd the desired values
[03:45:40 CET] <xtina> does it still sound like a connectivity issue if Ffmpeg does hit my target bitrate but has to sacrifice FPS?
[03:46:12 CET] <xtina> i don't understand what is *really* happening when the target bitrate is hit but FPS target is missed and speed <1.0x
[03:55:17 CET] <thebombzen> what's the most accurate motion prediction that -vf minterpolate has?
[03:55:31 CET] <thebombzen> is it "exhaustive search algorithm"
[04:04:06 CET] <xtina> does anyone know what it means when Ffmpeg hits my target bitrate but speed is 0.7x and FPS is 2/3 of my specified 15 FPS?
[04:51:50 CET] <darrel12> where would I find the logs for this channel?
[04:53:59 CET] <xtina> darrel12: http://ffmpeg.gusari.org/irclogs/2017/02/17/ffmpeg.log.20170217
[04:54:27 CET] <darrel12> xtina: thanks a bunch
[05:02:03 CET] <ROMaster2> When ffmpeg concats ts files, are the video and audio losslessly preserved, or does it transcode? I keep seeing it "Fixing malformated aac bitstream in ... "
[05:11:43 CET] <thebombzen> ROMaster2: well you can actually concatenate ts files with "cat"
[05:12:03 CET] <thebombzen> but remuxing them is generally not possible
[05:12:24 CET] <thebombzen> typically, you only want to do this if you're going to transcode anyway
[05:13:28 CET] <ROMaster2> In most cases, as basic "copy /B *.ts output.ts" works fine, but on the occasion it corrupts the output file.
[05:13:58 CET] <thebombzen> !
[05:14:14 CET] <thebombzen> (also believe you mean: type *.ts >output.ts)
[05:14:33 CET] <thebombzen> copy just copies files
[05:14:49 CET] <ROMaster2> oh, good to know
[05:15:00 CET] <thebombzen> "type" is MS's bad version of "cat"
[05:15:10 CET] <thebombzen> it does the same thing but has the awkward issue of actually printing the filenames to stderr
[05:15:13 CET] <thebombzen> which is extremely pointless
[05:15:30 CET] <thebombzen> most MS batch stuff does that. they print what they're doing to stderr
[05:15:45 CET] <thebombzen> which you know what they're doing because you just told it to do it
[05:16:01 CET] <ROMaster2> for the most part
[05:16:26 CET] <thebombzen> yea, but with unix tools, if you want it to do it, you just make it verbose: cp -v tells you it copied it, but cp doesn't
[05:16:47 CET] <thebombzen> because if you run "cp A B" it'll copy A -> B and you can assume it's successful unless it prints an error message
[05:17:08 CET] <thebombzen> and if you run "cp -v A B" it'll tell you that it's copying A -> B, and then it'll be successfull unless it prints an error message
[05:17:28 CET] <ROMaster2> I'm under the impression ts to mp4 can't be done losslessly. Does ts to ts or mkv preserve the audio?
[05:17:28 CET] <thebombzen> in general you only want the verbose behavior if you're running a script, in which case it shouldn't be the default behavior
[05:17:47 CET] <thebombzen> well .ts to mp4 can be done as long as you can streamcopy. however, there's no guarantee that you can do that
[05:18:02 CET] <thebombzen> for example, if the mpegts file is the concatenation of two other ones, there's a chance you can't do it.
[05:18:11 CET] <thebombzen> if the mpegts file is not the result of a concatenation, then you usually can.
[05:18:29 CET] <thebombzen> matroska is not actually concatenation friendly
[05:18:41 CET] <thebombzen> but that means that you can generally remux matroska -> mp4
[05:19:00 CET] <thebombzen> if you're talking about "lossless" it's better to say "stream copy"
[05:19:21 CET] <thebombzen> because you could always transcode to a lossless video codec (like lossless H.264) and that will be "lossless" but it's still transcoding
[05:19:33 CET] <thebombzen> so you're not looking for "lossless conversion" you're looking for "without transcoding"
[05:20:14 CET] <ROMaster2> Well yeah, that's generally what implies so I went with that
[05:20:41 CET] <ROMaster2> In most cases where ffmpeg said the audio was malformed, a binary merge works just fine, unless that's just MPC-HC fixing it on the fly.
[05:21:02 CET] <ROMaster2> Wondering why that is
[05:21:12 CET] <thebombzen> it's possible that it was actually corrupt, and MPC-HC just refused to report the warning
[05:21:29 CET] <thebombzen> just because it didn't print an error message doesn't mean that it didn't perform the same sort of fix that FFmpeg did
[05:23:23 CET] <ROMaster2> Hard to say. Nearly all the ts files I concat are CBR which may be a factor.
[05:23:49 CET] <ROMaster2> Looking for error supressing settings in MPC-HC
[05:30:31 CET] <ROMaster2> So 'malformed' audio will transcode the audio?
[05:31:01 CET] <thebombzen> idk
[05:44:58 CET] <ROMaster2> I did a sample check between the original mp4 OBS made and a the online vod that uses ts and it came out identical.
[05:45:28 CET] <ROMaster2> I guess it just realigned it or something?
[05:56:26 CET] <ROMaster2> I guess in the long run I shouldn't worry about it this much; I'm just a stickler for unnecessary transcoding.
[06:01:36 CET] <ROMaster2> thanks for the help
[06:04:33 CET] <thebombzen> I'd record to matroska (mkv) with OBS
[06:04:41 CET] <thebombzen> that way if OBS crashes, the file isn't corrupted
[06:05:01 CET] <thebombzen> or mpegts, or flv, or any streamable format really
[06:05:04 CET] <thebombzen> but matroska is best
[06:05:14 CET] <ROMaster2> good idea, cheers
[06:33:34 CET] <thebombzen> is there true VBR with libopus?
[06:33:47 CET] <thebombzen> with libvorbis I can do -q:a 4, but is there an equivalent for libopus?
[06:35:48 CET] <xtina> hey all. what does it mean if my FFMPEG is running at <1.0x speed and less than my target FPS?
[06:36:05 CET] <xtina> my CPU is at 20% and I'm using 1Mbps upload bitrate. My wifi's max upload speed is 5Mbps
[06:45:40 CET] <thebombzen> so those two are the same thing
[06:46:00 CET] <thebombzen> <1.0x speed means it's not encoding in realtime
[06:46:12 CET] <thebombzen> which is the same thing as it's outputting fewer frames per second than the target fps
[06:46:29 CET] <thebombzen> what's the speed?
[06:46:36 CET] <thebombzen> cause if it's like 0.99, don't worry abou tit
[06:47:02 CET] <thebombzen> if it's like 0.99 it's probably just some rounding error stuff
[06:47:18 CET] <thebombzen> but xtina can you paste your full ffmpeg command and output?
[06:47:35 CET] <xtina> thebombzen: it's like 0.6x
[06:48:09 CET] <thebombzen> can you paste your full ffmpeg command and output?
[06:48:17 CET] <xtina> my command: http://vpaste.net/c94f5
[06:49:04 CET] <xtina> my output: http://vpaste.net/TF4Ex
[06:59:05 CET] <xtina> if i don't specify height, width, or bitrate at *all*
[06:59:13 CET] <xtina> then my ffmpeg bitrate shows at 5Mbps (which is my max internet upload speed)
[06:59:24 CET] <xtina> but my ffmpeg speed is around 0.6X
[06:59:40 CET] <xtina> (this is with ffmpeg deciding its own bitrate at 1080P, i suppose)
[06:59:46 CET] <xtina> and i've specified 10FPS
[08:44:46 CET] <layback> this might be a bit OT and belong somewhere els, but i'm running out of leads to follow to this problem. i'm using ffmpeg to convert h264 mp4 to webm (WITH SOUND). and it is all playing on desktop, but on iphone on safari and chrome, there is no sound. does anyone have ANY idea of what this could be or any leads that I might follow to find the issue?
[08:44:52 CET] <layback> command is: ffmpeg -i in.mp4 -filter:v scale=1024:-1 -b:v 1M -c:a libvorbis -c:v libvpx out.webm
[09:23:45 CET] <darrel12> With the following: rtsp://localhost:8888/live.sdp
[09:23:45 CET] <darrel12> Where is the live.sdp file supposed to be on an Ubuntu machine?
[10:07:07 CET] <thebombzen> layback: iPhones don't support vorbis audio
[10:09:54 CET] <thebombzen> xtina: perhaps this is why? :P
[10:10:33 CET] <thebombzen> you have "-fps 10 -o /tmp/temp_video.h264" and "-framerate 15 -i /tmp/temp_video.h264"
[10:11:03 CET] <thebombzen> oh they left
[10:11:04 CET] <thebombzen> figures.
[10:50:29 CET] <realies> hi, I've recorded a prores mov file, but it doesn't play in anything (vlc, quicktime) else other than ffplay
[10:50:48 CET] <realies> when I try and probe it I get [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fddda001000] Detected moov in a free atom.
[12:12:31 CET] <conseal> hmmm, why is it that ffmpeg refuse to read my "-input_format mjpeg" and instead fetches rawvideo from my input?
[12:12:45 CET] <conseal> I'm using a Logitech C920 webcam
[12:13:24 CET] <furq> -c:v mjpeg
[12:15:08 CET] <conseal> furq: I just realised that my 10 fps problem from yesterday is because ffmpeg is being fed rawvideo, and the USB2 bus doesnt have the juice to spit more than 10 fps to the RPI3.
[12:15:16 CET] <furq> oh right
[12:15:18 CET] <furq> yeah that'd do it
[12:17:48 CET] <conseal> after changing the -input_format, I'm recieving the correct input, but I an old friend returned
[12:17:51 CET] <conseal> [swscaler @ 0x1f10af0] deprecated pixel format used, make sure you did set range correctly
[12:17:58 CET] <conseal> I also get loads of:
[12:17:59 CET] <conseal> DTS -182142955646, next:1030791 st:0 invalid dropping
[12:17:59 CET] <conseal> PTS -182142955646, next:1030791 invalid dropping st:0
[12:17:59 CET] <conseal> DTS -182142955646, next:1101478 st:0 invalid dropping
[12:17:59 CET] <conseal> PTS -182142955646, next:1101478 invalid dropping st:0
[12:18:42 CET] <conseal> Input #1, video4linux2,v4l2, from '/dev/video0':
[12:18:43 CET] <conseal>   Duration: N/A, start: 182142.955646, bitrate: N/A
[12:18:43 CET] <conseal>     Stream #1:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
[12:31:23 CET] <conseal> This is what I'm doing atm: "ffmpeg -f lavfi -i anullsrc -f v4l2 -c:v mjpeg -s 1280x720 -thread_queue_size 1024 -i /dev/video0 -b:v 20M -codec:v h264_omx -acodec aac -ab 128k -g 60 -f flv rtmp://a.rtmp.youtube.com/live2/xxxxxxxxxxxx"
[12:40:12 CET] <conseal> this is driving me crazy, and I feel like its just a stupid thing that breaks it
[12:44:29 CET] <xtina> hey guys! i'm trying to understand some basic stuff about how bitrate/FPS work for ffmpeg vid streaming
[12:44:55 CET] <xtina> i'm streaming at 1920x1080P, 10FPS. letting raspivid and ffmpeg choose the appropriate bitrate
[12:45:10 CET] <xtina> raspivid/ffmpeg choose 8Mbps, but the stream is going at 0.1x speed and 1FPS
[12:45:28 CET] <xtina> i've read that at 1080P, and 25FPS, the recommended bitrate is 8Mbps: https://support.google.com/youtube/answer/1722171?hl=en
[12:45:37 CET] <xtina> so if I'm going at 1080P and 8Mbps, why am I only getting 1FPS?
[12:46:08 CET] <xtina> here's my full command: http://vpaste.net/PIYYz
[12:46:15 CET] <xtina> hopefully my question is clear :P
[12:47:33 CET] <CorvusCorax> Hi. I have an avi file with ffvhuff encoded frames. There are large gaps in the recording (there might be several thousand frames missing so after frame 101 might come frame 15739) I want to extract all the frames that are actually in the source video as images.  I tried "ffmpeg -i in.avi out.%08d.tiff" but that creates thousands of duplicate images for non-existant frames in the input
[12:47:46 CET] <xtina> also, if i don't specify FPS OR bitrate, ffmpeg chooses 15Mbps bitrate, 0.05x speed, 1-2 FPS. wtf?
[12:48:28 CET] <xtina> why am i getting 1FPS when I stream at 1080 and 8Mbps? shouldn't i be sending like 25 fps if I'm sending that bitrate at 1080p?
[12:52:24 CET] <CorvusCorax> It looks like I can prevent the creation of duplicates with "-vsync 0", but then the frame IDs don't match but get renumbered from 0
[12:53:37 CET] <xtina> if ffmpeg reports 8Mbps but 0.1x speed, does that mean it's actually doing 8Mbps or only 800kbps?
[13:00:00 CET] <BtbN> if at all it'd be 80Mbps, and no.
[13:02:45 CET] <DHE> it means that 1 second of video will be 8 megabits of data (on average) but it takes about 10 seconds to process that
[13:04:00 CET] <xtina> oh, thanks guys!
[13:04:11 CET] <xtina> so it's pushing out 1 second of video every 10 seconds, DHE?
[13:04:32 CET] <DHE> roughly yeah
[13:04:37 CET] <xtina> it's taking 10 seconds to process 1 second of video? does that means my bottleneck is processing, not wifi?
[13:04:43 CET] <xtina> my CPU usage is 20%, so i'm not maxed out there...
[13:04:53 CET] <CorvusCorax> argh, I think I found the issue   In img2enc.c  the code always uses incrementing image numbers, it doesn't care about the frames timestamp at all :-((((
[13:04:53 CET] <BtbN> it doesn't say anything about the bottleneck
[13:04:56 CET] <BtbN> it just reports the speed
[13:05:20 CET] <DHE> experimentation is needed. try saving to a local disk instead and see how it goes.
[13:05:20 CET] <xtina> I see. so it is indeed pushing out 800kbps of data per second, if it takes 10 seconds to push out 1 second of 8Mbps video
[13:06:17 CET] <xtina> if the CPU usage is 20%, is the bottleneck likely to be the wifi? sorry for all the q's
[13:06:31 CET] <xtina> i'm thinking of installing a different wifi chip to help things, but hoping to know if wifi is the bottleneck first, as it's a lot of work haha
[13:06:33 CET] <DHE> without further information that might be my first guess
[13:06:57 CET] <xtina> makes sense
[13:07:09 CET] <DHE> save to disk (or discard the video to /dev/null or such) and see how that goes
[13:11:56 CET] <conseal> BtbN: do you have any wise words to say about my mjpeg problem about 50 lines up? :)
[13:14:12 CET] <BtbN> I don't even understand what you think is a problem.
[13:14:24 CET] <BtbN> The deprecation note is not an error and there's nothing you can do about it.
[13:28:46 CET] <xtina> DHE: given my CPU usage is 20%, is there a chance the bottleneck *is* processing? i know i'm not giving you much info, sorry
[13:29:22 CET] <xtina> i.e. could it just take too long for ffmpeg to slowly process larger video files? does processing time really increase with video size?
[13:30:17 CET] <xtina> oh, you're right about saving to disk
[13:30:20 CET] <xtina> i didn't see your comment
[13:30:22 CET] <xtina> i will try that :)
[13:39:01 CET] <conseal> BtbN: I can ignore the pixel format error, but the "invalid dropping" errors was more of a concern.
[13:39:57 CET] <conseal> BtbN: and if the "Stream #1:0" output looks as expected when I recieve MJPG from the camera.
[13:45:53 CET] <xtina> DHE: I just tried dumping to /dev/null. lo and behold, i can do 1080P, 10Mbps up, at 1.0x speed (realtime) with no strain on my Zero's CPU :)
[13:46:13 CET] <xtina> this means my bottleneck must be the wifi, which is more or less good news, since I can do something about my wifi and can't do anything about the CPU :)
[13:48:23 CET] <xtina> however, it's still a mystery to me why my speedtest shows that I can get 5Mbps up, when ffmpeg can't manage more than 800kbps up
[13:50:36 CET] <furq> what framerate is that
[13:50:57 CET] <furq> if raspivid (or whatever you're using now) is pulling rawvideo off your camera then it could be exhausting your usb bus bandwidth
[13:51:59 CET] <furq> although i'm inclined to think the reason is that wifi sucks
[13:52:25 CET] <xtina> furq: it's 10FPS
[13:52:43 CET] <xtina> furq: yea, i'm using raspivid :) i realize i've been chatting in here about my project for ages..
[13:53:29 CET] <xtina> i'm also inclined to think my wifi sucks, since if i dump to /dev/null i can get 10Mbps up in real-time, or whatever arbitrarily high bitrate i want, without any CPU problems
[13:53:38 CET] <xtina> i assume that means it's my wifi...
[13:53:59 CET] <furq> well like i said it could be your usb bus
[13:54:18 CET] <furq> try running speedtest while ffmpeg is running to /dev/null
[14:02:08 CET] <xtina> furq: i tested speedtest while running ffmpeg at high settings (1080P, 10FPS, 6Mbps up) and it says 4.5Mbps up
[14:02:45 CET] <AndrewMock> site down?
[14:03:45 CET] <xtina> my wifi is not connected to USB btw.. it's using a SDIO hack
[14:04:17 CET] <xtina> there's no devices on my USB ports
[14:04:37 CET] <BtbN> conseal, I'd blame the webcam to generate bad timestamps
[14:16:07 CET] <conseal> BtbN: that might be. I'll try with a different camera once I get home.
[14:16:20 CET] <conseal> I got a Cisco/Tandberg Precision HD camera too
[14:18:29 CET] <conseal> not the latest and greatest but..
[14:20:48 CET] <furq> conseal: try adding -framerate 30 before -i
[14:27:21 CET] <xtina> btw, someone told me that streaming using Ffmpeg requires GPU cycles on the Pi.. is that true?
[14:28:13 CET] <xtina> is that due to hardware encoding using the GPU?
[14:35:15 CET] <DHE> if you used "-c:v h264" (or a specific codec) then yes it does. but if you're using "-c:v copy" then no
[14:35:32 CET] <DHE> or if you use libx264 then your CPU will scream. :)
[14:35:38 CET] <xtina> DHE: i'm using -c:v copy
[14:35:42 CET] <DHE> well then
[14:35:45 CET] <xtina> i'm using h264 encoded video with raspivid. ffmpeg is just muxing it
[14:35:54 CET] <xtina> but i thought raspberry pi h264 encoding was via GPU..
[14:36:14 CET] <DHE> probably raspivid is using the GPU in that case then
[14:37:29 CET] <xtina> DHE: yea, i guess so
[14:38:12 CET] <furq> don't you get h264 off your camera
[14:38:25 CET] <xtina> furq: well it has to be encoded somehow..?
[14:38:38 CET] <furq> yeah, by the camera
[14:38:39 CET] <bencoh> 15:03 < xtina> my wifi is not connected to USB btw.. it's using a SDIO hack
[14:38:42 CET] <xtina> sorry i'm sort of a noob at this
[14:38:49 CET] <bencoh> it's not a "hack" per-se actually
[14:38:51 CET] <xtina> the camera is encoding? not GPU?
[14:38:56 CET] <Delurk> Hello, I try to send pcm sound to icecast2 server but it doesn't work. The error : http://delurk.com/ffmpeg.txt
[14:38:57 CET] <bencoh> it's quite common in the embedded world
[14:38:59 CET] <furq> it could be either
[14:39:11 CET] <furq> idk what raspivid is choosing to do
[14:39:39 CET] <xtina> furq: huh, i see..
[14:39:45 CET] <xtina> didn't know that :)
[14:39:58 CET] <xtina> bencoh: yea, not suggesting it's novel or anything, just followed these steps http://hackaday.com/2015/12/09/raspberry-pi-wifi-through-sdio/
[14:40:24 CET] <furq> but yeah if the camera produces h264 then it won't touch the gpu at all
[14:40:50 CET] <furq> if you're reencoding it then it's mostly offloaded to the discrete h264 encoder, but that probably gets frames through the gpu
[14:41:17 CET] <furq> it seems unlikely that that'd bottleneck but i don't really know how weak that gpu is
[14:42:20 CET] <furq> i vaguely remember that you were using the camera h264 at one point and youtube didn't like it or something
[14:42:28 CET] <furq> so i assume raspivid is getting rawvideo/mjpeg off the camera and reencoding
[14:42:47 CET] <xtina> furq: "The raw data that comes from raspivid, a CLI tool that is part of the Raspberry Pi userland repository, is straight H264 encoded video data that comes from the on-board H264 encoder hardware chip built into the Raspi."
[14:43:38 CET] <furq> `ffmpeg -c:v h264 -f v4l2 -i /dev/video0` will pull h264 off the camera
[14:43:46 CET] <furq> like i said, i think you tried that and youtube didn't play it
[14:44:59 CET] <xtina> furq: yea, i'm not doing that, i'm getting h264 from raspivid and piping it to ffmpeg, which just copies it
[14:45:15 CET] <xtina> doesn't that mean there's no re-encoding happening?
[14:45:30 CET] <bencoh> no re-encoding occurs with -c:v copy
[14:45:33 CET] <xtina> cmd: http://vpaste.net/n3xw9
[14:45:41 CET] <bencoh> (no video reencoding, that is)
[14:46:32 CET] <furq> raspivid is encoding
[14:46:49 CET] <furq> if it's pulling mjpeg off the camera then that should be fine
[14:46:58 CET] <furq> if it's rawvideo then that could cause bandwidth issues over usb2
[14:47:15 CET] <xtina> can you tell which one is happening? /usr/bin/raspivid -v -fps 10 -w 1920 -h 1080 -o /tmp/temp_video.h264 -t 0 &
[14:47:20 CET] <furq> no idea
[14:47:45 CET] <furq> one would hope there'd be an option to control it
[14:47:53 CET] <oneo> hello all - I keep getting the error "Output file #0 does not contain any stream" on newer versions of FFMpeg.  I've tried both the 3.2 and 3.1 branches and they both have the issue.  Older versions don't seem to have this issue.  I'm trying to record an HLS stream.  I have full trace logs if needed.  Here's my command: ffmpeg -v trace -c copy -i "
[14:47:53 CET] <oneo> http://play-prod1.live.anvato.net/server/play/sni-foodx-ctg/master.m3u8" food.mp4
[14:48:08 CET] <xtina> mmm, i see
[14:48:52 CET] <furq> is there some reason you're using raspivid for that
[14:50:42 CET] <xtina> rather than ffmpeg, furq?
[14:51:04 CET] <furq> yeah
[14:51:10 CET] <furq> oneo: you probably want -c copy after the input url
[14:51:13 CET] <furq> looks fine otherwise
[14:53:56 CET] <oneo> @furk - Thanks for the help!  I'm still getting the same error with command: ffmpeg -i http://play-prod1.live.anvato.net/server/play/sni-foodx-ctg/master.m3u8 -c copy food.mp4
[14:54:25 CET] <oneo> ffmpeg version n3.2.4
[14:55:31 CET] <DHE> maybe it's different for you but I'm getting 403 from that URL
[14:55:37 CET] <furq> same
[14:56:10 CET] <oneo> are you in the US?
[14:56:16 CET] <DHE> no
[14:56:28 CET] <oneo> ah that could be why - it might be geo protected
[14:56:59 CET] <xtina> furq: if i tried something like this i would get like almost no video output, very low bitrate. idk why
[14:57:00 CET] <xtina> ~/special/ffmpeg/ffmpeg -f lavfi -re -i anullsrc -f v4l2 -input_format h264 -i /dev/video0 -c:v h264_omx -acodec aac -f flv rtmp://209.85.230.23/live2/xbjs-a3gp-0yvk-ftdg
[14:57:08 CET] <xtina> whoops.. pls ignore that RTMP key ..
[14:59:05 CET] <xtina> oh, and i would get video skipping too. that's why it seemed better to pipe things to a fifo
[14:59:37 CET] <xtina> so ffmpeg wouldn't lose anything
[15:00:11 CET] <furq> replace -input_format h264 with -c:v mjpeg -framerate 10
[15:00:50 CET] <furq> and add -b:v 5000k as an output option
[15:02:29 CET] <xtina> furq: http://vpaste.net/2fRKe
[15:03:17 CET] <furq> what's the cpu usage like
[15:03:52 CET] <DHE> considering that saving to disk instead of the RMTP target brings throughput to 1.00x I'm still inclined to say it's the network
[15:04:23 CET] <furq> and yeah run these benchmarks to /dev/null if you can
[15:04:24 CET] <xtina> furq, it's high, spiking to 85% sometimes
[15:04:27 CET] <xtina> (my current approach is <25%)
[15:04:45 CET] <furq> that cpu is probably struggling to decode mjpeg
[15:04:59 CET] <xtina>   Stream #1:0 -> #0:0 (mjpeg (native) -> h264 (h264_omx))
[15:05:21 CET] <SouLShocK> http://pastebin.com/y6rLg06j produces an overlapping of the background boxes as shown in https://ibin.co/3DHDA1mTedBS.jpg how do I avoid that overlap?
[15:05:31 CET] <xtina> i assume with my raspivid approach, it doesn't have to decode mjpeg
[15:05:36 CET] <xtina> it's just encoding raw to h264, isn't it?
[15:05:42 CET] <furq> you can do that with ffmpeg as well
[15:06:00 CET] <xtina> DHE: true. i'm still planning to replace the wifi
[15:06:56 CET] <furq> so uh
[15:07:18 CET] <furq> ffmpeg -c:v h264 -f v4l2 -i /dev/video0 -c:v copy -f flv
[15:07:22 CET] <furq> what does that do
[15:08:39 CET] <DHE> no output filename
[15:08:48 CET] <furq> ;_;
[15:11:24 CET] <Delurk> Nobody...? pipe:1: Invalid argument : http://delurk.com/ffmpeg.txt
[15:12:31 CET] <furq> Delurk: what's the actual ffmpeg command
[15:13:02 CET] <DHE> if your output is pipe:1, why does it also have an icecast server URL?
[15:13:16 CET] <Delurk> FFmpeg(inputs={'pipe:0':'-f s16le -ar 48000 -ac 2'},outputs={'pipe:1':'-c:a libvorbis -ab 128k -f ogg icecast://source:pass@direct.delurk.com:8000/ecouter.ogg'})
[15:13:23 CET] <DHE> at least I'm guessing that's the issue since I don't know how the python API actually works. I
[15:13:24 CET] <furq> that's not an ffmpeg command
[15:13:28 CET] <DHE> I'm just looking for inconsistencies
[15:14:11 CET] <Delurk> ok
[15:14:45 CET] <Delurk> input and or ouput to replace pipe ?
[15:15:04 CET] <termos> I have some AMF onCue markers in my input stream that seems to be causing issues with FFmpeg, giving me error messages: Packet mismatch 1358966208 11. Any way to ignore these AMF messages in the RTMP stream?
[15:18:05 CET] <xtina> furq: this does use very low CPU:
[15:18:14 CET] <xtina> ~/special/ffmpeg/ffmpeg -c:v h264 -f v4l2 -i /dev/video0 -c:v copy -f flv /dev/null
[15:18:28 CET] <xtina> no CPU difference that i can see vs. raspivid
[15:18:34 CET] <furq> does youtube accept it
[15:18:53 CET] <xtina> let me try, i'll add in the piping audio from arecord
[15:22:22 CET] <xtina> well it goes at like a ridiculous 10Mbps bitrate and 0.06x speed, so i need to specify those
[15:22:45 CET] <xtina> i wonder why ffmpeg doesn't try to autobalance to a bitrate to achieve real-time speed. do people ever want non-1.0x speed anyway?
[15:22:48 CET] <xtina> it seems to not be intelligent about it
[15:23:09 CET] <xtina> like if i don't give settings, it chooses a super high bitrate and then pushes out one second of video every 20s...
[15:23:19 CET] <furq> ffmpeg isn't controlling the bitrate
[15:23:34 CET] <xtina> oh
[15:23:50 CET] <xtina> is it just whatever the camera gives it?
[15:23:53 CET] <furq> yeah
[15:24:13 CET] <furq> you probably want to set -framerate or -input_size
[15:24:28 CET] <xtina> doesn't -b:v dictate output bitrate?
[15:24:40 CET] <furq> it does if you're not copying
[15:24:40 CET] <xtina> what happens if i'm getting fed 10Mps video and specify a 1Mbps bitrate in -b:v?
[15:24:43 CET] <DHE> when ffmpeg is doing the transcding, yes
[15:24:48 CET] <xtina> oh, i see
[15:24:49 CET] <furq> nothing
[15:24:52 CET] <xtina> so otherwise -b:v is meaningless haha
[15:24:58 CET] <xtina> whoops
[15:25:04 CET] <furq> most :v options are useless with copy
[15:25:21 CET] <furq> pretty much only -bsf:v does anything
[15:25:27 CET] <xtina> hmm, well with raspivid i'm able to choose the bitrate and i set it to 500kbps
[15:25:44 CET] <furq> well yeah, that's transcoding
[15:25:50 CET] <xtina> right now with the 10Mbps i'm getting, i'd have to choose like 1-2 FPS to get 1.0x speed
[15:26:08 CET] <xtina> i see
[15:26:12 CET] <furq> you can presumably replicate raspivid with ffmpeg with -c:v rawvideo -f v4l2 -i /dev/video0 -c:v h264_omx
[15:27:01 CET] <furq> i'd try copying at a lower fps and/or resolution
[15:27:48 CET] <xtina> so to clarify, with raspivid when i specify a target rez and bitrate, it is converting raw to h264 and then transcoding to my desired specs
[15:27:59 CET] <furq> probably
[15:30:30 CET] <xtina> huh, is input_size a real param? it's nowhere in this doc: https://ffmpeg.org/ffmpeg.html
[15:30:45 CET] <furq> sorry, video_size
[15:31:11 CET] <furq> !indev v4l2
[15:31:12 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2
[15:33:23 CET] <xtina> so, i do seem to have luck when i pipe in audio from SOX and use ffmpeg for video with this cmd:
[15:33:25 CET] <xtina>  ~/special/ffmpeg/ffmpeg -i /tmp/temp_audio.mp3 -s 640x480 -c:v h264 -f v4l2 -i /dev/video0 -c:v copy -c:a aac -f flv  rtmp://209.85.230.23/live2/KEY
[15:33:30 CET] <xtina> interesting, ffmpeg uses about 25% CPU
[15:33:38 CET] <xtina> whereas when i was using raspivid, raspivid used like 0% CPU
[15:33:40 CET] <xtina> so something is different..
[15:33:52 CET] <furq> well yeah that's encoding aac
[15:34:03 CET] <xtina> oh, whoops!
[15:34:18 CET] <xtina> 1sec then
[15:35:27 CET] <xtina> yea, so when i correct that, ffmpeg is hardly using any CPU
[15:35:28 CET] <xtina> same as raspivid
[15:35:45 CET] <xtina> youtube does tke it
[15:35:47 CET] <xtina> take it**
[15:35:52 CET] <xtina> stream seems healthy
[15:36:03 CET] <xtina> so maybe i should fold the video step into ffmpeg, i guess there's no reason to use raspivid
[15:36:09 CET] <xtina> although i guess both seem to work fine
[15:36:27 CET] <furq> did you build ffmpeg with --enable-mmal
[15:36:32 CET] <xtina> i did
[15:36:39 CET] <furq> oh cool
[15:36:41 CET] <xtina> er.. actually lemme check
[15:36:47 CET] <furq> apparently the pi does hardware mjpeg decode
[15:36:51 CET] <furq> that might be the way to go
[15:36:58 CET] <xtina> nah, i didn't
[15:37:00 CET] <xtina> http://vpaste.net/cXV9F
[15:37:02 CET] <furq> rip
[15:37:07 CET] <xtina> i used those instructions, someone here sent me (maybe you lol)
[15:37:11 CET] <furq> it probably was me
[15:37:18 CET] <furq> i didn't know about enable-mmal until recently
[15:37:37 CET] <xtina> what's the point of hardware decode mjpeg -> h264 vs raw->h264 like i'm doing now
[15:38:10 CET] <furq> 1080p rawvideo is big, and usb2 is slow
[15:38:11 CET] <xtina> seems like the current way is fewer steps?
[15:38:24 CET] <Delurk> DHE, is this correct ?  FFmpeg(inputs={'stereo_pcm':'-f s16le -ar 48000 -ac 2'},outputs={'icecast://source:pass@direct.delurk.com:8000':'-c:a libvorbis -ab 128k -f ogg'})
[15:38:59 CET] <furq> idk if that'll cause issues at 1080p10 but 1080p30 almost certainly won't work
[15:39:12 CET] <furq> if your wifi isn't using the usb bus then it might be fine? idk
[15:39:56 CET] <furq> either way if h264 off the camera works then that's the way to go
[15:40:16 CET] <xtina> so my camera can feed me mjpeg
[15:40:40 CET] <furq> most cameras will do rawvideo, mjpeg or h264
[15:40:56 CET] <xtina> (i don't think i'll be approaching 1080p30 even with my new wifi module)
[15:42:44 CET] <xtina> this is all really interesting
[15:43:21 CET] <xtina> i've learned a lot
[15:44:01 CET] <xtina> if i have issues with 1080 at 10 with my new wifi, how would i diagnose if it's the USB bus bandwidth being exhausted?
[15:46:34 CET] <furq> not sure how you'd measure that really
[15:46:48 CET] <furq> that's about 250mbps and i'd expect that to cause issues
[15:47:13 CET] <xtina> you know, i just read that the Zero is the only pi to not have the h264 chip
[15:47:14 CET] <xtina> http://elinux.org/RPi_Hardware
[15:47:34 CET] <xtina> unless i'm misunderstanding that table
[15:47:41 CET] <furq> er
[15:48:02 CET] <furq> i think that's trying to say that it's the same as the VC4 from the first column
[15:48:06 CET] <furq> otherwise h264_omx wouldn't work
[15:48:46 CET] <furq> my understanding was that it was the same gpu as the pi 1/2
[15:49:08 CET] <xtina> huh .. yea... i guess so
[15:49:11 CET] <xtina> it's not clear @_@
[15:49:25 CET] <furq> yeah that's a really unclear way of writing it
[15:49:33 CET] <furq> given the other two are both called "broadcom videocore iv"
[15:52:42 CET] <xtina> yea this seems to suggest that it does have it: https://en.wikipedia.org/wiki/Raspberry_Pi
[15:52:53 CET] <xtina> the gpu part of specs table
[15:53:45 CET] <xtina> i guess that the raspivid command is grabbing h264 via this h264 encoding chip
[15:53:58 CET] <xtina> but with the ffmpeg that takes raw video and then encodes it to h264, do you think it's also using the chip?
[15:54:03 CET] <xtina> sorry if i already asked this.. it's late..
[15:54:13 CET] <furq> that's what h264_omx is
[15:54:22 CET] <xtina> oh ok, my cmd didn't have h264_omx
[15:54:26 CET] <xtina> so it wasn't
[15:54:39 CET] <xtina> in which case... i'm surprised it's so low cpu
[15:54:39 CET] <furq> the camera has an h264 encoder as well
[15:55:01 CET] <furq> your command is just grabbing h264 encoded video from the camera and copying it
[15:55:15 CET] <xtina> camera has h264 encoder, pi has one too?
[15:55:16 CET] <xtina> lol
[15:55:19 CET] <xtina> @_@
[15:55:20 CET] <furq> yeah
[15:55:28 CET] <furq> a lot of webcams do now
[15:55:34 CET] <xtina> huh i see
[15:55:38 CET] <furq> they're generally pretty bad, but the one on the pi isn't great either
[15:56:06 CET] <xtina> how do you know whether ffmpeg/raspivid are using pi or camera h264 chip?
[15:56:24 CET] <furq> ffmpeg is using the camera's h264 because you're requesting it off the camera
[15:56:42 CET] <furq> raspivid is using the pi's chip because otherwise you wouldn't be able to set the bitrate etc
[15:56:47 CET] <furq> although idk what format it's taking off the camera
[15:57:01 CET] <furq> it could be using mjpeg or h264 and using the builtin decoder
[15:57:11 CET] <xtina> oh how interesting
[15:57:25 CET] <furq> i'd be surprised if 1080p10 worked smoothly if it was using rawvideo
[15:57:49 CET] <furq> 250mbps sustained throughput over usb2 is getting close to the territory of dreams
[15:58:20 CET] <xtina> OK this is another stupid question but what does the video stuff have to do with usb2/
[15:58:29 CET] <xtina> it's coming in through the CSI port right
[15:58:49 CET] <furq> oh.
[15:58:56 CET] <xtina> lol
[15:59:03 CET] <furq> ignore everything i said about usb2 then ;_;
[15:59:08 CET] <xtina> ohhh ok
[15:59:11 CET] <xtina> well that's good ^_^
[15:59:20 CET] <xtina> haha
[16:00:08 CET] <xtina> so with raspivid raw vid from camera is being encoded by pi h264 encoder. with ffmpeg the encoding happens on the camera's encoder. hmm, the ffmpeg way seems better...
[16:00:14 CET] <xtina> less data transfer, no?
[16:00:19 CET] <bencoh> hmm, h264_omx has never been merged to vanilla ffmpeg? :(
[16:00:29 CET] <furq> ?
[16:00:32 CET] <furq> it's been there for ages
[16:00:36 CET] <bencoh> oh, nevermind
[16:00:41 CET] <furq> along with mmal
[16:00:47 CET] <bencoh> yeah right, omx.c
[16:01:15 CET] <bencoh> I should try it on n900+openmax some day
[16:01:19 CET] <furq> xtina: it depends which h264 encoder is better
[16:01:34 CET] <furq> the builtin ones on cameras tend to be pretty crap
[16:02:08 CET] <bencoh> I wonder if the normal (ie not the broadcom-specific one) omx API is still maintained
[16:02:30 CET] <bencoh> actually I wonder if it'd be compatible with ti-omx at all
[16:02:32 CET] <furq> the pi camera might actually be using the pi's encoder anyway
[16:02:49 CET] <furq> i assumed it was some usb2 camera in which case it wouldn't be able to, but i have no idea how csi works
[16:03:42 CET] <furq> bencoh: there's --enable-omx and --enable-omx-rpi, so i assume it is
[16:04:12 CET] <bencoh> furq: unless ti-omx requires ti-specific calls
[16:04:25 CET] <furq> i meant wrt the normal api being maintained
[16:04:27 CET] <furq> i have no idea about ti-omx
[16:04:29 CET] <xtina> i see. i guess ffmpeg can use either the camera chip (h264) or the pi chip (h264_omx) if i understand correctly, and i can see which one works better, but the decoding mjpeg idea isn't necessary since i'm not worried about passing raw video over USB2
[16:04:59 CET] <bencoh> I remember vlc somehow working with ti-omx at some point so I guess I could always port code from there if needed anyway
[16:05:10 CET] <furq> xtina: i suspect the camera is actually just using the pi's encoder
[16:05:21 CET] <furq> it's just exposing it to v4l2 as if it has its own encoder
[16:05:41 CET] <xtina> so in that case h264_omx and h264 are hte same thing
[16:05:53 CET] <furq> pretty much
[16:06:40 CET] <furq> so uh
[16:06:40 CET] <xtina> cool
[16:07:02 CET] <furq> -c:v rawvideo -f v4l2 -i /dev/video0 -c:v h264_omx -b:v 5000k
[16:07:06 CET] <furq> i guess that's what you want
[16:07:15 CET] <xtina> right
[16:07:36 CET] <xtina> so since it's decoding on the pi chip i should be able to control bitrate and stuff the way i did with raspivid?
[16:07:45 CET] <xtina> or no?
[16:07:53 CET] <furq> rawvideo is already decoded
[16:07:56 CET] <furq> hence raw
[16:08:13 CET] <furq> but yeah you can control bitrate with ffmpeg if you do that
[16:08:16 CET] <xtina> so i just specify the output
[16:08:18 CET] <xtina> bitrate and stuff
[16:08:25 CET] <furq> and the input framerate/resolution
[16:10:02 CET] <xtina> right
[16:10:05 CET] <xtina> OK, awesome
[16:10:11 CET] <xtina> it's an ungodly hour here, i need to crash soon
[16:10:19 CET] <furq> i sure made that more complicated than it needed to be
[16:10:21 CET] <xtina> thanks for the lesson, this has been a very enlightening chat :D
[16:11:14 CET] <xtina> haha np, seems we figured it out
[17:03:16 CET] <xeche> Is it just me or does avformat_free_context and avcodec_free_context just not play nice with eachother when avcodec_new_stream is involved? I see there have been issues reported before, but it was tagged resolved and fixed
[17:05:12 CET] <xtina> furq: i lied about sleeping, stayed up trying to play with your suggestion. i'm currently doing this:
[17:05:13 CET] <xtina> -framerate 10 -video_size 640x480 -c:v rawvideo -f v4l2 -thread_queue_size 1024 -i /dev/video0 -c:v h264_omx
[17:05:21 CET] <xtina> i'm getting: [video4linux2,v4l2 @ 0x2be45f0] The device does not support the streaming I/O method. /dev/video0: Function not implemented
[17:05:56 CET] <xtina> any idea what's wrong?
[17:22:30 CET] <Guest31237> compiling ffmpeg with libmfx error : libmfx not found using pkg-config
[17:23:13 CET] <Guest31237> response to pkg-config --libs libmfx is
[17:23:37 CET] <Guest31237> -L/mingw64/lib -lmfx -lstdc++
[17:23:58 CET] <Guest31237> it seems all ok but configure fails
[17:26:15 CET] <JEEB> check config.log
[17:27:51 CET] <xtina> also this is strange but i get Unknown decoder 'h264_omx'
[17:28:07 CET] <xtina> even tho my ffmpeg version says:    configuration: --extra-cflags=-I/opt/vc/include/IL --enable-nonfree --enable-omx-rpi --logfile=CONFIG.TXT
[17:28:23 CET] <xtina> '--enable-omx-rpi' - shouldn't that do it?
[17:29:14 CET] <Guest31237> how to "decode" config.log ?  check_pkg_config libmfx mfx/mfxvideo.h MFXInit pkg-config --exists --print-errors libmfx check_func_headers mfx/mfxvideo.h MFXInit -I/mingw64/include -L/mingw64/lib -lmfx -lstdc++ check_ld cc -I/mingw64/include -L/mingw64/lib -lmfx -lstdc++ check_cc -I/mingw64/include -L/mingw64/lib BEGIN /tmp/ffconf.pnwxQFgm.c     1	#include <mfx/mfxvideo.h>     2	#include <stdint.h>     3	long check_MFXInit(void) { 
[17:30:43 CET] <Guest31237> issuing the command pkg-config --exists libmfx it seemsnothing happens
[17:31:30 CET] <Guest31237> errors are In function `MFX::MFXAutomaticCriticalSection::MFXAutomaticCriticalSection(int volatile*)': /c/downloads/mfx_dispatch-master/src/mfx_critical_section.h:55: undefined reference to `MFX::mfxEnterCriticalSection(int volatile*)'
[17:32:13 CET] <Guest31237> like if mfx_dispatch isn't correctly compiled or installed
[17:42:46 CET] <xtina> alright, stupid question. my /dev/video0 device doesn't load when i run ffmpeg as root. it loads if I don't run as root.
[17:43:28 CET] <xtina> when running ffmpeg as root i get: '[video4linux2,v4l2 @ 0x1f62610] fd:4 capabilities:1000001 [video4linux2,v4l2 @ 0x1f62610] The device does not support the streaming I/O method.'
[17:43:45 CET] <xtina> when running as a user i get: '[video4linux2,v4l2 @ 0x1a53820] fd:4 capabilities:5000001 [video4linux2,v4l2 @ 0x1a53820] Current input_channel: 0, input_name: default, input_std: 0'
[17:43:46 CET] <xtina> and it works fine
[17:44:24 CET] <xtina> i checked the device exists: http://vpaste.net/uqqLR
[17:48:14 CET] <xtina> exactly the same question as this guy: https://www.raspberrypi.org/forums/viewtopic.php?t=158136&p=1028603
[17:48:15 CET] <xtina> no answer there tho
[17:48:34 CET] <furq> why are you running as root
[17:49:09 CET] <xtina> furq: running in a bash script
[17:49:14 CET] <xtina> upon startup
[17:49:15 CET] <xtina> it just runs as root
[17:50:25 CET] <furq> so have the script change to your user
[17:51:25 CET] <xtina> eh.. do you know why ffmpeg doesn't recognize /dev/video0 when run as root? seems unnecessary to have to run as user, this should be solveable right?
[17:52:14 CET] <furq> no but you generally shouldn't run anything as root
[17:54:22 CET] <xtina> ehhh
[17:54:31 CET] <xtina> okay, okay
[17:55:13 CET] <bencoh> :)
[17:57:01 CET] <xtina> i'll try to run as user, though still curious why ffmpeg doesn't recognize /dev/video0 as sudo
[17:57:07 CET] <xtina> must be something stupid ;_;
[18:10:49 CET] <conseal> hmm, does ffmpeg require additional options while compiling to utilize all four cores while encoding?
[18:11:10 CET] <conseal> it seems to ignore "-threads 4"
[18:11:19 CET] <conseal> and is maxing one core
[18:12:06 CET] <furq> not all encoders are multithreaded
[18:13:34 CET] <tested> hi
[18:14:05 CET] <tested> ffmpeg -i video.avi -vf subtitles=subtitle.srt out.avi has no effect
[18:14:20 CET] <tested> subtitle is added but media player not picked
[18:15:21 CET] <tested> so it means it was not hardsubs
[18:15:44 CET] <tested> i follow tutorial https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
[18:17:58 CET] <tested> anyone?
[18:17:59 CET] <conseal> furq: I'm guessing h264_omx is not? :(
[18:18:10 CET] <furq> that's not a cpu encoder
[18:18:12 CET] <krstjns> hmmm, so h264_cuvid decoder is giving me an odd issue, ends up not giving me the last 7 frames on specific videos
[18:19:01 CET] <krstjns> any1 ran in to anything similar?
[18:20:41 CET] <conseal> furq: I have no idea, the first time I touched ffmpeg was less than a week ago :)
[18:20:53 CET] <krstjns> thats using ffmpeg.c
[18:22:33 CET] <tested> any suggestion for me?
[18:22:53 CET] <bencoh> conseal: h264_omx basically offloads encoding on gpu/vpu
[18:24:16 CET] <tested> when i check mp4 file i saw 3 ids
[18:24:30 CET] <tested> 1 is video 2nd is audio 3rd is subtitle
[18:24:31 CET] <tested> Format                      : Timed Text
[18:24:40 CET] <tested> Codec ID                    : tx3g
[18:25:25 CET] <tested> any command for add SRT file to mp4
[18:26:03 CET] <conseal> bencoh: thanks for the info. I'm trying to fetch mjpeg off a webcam and encode it to h264 and send it to an rtmp destination, but I seem to max out my RPI3B's CPU
[18:26:20 CET] <conseal> bencoh: + dropping frames and only getting x0.8 speed
[18:26:40 CET] <conseal> seems like I'm returning my RPI to get my money back and rather invest in something a bit more powerful.
[18:27:40 CET] <furq> conseal: did you build with --enable-mmal
[18:27:52 CET] <furq> you'll need that to do hardware mjpeg decoding
[18:29:01 CET] <tested> furq any suggestion or cmd for me?
[18:29:15 CET] <furq> pastebin your command and full output
[18:29:52 CET] <tested> i followd https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
[18:30:12 CET] <tested> srt file command and ass file cmd both work but subtitle does not
[18:30:25 CET] <conseal> furq: probably not, as the howto I originally followed was intended to "pass through" h264.
[18:30:31 CET] <bencoh> conseal: I'd suggest you talk to xtina then since you seem to have similar goals :]
[18:30:59 CET] <xtina> hey, haven't followed but heard a beep ..
[18:31:14 CET] <xtina> i'm taking video from my pi camera and streaming it to an rtmp destination, it takes less than 20% CPU on my Zero
[18:31:20 CET] <xtina> so it certainly should be doable on your 3B
[18:31:25 CET] <bencoh> :)
[18:32:13 CET] <conseal> furq: give me a sec, I'll pastebin it
[18:32:36 CET] <furq> conseal: not you
[18:33:36 CET] <conseal> oh
[18:33:47 CET] <furq> you should just be able to rebuild with --enable-mmal
[18:33:53 CET] <furq> that enables the hardware decoder
[18:34:44 CET] <furq> i'm not 100% sure if the mjpeg decoder is present in ffmpeg though
[18:34:48 CET] <furq> you might need to use raspivid or something
[18:34:51 CET] <tested> 1 min
[18:35:52 CET] <conseal> furq: yup, I hadn't compiled it with --enable-mmal now, its in progress though.
[18:36:10 CET] <tested> http://pastebin.com/cpgUWKqq
[18:36:47 CET] <tested> what i found is
[18:36:52 CET] <tested> Fontconfig error: Cannot load default config file
[18:36:52 CET] <tested> [Parsed_ass_0 @ 05207f40] No usable fontconfig configuration file found, using f
[18:36:53 CET] <tested> allback.
[18:36:53 CET] <tested> Fontconfig error: Cannot load default config file
[18:38:16 CET] <furq> conseal: looks like it's not exposed
[18:40:58 CET] <tested> i gonna download latest ffmpeg
[18:41:16 CET] <tested> and will follow solution
[18:42:07 CET] <tested> thanks furq
[18:53:31 CET] <xtina> hey all. i have a script that starts a livestream upon boot. every time i boot, the audio buffer overruns at the 20 second mark. if i execute this stream while SSHed into the device, there are *never* overruns
[18:53:49 CET] <xtina> i've captured logs from a boot-run and a manual run from SSH and i don't see differences
[18:54:12 CET] <xtina> in both cases it takes Ffmpeg 5 seconds to go from startup to beginning to stream and during this time the video encoder is activating (since all the video stuff happens in ffmpeg now)
[18:55:05 CET] <xtina> boot run output: http://vpaste.net/fPDsk
[18:55:06 CET] <furq> is something starting up 20 seconds after you boot
[18:55:24 CET] <xtina> successful manual run output: http://vpaste.net/joGCw
[18:55:46 CET] <xtina> hmmmm
[18:56:11 CET] <xtina> good q..
[18:56:26 CET] <xtina> nothing i'm manually executing, this is the only script.
[18:57:51 CET] <conseal> furq: that means I should try raspivid + ffmpeg in combination?
[18:59:16 CET] <nohop> I'm using livavcodec/format to generate a stream. When I'm using nvenc_nevc with preset=lossless, I'm getting a lot of "packet too large, ignoring buffer limits to mux it", "buffer underflow st=0 bufi=559242 size=566243"
[18:59:58 CET] <furq> conseal: probably
[19:00:03 CET] <nohop> which makes it difficult to see the actual other debug information my application is spitting out :) How would I go about increasing these buffers, or simply supressing these warning ? (rpeserable the former)
[19:12:25 CET] <conseal> xtina: are you fetching mjpeg or rawvideo from your webcam btw?
[19:12:33 CET] <conseal> and at what fps and resolution?
[19:12:43 CET] <xtina> i'm getting h264
[19:12:52 CET] <xtina> 640x480, 10fps
[19:12:56 CET] <xtina> i have a zero with crappy wifi
[19:12:59 CET] <xtina> so really low settings
[19:13:02 CET] <conseal> in that case we're not doing the same
[19:13:04 CET] <conseal> :p
[19:13:13 CET] <furq> conseal: that's a csi webcam anyway so there's no usb bus limits
[19:13:24 CET] <conseal> ah
[19:13:48 CET] <conseal> I considered getting the noir one
[19:14:09 CET] <conseal> but I don't want to put my raspberry into the birdcase in case of humidity/leaks, etc
[19:14:28 CET] <furq> i wouldn't want to stream 720p30 over wifi anyway
[19:15:20 CET] <furq> conseal: does that camera put out h264
[19:15:28 CET] <conseal> not the one that I am using now afaik
[19:15:31 CET] <furq> shame
[19:15:33 CET] <conseal> I stole a new one from work
[19:15:40 CET] <conseal> Microsoft Lifecam something
[19:16:01 CET] <kepstin> probably just mjpeg then
[19:16:29 CET] <furq> did you check v4l2-ctl --list-formats-ext
[19:16:45 CET] <conseal> xtina: I tried doing what you're doing, but my Logitech camera was sending keyframes at odd times and Youtube was bitching about it
[19:17:08 CET] <xtina> Youtube bitches about my keyframes too but it's no issue
[19:17:17 CET] <furq> well yeah it's not ideal but i'm thinking you could take h264 off the camera and reencode it
[19:17:20 CET] <Aerroon> hey i'm getting different video lengths when i extract with ffmpeg vs mkvextract
[19:17:21 CET] <xtina> i always ignore the keyframe warnings
[19:17:24 CET] <furq> you'll at least be able to hardware decode that with ffmpeg
[19:17:27 CET] <conseal> and sadly "-codec:v copy" doesnt let you manipulate keyframes
[19:17:39 CET] <xtina> exactly
[19:17:56 CET] <conseal> furq: I tried re-encoding h264, it didnt look pretty.
[19:17:58 CET] <xtina> but still, i just ignore youtube's keyframe warnings
[19:17:59 CET] <conseal> :-D
[19:18:05 CET] <furq> i can't say i'm too surprised
[19:18:18 CET] <xtina> is the keyframe thing actually causing problems to the stream?
[19:18:19 CET] <furq> bear in mind omx-rpi defaults to 200kbps or something stupid
[19:18:25 CET] <furq> so make sure you changed that
[19:18:41 CET] <conseal> v4l2 lists M420, MJPEG and YUYV formats
[19:19:04 CET] <furq> yeah m420 and yuyv are both too big for 720p30 over usb2
[19:19:16 CET] <furq> m420 is about 330mbps, yuyv is even bigger
[19:19:57 CET] <conseal> xtina: I would assume, that is what its specifically bitching about. It was <4 sec interval keyframes, my Logitech did more than that.
[19:20:30 CET] <conseal> thinking about it, if it was the camera sending keyframes at odd times - wouldnt the interval be the same at all times?
[19:20:33 CET] <xtina> i'm still getting those warnings but my stream works fine for hours
[19:20:57 CET] <furq> conseal: someone in here mentioned that youtube insists on splitting into 4-second gops for HLS, and it'll break if your gops are bigger
[19:21:00 CET] <conseal> in my case it was everything between 6-12 seconds
[19:21:11 CET] <furq> yeah that sounds bad
[19:21:14 CET] <xtina> right, youtube wants <4, i'm giving it 6s
[19:21:30 CET] <conseal> yeah BtbN mentioned that
[19:21:32 CET] <furq> i expect it doesn't like the irregular intervals
[19:23:35 CET] <conseal> but yeah, re-encoding h264 from the camera was artifact hell.
[19:24:17 CET] <furq> does the mjpeg reencode look ok
[19:24:22 CET] <conseal> yes
[19:24:26 CET] <conseal> well, decent
[19:24:32 CET] <furq> how annoying
[19:24:38 CET] <conseal> indeed
[19:24:52 CET] <furq> apparently mmal does support mjpeg but i don't see a hwaccel for it
[19:24:57 CET] <furq> maybe you could bug a developer
[19:25:20 CET] <conseal> I'll try to hook up my older Cisco Precision HD webcam and see if it supports h264
[19:25:49 CET] <xtina> furq: i've looked carefully at the differences between the FFMPEG logs upon boot and on manual execution from SSH. both scripts exhibit interesting behaviors in the first 20s of streaming, but they are different
[19:25:49 CET] <furq> it's good that they market the rpi at "hackers" because it seems like a lot of hacking is needed
[19:26:17 CET] <xtina> the boot script spikes to a speed of 7.1X but bitrate never goes beyond 400Kbps in the first 5s of streaming
[19:26:42 CET] <xtina> the manual SSH script spikes to a speed of 2.2X but a bitrate of 1Mbps in the first 5s of streaming
[19:26:58 CET] <xtina> boot script: http://vpaste.net/wwupI
[19:27:04 CET] <xtina> manual SSH script: http://vpaste.net/tIqor
[19:27:16 CET] <xtina> so it's the boot script that *always* over-runs the audio
[19:27:17 CET] <xtina> manual is fine
[19:28:00 CET] <xtina> i guess they are both trying to "catch up" video off the bat, but it seems like they are doing it differently..? i'm kind of confused
[19:28:39 CET] <xtina> also, lol, yea the rpi is hacky
[19:29:25 CET] <xtina> i don't know if these logs tell the whole story because i guess both are just printing snapshots
[19:29:51 CET] <xtina> but is anything i've said a clue as to why the boot script overruns the audio?
[19:30:42 CET] <xtina> at the point of the overrun (0:21), the boot script has already settled down to 1.07X 220kbps
[19:31:04 CET] <xtina> at 0:21 in the manual script, it's still catching up at 1.4X 285Kbps
[19:31:43 CET] <conseal> furq: it brings back memories from my early days with  FreeBSD 2.0 and early Slackware..
[19:32:42 CET] <pbos> Hi, I have an ivf without timestamps and I need to repack it to a webm with timestamps, does ffmpeg let me do this?
[19:33:13 CET] <pbos> -vf setpts can't be used because -c:v copy disables all filters
[19:33:43 CET] <furq> pbos: probably -r before -i
[19:34:31 CET] <xtina> is it possible to know how much video ffmpeg has in the queue at a given point?
[19:36:00 CET] <pbos> furq: Interestingly this works if I rewrite the ivf (ivf->ivf) and then copy ivf to webm, but not ivf->webm
[19:36:19 CET] <furq> fun
[19:36:29 CET] <furq> that works for raw h264 streams, i've never tried it with vp8
[19:37:02 CET] <pbos> e.g. ffmpeg -r 30 -i /media/pbos/Lexar1/out-yami/FourPeople.1280_720-yami-vp8-1sl1tl-1200-sl0-tl0.ivf -c:v copy -r 30 test.ivf and then test.ivf -> test.webm
[19:37:10 CET] <pbos> but not test.webm directly, that borks timestamps
[19:37:19 CET] <pbos> or gives me the wrong rate
[19:37:26 CET] <pbos> maybe I'm wielding it wrong
[19:37:44 CET] <furq> it shouldn't break it, but you don't need -r as an output option
[19:38:05 CET] <pbos> yeah, I added that when it didn't work, removing that has the same issues
[19:38:41 CET] <furq> weird
[19:43:58 CET] <conseal> so few webcams with a h264 encoder
[19:44:42 CET] <conseal> I'm either stuck with buying a new USB webcam hoping it doesnt have the same issues as the Logitech C920
[19:44:53 CET] <conseal> or buying better hardware
[19:46:04 CET] <llogan> the H.264 encoder in the webcam is probably super inefficient.
[19:47:03 CET] <conseal> Yeah, the C920 one wasnt impressive
[19:47:08 CET] <furq> you could buy the pi camera
[19:48:32 CET] <conseal> Yeah, but then I would have to embed the pi into the birdcase and having 2 cables (or 1 with a PoE converter) instead of one.
[19:49:22 CET] <conseal> its not a problem, I'd just have to redesign the camera enclosure inside the bird case
[19:49:27 CET] <Aerroon> so yeah, mkvextract is giving me a different video length duration than ffmpeg copy
[19:49:55 CET] <Aerroon> there seem to be some keyframes (? not sure if this is the right term) missing from the start of the video file, so ffmpeg's version is shorter
[19:53:27 CET] <conseal> actually I've seen ribbon cable -> hdmi conversion kits
[19:53:53 CET] <conseal> but I don't know how long you can stretch the length of the HDMI cable.
[19:54:51 CET] <conseal> and how the loss of signal would affect throughput
[20:14:44 CET] <xtina> furq: and whoever else is curious. the way i stopped the audio overruns from happening when i stream from boot is to set -analyzeduration to something very small. it defaults to 5s
[20:14:56 CET] <xtina> i lowered it to 500ms and i haven't seen audio overruns on boot anymore
[20:14:59 CET] <xtina> lowering probesize might help too
[20:20:32 CET] <Aerroon> i know what the problem is
[20:20:35 CET] <Aerroon> i'm using -vn and -an
[20:22:26 CET] <llogan> both in the same command? that would make a boring video.
[20:22:31 CET] <llogan> "video"
[20:23:45 CET] <Aerroon> nah, not that
[20:23:52 CET] <Aerroon> okay i have no idea how to fix this
[20:24:15 CET] <Aerroon> i thought i had it fixed but i forgot that if i just remove -an without a -map then i'm putting audio in the video file too
[20:24:33 CET] <Aerroon> and the moment i used map to just copy the video file the video length got screwed up again
[20:24:36 CET] <Aerroon> just kill me
[20:24:53 CET] <Aerroon> ffmpeg doesn't do what i want, mkvextract doesn't work like i want
[20:25:12 CET] <Aerroon> only thing that works like i want is the GUI of mkvextract, but using the gui is such a pain in the ass
[20:26:49 CET] <llogan> what are you trying to do?
[20:27:03 CET] <Aerroon> basically i record footage with OBS
[20:27:11 CET] <Aerroon> but sometimes the start of the clip has some missing keyframes
[20:27:31 CET] <Aerroon> and i need to demux the audio and video tracks into different files
[20:27:57 CET] <Aerroon> but if i demux the video portion alone with ffmpeg the missing keyframes portion gets dropped in the video file
[20:28:07 CET] <Aerroon> so i can end up with a shorter video file at the start
[20:28:49 CET] <Aerroon> so i have an .mkv file that's 22:31 in length with some missing video keyframes (i think that's what you call it) at the start
[20:29:02 CET] <Aerroon> if i demux this i get an audio file that's 22:31 in length and a video file that's 22:28 in length
[20:29:18 CET] <Aerroon> if i demux it so the video file only has one of the audio tracks listed then the video file is also 22:31 in length
[20:29:40 CET] <Aerroon> i know that the missing keyframes part doesn't have useful information, but i'd still like it to keep the same duration since it makes later editing easier
[20:29:54 CET] <Aerroon> with mkvextract's gui i can extract just the video portion and it will also be 22:31
[20:30:12 CET] <Aerroon> but with the command line for some reason it just pulls random stuff out of nowhere and ends with like a 23 minute video somehow
[20:38:55 CET] <thebombzen> I've noticed -vf minterpolate will downscale from yuv420p10le to yuv420p. is this a limitation of the minterpolate filter or can I avoid this?
[20:39:46 CET] <JEEB> most likely yes
[20:40:02 CET] <JEEB> its calculations are done in that color space because it doesn't necessarily need the extra depth
[20:40:21 CET] <JEEB> (or the person who coded it just didn't care)
[20:41:00 CET] <thebombzen> it's just annoying cause I have 10bit input
[20:41:05 CET] <durandal_1707> nobody cares
[20:41:08 CET] <thebombzen> I feel there shouldn't be any reason to downscale it.
[20:41:43 CET] <thebombzen> is minterpolate one of those filters that isn't maintained because if you actually need it you'll do something specialized and better?
[20:42:02 CET] <JEEB> I think the guy who made it is still around
[20:42:06 CET] <JEEB> and it was IIRC pretty alright
[20:42:09 CET] <durandal_1707> buy svp
[20:42:12 CET] <thebombzen> svp?
[20:42:14 CET] <JEEB> it's just that nobody really cared about >8bit
[20:42:36 CET] <thebombzen> ah, so in order to make it work with 10bit you'd have to submit a patch. which requires effort
[20:42:42 CET] <thebombzen> and nobody's got the free time for that
[20:42:51 CET] <durandal_1707> yes
[20:44:22 CET] <JEEB> yup
[20:44:40 CET] <JEEB> thebombzen: but first of all someone needs to come up with the requirement
[20:44:45 CET] <JEEB> and you seem to be the first one
[20:44:48 CET] <JEEB> congrats :P
[21:00:06 CET] <durandal_1707> doesnt minterpolate have some artefacts?
[21:00:16 CET] <JEEB> all interpolation filters have
[22:21:48 CET] <nohop> can anyone point me to an example of avformat and avcodec writing an h.265/hevc stream to file ?
[22:22:43 CET] <nohop> I've been working on it for days now. It will always produce something that can't be played with some players, or outputs a ton of "packet too large" messages... Write an avi that only displays balck frames in VLC ... etc
[22:23:02 CET] <nohop> the output examples that ship with ffmpeg do not work with HEVC at all
[22:23:09 CET] <JEEB> see the demux example and use the raw hevc demuxer (which basically reads the NALs), and then mux with the muxer of your choice. best alternatives would be mp4,mkv,mpegts
[22:23:23 CET] <JEEB> it shouldn't be any different from muxing avc
[22:23:44 CET] <nohop> i did use muxing.c, and changed the codec to HEVC. it's not playable
[22:23:48 CET] <nohop> not even by ffplay
[22:24:05 CET] <JEEB> well how are you taking in the data?
[22:24:13 CET] <JEEB> you should have AVPackets (I think)
[22:24:38 CET] <nohop> when i started i literally used muxing.c :) do, yes, with packets
[22:24:54 CET] <JEEB> no, I mean how do you read your raw thing?
[22:25:08 CET] <JEEB> also if you can share code that'd probably be simpler
[22:25:14 CET] <nohop> there's probably just some extra 'stuff' needed for hevc, that is not included in the examples
[22:25:31 CET] <JEEB> it should be exactly the same as with AVC
[22:25:38 CET] <JEEB> HEVC shouldn't be a special snowflake
[22:25:41 CET] <nohop> oh, well, hang on.. I'll have to reduce it back to the example-code then :) hang on
[22:25:59 CET] <JEEB> use a pastebin or a github repo or gist or whatever
[22:26:09 CET] <nohop> sure
[22:31:06 CET] <nohop> JEEB: http://pastebin.com/7bEChxhh
[22:31:43 CET] <BtbN> Does avi even support hevc?
[22:31:50 CET] <JEEB> "barely"
[22:31:57 CET] <JEEB> aka "please don't do it"
[22:32:16 CET] <BtbN> I'd rather test with something where it's actually supported
[22:32:36 CET] <JEEB> yes
[22:32:52 CET] <JEEB> which is why I mentioned mp4, matroska and mpegts there
[22:33:16 CET] <JEEB> nohop: that looks like encoding and muxing that instead of reading a stream and pushing it into a muxer
[22:34:03 CET] <nohop> what do you mean ? it's basically ffmpeg's muxing.c example :)
[22:34:20 CET] <JEEB> I would have thought that you had a raw HEVC stream, and you avformat_open_file'd it
[22:34:29 CET] <JEEB> started doing crap to it and demuxing it
[22:34:33 CET] <JEEB> then muxing that stream into a container
[22:35:19 CET] <nohop> where am i demuxing anything ?
[22:35:43 CET] <JEEB> you're not, that's why I noted that that code is encoding and muxing
[22:35:55 CET] <nohop> oooh, alright :)
[22:36:40 CET] <JEEB> because just keeping out of decoding and encoding and staying on the layer of just demuxing and muxing
[22:36:45 CET] <JEEB> that's a different level of complexity
[22:37:20 CET] <JEEB> so if your problem is putting HEVC bit stream into a container, I would have thought you were on that level
[22:38:04 CET] <nohop> I see. No.. And kind of had it working, by changing the contained to "mpeg", but i'll try "mov" or something
[22:38:13 CET] <nohop> I'll probably get back to you :) Thanks so far!
[22:38:33 CET] <JEEB> yes, you will want to try mp4, matroska or mpegts
[22:38:38 CET] <JEEB> mpeg is not really what you want
[22:41:51 CET] <nohop> yeah... and it looks like the example code actually works with "mov", and my code creates a file with black frames in it :) I'll have to go and see what i'm doing different (wrong)
[22:43:19 CET] <JEEB> those containers all can more or less take it in (the ones I mentioned and most likely mov)
[22:43:28 CET] <JEEB> avi is going to be a crapshoot anyways
[22:43:55 CET] <nohop> alright
[22:49:33 CET] <furq> s/shoot//
[22:49:50 CET] <JEEB> why would you not shoot AVI!
[22:50:25 CET] <furq> i've been so foolish
[23:43:18 CET] <xhip> "When asking a question be precise" let me try
[23:44:17 CET] <xhip> do I need something specific to get alsa while compiling my raspberry pi ?
[23:44:30 CET] <xhip> I tried 2 diff sources and nothing
[23:46:29 CET] <furq> xhip: you need asoundlib.h and libasound
[23:46:48 CET] <furq> libasound2-dev if you're on a debian-aliek
[23:46:49 CET] <furq> ke
[23:47:13 CET] <slalom_> it's a shame ffmepg can't do full HLS packaging, creating the iframe_index and a playlist m3u8 of all the qualities/etc.   The only two tools that do this are on OSX or unified-streaming's pay stuff.
[23:47:34 CET] <slalom_> we have a workflow that requires bringing stuff to an OSX machine to do that part, then copying it back
[23:47:43 CET] <xhip> "libasound2-dev is already the newest version."
[23:47:57 CET] <xhip> @furq weird.. I have it.
[23:48:02 CET] <furq> shrug
[23:48:03 CET] <furq> that should work
[23:48:14 CET] <xhip> ffmpeg -f v4l2 -i /dev/video0 -f alsa -i plughw:1 -ar 22050 -ab 64k -strict experimental -acodec aac -vcodec mpeg4 -y webcam.mp4
[23:48:29 CET] <xhip> "Unknown input format: 'alsa'"
[23:48:44 CET] <furq> did you rebuild ffmpeg
[23:49:18 CET] <xhip> yes
[23:49:23 CET] <xhip> http://pastebin.com/vKvhvM7T
[23:49:29 CET] <xhip> output of that command
[23:49:55 CET] <xhip> but yeh, I rebuild it using a tut. from a blog I even used make -j4
[23:50:00 CET] <xhip> to use 4 cores..
[23:51:25 CET] <furq> are you sure you had libasound2-dev installed when you built it
[23:51:46 CET] <xhip> I rebuild it this afternoon..
[23:52:12 CET] <xhip> I can try to make the process again..
[23:52:24 CET] <xhip> rebuild it
[23:52:30 CET] <furq> well if you do rebuild it you probably want to add --enable-omx-rpi --enable-mmal
[23:52:36 CET] <furq> and get rid of --target-os=linux, that's for cross compiling
[23:53:19 CET] <furq> also you should see alsa listed as an input device in the configure output
[23:53:38 CET] <furq> if it's not there then check config.log
[00:00:00 CET] --- Thu Feb 23 2017