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

burek burek021 at gmail.com
Thu Jul 27 03:05:01 EEST 2017


[00:14:11 CEST] <wondiws2> dystopia_, it was a wrong rip, now I can extract the audio again
[00:30:52 CEST] <furq> wondiws2: use pgcdemux or tccat to extract a single title
[00:56:46 CEST] <nicolas17> how do I extract and concatenate multiple time segments of a video? like if I want to grab from 1:00 to 2:05 and then from 2:45 to 3:15
[01:14:15 CEST] <b0bby__> Hello
[01:14:39 CEST] <nicolas17> ohh -f concat
[01:14:41 CEST] <nicolas17> that's handy
[01:15:35 CEST] <b0bby__> Does anyone have experience with RTMP
[01:15:38 CEST] <b0bby__> ??
[01:30:02 CEST] <b0bby__> Is anyone online?
[01:55:12 CEST] <b0bby__> Hello
[03:28:40 CEST] Action: redrabbit /o/ \o/ \o\
[04:02:52 CEST] <stapler> horribly vague and broad question, but how am i supposed to handle packet loss while decoding?
[04:03:37 CEST] <stapler> or reordering of packets
[04:04:17 CEST] <atomnuker> give lavc the next available packet, if it can it'll produce a somewhat corrupted frame
[04:04:35 CEST] <atomnuker> reordering packets due to networks? yourself lol
[04:04:43 CEST] <stapler> :s
[04:04:57 CEST] <stapler> is it worth trying to drop corrupted frames entirely?
[04:06:17 CEST] <atomnuker> if that happens you'll get AVERROR_INVALIDDATA returned
[04:06:35 CEST] <atomnuker> when you try to decode it
[04:06:41 CEST] <furq> TD-Linux: did you run that ffv1 vs flif test with -context 1
[04:06:46 CEST] <stapler> ah ok
[04:06:46 CEST] <furq> i got better results with that
[04:06:57 CEST] <stapler> >reordering packets due to networks? yourself lol
[04:07:03 CEST] <stapler> would you mind throwing me a bone, please?
[04:07:14 CEST] <stapler> or just google it
[04:07:16 CEST] <TD-Linux> furq, I used -coder range_tab
[04:07:16 CEST] <stapler> :-)
[04:07:23 CEST] <furq> yeah i got better results using both
[04:07:36 CEST] <furq> 10751320 vs 11147747
[04:07:40 CEST] <furq> still worse than flif though
[04:08:27 CEST] <furq> http://vpaste.net/I4KKd
[04:08:36 CEST] <furq> idk why i didn't just link that instead of typing it out
[04:08:49 CEST] <atomnuker> stapler: never done it myself, from what I remember you cache packets until the next logical sequence number is found
[04:09:01 CEST] <furq> also i assume the h264/h265 ones are wrong somehow because otherwise heif is going to suck ass
[04:09:12 CEST] <furq> technically as well as for all the reasons it does suck ass
[04:09:17 CEST] <atomnuker> unless you use libavformat, that'll handle out of order packets for you
[04:09:23 CEST] <stapler> atomnuker, lavc wont buffer them for m--
[04:09:26 CEST] <stapler> ah
[04:09:29 CEST] <stapler> i see
[04:10:01 CEST] <TD-Linux> furq, I'm pretty sure heif targets lossy mode only
[04:14:04 CEST] <TD-Linux> and yeah h264/h265 lossless mode is mostly a "because we can" feature
[04:14:28 CEST] <TD-Linux> especially for single images, where the one advantage over ffv1 (motion compensation) is nulled
[04:17:45 CEST] <atomnuker> ffv1 got that now though, at least the v4
[04:18:47 CEST] <furq> TD-Linux: oh
[04:18:50 CEST] <furq> that explains it then
[04:19:18 CEST] <furq> i was just surprised that vp8 outperformed it, but i guess webp has specifically worked on that use case
[04:19:53 CEST] <TD-Linux> webp's lossless encoder is totally different than vp8
[04:20:06 CEST] <furq> i feel like someone already told me that and i forgot it
[04:20:06 CEST] <TD-Linux> also only vp9 has a lossless mode
[04:20:52 CEST] <TD-Linux> vp9's lossless mode is mostly in the same bin as h264's (it does have a special transform for lossless, but that's it)
[04:21:11 CEST] <furq> so when is someone going to create a wonderful new ffv1 image format that everyone will immediately support and use
[04:22:13 CEST] <furq> you could call it ffi
[04:22:19 CEST] <atomnuker> you don't need to create anything
[04:22:24 CEST] <furq> and guess what the library that encodes it is called
[04:22:29 CEST] <TD-Linux> no
[04:22:33 CEST] <furq> that's right
[04:22:34 CEST] <furq> it's called z.lib
[04:22:38 CEST] <atomnuker> just put a single ffv1 packet in mkv and its done
[04:22:49 CEST] <furq> will any image viewer want to know about that shit
[04:22:53 CEST] <TD-Linux> how do you put EXIF in mkv
[04:22:57 CEST] <furq> also yeah that
[04:22:58 CEST] <TD-Linux> actually don't tell me I don't want to know
[04:23:06 CEST] <furq> i suspect the answer involves a lot of xml
[09:12:14 CEST] <twosee> I'm looking to merge n video files, but all the concat methods I'm looking into result in audio desyncing
[09:12:41 CEST] <twosee> Answers like https://stackoverflow.com/a/34918815/2049141 (transform each video to the same fps and timescale) don't seem to help
[11:56:52 CEST] <jcelerier> does someone knows how AVCodecContext::request_sample_fmt is supposed to work ? I've set it to AV_SAMPLE_FMT_FLTP before av_read_frame, but still get ints in the data
[12:04:25 CEST] <durandal_1707> jcelerier: not all decoders allow different formats
[12:24:59 CEST] <jcelerier> okay, so I have to do the conversion myself
[12:53:50 CEST] <maziar> hey guys, how should I fix this error on debian stretch : "Unknown encoder 'libvo_aacenc'"
[12:57:00 CEST] Last message repeated 1 time(s).
[13:02:22 CEST] <thebombzen> maziar: stop using libvo_aacend
[13:02:29 CEST] <thebombzen> just use the native encoder
[13:02:30 CEST] <thebombzen> aac
[13:02:41 CEST] <maziar> thebombze how ?
[13:02:53 CEST] <maziar> thebombzen this is my ffmpeg command
[13:03:26 CEST] <thebombzen> whatever you're about to type, replace "libvo_aacenc" with "aac"
[13:03:28 CEST] <thebombzen> and then try that
[13:04:08 CEST] <maziar> ffmpeg -i file1 -b:a 2500k -s 426x240 -vcodec libx264 -hls_list_size 0 -acodec libvo_aacenc -ab 128k -ar 44100 -hls_time 4 file2.m3u8
[13:04:41 CEST] <maziar> aac is better ?
[13:04:55 CEST] <maziar> thebombzen "aac" codec is better ?
[13:05:30 CEST] <thebombzen> Yes
[13:17:51 CEST] <yns> hi
[13:18:21 CEST] <yns> can I stream copy and split by file size?
[13:19:35 CEST] <yns> instead of splitting by half an hour -c copy -t 00:30:00 I'd like to split into, say, 300MB chunks
[14:02:04 CEST] <DHE> maziar: in general hardware encoders are poorer quality than software encoders when using defaults
[15:37:29 CEST] <maziar> I am using ffmpeg in shell script but && is not working after that, why ?
[15:40:19 CEST] <DHE> that's a shell command, not an ffmpeg command. can't help you if you're not WAY more specific
[17:14:38 CEST] <Mavrik> Hmm, does ffmpeg include a faster deinterlacer than yadif?
[17:20:15 CEST] <furq> w3fdif is faster
[17:20:56 CEST] <furq> separatefields,setdar is the fastest, but it hardly qualifies as a deinterlacer
[17:33:20 CEST] <Mavrik> Yeah, just separating fields isn't enough.
[17:36:14 CEST] <furq> huh
[17:36:26 CEST] <furq> maybe i'm doing something wrong here but mcdeint=slow is even slower than nnedi and still looks like garbage
[17:53:47 CEST] <arpu> hey how can i set the connection timeout on a rtmp connection ? (without librtmp)
[19:02:11 CEST] <jcelerier> does swresample support in-place conversion ?
[19:10:16 CEST] <DHE> I don't think so. the sample sizes and number of channels can change which would make this impractical
[19:26:46 CEST] <thebombzen> what about hardware-deinterlacers-in-the-decoder
[19:26:50 CEST] <thebombzen> like cuda
[19:26:54 CEST] <thebombzen> how do those compare to yadif
[19:37:41 CEST] <Accord> hey, is there any way to automatically adjust bitrate based when streaming to youtube?
[19:38:23 CEST] <Accord> so for example if my connection drops from 2 mbps to 1mbps I would like the bitrate to drop aswell
[19:43:58 CEST] <Mavrik> That's not how that works :/
[19:44:15 CEST] <Mavrik> In other words - I don't know of a software that could do that from streamer side.
[19:44:28 CEST] <DHE> it's not something ffmpeg handles natively. you'd have to write or use an app that does support that feature explicitly
[19:45:24 CEST] <Mavrik> I also doubt you can really do it since as a sender you don't know much about network performance.
[19:45:40 CEST] <Mavrik> (Unless you get info back from client)
[19:45:59 CEST] <DHE> if it's streaming over TCP, you can see the buffering in the network layer and/or the blocking writes as a hint that something's wrong
[19:49:24 CEST] <Blubberbub> isn't that what rtsp is for? (i thought so - but i have no clue_
[20:12:30 CEST] <Accord> ok but can I atleast have ffmpeg exit if there's major network issues?
[20:12:33 CEST] <Accord> right now it seems to hang
[20:12:44 CEST] <Accord> doesn't seem to transmit anything or encode
[22:07:37 CEST] <jcelerier> thanks DHE
[23:57:02 CEST] <stapler> is there a good primer to read before starting to use lav?
[23:57:16 CEST] <stapler> or anything about lav itself? i think i understand the process of what i want to do, just not the calls exactly, heh
[23:59:38 CEST] <Mavrik> well, there are examples in docs dir
[00:00:00 CEST] --- Thu Jul 27 2017


More information about the Ffmpeg-devel-irc mailing list