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

burek burek021 at gmail.com
Mon Jul 31 03:05:02 EEST 2017


[00:53:02 CEST] <ZexaronS> hello
[00:56:40 CEST] <ZexaronS> I kinda floated this idea a few times but nothing conclusive (i'm still busy with other projects and chores) the idea of making some kind of algorithm to use good analysis on top of a video or a large volume of images, that would also offer detailed parameters to fine tune, but basically it would create a very good looking smooth timelapse but also at a good storage size, because it would detect movement at pixel level, analysing
[00:56:40 CEST] <ZexaronS> over many frames/images, and pick out more images when there is more activity and vice versa using less images when there is lower activity (pixel change, even down to which colors changes how much from this to this frame or from minute 1 to minute 2, patterns, statistics etc taken into account)
[00:57:31 CEST] <ZexaronS> But I kinda forgot what or where would be the place to start something like this, would this be some kind of a separate filter that could be integrated into ffmpeg, or something else ?
[00:59:04 CEST] <ZexaronS> I have done some research but it's not full proof, since no tools were build specifically for timelapse, the end result video has to be fixed 30 or 60 or whatever fps, that should be completely separate from the above algorithm that picks out the images to use
[02:15:30 CEST] <qebafhzn> hey guys, i'm trying to set up a video server to stream a movie for some friends, but ffserver throws up a 503 error whenever i try to feed it video from ffmpeg. my conf is https://pastebin.com/BPqQMKb3. anyone know what i'm doing wrong?
[02:39:45 CEST] <yyf> jion
[02:53:34 CEST] <ebrock> hi
[02:53:58 CEST] <ebrock> trying to set up ffmpeg with rtmp
[02:56:47 CEST] <ebrock> error log and stuff: https://p.teknik.io/NRk8e
[02:58:29 CEST] <ebrock> the main error: av_interleaved_write_frame(): Connection reset by peer
[02:59:44 CEST] <ebrock> any hints on what's going on?
[04:56:27 CEST] <klaxa> ebrock: afaik rtmp can't stream mp4
[05:57:17 CEST] <ebrock> hmm
[08:00:34 CEST] <ebrock> im back
[08:00:40 CEST] <ebrock> also im pretty sure it can
[08:04:46 CEST] <ebrock> wait nvm
[08:04:49 CEST] <ebrock> lol
[09:03:18 CEST] <DaVu> I have a problem with a file I'm trying to convert. Mediainfo of that file: http://paste.ubuntu.com/25203701/
[09:04:21 CEST] <DaVu> and here is the error I get: http://paste.ubuntu.com/25203706/
[09:05:29 CEST] <DaVu> that's the command I use: ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i 21_t00.mkv -map 0 -c copy -vcodec hevc_nvenc 21-hevc.mkv
[09:05:52 CEST] <DaVu> already found this: https://trac.ffmpeg.org/ticket/6375
[09:06:27 CEST] <DaVu> but adding: '-max_muxing_queue_size 400' only gets me other errors
[13:51:15 CEST] <momomo> i was running ffprobe on over night on 1000+ streams
[13:51:21 CEST] <momomo> it is behaving a bit strange
[13:52:49 CEST] <momomo> last commadn started 07:46 and haven't finished
[13:52:52 CEST] <momomo> ffprobe -v verbose -select_streams v:0 -show_format -of json -show_streams -timeout 5000000 http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c0
[13:52:57 CEST] <momomo> the timeout here is 5 seconds
[13:53:03 CEST] <momomo> so I don't get what is holding it up
[13:53:33 CEST] <JEEB> have you tested that that is the correct timeout parameter?
[13:53:50 CEST] <momomo> yes, i think it has worked for other urls before
[13:53:53 CEST] <JEEB> ok
[13:53:56 CEST] <momomo> it's supposed to be in microseconds
[13:54:06 CEST] <JEEB> yea, that's the default timebase for many option
[13:54:08 CEST] <JEEB> *options
[13:54:29 CEST] <JEEB> in that case it might not be a connection timeout thing
[13:54:34 CEST] <JEEB> but rather something else
[13:55:03 CEST] <momomo> I am trying something here
[13:55:07 CEST] <JEEB> (I think the timeout option only gets gets handled by the IO side of things, although it depends on the protocol)
[13:55:15 CEST] <momomo> if I decrease the timeout to 5000 then it times out
[13:55:21 CEST] <momomo> for that particular url
[13:55:30 CEST] <momomo> but when I put it at 5000 000 then it doesnt
[13:56:06 CEST] <JEEB> you'd have to debug at what stage it gets stuck
[13:56:16 CEST] <JEEB> because it seems like it can definitely get a connection
[13:56:38 CEST] <momomo> yes, i am not getting a very verbose output either ... maybe try trace
[13:56:39 CEST] <JEEB> you can add verbosity to debug and put stderr (2>) into a file
[13:57:04 CEST] <JEEB> afterwards also running ffprobe under something like strace can be very useful
[13:57:26 CEST] <momomo> output kind of keeps repeating this kind of message: https://hastebin.com/kunevepuva.go
[13:57:51 CEST] <JEEB> yea, so it's getting mpegts from the input
[13:58:05 CEST] <JEEB> it even gets a program from one of the PMTs
[13:58:12 CEST] <momomo> looks like a debug of somekind where it ends up in a while loop and never able to get out to check if timeout has elapsed
[13:58:33 CEST] <momomo> i guess an while ( && timeoutHasNotElapsed() ) needs to be added someplace
[13:58:41 CEST] <momomo> fcuk
[13:58:47 CEST] <JEEB> the timeout is for IO and you have no issues with IO
[13:59:04 CEST] <momomo> JEEB: but I want a global timeout, is that possible?
[13:59:11 CEST] <JEEB> there's options starting with probe or analyze (and ending with duration/whatever)
[13:59:23 CEST] <JEEB> you might be able to figure things out with that
[13:59:28 CEST] <JEEB> *those
[13:59:45 CEST] <JEEB> momomo: I don't think there's a global timeout, usually the thing that started the process knows that the best
[14:00:07 CEST] <momomo> JEEB: yes, I guess. I'll look into adding a timeout kill switch
[14:00:18 CEST] <JEEB> anyways, what it looks like is that the stream is there and IO layer is a-OK
[14:00:25 CEST] <JEEB> but ffprobe is trying to find the streams
[14:00:29 CEST] <JEEB> from the mpeg-ts
[14:00:35 CEST] <JEEB> while the stream is only giving out metadata
[14:00:40 CEST] <momomo> yes, let me try play it in vlc
[14:00:44 CEST] <JEEB> so it keeps reading and reading
[14:01:23 CEST] <JEEB> vlc -vvv -Idummy -Adummy -Vdummy -Sdummy URL
[14:01:27 CEST] <JEEB> is a good way usually
[14:01:30 CEST] <momomo> vlc not playing it seems
[14:01:38 CEST] <JEEB> that outputs you stuff in the terminal as well
[14:01:43 CEST] <momomo> oh nice... is that real argumetns?
[14:01:45 CEST] <momomo> haha
[14:01:47 CEST] <JEEB> like "received PMT"
[14:02:03 CEST] <JEEB> and yes, it's very likely that the stream is a minimal viable MPEG-TS :P
[14:02:18 CEST] <JEEB> so it only has metadata of the program (PMT is program mapping table)
[14:02:21 CEST] <momomo> vlc command: 00007fd970c140c8] ts demux debug:   * event id=32 start_time:1501430400 duration=21600 running=1 free_ca=1
[14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug:     - short event lang=ita 'Shopping Tv 1' : '(null)'
[14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug:     - extended event lang=ita [0/0]
[14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug:        - text='Shopping Tv'
[14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug:     - tag=0x5f(95)
[14:02:23 CEST] <momomo> [00007fd970c140c8] ts demux debug:     - tag=0x54(84)
[14:02:25 CEST] <momomo> [00007fd970c140c8] ts demux debug:     - tag=0xcc(204)
[14:02:29 CEST] <momomo> [00007fd96c005ca8] core input debug: EsOutProgramEpg: number=14558 name=Shopping Tv [Program 14558]
[14:02:31 CEST] <momomo> [00000000008bd328] dbus interface debug: Getting property Position
[14:02:37 CEST] Last message repeated 2 time(s).
[14:02:37 CEST] <momomo> getting repeated the last messages
[14:02:40 CEST] <momomo> getting property position
[14:02:53 CEST] <momomo> i guess this is not a valid stream, so i will just put my own timeout and nix it
[14:02:54 CEST] <JEEB> yea, don't paste long pieces of text on teh channel in the future, please :)
[14:03:14 CEST] <momomo> JEEB: i know, but I think we are the only ones here now :p
[14:03:17 CEST] <JEEB> well the stream might be valid but for something that wants actual video/audio/subtitle streams
[14:03:20 CEST] <DHE> doesn't matter
[14:03:23 CEST] <momomo> hehe
[14:03:42 CEST] <JEEB> I guess the analyze/probe parameters might help you there
[14:03:46 CEST] <momomo> DHE: may I debate this issue? the actual logic / rationale behind that rule?
[14:03:50 CEST] <JEEB> "give up if you couldn't find the streams after X"
[14:04:15 CEST] <JEEB> if your paste doesn't fit into a single line or so you use a secondary channel of providing that :P
[14:04:18 CEST] <momomo> If there are no competing discussions, and there are no posts coming in between, what would be the harm of pasting a few lines to speed up sharing?
[14:04:58 CEST] <DHE> what you don't see is that your IRC client is intentionally rate-limiting your messages, roughly 2 seconds per line.
[14:05:09 CEST] <momomo> JEEB: i know the rules, but they just don't always make sense. much like swedish rules about not using the washing room on sundays and after 16.00 on saturdays ... whyyyyyy, that's when I have time. not on weekdays
[14:05:19 CEST] <DHE> IRC servers will kick you off with the message "Excess flood" for large or rapid floods, which is why your clients throttles itself
[14:05:26 CEST] <JEEB> momomo: try -analyzeduration and -probesize
[14:05:31 CEST] <JEEB> first one is in the usual time based
[14:05:36 CEST] <JEEB> and the second is in bytes I think?
[14:06:02 CEST] <momomo> DHE: thanks for the explanation
[14:06:29 CEST] <momomo> the swedish socialist enforcement of work, don't wash your clothes on sundays are still fcuked up though!
[14:06:29 CEST] <momomo> haha
[14:06:34 CEST] <momomo> communism
[14:07:25 CEST] <momomo> JEEB: I just tried:
[14:07:26 CEST] <momomo> ffprobe -v trace -select_streams v:0 -show_format -of json -show_streams -timeout 5000000 -analyzeduration 1000 -probesize 1000 http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3
[14:07:35 CEST] <momomo> are those values integeres ?
[14:07:39 CEST] <JEEB> yes
[14:07:42 CEST] <momomo> did not help stop the stream though
[14:07:52 CEST] <momomo> let me try lower to 1
[14:08:11 CEST] <DHE> http://bash.org/?7936 Hence jokes like this :)
[14:08:41 CEST] <JEEB> anyways, seems like lavf really doesn't like mpegts without any actual streams connected to the program :P
[14:09:06 CEST] <JEEB> still sounds like a boog
[14:09:23 CEST] <JEEB> since it should give up trying to get the streams
[14:09:24 CEST] <momomo> I guess i will have to start a separate thread/process that manages the time for this one
[14:09:31 CEST] <momomo> or maybe just install nix
[14:10:31 CEST] <JEEB> if I ever get free time I should probably try and generate that kind of sample. (which I most likely won't have the time to do)
[14:10:47 CEST] <momomo> JEEB: I can give you access to that stream if you want
[14:10:48 CEST] <JEEB> just keep pushing out PMTs and PATs
[14:11:14 CEST] <JEEB> momomo: coolio. would be enough to dump like a few megs of it
[14:11:36 CEST] <JEEB> so you don't really have to give access to the live stream but even a byte dump of the data would be enough (something.ts)
[14:12:03 CEST] <momomo> ook, i'll generate some now
[14:20:35 CEST] <momomo> JEEB: seems ffmpeg also gets stuck in the same way
[14:20:37 CEST] <momomo> no output
[14:20:39 CEST] <JEEB> yea
[14:20:46 CEST] <JEEB> I mean, they both use libavformat in the basement
[14:20:48 CEST] <momomo> ffmpeg -v trace -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 3000 -i http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3 -map 0:a:0 -map 0:v:0 -preset veryfast -c:v libx264 -sn /momomo/Generated/Tv/streams/FFProbe.video
[14:20:55 CEST] <JEEB> and if libavformat has a problem
[14:21:26 CEST] <momomo> yes, I guess this is not good for ffmpeg either because you'd need a timeout there too
[14:21:34 CEST] <JEEB> also I recommend using something like curl for the dumping of the input :P (or if you really want, you can use vlc's demux=dump demuxdump-file=blah.ts
[14:21:46 CEST] <momomo> otherwise it will get stuck forever
[14:21:49 CEST] <momomo> and take a mux for nothing
[14:22:57 CEST] <momomo> JEEB: hit me up on email if you ever need access to stream .. let me take note of the name incase url changes
[14:23:03 CEST] <momomo> want my email?
[14:24:29 CEST] <JEEB> not really :D anyways, if you can share a sample where the same happens after you dump the stream into a file, that'd be lovely. then you don't have to provide access to the actual stream, as I noted
[14:24:52 CEST] <JEEB> and since the sample has no video/audio/subtitle tracks in the stream, it should be OK to share :P
[14:25:32 CEST] <Blubberbub_> could one just use wget to get that sample?
[14:27:35 CEST] <JEEB> or curl
[14:27:42 CEST] <momomo> JEEB: output to stream or video to stream?
[14:27:52 CEST] <momomo> video to stream wasn't possible
[14:27:54 CEST] <JEEB> momomo: you take your source HTTP url, and dump data from it
[14:28:00 CEST] <JEEB> as-is, no processing
[14:28:04 CEST] <momomo> ook
[14:28:07 CEST] <JEEB> wget,curl,whatever
[14:28:08 CEST] <momomo> wget ?
[14:28:23 CEST] <JEEB> as long as you can just stop the GET at some point and then check the sample that's fine
[14:28:49 CEST] <JEEB> the file extension for MPEG-TS is .ts
[14:29:00 CEST] <momomo> JEEB: I am running this now: wget http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3 ffprobe.wget.error
[14:29:01 CEST] <JEEB> (which the data is)
[14:29:58 CEST] <momomo> hmm.. when aborted i get nothing .. i think it's stored temporarily someplace else
[14:30:09 CEST] <JEEB> that's why I like curl :P
[14:30:15 CEST] <JEEB> curl "URL" > file.ts
[14:30:23 CEST] <JEEB> then you can just abort it with ctrl+C
[14:30:38 CEST] <momomo> hell yeah
[14:30:46 CEST] <momomo> i am a convert
[14:31:01 CEST] <JEEB> if the URL contains a file name then you usually want `curl -LO "URL"`
[14:31:03 CEST] <momomo> upload online?
[14:31:06 CEST] <JEEB> in this case it doesn't
[14:31:16 CEST] <JEEB> can you check first if the issue happens with the file as well?
[14:31:44 CEST] <JEEB> I have a hunch it might have to do with no EOF/slow reading
[14:32:23 CEST] <JEEB> so it might not happen with a static file. but yea, after there's a sample it can be poink'd
[14:39:33 CEST] <momomo> I get a different output on the file
[14:39:36 CEST] <momomo> I ran this:
[14:39:38 CEST] <momomo> ffprobe -v trace -select_streams v:0 -show_format -of json -show_streams -timeout 30000000 /momomo/ffprobe.wget.error
[14:39:48 CEST] <momomo> maybe i need to change something for a local file?
[14:40:10 CEST] <momomo> i guess it has to be served slowly otherwise it will finish fast
[14:40:16 CEST] <JEEB> yea
[14:40:18 CEST] <momomo> here is the file anyway
[14:40:18 CEST] <momomo> https://ufile.io/d18qm
[14:40:28 CEST] <JEEB> I guess you could loop the file or something
[14:40:42 CEST] <momomo> JEEB: this is a real problem within ffmpeg
[14:40:49 CEST] <momomo> since you can not timeout a ffmpeg conneciton
[14:40:58 CEST] <momomo> since it continues to run for a long time
[14:41:18 CEST] <momomo> only way is try to parse some error messages and wait for some output that determines its ok
[14:41:47 CEST] <JEEB> that's why in the end using the APIs is the only real thing to left to do
[14:41:56 CEST] <momomo> do you know what is the best way to commuinicate about the state of ffmpeg?
[14:42:14 CEST] <JEEB> using the API, unfortunately (since it seems like you're trying to avoid making your own API client)
[14:42:16 CEST] <momomo> JEEB: that looked timeconsuming on a tight deadline. I guess the second best thing is parse the output ?
[14:42:34 CEST] <JEEB> that's a shitty thing and will break as soon as the command line output changes :P
[14:42:53 CEST] <JEEB> there's some stuf that you can send commands from tty or so
[14:43:00 CEST] <JEEB> but I've never seen that myself
[14:43:35 CEST] <JEEB> oh, the program actually contains streams but they don't get any packets?
[14:43:38 CEST] <momomo> JEEB: yes, i know, but that is it? couldn't ffmpeg just keep a file with a state that one can read...or get an status stream where ffmpeg could write data by making http kind like requests with status ?
[14:43:43 CEST] Action: JEEB just finally got to checking out the sample
[14:45:15 CEST] <JEEB> momomo: I would agree that some mechanism of getting the state would be nice, but the workload of that would be very similar to hooking such a thing to your API client since ffmpeg.c is also an API client
[14:45:26 CEST] <momomo> like a flag: ffmpeg - .... -communicate http://path/to/my/recieving/url -onevent [status, bitrate, ... ] ... then ffmpeg could make requests there as these things happen
[14:46:33 CEST] <momomo> JEEB: sound like a mix of that and the ffmpeg api might be a solution ... to write an ffmpeg libav addon that can push things onto a url/file
[14:48:33 CEST] <JEEB> well the thing would be 100% a client thing rather than a libav* thing
[14:48:44 CEST] <JEEB> since the client knows its state and when it last received a packet from input etc
[14:49:05 CEST] <JEEB> so in that sense it shouldn't touch the underlying libraries at all
[14:50:12 CEST] <momomo> yes that would be great, along with a nice way to hook into that
[14:50:34 CEST] <momomo> rest based would be ideal .. and very simple for users to get access to
[14:50:49 CEST] <momomo> no need to dive into writing complex libav code :)
[14:50:59 CEST] <momomo> although i'd like to learn that as well.
[14:51:01 CEST] <JEEB> you can almost forget about any HTTP stuff. it's theoretically possible but something like a state file would most likely be much more possible
[14:51:10 CEST] <JEEB> in the end libav* isn't that complex
[14:51:15 CEST] <momomo> JEEB: but that would be overwritten
[14:51:30 CEST] <JEEB> well your state-checking thing would request it
[14:51:37 CEST] <JEEB> say it's a tty command
[14:51:42 CEST] <JEEB> write-state /path/to/file
[14:51:56 CEST] <JEEB> then when that returns it goes to look for the newly written state
[14:52:04 CEST] <momomo> you replace the file? maybe i won't be quick enough to caputre last message
[14:52:05 CEST] <JEEB> or heck, you could even output it there
[14:52:14 CEST] <JEEB> as in, return it from that command
[14:52:22 CEST] <momomo> i guess that's possible though
[14:52:25 CEST] <JEEB> although not sure how :P
[14:52:43 CEST] <momomo> i think the output is already clogged up with messages
[14:52:49 CEST] <momomo> from the log
[14:53:04 CEST] <JEEB> also libav* coding is not that hard really. requires some trial and error but that's the case with everything
[14:53:28 CEST] <JEEB> Í mostly develop inside the libav* libs but I've done an API client now three times I think
[14:53:35 CEST] <DHE> can confirm. made my own app with it and it was actually pretty nice to work with
[14:53:47 CEST] <momomo> JEEB: yes sure, but there is a slight uphill battle .. more so than readin a file .. it would be nice if ffmpeg eventually evolved on that wrong
[14:53:49 CEST] <momomo> front
[14:54:06 CEST] <momomo> DHE: opensource? care to share?
[14:54:07 CEST] <JEEB> ffmpeg.c is already a mutant doing way too many things and having workarounds that actually end up breaking your shit
[14:54:23 CEST] <DHE> sorry, it's a company application
[14:54:25 CEST] <JEEB> which is why as soon as you get past the very basic "can the FFmpeg libs do this"
[14:54:37 CEST] <JEEB> you should start thinking if it's a good idea to make your own API client
[14:54:54 CEST] <JEEB> my initial API client is https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbnailer.cpp#L98
[14:54:56 CEST] <momomo> is the base class ffmpeg.c ?
[14:55:07 CEST] <JEEB> no, ffmpeg.c is the command line API client
[14:55:11 CEST] <JEEB> (and related files)
[14:55:24 CEST] <JEEB> this thing is from 2013, though
[14:55:30 CEST] <JEEB> (the matroska thumbnailer thing)
[14:55:41 CEST] <JEEB> and it was literally my babby's first API client
[14:55:41 CEST] <JEEB> :D
[14:56:04 CEST] <momomo> matroska sounds russian :)
[14:56:30 CEST] <Blubberbub_> mkv = matroska?
[14:56:33 CEST] <JEEB> yes
[14:56:44 CEST] <JEEB> specifically typo'd so it's not the shirt
[14:56:51 CEST] <momomo> only experience i have with c code was from a class in university ... that was 10 years ago ... i got an A+ though! haha
[14:56:56 CEST] <JEEB> or wait no, the doll :P
[14:57:02 CEST] <momomo> i will look into it though
[14:57:12 CEST] <JEEB> yea, I recommend. the examples under docs can get you surprisingly far
[14:57:35 CEST] <JEEB> esp. the ones that use the newer decoding/encoding APIs
[14:57:52 CEST] <momomo> I'd be up for a github fork collaboration thing to develop some api for getting info on various things
[14:57:54 CEST] <JEEB> you notice those because they have separate push (?) and receive
[14:58:01 CEST] <momomo> without coding c code
[14:58:34 CEST] <JEEB> well the status is a thing for your app, which is on top of the libs. so it's rather specific to your use case
[14:58:44 CEST] <JEEB> as app I mean the API client
[14:59:54 CEST] <JEEB> also while I do completely agree that getting the state of ffmpeg.c would be nice, I have a feeling that it would make people use ffmpeg.c even more. which I'm mostly scared of because it's such a monster and of limited design.
[15:00:10 CEST] <JEEB> I mean, lavf can do dynamic stream selection but ffmpeg.c doesn't
[15:00:48 CEST] <JEEB> albeit the way you do that stuff is suboptimal because you have to check the stream ID on each AVPacket read
[15:16:14 CEST] <guysoft42> hey all, I am compiling ffmpeg for raspberrypi and i all seems well. I was wondering - is there a way to make the make-install take less space? Anything I can remove?
[15:17:19 CEST] <mnr200> how do access streamed video from web browser
[15:40:40 CEST] <MaSTeR|2> Hello everyone! I have a little question about hardware accelerated video decoding. Is there someone that can help me?
[15:43:51 CEST] <JEEB> just ask your question and stay around and maybe someone will reply
[15:47:17 CEST] <MaSTeR|2> okie. So I wanted to know why av_hwdevice_ctx_create for AV_HWDEVICE_TYPE_D3D11VA returns always error -12. I'm getting the same with av_hwdevice_ctx_alloc and I know that this means ENOMEM but I can't understand why it keeps saying that there's no enough memory when any other hardware device types is working normally
[15:51:32 CEST] <jkqxz> MaSTeR|2:  Does your build actually contain D3D11VA device support?
[15:52:23 CEST] <MaSTeR|2> Yes, I think so, we made our build using --enable-d3d11va
[15:52:46 CEST] <jkqxz> It looks like you get ENOMEM for that case because it tries to allocate the context for it and fails because it isn't there.  I guess that's rather a misleading error code.
[15:53:11 CEST] <jkqxz> What does "ffmpeg -init_hw_device list" show?
[15:53:48 CEST] <MaSTeR|2> let me check
[15:54:09 CEST] <jkqxz> The device support for it was only added quite recently, though the hwaccels have been around for a while (with user-supplied context).
[15:56:10 CEST] <MaSTeR|2> I can see d3d11va in supported hardware device types
[15:56:16 CEST] <MaSTeR|2> also --enable-d3d11va
[15:57:05 CEST] <jkqxz> Odd.  I can't see any other way for that to return ENOMEM.
[15:58:33 CEST] <jkqxz> If you call av_hwdevice_iterate_types() from your program it can iterate over the supported device types and make sure D3D11VA is there, I guess.
[15:59:32 CEST] <MaSTeR|2> That's weird but I just downloaded ready binaries and everything is fine now
[16:00:15 CEST] <MaSTeR|2> Thanks for your help :) I can't even imagine that problem was on the libraries side
[16:08:45 CEST] <MaSTeR|2> oh, and also. Should this work with gpl disabled? or that's only for GPL version of ffmpeg?
[16:09:30 CEST] <jkqxz> Should be fine.  I don't think there is anything around hardware stuff which needs GPL code.
[20:13:21 CEST] <lucifer333> yo
[20:13:39 CEST] <lucifer333> i have a directory full of *wav files, how do i conver them to *webm?
[20:30:57 CEST] <dystopia_> https://trac.ffmpeg.org/wiki/Encode/VP8
[20:33:03 CEST] <lucifer333> thats not really helpfull
[20:33:06 CEST] <lucifer333> wav to webm
[20:33:33 CEST] <lucifer333> I can google the docs, i dont have the time to look up every fucking option
[20:33:50 CEST] <lucifer333> and synthesise    wav-> webm
[20:34:01 CEST] <lucifer333> the link has only examples mp4-> webm
[20:34:03 CEST] <lucifer333> ok?
[20:39:25 CEST] <DHE> Opus? or what codec did you have in mind?
[20:40:30 CEST] <kepstin> lucifer333: you're basically gonna have to write a shell or batch script that runs "ffmpeg -i file.wav file.webm" in a loop over each file, and add additional ffmpeg options to taste based on preferred codec & quality.
[20:40:55 CEST] <lucifer333> yeah, uuh, just the one liner for ffmpeg, i know how to use find
[20:41:07 CEST] <lucifer333> i am here for ffmpeg not basic bash scripting
[20:41:44 CEST] <lucifer333> how do i use ffmpeg to convert wav to webm
[20:41:47 CEST] <DHE> something like: ffmpeg -i input.wav -c opus -b 128k output.webm    # adjust the codec and audio bitrate to meet your preferences
[20:41:55 CEST] <lucifer333> nice
[20:41:57 CEST] <kepstin> lucifer333: I gave you the command in that message
[20:42:05 CEST] <dystopia_> lucifer333
[20:42:06 CEST] <DHE> try it with one file first, make sure the quality is to your liking. wav is uncompressed (usually)
[20:42:12 CEST] <lucifer333> lets wrap that in a "find"
[20:42:13 CEST] <dystopia_> ren *.wav *.webm
[20:42:20 CEST] <lucifer333> yeah
[20:42:28 CEST] <lucifer333> will test it on one file
[20:49:06 CEST] <lucifer333> oh one thing
[20:49:10 CEST] <lucifer333> it will be used for web
[20:49:11 CEST] <lucifer333> html
[20:49:19 CEST] <lucifer333> so opus is correct codec for this?
[20:50:59 CEST] <lucifer333> it says opus is experimental
[20:51:01 CEST] <lucifer333> waaaat?
[21:03:46 CEST] <ebrock> im back
[21:03:55 CEST] <ebrock> i checked the rtmp spec and mp4 should work
[21:04:11 CEST] <ebrock> is there anywhere i should post the error logs?
[21:04:34 CEST] <ebrock> also should i post my nginx config? (im using nginx compiled with rtmp support)
[21:04:53 CEST] <ebrock> i nmapped it and the port seems to be open so idk
[21:08:32 CEST] <ebrock> ebrock | error log and stuff: https://p.teknik.io/NRk8e
[21:08:39 CEST] <ebrock> ebrock | the main error: av_interleaved_write_frame(): Connection reset by peer
[21:08:44 CEST] <ebrock> what i posted before
[21:08:59 CEST] <lucifer333> thank you everybody; kepstin , dystopia_ etc, i convered all ogg, wav, etc to webm
[21:09:09 CEST] <lucifer333> it seems to be the media standerd for browsers
[21:09:11 CEST] <lucifer333> donno
[21:09:46 CEST] <kepstin> well, if your source was .ogg, you should probably use "-c copy" to avoid a lossy re-encode
[21:10:06 CEST] <kepstin> probably aac in mp4 is more browser compatible overall
[21:11:31 CEST] <DHE> donno?
[21:24:46 CEST] <kerio> 128kbps aac is perceptually lossless, right?
[21:26:28 CEST] <TD-Linux> lucifer333, you want to use -c:a libopus, not opus
[21:27:41 CEST] <kepstin> kerio: depends on the encoder used
[21:27:47 CEST] <kerio> itunes
[21:27:58 CEST] <kepstin> kerio: for example, libvo_aacenc is never perceptually lossless at any bitrate
[21:27:59 CEST] <kerio> so quicktime i guess
[21:28:16 CEST] <kepstin> itunes is one of the best yeah, 128kbit there should be pretty good
[21:40:40 CEST] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png
[21:41:09 CEST] <furq> i'd expect that to be a solid 5 at 128k
[21:41:40 CEST] <furq> i normally use fdk -vbr 5 when i need aac
[23:35:01 CEST] <paul_> hi
[23:35:16 CEST] <paul_> Hi, is there someone here who can help me build ffmpeg in the architecture sh4
[23:35:43 CEST] <JEEB> shouldn't be any different from any other cross-compilation
[23:35:55 CEST] <JEEB> http://fate.ffmpeg.org/
[23:35:59 CEST] <JEEB> see some examples here
[23:36:31 CEST] <JEEB> there's some arm stuff there at least
[23:36:54 CEST] <JEEB> also ppc64
[23:37:38 CEST] <paul_> Can i compile ffmpeg on linux on a laptop under sh4 architecture? I have ubuntu
[23:37:52 CEST] <paul_> a moze jest tu jakies polak ?
[23:38:22 CEST] <JEEB> i don't know if it will actually build since I'm pretty sure sh4 isn't exactly a well-tested architecture
[23:38:53 CEST] <atomnuker> holy shit someone's compiling for sh4
[23:39:02 CEST] <paul_> I :)
[23:39:17 CEST] <atomnuker> awesome, I've always wanted an sh4 processor to play around with
[23:39:44 CEST] <atomnuker> we had some sh4 asm code many years ago but it was very little and was removed
[23:39:46 CEST] <paul_> Wants to play .webm files on ffmpeg and must be libvpx
[23:39:46 CEST] <JEEB> but the parameters would be --arch=XX --cpu=XX --cross-prefix=your-triplet-prefix-
[23:39:58 CEST] <JEEB> for cross-compilation
[23:40:08 CEST] <JEEB> probably not needed for native sh4 building
[23:40:21 CEST] <atomnuker> paul_: you don't need libvpx to play vp8/vp9 files, we have native decoders
[23:40:59 CEST] <paul_> Can you explain?
[23:41:09 CEST] <JEEB> vp8 and vp9 have internal decoders within libavcodec
[23:41:13 CEST] <JEEB> which is an FFmpeg library
[23:41:27 CEST] <JEEB> (you can also use libvpx which has a wrapper in libavcodec separately)
[23:42:05 CEST] <paul_> I can show you what I currently have ffmpeg
[23:44:19 CEST] <paul_> http://pastebin.ca/3849168
[23:44:59 CEST] <paul_> You can check whether I have ffmpeg can see .webm?
[23:46:01 CEST] <JEEB> ffmpeg -formats |grep webm , ffmpeg -decoders |grep vp
[23:47:11 CEST] <atomnuker> paul_: you don't have --enable-decoder=vp8 and --enable-decoder=vp9
[23:47:26 CEST] <JEEB> yea, if it's an "all disabled" build
[23:47:31 CEST] <JEEB> then you need to specifically enable them
[23:47:32 CEST] <atomnuker> and --enable-demuxer=mkv
[23:47:49 CEST] <JEEB> yup
[23:47:52 CEST] <atomnuker> yeah, just use ccache and enable everything
[23:48:24 CEST] <paul_> But it has to be compiled first, right?
[23:48:33 CEST] <JEEB> yes
[23:48:53 CEST] <JEEB> --enable-cross-compile --cross-prefix=sh4-linux- --target-os=linux --arch=sh4
[23:48:57 CEST] <JEEB> seem to be the primary parameters
[23:49:01 CEST] <paul_> With these settings? --enable -libvpx
[23:49:04 CEST] <JEEB> no
[23:49:10 CEST] <JEEB> just don't use disable-everything
[23:49:14 CEST] <JEEB> start with a base build
[23:49:28 CEST] <JEEB> don't add any parameters, just set the cross compilation parameters
[23:49:45 CEST] <JEEB> you can optimize build times after you get used to things
[23:50:12 CEST] <paul_> Is there a tutorial on the internet? Step by step
[23:50:21 CEST] <JEEB> you get your cross compiler
[23:50:24 CEST] <JEEB> add it to PATH
[23:50:30 CEST] <JEEB> and literally those three parameters I just noted
[23:50:42 CEST] <JEEB> which i got from your build's configuration output
[23:51:03 CEST] <JEEB> or if you want to be insane and build on the laptop I don't think you need any parameters?
[23:51:14 CEST] <JEEB> just mkdir -p build && cd build && ../configure
[23:52:34 CEST] <paul_> jeeb Would you do this to me by teamviewer?
[23:52:44 CEST] <JEEB> pfft
[23:52:56 CEST] <JEEB> maybe atomnuker if he cares about access to your box
[23:53:55 CEST] <paul_> 	 detriment 	
[23:54:58 CEST] <atomnuker> i'm not the most appropriate person having cross compiled exactly 0 things in my life
[23:55:32 CEST] <paul_> me too
[23:55:34 CEST] <paul_> :)
[23:57:33 CEST] <atomnuker> just compile ffmpeg on the box and go grab a beer and wait for a few hours
[23:57:52 CEST] <JEEB> yea
[23:59:05 CEST] <paul_> on the box ? Rather not because it's just a satellite decoder. I ffmpeg I wanted to compile on a laptop with ubuntu.
[23:59:48 CEST] <JEEB> well, if you have the STM cross-compiler then at least you could get to it :P
[00:00:00 CEST] --- Mon Jul 31 2017


More information about the Ffmpeg-devel-irc mailing list