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

[burek]

[02:57:31 CET] <Daycatz> test
[03:00:16 CET] <Daycatz> Hello, I have a question about FFmpeg with Nvidia Hw acceleration.. Can I ask about it?
[03:00:23 CET] <geri> hi
[03:04:28 CET] <klaxa> Daycatz: i probably don't know the solution to your problem but maybe someone else does, so just ask
[04:27:24 CET] <geri> hi klaxa
[06:50:24 CET] <hiihiii> hello
[06:50:48 CET] <hiihiii> I'm trying to play videos from youku.com
[06:51:21 CET] <fella> what is youku? and what's the problem with that?
[06:51:52 CET] <hiihiii> the input I give to ffmpeg/ffplay is an m3u8 playlist
[06:52:13 CET] <hiihiii> normally they work fine (e.g. twitch)
[06:53:15 CET] <hiihiii> but for some reason they don't for youku. I get HTTP error 403 forbidden
[06:53:46 CET] <iirc> Can you wget the files individually?
[06:54:27 CET] <iirc> a.k.a. wget "http://path-to-m3u8", then for each of the files listed inside, perform the same command, but instead on each of those URLs?
[06:54:50 CET] <hiihiii> the thing that's getting to me is : videos play up till a certain point then I get the error
[06:55:03 CET] <fella> like wget -i playlist.m3u8
[06:55:34 CET] <fella> does it work with other players, or from your browser?
[06:55:38 CET] <hiihiii> iirc, I didn't try that but I did try downloading them with my browser. and in that case I always get 403
[06:55:59 CET] <iirc> well, that sounds like a problem with youku, not ffmpeg
[06:56:01 CET] <hiihiii> I think i have to pass some sort of header
[06:56:34 CET] <iirc> perhaps - use the web inspector in chrome to sniff the network connection, you should  be able to see the header (and tokens) if anything special is sent
[06:56:38 CET] <hiihiii> yeah but why does videos play ok @ youku
[06:56:46 CET] <iirc> ^^
[06:57:32 CET] <iirc> could be some kind of anti-embedding technique, using some kind of authentication technique
[06:57:34 CET] <hiihiii> I'll try that w/ firefox if it has it
[06:57:52 CET] <iirc> Yeah from memory it does, it should be under the Network tab
[06:58:06 CET] <iirc> Also, I've got a question for everyone too
[06:58:13 CET] <fella> hiihiii: would you mind to paste one of those playlists on some nopaste?
[06:58:26 CET] <hiihiii> sure
[06:58:39 CET] <hiihiii> http://pl-ali.youku.com/playlist/m3u8?vid=XODY2ODc1NDg0&type=hd2&ups_client_netip=158.69.116.65&ups_ts=1509686192&utid=rumCEpcpCW4CAZ5FdEFgGZXp&ccode=0401&psid=15dfd74b503acf9de2cedf13befb3f6f&duration=2942&expire=18000&ups_key=265a171e6158575d55fa78168d1bedb6
[06:59:34 CET] <hiihiii> url too
[06:59:39 CET] <hiihiii> http://v.youku.com/v_show/id_XODY2ODc1NDg0.html
[07:00:23 CET] <iirc> I've got an .ogg file, encoded with vorbis, and it doesn't appear to be able to be decoded by ffmpeg. I've got some pastebin links if need be, plus a link to the raw music file.
[07:00:32 CET] <iirc> hex dump: https://pastebin.com/RbNYcDzt
[07:00:41 CET] <iirc> Decoder list: https://pastebin.com/6AMjBYLK
[07:00:48 CET] <iirc> ffprobe results: https://pastebin.com/BshJ6vcP
[07:01:29 CET] <iirc> Now, VLC is able to play it, so it can't be a corrupt file, as I've got a few others like it too
[07:03:57 CET] <fella> iirc: what does 'file song.ogg' tell you?
[07:04:21 CET] <iirc> "song.ogg: Ogg data"
[07:05:31 CET] <iirc> as compared to "otherfile.ogg: Ogg data, Vorbis audio, stereo, 48000 Hz, ~112000 bps" for an ogg file that ffmpeg can decode
[07:08:31 CET] <hiihiii> are you batch converting
[07:09:57 CET] <iirc> hiihii: me? nope, $ ffprobe song.ogg, fails (unless I'm misunderstanding what batch converting means)
[07:11:53 CET] <fella> _maybe_ your header is corrupt / partly missing - vlc just guesses and plays the data part anyway .. not quite sure
[07:12:31 CET] <iirc> That's what I'm thinking too - do you reckon I can just create a header and splice it verbatim?
[07:13:23 CET] <iirc> Problem is, I have about 1k of these files... so it's a bit difficult to do manually - plus VLC's inbuilt converter is terrible
[07:13:25 CET] <hiihiii> iirc libvorbis and vorbis are different
[07:13:58 CET] <hiihiii> ehh vorbis is not an ffmpeg encoder anymore k
[07:14:22 CET] <iirc> hiihiii: problem is, I've got both decoders, https://pastebin.com/6AMjBYLK
[07:15:21 CET] <hiihiii> can you see the info of it in vlc
[07:17:05 CET] <hiihiii> emm there's no libvorbis decoder for ffplay
[07:17:29 CET] <iirc> You sure you've compiled with it? I built from source
[07:18:11 CET] <iirc> But yep, hiihiii: Codec: Vorbis Audio (vorb), Bitrate: 160kb/s, Channels: Stereo, Type: Audio
[07:19:34 CET] <hiihiii> I'm reading ffplay documentation, there's no libvorbis decoder
[07:20:10 CET] <hiihiii> at least no documentation for it
[07:21:35 CET] <hiihiii> ahh sorry I though you were saying you couldn't play your files in ffply
[07:21:44 CET] <hiihiii> my bad
[07:22:02 CET] <fella> hiihiii: but i just created an ogg with 'ffmpeg .. -c:a libvorbis ..' and i'm able to play it with ffplay
[07:25:00 CET] <hiihiii> try with libtheora
[07:26:29 CET] <hiihiii> but output only audio
[07:26:37 CET] <hiihiii> see if that works for you
[07:29:13 CET] <iirc> hiihiii: as in, "ffmpeg -c libtheora -i song.ogg -c:a libvorbis outfile2.ogg"?
[07:36:20 CET] <iirc> btw hiihiii, looks like they've got a custom js player generating the keys, as a sort of DRM
[07:36:48 CET] <iirc> explains why it works for a short time, the keys seem to rotate
[07:37:24 CET] <iirc> i guess to download from here, you'll rev engineer the JS to generate the keys as part of a download script
[07:38:14 CET] <iirc> i found a good solution however, youtube-dl seems to be able to download it
[07:39:10 CET] <iirc> its a bit slow to download, I'm only getting 250KiB/s
[07:40:53 CET] <hiihiii> iirc, as in "ffmpeg -i input -c copy -f libtheora - | ffmpeg -i pipe:0 -c:a copy output.ogg"
[07:42:57 CET] <iirc> just tried that, doesn't work unfortunately, https://pastebin.com/qJPdLYCF
[07:43:01 CET] <fella> iirc: yt-dl? but it didn't managed to work on that m3u8 in my case
[07:43:13 CET] <iirc> nope, just point it at the original site
[07:43:39 CET] <iirc> i.e. fella: $ youtube-dl http://v.youku.com/v_show/id_XODY2ODc1NDg0.html
[07:43:39 CET] <hiihiii> oh I can get th file directly from my browser's cache
[07:43:50 CET] <iirc> haha, nice
[07:43:51 CET] <hiihiii> it's just that why it doesn't work
[07:43:58 CET] <fella> iirc: ok i fumbled around a bit with vlc -  maybe you'ld like to try something like this: 'for f in bad*ogg; do vlc -I dummy -v "$f" --sout "#transcode{vcodec=none,acodec=vorb,ab=128,channels=2,samplerate=44100}:file{dst="${f//.ogg}".repaired.ogg}"; done'
[07:45:38 CET] <fella> problem is, it seems to stop at the end of each file, but 'killall vlc' will start the next encoding .. it's a bit bungling :(
[07:46:00 CET] <hiihiii> iirc, what's not working in that cmd?
[07:46:33 CET] <hiihiii> does't it generate an output? I don't have libtheora or libvorbis
[07:46:56 CET] <iirc> hiihiii: i pasted the output into a pastebin as above
[07:47:38 CET] <iirc> also, fella looks like it works pretty well (ctrl-c) to stop, didn't realise I could use the vlc commandline to convert (the gui one was ridiculously clumsy)
[07:47:42 CET] <iirc> i'll have a play around
[07:48:11 CET] <iirc> cheers fella
[07:48:54 CET] <fella> yw :)
[07:49:55 CET] <hiihiii> k wait "pipe:0: Invalid data found when processing input"? I don't see where this is coming from?
[07:50:47 CET] <hiihiii> ffmpeg -i input -c copy -f libtheora pipe:1 | ffmpeg -i pipe:0 -c:a copy -vn output.ogg
[07:50:53 CET] <iirc> hiihiii: it's likely because no output is coming from the first command
[07:51:16 CET] <iirc> will try
[07:53:26 CET] <iirc> hiihiii: similar result https://pastebin.com/8DWGWS07
[07:58:07 CET] <hiihiii> it's oga not ogg
[07:58:10 CET] <hiihiii> ffmpeg -i input -c copy -f libtheora pipe:1 | ffmpeg -i pipe:0 -c:a copy -vn output.oga
[07:58:24 CET] <hiihiii> try 1st one though
[07:58:39 CET] <hiihiii> ffmpeg -i input -c copy -f libtheora - | ffmpeg -i pipe:0 -c:a copy output.oga
[08:00:15 CET] <iirc> problem is not with the second command, the first command refuses to execute
[08:01:49 CET] <hiihiii> all those errors were related to the second part
[08:01:55 CET] <hiihiii> [ogg @ 0x5606f85876c0] Codec not found
[08:02:12 CET] <hiihiii> pipe:0: Invalid data found when processing input
[08:03:09 CET] <hiihiii> 1st part just outputs to stdout and then it reads from there again
[08:03:45 CET] <iirc> nope, the Codec not found happens with just the first command
[08:04:32 CET] <iirc> i'm actually looking at the hexdumps of the repaired file (from fella) and my original file, and they're pretty similar (except that everything is offset by one byte)
[08:04:37 CET] <hiihiii> ok I don't have those codecs so I can't really tell you anything
[08:05:20 CET] <iirc> all good, cheers for the help
[08:05:37 CET] <iirc> just looks like the header information is slightly incorrect
[08:50:04 CET] <styler2go> Can i tell ffmpeg to stop after one minute transcoding from an rtsp stream?
[08:55:15 CET] <fella> styler2go: ffmpeg ... -t 00:00:01.00 ... should work
[08:55:37 CET] <styler2go> fella even for streams? i'll just give it a try, thank you
[08:56:02 CET] <Nacht> That's one second though :)
[08:57:11 CET] <styler2go> no problem, i'll figure otu how much time i need if it works.. i am trying to make a ip camera recorder kind of
[08:58:25 CET] Action: fella needs to read more carefully
[08:58:49 CET] <fella> anyway - that will get them quicker results ;)
[09:00:41 CET] <styler2go> hmm sevrer returned 401, can i send http auth with ffmpeg?
[09:04:28 CET] <fella> styler2go: ffmpeg -i rtsp://USER:PW@...
[09:08:28 CET] <styler2go> hmm doesn't seem to accept the user at least
[09:12:29 CET] <fella> styler2go: can't test it here, sry
[10:34:50 CET] <minru> Hello, how to keep the video/audio sync when transcoding UDP(mpeg2) or UDP(h264) -> UDP(h264) and the source is far away from ideal, there a lot of lost frames, and sooner or later the sync is lost?
[17:49:04 CET] <DocHopper_> Hey FFMPEG, working on a webcam capture command in linux and was hoping there was a better way than /dev/videox to point to a USB device.  Can I use the device name in some fashon like in windows?
[17:52:24 CET] <jkqxz> DocHopper_:  /dev/vl4/by-id/
[17:55:28 CET] <DocHopper_> jkqxz: And then the device name, or replace "by-id"?
[17:57:20 CET] <jkqxz> Look in that directory.  It makes a device name using some id strings from the device.
[18:07:52 CET] <hopper_> join #hopperlabs
[18:14:51 CET] <DocHopper> Alright, I've got a dual webcam capture running on my lattepanda, but being that it's not a strong processor, I need to method of making it more lean so it can run at a higher framerate.  Any suggestions?
[18:14:53 CET] <hopper_> https://pastebin.com/uNkKypbW
[18:18:35 CET] <jkqxz> "HD_Camera_Manufacturer_USB_2.0_Camera"?  Nice useful device name there.
[18:19:07 CET] <DocHopper> jkqxz: It's a generic little camera, I can post the ffmpeg format list if you want.
[18:19:33 CET] <DocHopper> jkqxz: It was the cheapest ultra wide angle I could find.
[18:20:01 CET] <jkqxz> What sort of machine is it?  Some hardware encoders will be able to do similarly to libx264 ultrafast while using less CPU, though your filter stuff may be more of the problem.
[18:21:40 CET] <DocHopper> jkqxz: A single board comp, latte panda, http://www.lattepanda.com/product-details/?pid=3
[18:25:27 CET] <jkqxz> The VAAPI encoder should work on that.
[18:27:40 CET] <DocHopper> jkqxz: looking at https://trac.ffmpeg.org/wiki/Hardware/VAAPI but I'm not sure where to start.
[18:33:24 CET] <DocHopper> jkqxz: Suggestions on how to use VAAPI?
[19:41:36 CET] <xeche> hi guys. trying to figure out why my transcoded file fails to get a frame on the first couple of packets (receive_frame eventually returns a valid frame). any tips?
[19:44:12 CET] <kepstin> that's normal and expected with modern video codecs.
[19:45:35 CET] <kepstin> it should be returning AVERROR(EAGAIN) in that case, which basically means "the decoder needs more data before it can produce a frame"
[19:45:37 CET] <xeche> kepstin: okay. my input was not like that though. so what i'm trying to understand is what constitutes the difference between getting a full frame from the first packet, or having to read several packets before getting a full frame
[19:46:14 CET] <kepstin> xeche: using a modern video codec with B (bidirectionally predicted frames) means that in some cases the decoder has to receive and process multiple packets before it can output the first frame.
[19:46:36 CET] <xeche> is x264 "modern" ?
[19:46:38 CET] <kepstin> yes
[19:47:17 CET] <kepstin> note that you can turn this feature off in x264, but doing so means its less efficient (so you'll get worse quality or larger files)
[19:47:47 CET] <xeche> alright. so, since i specificed basically no parameters besides start time and duration, ffmpeg may have decided to do encode it differently than the input file, even if they are both 264?
[19:48:08 CET] <xeche> different with respect to bi-directional frames, i mean
[19:48:09 CET] <kepstin> yes, that's almost certainly the case. The encoding parameters of the output have nothing to do with the input, after all.
[19:50:42 CET] <xeche> kepstin: alright thanks. i still don't understand why it never returns anything but AVERROR(EAGAIN) though
[19:51:06 CET] <xeche> your explanation covers the first two times, then it starts decoding as expected, but I don't get an EOF
[19:51:12 CET] <kepstin> xeche: not sure what you mean, https://www.ffmpeg.org/doxygen/3.1/group__lavc__encdec.html describes the usage of the api
[19:51:58 CET] <kepstin> then decoding, you have to submit a NULL packet to the decoder with send_frame to tell it that it's at the end of the file, then you can receive frame until you get AVERROR_EOF
[19:52:46 CET] <xeche> ah, I think see what I missed here. av_read_frame probably returns an EOF that I'm not handling correctly?
[19:53:39 CET] <kepstin> xeche: if you're getting AVERROR(EAGAIN), then the problem is that you didn't start draining mode by sending a NULL packet to the decoder.
[19:53:48 CET] <kepstin> it will return a different code for EOF.
[19:54:26 CET] <xeche> right. and to know when  i should initiate draining mode, I have to watch the return value of av_read_frame?
[19:54:57 CET] <kepstin> well, however you're getting packets, it's up to you to notice an EOF and pass it on to the decoder(s)
[19:55:27 CET] <xeche> alrighty. seems pretty straight forward. thanks. :)
[19:56:21 CET] <kepstin> ah, i didn't notice you were talking about av_read_frame there, yeah. 'receive_frame' and 'read_frame' are too similar :)
[19:58:07 CET] <kepstin> yes, av_read_frame should be returning AVERROR_EOF at EOF.
[19:59:18 CET] <xeche> kepstin: worked like a charm. thanks again. :)
[20:14:52 CET] <DocHopper> Okay ffmpeg, I've not been able to get any hardware decoding going, but I've dropped my framerate input which has helped my CPU usage.  My next issue is an abrupt decrease in quality after the first few frames.  Does anyone know what causes this?  https://imgur.com/a/KJG2r
[20:18:24 CET] <BtbN> Decoding does not cause quality loss. Unless that is some super exotic codec I have never heard of
[20:18:57 CET] <DocHopper> BtbN: I'm sorry, encoding.  I'll paste my code again.
[20:19:45 CET] <hopper_> BtbN, https://pastebin.com/35BLtSTH
[20:20:30 CET] <BtbN> You're not setting any encoder setting there
[20:20:37 CET] <BtbN> So you will end up with the defaults
[20:20:50 CET] <BtbN> Which I have no idea what codecs that are for mpeg-ts, but nothing good it seems
[20:21:11 CET] <DocHopper> BtbN: Ya, it looks terrible, any ideas on how to improve?
[20:21:39 CET] <BtbN> pick proper codecs and set setting for them that suit your needs
[20:22:11 CET] <DocHopper> Is there a resource I can follow to determine my needs and how to fulfill them?
[20:22:28 CET] <BtbN> h264 encoding wiki page I guess
[20:23:28 CET] <furq> BtbN: m2v and mp2 iirc
[20:25:18 CET] <DocHopper> furq: Those are the codecs for .ts?
[20:25:29 CET] <alexpigment> sorry - coming in mid-convo on this
[20:25:33 CET] <alexpigment> but TS supports a lot
[20:25:41 CET] <alexpigment> including h264
[20:25:47 CET] <furq> DocHopper: those are the defaults
[20:25:47 CET] <alexpigment> a lot of audio formats too
[20:26:24 CET] <DocHopper> alexpigment: No problem, you've seen my command and my issues?  I'm not using audio, so that's nice.
[20:27:03 CET] <alexpigment> no, it just seemed like there was an assumption that ts only supported m2v and mp2
[20:27:19 CET] <alexpigment> maybe i read that wrong, but as a person who uses TS constantly, i know it supports a lot of formats
[20:27:47 CET] <alexpigment> anyway, MPEG-2 in FFMPEG sucks, if that's what we're discussing
[20:28:04 CET] <DocHopper> alexpigment: In my case it looks terrible, do you know what I'm doing wrong?  https://imgur.com/a/KJG2r
[20:28:12 CET] <hopper_> https://pastebin.com/35BLtSTH
[20:29:03 CET] <alexpigment> DocHopper: MPEG-2 in FFMPEG has a really bad i-p-b ratio, and so i see those artifacts like that commonly
[20:29:09 CET] <alexpigment> usually it "pumps" on regular intervals
[20:29:31 CET] <alexpigment> you can work around it slightly if that's the case
[20:29:42 CET] <alexpigment> can you confirm that it pumps/pulses at intervals?
[20:30:10 CET] <DocHopper> That the video cycles from good to bad over and over?
[20:30:10 CET] <furq> DocHopper: add -c:v libx264
[20:30:18 CET] <DocHopper> furq: I'll try that now.
[20:30:27 CET] <furq> you're setting -preset ultrafast so i assume that's what you actually want
[20:30:33 CET] <alexpigment> also, if H.264 is an option, then yes. do that. listen to furq :)
[20:30:51 CET] <DocHopper> furq: I do not know that it is what I want, but it was suggested previously to help lower CPU usage.
[20:31:12 CET] <furq> it's an x264 preset, so it doesn't do anything unless you're using x264
[20:33:05 CET] <DocHopper> furq: It look wonderful now, but has doubled my CPU usage.
[20:33:52 CET] <furq> try dropping to -crf 30 or something
[20:34:32 CET] <DocHopper> That is related to the presets, correct?
[20:34:42 CET] <furq> crf is the quality
[20:34:54 CET] <furq> higher numbers are lower quality
[20:35:09 CET] <furq> but they should also use less cpu
[20:35:39 CET] <furq> i'm pretty sure x264 will be faster than m2v given an acceptable quality level, but it might depend on the cpu
[20:36:09 CET] <DocHopper> Okay, so leave -preset as ultrafast and add -crf 30?
[20:36:12 CET] <furq> yeah
[20:36:51 CET] <furq> you might also want to use yuv420p instead of yuyv422 and maybe drop the video size a bit
[20:37:06 CET] <DocHopper> The webcams don't list that as a supported option.
[20:37:16 CET] <furq> you can have ffmpeg convert to that
[20:37:23 CET] <furq> in both cases
[20:37:24 CET] <alexpigment> -crf 30? that's pretty ow
[20:37:27 CET] <alexpigment> *low
[20:37:40 CET] <alexpigment> honestly, i've never used below crf 23 ever
[20:37:52 CET] <furq> i have and it's passable
[20:37:56 CET] <DocHopper> -crf 30 is looking just fine, and using less CPU.
[20:37:57 CET] <furq> obviously not for archival
[20:37:58 CET] <alexpigment> i'll take your word for it
[20:38:10 CET] <furq> but then i wouldn't use 23 for archival either
[20:38:14 CET] <alexpigment> right
[20:38:22 CET] <alexpigment> i use only 18 or lower usually
[20:38:27 CET] <furq> 18-21 here
[20:38:46 CET] <DocHopper> though my CPU is still a boatload higher after adding -c:v libx264
[20:38:51 CET] <furq> but yeah 30ish is broadly fine
[20:39:00 CET] <furq> it's about what you'd get on a lot of web streams
[20:39:08 CET] <furq> DocHopper: what cpu is it
[20:39:12 CET] <alexpigment> dochopper: again, i'm coming in late and furq usually has the right answers, but are you on windows or linux?
[20:39:40 CET] <alexpigment> if so, this might be a situation to use hardware encoding via intel or nvidia, if that's an option
[20:39:47 CET] <alexpigment> your cpu usage will go way down
[20:39:48 CET] <DocHopper> Linux, on a lattePanda, it's a intel cheery Trail cpu.
[20:40:06 CET] <DocHopper> *cherry*
[20:40:11 CET] <alexpigment> hmm. i don't remember is linux supports qsv encoding
[20:40:15 CET] <furq> linux does
[20:40:19 CET] <furq> i'm not sure if cherry trail does
[20:40:44 CET] <DocHopper> furq: What were you saying about using yuv420p vs yuyv422?
[20:40:46 CET] <furq> wikipedia reckons it does have h264 encoding
[20:41:18 CET] <alexpigment> yuv420p is what you should be using for this doc
[20:41:33 CET] <furq> DocHopper: add -vf format=yuv420p as an output option
[20:41:55 CET] <alexpigment> furq: any reason to use that rather than -pix_fmt yuv420p?
[20:41:59 CET] <alexpigment> or is it the same?
[20:42:00 CET] <furq> they do the same thing
[20:42:03 CET] <alexpigment> k
[20:42:20 CET] <alexpigment> some cherry trail CPUs support quick sync, some don't apparently
[20:42:22 CET] <furq> -pix_fmt, -r, -s etc just insert the relevant filter into the chain
[20:42:28 CET] <alexpigment> what CPU is it exactly?
[20:42:47 CET] <furq> yeah if you do have quicksync then that'll definitely be the way to go for low cpu usage
[20:42:47 CET] <DocHopper> alexpigment: Intel Cherry Trail Z8300 Quad Core 1.8GHz
[20:42:56 CET] <furq> idk how you actually use it on linux though
[20:43:13 CET] <alexpigment> the x5-z8300 does apparently
[20:43:21 CET] <furq> maybe just -c:v h264_vaapi
[20:43:29 CET] <alexpigment> probably. checking now
[20:43:33 CET] <furq> it'd be nice if it was that simple
[20:43:54 CET] <alexpigment> well, if it's anything like the windows implementation, you have to also specify -look_ahead 0
[20:44:12 CET] <hopper_> furq, Error: Filtergraph 'format=yuv420p' was specified through the -vf/-af/-filter option for output stream 0:0, which is fed from a complex filtergraph.
[20:44:23 CET] <alexpigment> and you'd never know this without spending an hour tearing your hair out
[20:45:43 CET] <furq> oh right
[20:45:56 CET] <DocHopper> So, should I change my -c:v libx264 to h264_vaapi?
[20:46:10 CET] <furq> it's worth a try
[20:47:10 CET] <hopper_> furq, Error: Unknown encoder 'h264_vaapi'
[20:47:41 CET] <alexpigment> well, there's that
[20:48:04 CET] <alexpigment> could be a driver issue, could be an older ffmpeg, could be that the CPU somehow doesn't support it even though it seems like it does
[20:48:32 CET] <DocHopper> Linux support for this device is dismal.
[20:53:38 CET] <DocHopper> furq: Thanks for all your help, is there something else I should be working towards for HW encoding or optimizing for lowered CPU usage?
[20:54:11 CET] <DocHopper> Also, are we giving up on yuv420p?
[20:55:13 CET] <DocHopper> alexpigment: Anything else you can think of to try?
[20:55:45 CET] <alexpigment> no, H.264 is more complex than MPEG-2 inherently, so you're going to be using more CPU with H.264, but you don't have any many quality problems
[20:56:10 CET] <alexpigment> so if CPU is really limited (as it is on a cherry trail CPU), you'd ideally go to hardware, which doesn't seem like it's an option
[20:56:30 CET] <alexpigment> anyway, if you're specifying yuyv422, change it to yuv420p
[20:57:10 CET] <alexpigment> otherwise, you're doing double the color information for little benefit due to the fact that almost all delivery video is 420p
[20:58:17 CET] <DocHopper> alexpigment: I can try that, but I assumed it wouldn't work since that wasn't a listed format on the webcam outputs.
[20:58:41 CET] <alexpigment> well, this would be in the output section
[20:58:47 CET] <alexpigment> -pix_fmt yuv420p
[21:00:02 CET] <DocHopper> It's worth pointing out to furq that -pix_fmt yuv420p worked where -vf format=yuv420p did not.
[21:00:36 CET] <alexpigment> cpu usage any lower?
[21:00:37 CET] <DocHopper> alexpigment: Great thinking that's decreased CPU usage by almost 20%
[21:00:48 CET] <alexpigment> cool
[21:01:17 CET] <alexpigment> it may be worth raising the crf value now that you've done that
[21:01:42 CET] <alexpigment> i'm not sure what your bitrate limitations are, but something like crf 23 or 24 would be a good place to start
[21:01:49 CET] <alexpigment> see if the cpu usage changes dramatically
[21:02:46 CET] <alexpigment> admittedly, i don't really know how much crf affects CPU usage. I've never been in a situation where I had to trade off between the two
[21:03:20 CET] <DocHopper> I can experament with that a bit, but I will say the video quality is miles above what it is before and imo, nothing to shake a stick at.
[21:03:37 CET] <alexpigment> k
[21:03:46 CET] <DocHopper> alexpigment: I hope you're a native english speaker so that makes sense. ^_^
[21:03:55 CET] <alexpigment> yep :)
[21:11:42 CET] <DocHopper> furq, alexpigment: https://imgur.com/a/KJG2r
[21:12:59 CET] <alexpigment> nice
[21:13:46 CET] <alexpigment> i saw the frame rate was 9 in your code - is that correct?
[21:13:58 CET] <alexpigment> it's probably better to put something evenly divisible by your display
[21:14:11 CET] <alexpigment> e.g. 10 or 15
[21:14:26 CET] <alexpigment> unless that's what your webcam natively supports
[21:14:36 CET] <DocHopper> alexpigment: https://pastebin.com/6gX4GnzC
[21:14:42 CET] <alexpigment> it's not a huge deal, but it does make motion more evenly smooth, even if it's still not smooth
[21:15:26 CET] <alexpigment> ah
[21:15:37 CET] <alexpigment> did you try using the mjpeg 1080p30 already?
[21:15:41 CET] <alexpigment> not sure how that'll affect CPU
[21:16:07 CET] <alexpigment> or rather, 720p60
[21:16:08 CET] <DocHopper> I can only get 8 fps when I use mjpeg.
[21:16:11 CET] <alexpigment> k
[21:16:14 CET] <DocHopper> You mean 60.0002?
[21:16:15 CET] <alexpigment> just figured i'd ask
[21:16:28 CET] <alexpigment> yeah
[21:16:36 CET] <DocHopper> I get a laugh out of using that one.
[21:17:00 CET] <alexpigment> gotta love it when webcams invent their own frame rate standards
[21:17:31 CET] <DocHopper> Yup, Well I can give 30fps a try again with the new output codec, but I expect to see the same limitations.
[21:18:00 CET] <alexpigment> probably so
[21:45:50 CET] <dystopia_> ffmpeg.exe -i aac_test.ts -vcodec copy -acodec aac -latm 1 -b:a 120k out.ts
[21:45:52 CET] <dystopia_> Unrecognized option 'latm'.
[21:46:00 CET] <dystopia_> anyone got any ideas?
[21:48:15 CET] <dystopia_> https://ffmpeg.org/ffmpeg-codecs.html#Options-8
[21:48:44 CET] <furq> dystopia_: latest ffmpeg?
[21:48:49 CET] <dystopia_> latm is supposed to be an option in libfdk_aac
[21:48:56 CET] <furq> oh
[21:48:57 CET] <dystopia_> yes furq
[21:49:01 CET] <furq> well yeah you're not using that, you're using aac
[21:49:08 CET] <dystopia_> oh
[21:49:12 CET] <furq> if your build has fdk then -c:a libfdk_aac
[21:50:05 CET] <dystopia_> gives the same error
[21:50:24 CET] <furq>  did you remove -acodec aac
[21:51:01 CET] <dystopia_> yeah
[21:51:10 CET] <dystopia_> ffmpeg.exe -i aac_2chan_128.ts -vcodec copy -c:a libfdk_aac -latm 1 -b:a 120k test.ts
[21:52:13 CET] <furq> shrug
[21:52:14 CET] <furq> that works here
[21:52:29 CET] <josefig_> hello, can you help me with this? im trying to convert from ogg file to gsm using this: /usr/bin/ffmpeg  -i j695r1mQVf.ogg -c:a libgsm -ar 8000 -ab 13000 -ac 1 -f gsm j695r1mQVf.gsm, but the output says no output because of the gsm format
[21:53:50 CET] <alexpigment> josefig_: does libgsm_ms work?
[21:54:22 CET] <josefig_> alexpigment: not working, i installed from repo on centos 6 the ffmpeg but i will compile i assume
[21:54:22 CET] <alexpigment> actually, nm. the encode works, but the format doesn't
[21:55:06 CET] <alexpigment> yeah, it's worth compiling and making sure you have the latest code
[21:55:09 CET] <utack> wow ffmpeg supports some insane formats
[21:55:54 CET] <josefig_> alexpigment: ok great, can you please refer me to the libgsm_ms homepage? please because i found Multicast Audio Streaming Toolkit https://github.com/njh/mast
[21:56:03 CET] <alexpigment> yeah, there are a lot of telephony formats (amr, adpcm, etc)
[21:56:07 CET] <utack> does the latest static build work too? https://ffmpeg.org/download.html
[21:56:17 CET] <utack> or does it use system provided libgsm and fail?
[21:56:35 CET] <alexpigment> josefig_: i just suggested it because it was listed as an alternate encoder when I did a list of codecs
[21:56:43 CET] <alexpigment> i don't know what pages exist
[21:57:04 CET] <alexpigment> but the error you mentioned sounds like it's having a problem with the *format* itself
[21:57:13 CET] <alexpigment> like where you're specifying -f gsm
[21:57:13 CET] <josefig_> alexpigment: you're right
[21:57:55 CET] <josefig_> alexpigment: is there a way to see in my local installation of ffmpeg the supported formats?
[21:58:02 CET] <alexpigment> yeah
[21:58:14 CET] <alexpigment> ffmpeg -formats
[21:58:46 CET] <josefig_> D  gsm             raw GSM
[21:58:53 CET] <alexpigment> D means it's decode-only
[21:58:59 CET] <alexpigment> it should have DE beside it
[21:59:04 CET] <josefig_> ok, so i need to install the encoder
[21:59:19 CET] <alexpigment> no, just get a new static build as utack suggested
[21:59:40 CET] <josefig_> ok
[21:59:47 CET] <josefig_> thanks alexpigment, utack
[21:59:48 CET] <josefig_> let me check
[22:09:10 CET] <josefig_> this is the error from static build: Unknown encoder 'libgsm'
[22:18:06 CET] <alexpigment> ok, do ffmpeg codecs
[22:18:08 CET] <alexpigment> er
[22:18:10 CET] <alexpigment> ffmpeg -codecs
[22:18:24 CET] <alexpigment> is libgsm listed?
[22:18:50 CET] <josefig_> no, only D.A.L. gsm and D.A.L gsm_ms
[22:19:04 CET] <alexpigment> yeah, it would need to have E for it to encode
[22:19:14 CET] <alexpigment> well, it looks like you're going to have to compile your own build then
[22:19:25 CET] <josefig_> crap, ok
[22:21:48 CET] <josefig_> alexpigment: where can i see the compilation guide or something ? I use centos 6 for production
[22:22:23 CET] <alexpigment> https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[22:22:29 CET] <alexpigment> that's the most help I can give
[22:22:40 CET] <josefig_> ok, i appreciate it alexpigment
[22:22:48 CET] <alexpigment> I've never even looked at CentOS, so... :)
[22:26:36 CET] <hiihiii> hello
[22:27:00 CET] <hiihiii> what are the font families I can use for drawtext filter?
[22:27:14 CET] <BtbN> All the ones you have?
[22:28:21 CET] <hiihiii> I'm guessing this works like css. you omit a font byt specify a family and it'll work
[22:28:53 CET] <hiihiii> I'm setting font=sans but no fontfile
[22:29:15 CET] <hiihiii> it doesn't work though
[22:29:34 CET] <sfan5> just specify the path to the file
[22:30:07 CET] <hiihiii> ok so fontfile is mandatory
[22:31:45 CET] <Pegasik> can you explain the difference between he and hev2 for AAC?
[22:32:21 CET] <rIMpossible> Hi, where do I find the prerequisites for building ffmpeg on OpenBSD? doc/build_system.txt is only (g)make instructions
[22:32:52 CET] <BtbN> I don't see what it would be any different on BSD
[22:36:43 CET] <rIMpossible> Building with only ./configure and gmake -j 4 all made no problems, with ./configure --enable-openssl it ended with errors. We have libressl ...
[22:45:13 CET] <JEEB> rIMpossible: newer libressl versions became very obnoxious to support so support hasn't been added yet
[22:45:35 CET] <JEEB> if you have gnutls available, use that
[22:45:50 CET] <JEEB> (the option is the same way, just replace openssl with gnutls)
[22:45:52 CET] <rIMpossible> JEEB: I will look for it, if it's in ports
[22:47:33 CET] <sfan5> hm that's remind me i wanted to send ffmpeg a patch for libressl support
[22:47:51 CET] <rIMpossible> JEEB: for api incompatible progs we have even openssl in ports. Did not know that
[22:48:06 CET] <JEEB> not surprising
[22:52:30 CET] <rIMpossible> sfan5: Are you on OpenBSD?
[22:52:38 CET] <sfan5> no
[22:52:52 CET] <BtbN> There was a patch for libressl support
[22:52:55 CET] <BtbN> I think it was rejected
[22:53:01 CET] <JEEB> #ifdef hell
[22:53:03 CET] <BtbN> Too much insane ifdefery
[22:53:23 CET] <BtbN> So for a patch for libressl to be accepdted, it has to add it as independend backend
[22:53:32 CET] <sfan5> ugh
[22:53:58 CET] <sfan5> might as well add libtls support directly then
[22:54:15 CET] <BtbN> With openssl and libressl diverging more and more, the ifdef hell to have one backend for both would be just hellish
[22:54:22 CET] <JEEB> yea
[22:54:29 CET] <JEEB> unless someone found a very special way of doing it
[22:54:36 CET] <JEEB> but unlikely
[22:54:46 CET] <BtbN> Then libressl drops another symbol, and that way breaks
[22:54:55 CET] <teratorn> is libressl no longer drop-in compatible with (a subset of) openssl ?
[22:55:01 CET] <BtbN> it never was
[22:55:08 CET] <BtbN> They dropped a lot of openssl API
[22:55:12 CET] <teratorn> it was pretty damn close
[22:55:17 CET] <teratorn> i said subset
[22:55:24 CET] <BtbN> And then openssl changed its API
[22:55:32 CET] <teratorn> *shrug*
[22:55:35 CET] <BtbN> so supporting openssl 1.1 and libressl at the same time is close to impossible
[22:55:43 CET] <BtbN> without a hell lot of ifdefs
[22:55:49 CET] <teratorn> that's wonderful
[22:56:18 CET] <teratorn> reminds me of the nightmare that was libav vs ffmpeg fork and the ifdef hell there
[22:56:42 CET] <teratorn> then libav jerks start adding codec IDs that were already used in ffmpeg, for different codecs
[22:58:00 CET] <teratorn> ah, I guess that is preaching to the choir here :/
[22:59:17 CET] <rIMpossible> No luck on OpenBSD 6.2-stable :( http://sprunge.us/DgSD
[23:01:11 CET] <rIMpossible> How can I see or configure that it takes the openssl from ports and not the installed libressl from base sys?
[23:01:38 CET] <rIMpossible> configure opt is --enable-openssl
[23:02:30 CET] <BtbN> put the ports directory first in your pkg config path, so it's found first
[23:04:12 CET] <rIMpossible> BtbN: It is in /usr/local/lib/eopenssl
[23:10:31 CET] <Johnjay> any of you guys have a clue how vlc works?
[23:10:46 CET] <Johnjay> i've been trying to get the vlm rtsp streaming to work but no luck
[23:23:35 CET] <rIMpossible> BtbN: with configure option --pkgconfigdir=/usr/local/lib/eopenssl ?
[23:23:51 CET] <BtbN> just sort your PKG_CONFIG_PATH properly
[23:26:47 CET] <Johnjay> JEEB: you thar??
[23:33:18 CET] <DocHopper> Hey FFMPEG users, for what do you use FFMPEG?
[23:33:52 CET] <DocHopper> Just curious of everyone's implementation.
[23:34:01 CET] <JEEB> live streaming, clip creation, remuxing, whatever
[23:34:32 CET] <DocHopper> JEEB: Streaming and clipping what?
[23:34:56 CET] <JEEB> with live streaming it's usually either a capture device or UDP
[23:35:12 CET] <JEEB> clip creation can be from basically whatever lavf can eat
[23:35:53 CET] <JEEB> depending on your use case you might want to use something that doesn't come from FFmpeg for the input and output parts (reading data and demultiplexing and the same outwards)
[23:36:16 CET] <JEEB> decoding and encoding is something libavcodec is really good at and often you just don't have less insane alternatives
[23:36:40 CET] <Mavrik> QuickTime!
[23:36:56 CET] <JEEB> that's a framework
[23:38:15 CET] <Mavrik> I'll let myself out
[23:43:15 CET] <rIMpossible> export PKG_CONFIG_PATH=/usr/local/lib/eopenssl ; ./configure --enable-openssl
[23:43:27 CET] <rIMpossible> seems not to work (I am no developer)
[23:44:22 CET] <rIMpossible> OpenSSL 1.0.2l
[23:53:16 CET] <furq> rIMpossible: PKG_CONFIG_PATH is the path to the .pc file, which i assume isn't in that path
[23:53:27 CET] <furq> if you don't have a .pc then use --extra-cflags and --extra-ldflags
[00:00:00 CET] --- Sat Nov  4 2017