Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2016

1 participants
60 discussions

ffmpeg-devel.log.20160429
by burek 30 Apr '16

30 Apr '16

[00:03:46 CEST] <Angus> it seems the server that hosts the ffmpeg doxygen just died [00:11:12 CEST] <kierank> durandal_1707: yes I agree [00:46:47 CEST] <michaelni> Angus, http://ffmpeg.org/doxygen/trunk/index.html works fine here [04:34:27 CEST] <jamrial> ubitux: are your fate clients dead? they haven't updated in two days [08:30:27 CEST] <ubitux> michaelni: mmh no didn't see, will have a look [08:56:29 CEST] <kurosu> kierank, isn't transport stream "encapsulable" in yet another layer (IP?) which can be encapsulated again in ts (GSE?) ? Disclaimer: this is likely gibberish [08:56:52 CEST] <kurosu> I'm not siding with Carl, on the contrary, but that's more for personal education [10:35:47 CEST] <cone-748> ffmpeg 03wm4 07master:66dd21d50be1: avcodec/utils: split side-data in new decode API too [11:10:06 CEST] <wm4> is there a way to make x264 write a crop rectangle? I see that it has a crop video filter, but that's useless [11:17:33 CEST] <b_amabo> kierank: I have build afl on my ubuntu machine, but i seem to be missing the command to compiling the source in fffuzz folder which I clone from: https://github.com/OpenBroadcastSystems/fffuzz. Any heads up? [11:26:02 CEST] <jkqxz> wm4: It's crop_rect in the x264 parameters. ffmpeg libx264 doesn't support it directly, but something like '-x264opts crop-rect=0,0,0,8' works. [11:26:20 CEST] <wm4> ah thanks [11:28:04 CEST] <nevcairiel> man gnu infrastructure is slow today, even more so then usual, even downloading tarballs fails from their main site, guess i need to change my script to some mirror [11:31:13 CEST] <wm4> aw x264 refuses non-mod2 crop [11:31:33 CEST] <nevcairiel> because it sane? :) [11:31:57 CEST] <wm4> there's no reason why crop should be mod-2 [11:32:48 CEST] <nevcairiel> except that its a pain in the behind if its not, because you have to crop after rgb conversion, which adds a lot of complexity [11:32:48 CEST] <jkqxz> There is with 4:2:0. Try 4:4:4? [11:33:09 CEST] <wm4> well 4:4:4 is generally supported by sw decoders only [11:33:53 CEST] <rcombs> ~subsampling~ [11:34:20 CEST] <rcombs> I'm reminded of http://inta.re [11:38:34 CEST] <jkqxz> The crop variables which you actually write in the SPS in H.264 are divided by the subsampling. You just can't express odd cropping at all. [11:39:00 CEST] <nevcairiel> i know hevc does that, i guess h264 as well then huh [11:39:47 CEST] <wm4> hm is that so [11:40:46 CEST] <rcombs> "crop in macropixels" I guess [11:41:03 CEST] <wm4> jkqxz: hm seems so [11:41:34 CEST] <wm4> (the ffmpeg jpeg decoder can output non-mod2 sizes anyway) [11:41:39 CEST] <nevcairiel> somehow i feel like i have seen odd cropping in h264 before [11:42:04 CEST] <nevcairiel> but maybe it was interlaced 420 with mod2 cropping, which is once again problematic then [11:42:14 CEST] <nevcairiel> since fields then have odd height [11:42:40 CEST] <rcombs> http://inta.re [11:42:54 CEST] <jkqxz> Look at H.264 section 7.4.2.1.1, CropUnitX and CropUnitY. [11:43:08 CEST] <wm4> rcombs: I don't get it [11:43:26 CEST] <rcombs> ZETTAI DAME [11:43:26 CEST] <jkqxz> (It also includes a fiddle for interlaced.) [11:43:57 CEST] <rcombs> ("absolutely useless") [11:45:34 CEST] <nevcairiel> maybe i'm just remembering wrong and it just wasnt h264 [11:50:08 CEST] <fritsch> rcombs: did you have a chance to test vtb with the interlaced h264? [11:50:15 CEST] <rcombs> not yet [11:50:34 CEST] <fritsch> oki, no hurry - i am just interested as I could not find public specs [11:51:44 CEST] <rcombs> the only docs for videotoolbox are the headers, a WWDC transcript, and I think a tech note or two [11:55:15 CEST] <wm4> rcombs: that's definitely worse than microsoft [11:55:24 CEST] <rcombs> yup [11:55:43 CEST] <rcombs> audiotoolbox is _generally_ pretty well-documented [11:57:20 CEST] <rcombs> but there are some odd quirks, at least one function that's internally broken because someone misplaced a & (it takes a void*, but to get it to work you have to pass in `*(int*)pkt->data`), and a few features that just aren't documented at all [11:57:47 CEST] <fritsch> lol about that bug [11:59:23 CEST] <rcombs> (it reads the first 4 bytes) [12:07:07 CEST] <Carlrobertoh> Could please anybody help me out? I'm able to capture screen with codec h.264 and save it on disk as test.h264 file. But if i want to save it on disk as test.mp4 then it doesn't play the video. [12:09:32 CEST] <Carlrobertoh> Also, the .mp4 video can be played in MPlayer but cannot played in VLC. [12:10:29 CEST] <Carlrobertoh> Also if I use ffmpeg command line tool to encode .h264 byte-stream to mp4 then it works like a charm [13:23:01 CEST] <Compn> Carlrobertoh : ask in #ffmpeg , this channel is for development [13:28:16 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:2a158602273f: avformat/ffmdec: Check pix_fmt [13:28:16 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:4e4afe29b989: avcodec/motion_est: Attempt to fix "short data segment overflowed" on IA64 [14:06:13 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:da4ea9716173: Changelog: update [14:22:07 CEST] <cone-579> ffmpeg 03wm4 07n2.8.7:HEAD: avcodec/utils: split side-data in new decode API too [14:25:52 CEST] <wm4> wut, how is the new decode api in an old release? [14:27:09 CEST] <wm4> must be some sort of irc bot glitch [14:27:35 CEST] <nevcairiel> it glitches the message on tags, yes [14:27:55 CEST] <nevcairiel> uses last master commit for the message for some reason [15:25:19 CEST] <Daemon404> ubitux, feel free to do some merges this weekend [15:25:25 CEST] <Daemon404> im traveling till monday [16:48:09 CEST] <durandal_1707> michaelni: why is irc operator status lost? [17:21:01 CEST] <BBB> durandal_1707: he probably didnt identify with nickserv [17:23:12 CEST] <durandal_1707> BBB: I'm talking about users who identified and have voice [17:33:12 CEST] <BBB> hm, strange [19:30:54 CEST] <michaelni> f*cking ISP [19:30:59 CEST] <kurosu> kierank, could you provide a command-line to generate a realistic vc2 bitstream where vlc reading is costly ? [19:43:25 CEST] <durandal_1707> I'm fine if new reader is faster but I dislike unnecessary long renames [19:44:24 CEST] <kurosu> durandal_1707, what do you mean? as in function names? or in number of patches? [19:45:07 CEST] <durandal_1707> names [20:30:45 CEST] <kurosu> anyway, that's unlikely to be the only issue - it's a codecpar situation again [20:31:55 CEST] <kurosu> but the situation can be incrementally fixed, though [20:55:49 CEST] <kylophone> I've built ffmpeg_g, but it's still linking to a libavfilter without debug symbols. Is there a config flag or something to build debug versions of the libs? [20:57:10 CEST] <wm4> --disable-stripping AFAIK [20:57:16 CEST] <wm4> and yes this is dumb [20:57:56 CEST] <wm4> kurosu: not comparable at all, since the old bitstream reader can just exist forever [21:07:46 CEST] <jamrial> wm4: --disable-stripping skips stripping ffmpeg after being copied from ffmpeg_g. the libraries afaik are not supposed to be stripped as part of the building process [21:08:10 CEST] <BtbN> sounds like it's using some random libraries from somewhere else on your system. [21:09:32 CEST] <wm4> eh [21:10:01 CEST] <wm4> why can't ffmpeg just be debuggable out of the box [21:10:17 CEST] <DHE> it is [21:10:34 CEST] <DHE> if you just run configure without args, you'll get an ffmpeg_g with full debug symbols all the way through the libav* components [21:10:59 CEST] <DHE> as BtbN said, it sounds like it pulled in libav* from elsewhere. like maybe /usr/lib ? [21:14:15 CEST] <Compn> also this is #ffmpeg question [21:16:58 CEST] <kylophone> `--disable-stripping' seems to work for this. [21:18:23 CEST] <kylophone> DHE: Running configure without flags seems like a weird solution. What if you wanted to debug something that required a configure flag to be built? [21:18:46 CEST] <DHE> *thunk* [21:19:11 CEST] <kierank> kurosu: anything high bitrate [21:19:37 CEST] <kierank> 5gbit/s 4k [21:30:49 CEST] <kurosu> wm4, sure, I even mentioned that afterwards, but I was thinking of the large amount of things to port [21:32:20 CEST] <kurosu> kierank, I was more thinking of a command-line but nevermind - you'll do it if that interests you [21:33:26 CEST] <kurosu> I think it will work pretty much everywhere when vlc parsing is costly - my test on ffmpeg's huffyuv show around 10% improvement [21:48:54 CEST] <durandal_170> Nope, too much busy [21:51:51 CEST] <kurosu> kierank, huffyuvdec is mostly macros - and there are several occurrences of a reader loop, but dirac/vc2 might be less easy to translate [21:52:30 CEST] <kurosu> iirc, some golomb reading is the most costly part at those bitrates, so it should likely be the main focus [21:53:20 CEST] <kurosu> Compn, yes, it's an all-intra codec, so frame multithreading is almost free [21:54:18 CEST] <kurosu> I thought there were slices in ffvhuff, but it appears not - no big deal except for low delay decoding [22:06:03 CEST] <Angus> hmm. [swscaler @ 0x8e2c60] vdpau_h264 is not supported as output pixel format [22:06:35 CEST] <Angus> I assume av_read_frame can't be used with a vdpau_h264 AVPixelFormat? [22:09:29 CEST] <kurosu> actually, dirac looks more bothersome [22:13:41 CEST] <Angus> oh, it's this that's spewing out the error: sws_getContext [22:36:03 CEST] <wm4> Angus: libswscale doesn't support GPU surfaces [22:36:13 CEST] <wm4> Angus: and this has nothing to do with av_read_frame at all [22:37:04 CEST] <wm4> Angus: on ffmpeg git, you can use av_hwframe_transfer_data() to get a GPU surfaces in CPU [22:37:14 CEST] <wm4> well, to copy it to CPU memory [22:44:16 CEST] <rcombs> (kinda makes sense that _sw_scale wouldn't support hardware surfaces) [22:46:24 CEST] <wm4> some say it should [22:57:33 CEST] <Angus> does vdpau_get_buffer do the same thing as av_hwframe_transfer_data? [22:57:40 CEST] <wm4> no [22:57:44 CEST] <wm4> not at all [22:58:02 CEST] <wm4> vdpau_get_buffer allocates a new GPU surface from a pool [22:58:16 CEST] <Angus> Ah. [22:58:29 CEST] <wm4> av_hwframe_transfer_data copies a GPU surface's data to a CPU surface (but it can allocate the memory for the CPU memory for you) [22:59:37 CEST] <Angus> so calling the VDPAU function should go: avformat_open_input->avformat_find_stream_info->avcodec_find_decoder->setup Codec->avcodec_open2->vdpau_init->av_hwframe_transfer_data? [23:00:27 CEST] <wm4> 1. you shouldn't use the AVStream.codec for decoding (copy it with avcodec_copy_context to a new AVCodecContext instead) [23:00:46 CEST] <wm4> 2. you need to set the get_format and get_buffer and some more fields yourself, see ffmpeg_vdpau.c [23:03:45 CEST] <jsebechlebsky> Hi, could someone confirm me, that I can replace av_copy_packet and av_dup_packet simply by av_packet_ref ? [23:04:54 CEST] <Angus> wm4: does this look reasonable to you? [23:04:54 CEST] <Angus> http://pastebin.com/3apNxkhQ [23:05:16 CEST] <Angus> (if you ignore the codec copying thing) [23:05:47 CEST] <Angus> pCtx replaces InputStream [23:06:09 CEST] <wm4> looks like a start, also you don't need av_dict_get [23:06:46 CEST] <Angus> alrighty [23:12:14 CEST] <Angus> wm4: the git vdpau_retrieve_data calls av_hwframe_transfer_data [00:00:00 CEST] --- Sat Apr 30 2016

1 0

ffmpeg.log.20160429
by burek 30 Apr '16

30 Apr '16

[01:01:35 CEST] <spirou> neuro_sys: what linux distro/version are you using? [01:32:48 CEST] <smthorwhat> [15:46:11] <smthorwhat> hey guys. anyone know what this means " [graph 1 aresample for input stream 0:2 @ 0x207b280] [SWR @ 0x21de040] Failed to compensate for timestamp delta of 273.516250" [01:32:48 CEST] <smthorwhat> [15:46:16] <smthorwhat> is there something i can use to fix that ? [01:36:26 CEST] <pandb> i'm using the muxing.c example to live stream on youtube, but the video pauses frequently (to buffer, i presume) and the video plays back slightly faster than it should [01:36:45 CEST] <pandb> where should I start looking? [01:38:50 CEST] <pandb> the frame->pts gets incremented before being sent to the encoder, then the resulting packet is given to av_packet_rescale_ts() with the codec's time_base and the stream's time_base fields as the second and third parameters [01:41:04 CEST] <pandb> i've managed to slow playback down by writing two or three copies of the same frame before getting more input image data, but that feels like a an overly kludgy way to do things [01:42:32 CEST] <pandb> should I write my program to only grab a new frame after a certain number of milliseconds have elapsed(based on my preferred frame rate)? [02:11:22 CEST] <spiderkeys> I'm looking at execution times for my pipeline and found that av_read_frame is taking ~250us per frame (1080p h264 stream), while av_write_frame only takes ~50us (muxing into mp4) [02:11:35 CEST] <spiderkeys> Does anyone know of any options or methods I can use to speed up the read frame [02:12:26 CEST] <spiderkeys> my ReadPacket( void *userDataIn, uint8_t *avioBufferOut, int avioBufferSizeAvailableIn ) function only takes ~3-5us of the time spent by av_read_frame [02:15:42 CEST] <spiderkeys> wondering if the "AVFMT_FLAG_NOPARSE" flag might help, since I am absolutely sure that what I pass it is a single h264 frame, and all I need to do is mux it into a fragmented mp4 container [02:23:26 CEST] <spiderkeys> hmm, closed the stream's parser, which effectively would have done the same. no noticeable difference [03:44:33 CEST] <pandb> What should I do when I constantly see messages like "Delay between the first packet and last packet in the muxing queue is 10066000 > 10000000: forcing output' [04:24:58 CEST] <needmorespeed> Are there any known issues with FFmpeg locking a file and not releasing once everything is freed? [07:46:33 CEST] <pinPoint> does ffmpeg support .r3d yet? [07:47:24 CEST] <Betablocker> is this for red cameras ? [07:48:14 CEST] <Betablocker> https://trac.ffmpeg.org/ticket/2690 [07:49:31 CEST] <pinPoint> yeap [10:53:19 CEST] <pkajaba> Hello guys, Have you tried to compile ffmpeg with new OpenCV 3.1? [10:53:34 CEST] <pkajaba> I have this problem: http://koji.russianfedora.pro/kojifiles/work/tasks/4865/74865/build.log [10:57:31 CEST] <jkqxz> From your output: q(Include the log file "config.log" produced by configure as this will help solve the problem.) [10:58:23 CEST] <jkqxz> Though mainly it looks like you haven't installed opencv in a place that the ffmpeg configure can see it. Does pkg-config give you something sensible for it directly? [11:09:34 CEST] <pkajaba> jkqxz I will try it. However there is file /usr/lib64/pkgconfig/opencv.pc [11:10:31 CEST] <pkajaba> so pkg-config should be OK and openCV installed [11:15:15 CEST] <jkqxz> Look at the pkg-config command that config.log shows the ffmpeg configure running, and try it standalone. [11:18:08 CEST] <JEEB> you can add directories to pkg-config's search path with PKG_CONFIG_PATH [11:18:25 CEST] <JEEB> PKG_CONFIG_PATH=/opt/huehue/lib/pkgconfig ./configure --muh-configure-parameters [11:37:16 CEST] <Fyr> guys, people who upload porn videos usually show tiled screenshots of the movie. how do they do that? [11:37:34 CEST] <Fyr> is it some kind of script for ffmpeg? [11:40:03 CEST] <Fyr> those screenshots usually are not the same, it means the program compare the screenshots and if they are close/identical, moves the timeline and makes another screenshot. [11:42:49 CEST] <Fyr> mosaic of screenshots, that's the right definition, I guess. [12:06:32 CEST] <jkqxz> Fyr: You want to make a set of images from a stream, where you look at all the frames and output a new image on each frame if it is "sufficiently different" somehow from the previous one? [12:07:44 CEST] <jkqxz> Maybe look at the mpdecimate filter? [12:08:34 CEST] <Fyr> jkqxz, I meant thmbnailer. [12:08:54 CEST] <Fyr> is there a small python/bash/winthing tool to create thumbnails? [12:09:01 CEST] <Fyr> every porn movie has thumgnails. [12:09:47 CEST] <Fyr> when it comes to create thumbnails from a normal movie I'm about to upload, I'm stuck with googling that program. [12:11:22 CEST] <Carlrobertoh> Could please anybody help me out? I'm able to capture screen with codec h.264 and save it on disk as test.h264 file. But if i want to save it on disk as test.mp4 then it doesn't play the video. [12:11:26 CEST] <Carlrobertoh> Also, the .mp4 video can be played in MPlayer but cannot played in VLC. [12:11:29 CEST] <Carlrobertoh> Also if I use ffmpeg command line tool to encode .h264 byte-stream to mp4 then it works like a charm [12:12:33 CEST] <Fyr> Carlrobertoh, missing -f mp4 option? [12:13:06 CEST] <Carlrobertoh> i'm writing code for screen capture. im not using the command line tool [12:13:17 CEST] <Fyr> ok [12:13:49 CEST] <Carlrobertoh> what could be the issue here? some missing headers perhaps? [12:18:07 CEST] <jkqxz> Carlrobertoh: Can you write anything other than an H.264 elementary stream? (You are using libavformat to do the writing here, right?) [12:19:36 CEST] <Carlrobertoh> Yes, i've tried mpeg aswell [12:20:33 CEST] <Carlrobertoh> But how's that possible that MPlayer can play the mp4 container but VLC don't ? [12:22:50 CEST] <jkqxz> Fyr: Do you actually just want a thumbnail every time interval rather than comparing frames? Try something like q(ffmpeg -i ... -vf 'fps=1/10,scale=160x90' out%03d.jpeg) to make a 160x90 image every 10 seconds. [12:23:48 CEST] <jkqxz> Carlrobertoh: Is it actually an mp4 container at all? (What do file and mplayer actually say about it?) [12:25:18 CEST] <Carlrobertoh> jkqxz, http://www.upload.ee/files/5767920/test.mp4.html [12:48:58 CEST] <Fyr> guys, I'm trying to find what means -vf select=gt(scene\,0.3) [12:49:11 CEST] <Fyr> what does "gt" mean? [12:49:29 CEST] <Fyr> what is that number after "gt?" [12:49:29 CEST] <furq> greater than [12:49:52 CEST] <Fyr> ok, furq, what are the numbers for scenes? [12:51:12 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect [12:51:20 CEST] <t4nk321> hello guys [12:53:05 CEST] <Fyr> "Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)" [12:53:06 CEST] <Fyr> =) [12:53:12 CEST] <Fyr> ='( [12:53:27 CEST] <t4nk321> i make an overlay video with two video input, but i have a problem to choose one of the audio stream that come both in two videos, and turn off another one?? [12:54:23 CEST] <t4nk321> how can we achieve that, thanks. [13:02:32 CEST] <Fyr> guys, how to create a mosaic from a movie by scene selection with setting the number of tiles? [13:02:44 CEST] <Fyr> the movie is too long to get all the scenes. [13:03:07 CEST] <Fyr> I need only 20 or 60 scenes. [13:10:54 CEST] <jkqxz> Carlrobertoh: "test.mp4: JVT NAL sequence, H.264 video @ L 50" - that's an elementary stream. You're not actually writing an mp4, you've just changed the file name. [13:11:24 CEST] <Carlrobertoh> Okey, but how could i write the actual mp4 file ? [13:17:58 CEST] <t4nk283> hello i making overlay two video input that comes with its own audio for both of video, how can i choose just to output the second one in filter complex, thanks. [13:21:38 CEST] <jkqxz> Carlrobertoh: You're using avformat_alloc_output_context2(), presumably? If it isn't doing the right thing from the filename, you must be passing something unhelpful in one of the other arguments. [13:23:03 CEST] <Carlrobertoh> no, i'm using avformat_alloc_context() and output_format_ctx->oformat = av_guess_format() [13:35:48 CEST] <trfl> I just followed the centos compile guide to build the exact same source on rhel6 and centos7, and for some reason the rhel6 build lets me use yuv444p with libvpx-vp9, while the c7 build only supports yuv420p... c7 also warns me that vp9 is experimental while rh6 doesn't, but c7 somehow has a higher version number for libavcodec etc in the ffmpeg -version output. What's going on? [14:30:15 CEST] <GimmeSpace> hello guys.. [14:30:21 CEST] <Fyr> hey [14:30:25 CEST] <GimmeSpace> its my pastebin cli command [14:30:29 CEST] <GimmeSpace> http://pastebin.com/L6trzV25 [14:31:30 CEST] <GimmeSpace> the result of it give me an audio stream from the first video, i need the result give the second one. thanks. [14:33:37 CEST] <GimmeSpace> how to achieve it? thanks. [14:33:47 CEST] <Fyr> just do -an and then use second command: [14:33:47 CEST] <Fyr> ffmpeg -i vid2.mp4 -c:a copy -vn -f mp4 1.m4a [14:33:47 CEST] <Fyr> ffmpeg -i gen.mp4 -i 1.m4a -c:v copy -c:a copy final.mp4 [14:34:00 CEST] <Fyr> two-stage muxing [14:34:11 CEST] <trfl> could it be that the lack of yuv444p support is due to missing cpu features? the centos7 box is a core2duo T6600 from 2009, doesn't have VTx or anything like that [14:34:24 CEST] <Fyr> you can also use filter_complex, which I don't know. =)))))) [14:35:08 CEST] <GimmeSpace> yeah, i need one line cli command i use filter_complex, but didnt found any sugestion on the net? [14:35:46 CEST] <Fyr> two commands are as good as one. [14:36:05 CEST] <Fyr> less trouble =) [14:36:55 CEST] <trfl> this might work: -map 1:a [14:37:00 CEST] <GimmeSpace> i have to use it in bulk, so two stage will be wasted time, and not to mention i have old computer. thanks. [14:37:21 CEST] <Fyr> I would use pipes. =) [14:38:12 CEST] <trfl> also, if youre just copying streams without reencoding them then two stages will be *almost* as fast as 1 (hint: -vcodec copy) [14:38:21 CEST] <GimmeSpace> trfl, where we put the line "-map 1:a"? [14:38:41 CEST] <GimmeSpace> ow i dont know that trfl, thanks. [14:39:10 CEST] <trfl> try right before the filename you are saving to [14:39:39 CEST] <GimmeSpace> i had, but didnot work still it give me an error. [14:39:55 CEST] <trfl> what's the error? [14:41:13 CEST] <GimmeSpace> Filter format has a unconnected output [14:41:42 CEST] <trfl> hmm [14:42:52 CEST] <trfl> just a guess, but drop the -map thing and instead change [bg][fg] to [1:a][bg][fg] [14:45:12 CEST] <GimmeSpace> ERROR : Too many inputs specified for the "overlay" filter. [14:45:13 CEST] <GimmeSpace> Error initializing complex filters. [14:45:13 CEST] <GimmeSpace> Invalid argument [15:53:13 CEST] <Fyr> how will -c:a copy work with multi-channel audio? [15:53:36 CEST] <JEEB> that works on streams, not channels [15:54:02 CEST] <Fyr> ok, with many audio streams. [15:55:08 CEST] <JEEB> standard ffmpeg cli behavior is that it picks the "best" video and audio track so those selected tracks will get handled [15:55:17 CEST] <JEEB> use -map to map the input streams you want to handle [15:55:29 CEST] <Fyr> ok [15:55:38 CEST] <JEEB> that disables the automagic so you will specify everything you need [15:56:00 CEST] <JEEB> -map 0:v maps all video tracks from first input f.ex. [15:56:14 CEST] <Fyr> ok [15:56:14 CEST] <Fyr> JEEB, is there any chance that the delay bug will be fixed in this century? [15:56:15 CEST] <JEEB> -map 0:a:2 picks the third audio track from the first input [15:57:03 CEST] <Fyr> thanks for the mapping, it will help. [16:15:01 CEST] <Fyr> JEEB, do you know how to create mosaic thumbnail from scenes of a movie, with specified number (like, 16). I found out how to make it from scenes, however, FFMPEG creates them as many as it finds scenes, without upper limit. [16:15:46 CEST] <Fyr> what if I need only 20 of them, but dispersed all over on the timespan. [16:18:26 CEST] <furq> Fyr: -frames:v will limit the frames but it'll just be the first 20 [16:19:16 CEST] <furq> i've been meaning to use the API to do the same thing [16:19:35 CEST] <furq> but if you're not on a headless box then you might as well use mplayer [16:20:05 CEST] <Fyr> ok, guys, I'm out of words, how to do this: [16:20:05 CEST] <Fyr> http://s32.postimg.org/bs1ltmzpx/pic.jpg [16:20:06 CEST] <Fyr> with FFMPEG? [16:20:22 CEST] <Fyr> the picture may hurt your feelings. [16:20:27 CEST] <furq> yeah that is what i was hoping to do [16:20:32 CEST] <furq> except less explicit [16:20:59 CEST] <furq> like i said you can do it with mplayer if you just want a command line method [16:22:24 CEST] <durandal_1707> thumbnail filter [16:23:22 CEST] <Fyr> durandal_1707, ok, if the file were "input.mp4," how to create that nice picture? [16:23:24 CEST] <furq> oh neat [16:23:41 CEST] <Fyr> with the timestamps, scene selection, some info on the top. [16:23:43 CEST] <furq> Fyr: you'd need two passes, or more likely one ffprobe pass first [16:24:19 CEST] <furq> grab the info with ffprobe, use the total frame count to get the right argument for the thumbnail filter, then use the tile/drawbox/drawtext filters to fill in the info [16:24:33 CEST] <durandal_1707> select filter plus thumbnail filter [16:24:47 CEST] <Fyr> guys, I need the exact command. [16:24:53 CEST] <furq> we don't have the exact command [16:25:02 CEST] <furq> if i knew it i'd have already been using it [16:25:12 CEST] <Fyr> then, I can say the same: vf filter + ffprobe. [16:25:16 CEST] <durandal_1707> send me $$$ and I will tell it [16:25:19 CEST] <Fyr> very useful answer. [16:25:47 CEST] <Fyr> been there, tried that. [16:26:20 CEST] <Fyr> I posted a bug report and sent a donation of $5. [16:26:23 CEST] <Fyr> something simple [16:26:36 CEST] <Fyr> still, the bug is not fixed. [16:26:40 CEST] <durandal_1707> and there is tile filter. Too [16:27:02 CEST] <durandal_1707> What bug? [16:27:10 CEST] <Fyr> I'll never donate FFMPEG again. [16:27:20 CEST] <Fyr> I don't remember. =) [16:27:30 CEST] <Fyr> it's in the logs. [16:27:52 CEST] <durandal_1707> about what? [16:30:56 CEST] <Fyr> durandal_1707, look through your logs at [22 Nov 15 16:27:28] [16:31:32 CEST] <Fyr> [22 Nov 15 16:30:28] * durandal_1707: you mean coverart in m4a ? [16:31:32 CEST] <Fyr> [22 Nov 15 16:30:32] * Fyr: yes [16:31:47 CEST] <Fyr> you've seen it. [16:33:45 CEST] <s00b5u> I have a question, if we have a video which has Variable VBR and we transcode it to Constant VBR... are there chances of loosing lip sync? [16:34:05 CEST] <durandal_170> select=gt(scene\,0.4),scale=qcif,tile [16:47:10 CEST] <durandal_1707> Fyr: I posted command [16:48:19 CEST] <Fyr> oh [16:58:06 CEST] <vade> Im curious about how I might go about troubleshooting this issue: I have a video transcode that appears to be outputting valid h.264 to a mp4 container via libavformat libx264. VLC plays back and throws no errors / shows no errors / retiming log info, etc. However, upon opening the file with Quicktime, I get a kVTVideoDecoderUnsupportedDataFormatErr error. [16:58:06 CEST] <vade> Do I need to manually hint profiles, or provide some side dara to the encoder to satisy other decoders even though VLC seems to be ok or at least, silently recover from whatever idiocy I am doing? :) [16:58:54 CEST] <vade> Im specifying AV_CODEC_ID_H264 into a container that is MP4 part 14 [17:00:01 CEST] <jkqxz> AV_PIX_FMT_YUV420P? [17:00:55 CEST] <vade> yup [17:01:03 CEST] <vade> AV_PIX_FMT_YUV420P [17:01:40 CEST] <vade> is it possible to provide PTS / DTS that is valid for libx264 but maybe not for other decoders? [17:03:19 CEST] <jkqxz> What does ffprobe say about the H.264 stream inside the mp4 container? [17:03:47 CEST] <kepstin> i'm not sure what that sentence means, libx264 is not a decoder, and you don't give dts to an encoder [17:04:54 CEST] <vade> ohhh [17:05:35 CEST] <vade> do you have to set the resulting AVPackets stream index manually? [17:05:46 CEST] <vade> (from the encoder?) [17:05:54 CEST] <vade> sorry, first time playing with LibAV :) [18:02:53 CEST] <amdbcg> hello [18:14:41 CEST] <durandal_1707> hello [18:31:21 CEST] <amdbcg> Line 45 inlibavutil\common.h, [Error] libavutil/avconfig.h: No such file or directory [18:31:41 CEST] <amdbcg> I looked in libavutil, and there was no avconfig.h :o [18:32:26 CEST] <amdbcg> so either the config is wrong or I have not made/ installed something. [18:43:24 CEST] <c_14> make distclean and try again, are you building from git? What's your configure line [18:50:23 CEST] <amdbcg> I'm on windows, and just discovered gcc is unable to create an executable file from the configure. ... I'm installing more dev packages to fix. [18:52:14 CEST] <amdbcg> and... I might just use a dev binary instead. [18:59:58 CEST] <amdbcg> c_14 : what should the configure line look like? [19:02:39 CEST] <c_14> ./configure [19:02:45 CEST] <c_14> plus whatever you want to add [19:34:41 CEST] <Kurogane> Hello, i have a problem with installing ffmpeg i follow this guide https://trac.ffmpeg.org/wiki/CompilationGuide/Centos and the problem i have is say yasm is not found/old http://pastie.org/private/7ebsixq9smdon32khsgq [19:35:28 CEST] <DHE> centos 6 has too old a version of yasm. I built mine from source and run that instead [19:36:11 CEST] <DHE> hmm.. a quick check shows it may have been upgraded. EPEL has 1.2 [19:36:44 CEST] <Kurogane> i built from git..... [19:36:46 CEST] <drv> if you are trying to use yasm from your ~/bin directory, that needs to be in $PATH [19:37:31 CEST] <drv> or use --yasmexe to point to it [19:43:23 CEST] <Kurogane> i not understand now this warning "WARNING: pkg-config not found, library detection may fail.", if we need other custom paths why not put that on the guide or i miss something i'm not aware? [19:45:07 CEST] <furq> the guide mentions that you need to install pkg-config [19:45:22 CEST] <furq> and that you need to set PKG_CONFIG_PATH [19:45:45 CEST] <furq> if your distro calls pkg-config anything other than pkg-config then you'll need to set --pkg-config="pkgconf" or whatever your binary is called [19:51:02 CEST] <Kurogane> furkan, yes, you're right, but still not understand why not detect yasm [19:51:18 CEST] <Kurogane> furq, yes, you're right, but still not understand why not detect yasm* [20:50:54 CEST] <graphitemaster> I'm explicitly building ffmpeg with --disable-swscale and yet the libavfilter.so is complaining that it needs "libswscale.so.3, needed by ../../thirdparty/usr/lib/libavfilter.so" [20:55:43 CEST] <kepstin> graphitemaster: a build in a clean source tree? [20:56:27 CEST] <graphitemaster> yes [21:16:15 CEST] <c_14> graphitemaster: what was your configure line? what's the output of ldd libavfilter.so? Are you building from git? [21:21:11 CEST] <vade> I have an AVFrame that is being decoded marked bt709 color primaries / transfer etc etc. However my output / encoded stream via FFPRobe doesnt indicate my video stream is marked BT709 [21:21:54 CEST] <vade> I dont see an AVStream option / ivar I can fiddle with to set the color space transfer and primaries / color range etc [21:22:03 CEST] <vade> how would I go about marking that? :X [21:24:24 CEST] <vade> oh im an ass, its in the output stream -> codec [21:31:15 CEST] <jadesoturi> hi all. I have a questions. I used ffmpeg to rip audio from a file that is set to be 60fps and i added it to a file with 24fps. the problem now is the sync. If i sync it up at one part of the video, its out of sync a few minutes later.. how does one solve this? [21:32:55 CEST] <jadesoturi> i get the same sync problem in both avidemux and in vlc...and the merging was also done with ffmpeg [21:33:31 CEST] <kepstin> to fix that you'll have to adjust the speed of either the audio or video track [21:34:50 CEST] <jadesoturi> ok. total noob here. how does on do that? can i use ffmpeg? [21:35:42 CEST] <jadesoturi> its an aac file(used -acodec copy and saved as .aac when ripping) [21:35:43 CEST] <kepstin> sure, there are filters that can do either in ffmpeg. you'll want to find out the difference in length between your audio and video tracks to find out how much adjustment is needed. [21:48:14 CEST] <jadesoturi> it is the acc file i am talking about. it cuts at 1:37:09 but says its 1:48:17. the original file i ripped it from was 1:37:20(skipped the first 11 seconds) [21:48:43 CEST] <c_14> Then it's probably 1:37:09 [21:49:07 CEST] <jadesoturi> ok. but how do i make it "match" the 60fps 1:37:20 videofile? [21:50:34 CEST] <jadesoturi> is it the atempo filter you guys are talking about? cause i can only specify a ratio there, but not sure what that ratio should be with the difference is apparently on 7 seconds or so in time.. [21:51:35 CEST] <c_14> should be around 1.00189 [21:51:56 CEST] <jadesoturi> ok. thx ill try that.. [22:12:07 CEST] <vade> hrm. Im setting my output stream and codec contexts frame rate prior to opening to AVRational num 25, den 1 [22:12:18 CEST] <vade> but ffprobe shows my stream as being FPS 25.11 - [22:13:03 CEST] <vade> is that a PTS thing for my frames, or is it a container / stream nuance? [22:56:01 CEST] <kepstin> vade: what container? [22:56:08 CEST] <vade> mp4 [22:56:35 CEST] <kepstin> huh, I'm not familiar with how pts/framerate is represented in mp4. [22:56:49 CEST] <vade> i feel like the further I dig the less I know :P [22:57:48 CEST] <kepstin> I would expect 25fps to work fine in mp4, that's a common framerate for deinterlaced PAL stuff :/ [22:59:14 CEST] <pandb> After a minute or so of live streaming to youtube, my muxer is outputting messages that say "Delay between the first packet and last packet in the muxing queue is 10067000 > 10000000: forcing output" [23:00:11 CEST] <vade> you might be feeding packets in faster than you output them to your muxer, and the queue has a set length? [23:00:21 CEST] <vade> just guessing from that message [23:01:01 CEST] <pandb> How can I rectify that? [23:01:17 CEST] <pandb> I've looked at the avformatcontext documentation but I didn't see a suitable looking setting [23:01:34 CEST] <pandb> (assuming that's where I should look) [23:02:02 CEST] <vade> are you encoding too somewhere? [23:02:47 CEST] <pandb> yes, I think [23:03:08 CEST] <pandb> I'm taking a sws_scale'd frame and encoding it with avcodec_encode_video [23:03:30 CEST] <pandb> then calling av_interleaved_write_frame with the resulting packet [23:04:20 CEST] <pandb> it's actually a modified version of the muxing.c example that comes with ffmpeg [23:05:50 CEST] <pandb> Perhaps AVFormatContext::max_picture_buffer would be relevant? [23:17:14 CEST] <vade> yea (sorry walked off for a moment) - I was thinking something along those lines [23:17:35 CEST] <vade> the encoder buffers n frames based on the a bunch of variables I dont quite understand but you can toy with it [23:26:30 CEST] <kepstin> assuming you're using x264, you probably want to use the "tune=zerolatency" avoption to make the encoder not buffer lots of frames [23:35:38 CEST] <DHE> x264 has a default lookahead buffer of 40 (!) frames [23:35:55 CEST] <DHE> though the speed presets change that [00:00:00 CEST] --- Sat Apr 30 2016

1 0

ffmpeg-devel.log.20160428
by burek 29 Apr '16

29 Apr '16

[00:04:38 CEST] <cone-111> ffmpeg 03Piotr Bandurski 07master:55e632309061: avformat/riff: assign g721 and g723 codec tags to g726 decoder [01:35:23 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07master:492011f3c6d7: avutil/log: Fix occured typo [02:14:22 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/3.0:8d0cfa68b9a4: avcodec/ttaenc: Reallocate packet if its too small [02:14:23 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/3.0:ad559492dc75: update for 3.0.2 [02:32:34 CEST] <cone-111> ffmpeg 03;5:A0=4@ !;>1>45=N: 07master:688664e02d2f: avformat/riff: support for matrox m703 mpeg-2 [02:47:16 CEST] <cone-111> ffmpeg 03Dmitriy Kuminov 07master:5d7696fe2b40: configure: Do not create/install versioned DLLs on OS/2. [02:47:17 CEST] <cone-111> ffmpeg 03Dave Yeo 07master:3cb3dddeb490: configure: Allow choice in choosing a symlink command [03:05:25 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/3.0:c66f4d1ae64d: Changelog: Fix minor formating inconsistency [03:43:49 CEST] <cone-111> ffmpeg 03Dave Yeo 07n3.0.2:HEAD: configure: Allow choice in choosing a symlink command [05:29:22 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:46e791a9b35f: avutil/frame: Free destination qp_table_buf in frame_copy_props() [05:29:23 CEST] <cone-111> ffmpeg 03KO Myung-Hun 07release/2.7:010fd5deb6ca: MAINTAINERS: add myself as an OS/2 maintainer [05:29:24 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:34e76d75a0f0: swscale/x86/output: Move code into yuv2planeX_mainloop [05:29:25 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:13b75ba30a22: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination [05:29:26 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:8dce138510b9: avcodec/h264: Execute error concealment before marking the frame as done. [05:29:27 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:b8148973c59b: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats [05:29:29 CEST] <cone-111> ffmpeg 03Carl Eugen Hoyos 07release/2.7:c7b34fa73355: postproc: fix unaligned access [05:29:29 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:19257891d176: swscale/input: Fix GBRAP16 input [05:29:31 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:751e52575751: swscale/utils: Fix chrSrcHSubSample for GBRAP16 [05:29:31 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:c6950985cb91: avcodec/avpacket: clear priv in av_init_packet() [05:29:33 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:6fe1f5646e12: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg [05:29:33 CEST] <cone-111> ffmpeg 03Rodger Combs 07release/2.7:46e4028e6949: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354) [05:29:35 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:dc92c6045f94: avformat/cache: Fix memleak of tree entries [05:29:36 CEST] <cone-111> ffmpeg 03Boris Nagels 07release/2.7:f00f588a6ed4: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT [05:29:37 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:7b1803a427f9: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay [05:29:37 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:72b224e3f67a: avformat/concatdec: set safe mode to enabled instead of auto [05:29:39 CEST] <cone-111> ffmpeg 03Martin Cracauer 07release/2.7:2a73404558d4: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing [05:29:39 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:91b6d89d0a5e: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool [05:29:40 CEST] <cone-111> ffmpeg 03PrzemysBaw Sobala 07release/2.7:873ca2839052: avcodec/imgconvert: Support non-planar colorspaces while padding [05:29:42 CEST] <cone-111> ffmpeg 03Luca Barbato 07release/2.7:51f686fa77a0: indeo2data: K&R formatting cosmetics [05:29:42 CEST] <cone-111> ffmpeg 03Luca Barbato 07release/2.7:fbe2f77e3f73: indeo2: Fix banding artefacts [05:29:43 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:24bd4b363ecd: avcodec/resample: Remove disabled and faulty code [05:29:44 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:c6bb76597267: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored [05:29:45 CEST] <cone-111> ffmpeg 03Ico Doornekamp 07release/2.7:e112096885c5: avformat/rtpdec_jpeg: fix low contrast image on low quality setting [05:29:47 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:f3da3e2aed9d: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set [05:29:48 CEST] <cone-111> ffmpeg 03Aaron Boxer 07release/2.7:1bccba1893cf: avcodec/j2kenc: Add attribution to OpenJPEG project: [05:29:48 CEST] <cone-111> ffmpeg 03Marios Titas 07release/2.7:3d9f1c0dbbcb: avfilter/src_movie: fix how we check for overflows with seek_point [05:29:49 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:62e87d065b9b: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case [05:29:51 CEST] <cone-111> ffmpeg 03Ivan 07release/2.7:0696a555b6a5: avcodec/h264: Fix for H.264 configuration parsing [05:29:51 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:cff516d9e841: avcodec/avpacket: Fix off by 5 error [05:29:53 CEST] <cone-111> ffmpeg 03Paul B Mahol 07release/2.7:7e2c69516910: avcodec/apedec: fix decoding of stereo files with one channel full of silence [05:29:54 CEST] <cone-111> ffmpeg 03Paul B Mahol 07release/2.7:cec42e6f4de3: avcodec/takdec: add code that got somehow lost in process of REing [05:29:55 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:526aca805f77: avfilter/vf_drawtext: Check return code of load_glyph() [05:29:55 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:49fc747b4874: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3 [05:29:57 CEST] <cone-111> ffmpeg 03Jan Ekström 07release/2.7:3f69797e9b2f: pgssubdec: fix subpicture output colorspace and range [05:29:58 CEST] <cone-111> ffmpeg 03Michael Niedermayer 07release/2.7:d94d786bf06b: avcodec/ttaenc: Reallocate packet if its too small [11:21:09 CEST] <Carlrobertoh> Hi! I'm writing a C++ code for screen casting using ffmpeg libraries. I'm able to save the video on disk, but it has no video timeline(duration) and also the video is like 2-3x faster than it should be. Also i'm using H.264 codec. Could someone please tell me what could be te issue here? [11:21:50 CEST] <rcombs> Carlrobertoh: not setting frame timestamps? [11:22:02 CEST] <Carlrobertoh> outFrame->pts = (1.0 / 25 ) * 90 * frame_count++; [11:23:38 CEST] <Carlrobertoh> and it is done after decoding [11:26:17 CEST] <jkqxz> What is your AVCodecContext.time_base? [11:32:06 CEST] <Carlrobertoh> jkqxz, AVRational rational = { 1, 25 }; output_codec_ctx->time_base = rational; output_codec_ctx->time_base.num = 1; output_codec_ctx->time_base.den = 25; [11:33:10 CEST] <wm4> Carlrobertoh: what container format? [11:33:30 CEST] <Carlrobertoh> wm4, .h264 [11:33:36 CEST] <wm4> ok that has no timestamps [11:33:44 CEST] <wm4> or at the very least libavformat doesn't read them [11:34:12 CEST] <Carlrobertoh> so [11:34:18 CEST] <Carlrobertoh> i should change the container format? [11:39:36 CEST] <wm4> yes [11:39:46 CEST] <wm4> or change how you're playing that .h264 file [11:40:25 CEST] <Carlrobertoh> But if I change the container format , then It wont play the video anymore [11:45:46 CEST] <jkqxz> The pts is in time_base units, so your pts increasing by (1.0 / 25) * 90 with time_base 1/25 is going to play at 90fps (if you have something which actually respects the timestamps). [11:47:45 CEST] <jkqxz> Assuming you want a constant framerate, just set the time_base to that frame interval and then increase the pts by 1 each frame (so use the frame_count directly). [11:52:27 CEST] <Carlrobertoh> jkqxz, So right now outFrame->pts = (1.0 / 25) * 90 * frame_count++; will play at 90fps ? [11:56:32 CEST] <Carlrobertoh> jkqxz, How do I set it correctly? outFrame->pts = (1.0 / 25) * 25 + frame_count++ ? [12:01:26 CEST] <wm4> you get the frame time in seconds by doing "pts / time_base" [12:01:43 CEST] <wm4> that's all you need to know, and you can derive the rest from it [12:01:56 CEST] <jkqxz> You have constant framerate 25fps? With time_base set to 1/25, "outFrame->pts = frame_count++;", assuming there isn't anything funny happening somewhere else. [12:02:06 CEST] <wm4> well, actually "pts * time_base" if time_base is a proper fraction [12:09:23 CEST] <Carlrobertoh> http://pastebin.com/wve66YA4 [12:09:30 CEST] <Carlrobertoh> my parameters and the while loop [12:15:20 CEST] <Carlrobertoh> Also, here's the file http://www.upload.ee/files/5765237/test.h264.html [12:29:03 CEST] <Carlrobertoh> Did anybody watched it ? [13:24:54 CEST] <Carlrobertoh> damn, i've tried everything, i can't figure this out [13:24:55 CEST] <Carlrobertoh> every value i set to outFram->pts , the result is same. although if i don't set the outFrame , then the quality is going low every second [14:17:12 CEST] <wm4> if (ret == AVERROR(EAGAIN)) { [14:17:13 CEST] <wm4> av_usleep(10000); [14:17:13 CEST] <wm4> continue; [14:17:13 CEST] <wm4> } [14:17:15 CEST] <wm4> wat [14:17:26 CEST] <wm4> it's in ffmpeg.c after av_read_frame [14:18:29 CEST] <Shiz> lol [14:18:39 CEST] <rcombs> probably for stuff like RTP? [14:18:58 CEST] <wm4> shouldn't that just block [14:19:42 CEST] <rcombs> apparently there's a "non-blocking mode" [14:31:14 CEST] <atomnuker> rtp has never worked for me [14:34:20 CEST] <wm4> rtmp and hls also just barely work for me [14:34:32 CEST] <wm4> lavf sucks at reading streaming formats [14:34:47 CEST] <Shiz> i just give up and use livestreamer piped to mpv for tose [14:35:06 CEST] <wm4> meh [14:37:12 CEST] <atomnuker> udp works mostly perfectly though [14:37:45 CEST] <atomnuker> livestreamer died like 2 years ago, didn't it? [14:38:02 CEST] <Shiz> did it? [14:38:04 CEST] <atomnuker> (good riddance, you shitty python script) [14:38:08 CEST] <Shiz> it got updated the other day to support hitbox i think [14:38:16 CEST] <Shiz> the other day being like 2 months ago or whatever [14:38:22 CEST] <Shiz> or was it that other stream site [14:38:26 CEST] <Shiz> well, something at lesat [14:38:35 CEST] <Shiz> as shitty of a python script it is it worked [14:38:36 CEST] <atomnuker> youtube-dl supports everything it did and does a better job [14:38:39 CEST] <Shiz> can't say the same for anything else [14:39:24 CEST] <wm4> michaelni: can we disable the merge side data shithack [14:39:49 CEST] <wm4> michaelni: it just screwed me over again because the new decode API actually sends the merged side data to the decoder, causing funny failures [14:45:33 CEST] <Daemon404> wm4, avformat is certainly the wrong took for any streaming IMO [14:45:37 CEST] <Daemon404> on client side i mean [14:45:47 CEST] <durandal_170> I dislike APIs with long functions name [14:45:47 CEST] <Daemon404> at least as far as ingesting playlists is concerned [14:45:57 CEST] <wbs> for non-segmented stuff, it works just fine for me [14:46:02 CEST] <wm4> too bad for API users like me who actually try to use that stuff [14:46:21 CEST] <Daemon404> wbs, well i did mention playlists [14:46:39 CEST] <wbs> Daemon404: yes, but others seem to be having issues with stuff that works flawlessly for me [14:46:46 CEST] <Daemon404> oic [14:47:41 CEST] <Daemon404> beats me, i never use that stuff [14:47:41 CEST] <wm4> wbs: most recent issue: libavformat downloads the complete stream if it's a webvtt HLS stream [14:48:24 CEST] <wbs> wm4: yes, I can imagine that non audio/video tracks in HLS would require more changes to it, on top of the original stuff I wrote in 2010 [14:48:44 CEST] <wbs> (I suppose it's the stream probing) [14:48:45 CEST] <wm4> it's probably a libavformat/utils.c issue [14:48:50 CEST] <wm4> most likely [14:48:59 CEST] <wbs> possibly [14:52:57 CEST] <Carlrobertoh> Please could anybody help me? My video playback is like 1/4 faster than it should be. I'm using gdigrab to record my screen and then save it on disk. The output frame pts is taken from input packet and output_codec_ctx time_base is taken from input_codec_ctx time_base [14:58:33 CEST] <flux> carlrobertoh, did you switch to h264-inside-mp4 from raw h264? [14:59:05 CEST] <Carlrobertoh> what? [14:59:21 CEST] <Carlrobertoh> what u mean by h264-inside-mp4 [14:59:23 CEST] <flux> you used to produce, as far I understand, .h264-files, right? [14:59:28 CEST] <Carlrobertoh> yes [14:59:44 CEST] <flux> well, as mentioned, those files don't have the concept of time stamps or frame rate [14:59:50 CEST] <Carlrobertoh> okey. [14:59:57 CEST] <Carlrobertoh> but, if i produce .mp4 file [15:00:01 CEST] <Carlrobertoh> then it wont play with vlc [15:00:15 CEST] <flux> well, you're doing it wrong then ;), because vlc certainly plays those. [15:00:26 CEST] <Daemon404> [13:59] < flux> well, as mentioned, those files don't have the concept of time stamps or frame rate <-- .h264 annexb can have framerate in the VUI, but reading it properly in git master is currently broken [15:00:51 CEST] <flux> carlrobertoh, did you look at the examples in the ffmpeg/doc/examples directory? [15:00:56 CEST] <Carlrobertoh> yes [15:01:00 CEST] <flux> carlrobertoh, I think some of those to successfull mp4 muxing [15:01:01 CEST] <Carlrobertoh> i can produce .mpg files [15:01:07 CEST] <Carlrobertoh> with mpeg1video codec [15:01:09 CEST] <Carlrobertoh> it plays fine [15:01:16 CEST] <Daemon404> btw this belongs in #ffmpeg [15:01:25 CEST] <Carlrobertoh> but if i use h264 codec and produce .mp4 container, then vlc doesn't wanna play them [15:01:31 CEST] <flux> oops. the discussion used to be there :) [15:14:03 CEST] <Mavrik> Carlrobertoh, do you write a trailer when muxing mp4? [15:14:14 CEST] <Carlrobertoh> trailer? [15:14:18 CEST] <Carlrobertoh> i'll try. [15:22:07 CEST] <Shiz> > [15:22:11 CEST] <Shiz> whoops [16:05:26 CEST] <durandal_1707> in other news vlc doesn't play .mp4 which is actually .h264 [16:40:20 CEST] <kurosu> people still using gdigrab in this decade/century? Probably for lack of anything better in ffmpeg [16:40:53 CEST] <Daemon404> nobody cares enough to port the better code from vdub [16:40:54 CEST] <Daemon404> that uses dx1 [16:40:57 CEST] <Daemon404> dx11* [16:41:04 CEST] <Daemon404> or was it just vista+ [16:41:06 CEST] <Daemon404> cant remember [16:41:33 CEST] <nevcairiel> dont even need to port, i wrote that from scratch a couple years ago [16:41:33 CEST] <durandal_1707> everyone lazy [16:41:40 CEST] <nevcairiel> for something else [16:41:41 CEST] <kurosu> iirc there are 2 methods, of which one may require a driver? [16:42:36 CEST] <kurosu> actually, I was the one who wrote/ported the gdigrab stuff initially, but that was like 2007 - and I never pushed for it seeing its shortcomings [16:44:57 CEST] <kurosu> durandal_1707, while you are active here, could you reply on the 32 vs 64bits accumulator in wma lossless? [16:45:13 CEST] <kurosu> ie, is it RE (and thus what should be expected) or guess (in which case it may break but is ok until proven broken) [16:45:56 CEST] <rcombs> anyone have a test file for the VP9 superframe BSF? [16:46:05 CEST] <rcombs> I'd like to add a FATE test that uses it with autobsf [16:46:14 CEST] <Daemon404> BBB would [16:46:25 CEST] <nevcairiel> presumably any vp9 encode [16:46:54 CEST] <BBB> use FATE_SAMPLES/vp9-test-vectors/vp90-2-2pass-akiyo.webm [16:47:05 CEST] <BBB> and recode it with -c:v copy into an output ivf file or webm file [16:47:11 CEST] <BBB> and simply check the md5 of the file [16:47:18 CEST] <durandal_1707> kurosu: its not 64 bit, I just use 32 bits because that's logical, see clip functions in code [16:49:12 CEST] <rcombs> BBB: so, in a file without super-frames, there would be packets with pts=N/A? Or packets with identical timestamps? [16:49:22 CEST] <kurosu> yeah, you're right - it's not 32bits, but 24bits, so more than 25bits for a residual would be absurd [16:49:37 CEST] <wm4> rcombs: probably either [16:49:51 CEST] <wm4> depending on container and parser use [16:50:10 CEST] <BtbN> What's Bonk? [16:50:23 CEST] <durandal_1707> sex toy [16:50:36 CEST] <rcombs> vp90-2-2pass-akiyo.webm has consecutive packets with identical timestamps; vp90-2-10-show-existing-frame.webm has packets with no timestamps [16:50:58 CEST] <rcombs> (not sure how "no timestamp" codes in matroska to begin with) [16:51:09 CEST] <wm4> rcombs: the latter probably splits packets with the parser [16:51:32 CEST] <rcombs> ah [16:51:54 CEST] <rcombs> yeah, looks like it [16:52:29 CEST] <BBB> rcombs: I think the pts on the packet from the parser is N/A [16:52:34 CEST] <durandal_1707> BtbN: codec, sonic in ffmpeg is based on it [16:52:38 CEST] <BBB> rcombs: but the timestamp magic elsewhere may fill it in again [16:52:40 CEST] <BBB> rcombs: not sure [16:52:53 CEST] <rcombs> BBB: ffprobe shows it as N/A in show-existing-frame [16:53:00 CEST] <rcombs> and identical timestamps in 2pass-akiyo [16:53:14 CEST] <rcombs> so I assume 2pass-akiyo doesn't use superframes and show-existing-frame does [16:53:16 CEST] <BBB> I didnt create show-existing-frame [16:53:29 CEST] <BBB> 2pass-akiyo uses superframes [16:53:31 CEST] <wm4> rcombs: or it put it in a separate packet [16:53:35 CEST] <BBB> simply -c:v copy it with and without the bsf [16:53:40 CEST] <BBB> you will see that the output file is different [16:53:47 CEST] <BBB> that means the file has alt-ref frames [16:54:19 CEST] <BBB> I dont know what show-existing-frame does exactly, its a google-provided file [16:57:08 CEST] <fritsch> wm4: you know if ffmpeg's vtb can cope with h264 interlaced? [16:57:43 CEST] <fritsch> wm4: we have that disabled since ever for our hacked together guessed api decoder and transitioned to ffmpeg's vtb today and it seems it has the same issue [16:58:31 CEST] <wm4> vtb? [16:58:37 CEST] <fritsch> that osx thingy [16:58:39 CEST] <nevcairiel> videotoolbox [16:58:40 CEST] <fritsch> for hwaccel [16:58:42 CEST] <wm4> ffmpeg's is crap [16:58:47 CEST] <fritsch> that's new :-) [16:58:51 CEST] <wm4> someone needs to write a new wrapper [16:59:00 CEST] <wm4> and I think rcombs is working on that [16:59:02 CEST] <rcombs> wm4: I've got one half-finished sitting here [16:59:07 CEST] <rcombs> just needs the timestamp BS [16:59:14 CEST] <wm4> ah [16:59:17 CEST] <rcombs> because videotoolbox doesn't handle reordering at all [16:59:22 CEST] <nevcairiel> did someone tell the guy sending 10+ patch sets to the ML about vtb? [16:59:28 CEST] <Daemon404> i swear hwaccels are in a constant state of beign rewritten or refacotred or new apis [16:59:33 CEST] <wm4> fritsch: ffmpeg's current vtb support tries to use it as hwaccel, which has... disavdantages [16:59:34 CEST] <fritsch> nevcairiel: that's what I wonder, too! [16:59:50 CEST] <wm4> Daemon404: of course, because every vendors has at least 3 APIs for them [17:00:03 CEST] <fritsch> rcombs: h264 interlaced spits something out for you? [17:00:12 CEST] <rcombs> fritsch: haven't tried it [17:00:13 CEST] <nevcairiel> i find it fascinating that windows is still fine without such crap =p [17:00:17 CEST] <BBB> Im confused [17:00:22 CEST] <BBB> why is hwaccel bad? [17:00:28 CEST] <BBB> you want to go back to them being decoders? [17:00:33 CEST] <wm4> fritsch: nice to hear that kodi is switching to it though [17:00:36 CEST] <wm4> BBB: yes [17:00:37 CEST] <Daemon404> BBB, it is bad because the people who write the drivers and vendor apis are bad [17:00:39 CEST] <nevcairiel> BBB: if the hw api doesnt fit the design, it results in headaches [17:00:39 CEST] <rcombs> BBB: doesn't really make sense when the API takes a full packet and outputs a full frame [17:00:44 CEST] <fritsch> i am also confused, cause we transitioned while we thought "nice ffmpeg's vtb gets patches - looks good" [17:00:57 CEST] <BBB> so hwaccel is dead? [17:01:00 CEST] <wm4> fritsch: well as you see we're working on it [17:01:04 CEST] <fritsch> hehe [17:01:05 CEST] <BBB> did anyone tell that to the people that advocated it a few years ago? [17:01:12 CEST] <wm4> BBB: no, hwaccel is fine for APIs which are actually hwaccels [17:01:14 CEST] <rcombs> hwaccel still makes sense for lower-level APIs [17:01:15 CEST] <nevcairiel> BBB: no, still works fine for the existing APIs [17:01:24 CEST] <nevcairiel> just "new" vendor APIs are terrible and dont fit it [17:01:26 CEST] <rcombs> just not things like videotoolbox or MMAL or such [17:01:38 CEST] <BBB> so how will end users choose between hwaccel and decoders? [17:01:42 CEST] <BBB> it sounds fairly complicated to me [17:01:56 CEST] <wm4> fritsch: so the outlook is that ffmpeg will be able to fully use videotoolbox' capabilities [17:02:00 CEST] <Daemon404> thats because hardware acceleration is complicated [17:02:01 CEST] <nevcairiel> you usually will only have one that applies to your system at hand [17:02:02 CEST] <BBB> (not to mention how to switch back to SW decoding if the HW doesnt support your file) [17:02:05 CEST] <wm4> fritsch: for the old/current thing, that can still be maintained [17:02:11 CEST] <Daemon404> especially when you get into no-copy areas [17:02:13 CEST] <fritsch> https://github.com/xbmc/xbmc/pull/9702 [17:02:14 CEST] <Daemon404> with hw buffers [17:02:19 CEST] <fritsch> ^^ if someone feels like giving a statement [17:02:36 CEST] <wm4> BBB: it's not that hard, but it doesn't fit with hwaccel's model of falling back (which is broken anyway) [17:02:44 CEST] <fritsch> the transition was rather easy, but if it's something we need to drop again it's better to do it the future way [17:02:47 CEST] <rcombs> also apparently the full-decoder ones get AVHWAccel structs which& I guess are used for something involving pixfmt selection? [17:03:14 CEST] <rcombs> fritsch: do you support MMAL for RPi decoding? [17:03:20 CEST] <fritsch> yes [17:03:24 CEST] <rcombs> my work on VideoToolbox works the same way [17:03:32 CEST] <fritsch> we don't do it the ffmpeg way [17:03:33 CEST] <fritsch> though [17:03:37 CEST] <rcombs> ah [17:03:44 CEST] <fritsch> we use the "popcornmix" implementation [17:04:09 CEST] <fritsch> rcombs: http://solidrun.maltegrosse.de/~fritsch/1080i50_h264-2.ts <- here if you find some time to see if you get something out of 1080i h264 [17:04:09 CEST] <wm4> as soon as I change ffmpeg's mmal to the new decode API, it shouldn't have any disadvantages anymore [17:04:26 CEST] <fritsch> presentation is always critical for kodi [17:04:30 CEST] <fritsch> we are not done after decoding [17:04:32 CEST] <fritsch> :-) [17:04:43 CEST] <rcombs> also using the new decode API should make things faster for videotoolbox [17:04:56 CEST] <wm4> "well somehow there is always a -O3 sneaking into the ffmpeg compile which doesn't allow me to debug properly due to optimisation ..." [17:05:03 CEST] <wm4> also lol people at struggling with ffmpeg's dumb shit [17:05:05 CEST] <rcombs> since it's faster when used async [17:05:24 CEST] <Daemon404> wm4, its not obvious you need --optflags=-O0 --enable-debug=N --disable-stripping [17:05:24 CEST] <nevcairiel> wm4: some people are too dumb to read configure output [17:05:34 CEST] <nevcairiel> and no you dont need that [17:05:35 CEST] <fritsch> rcombs: we use it threaded, decoder + render [17:05:45 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193578.html mentions the 1:N bsf case, but afaict auto-bsf works fine with the superframe filter as-is [17:05:50 CEST] <Daemon404> nevcairiel, if i dont force -O0 i never ever get usable results [17:05:57 CEST] <Daemon404> <optimzied out> and wrong lines arent usable [17:06:16 CEST] <rcombs> I just --disable-optimizations --enable-debug [17:06:33 CEST] <rcombs> this breaks the build on ARM though [17:06:38 CEST] <Daemon404> i seem to recall the former doing something more than -O0 [17:06:43 CEST] <fritsch> rcombs: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/V… [17:06:44 CEST] <Daemon404> that i didnt want [17:08:07 CEST] <fritsch> wm4: help him if you cited him already :-) [17:09:05 CEST] <wm4> fritsch: posted [17:09:45 CEST] <fritsch> thx [17:09:49 CEST] <rcombs> BBB: know of any VP9 samples that would break remuxing if the BSF wasn't properly flushed at the end? [17:10:36 CEST] <BBB> rcombs: superframe filter is N:1, 1:N was more a theoretical thing [17:10:43 CEST] <rcombs> trying to find a practical case where the issues mentioned in https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193578.html cause problems [17:10:58 CEST] <BBB> VP9 samples that break& I dont think that is an issue at this point, basically [17:11:21 CEST] <BBB> a superframe would almost by definition be followed by a series of non-superframes, otherwise the superframe is useless [17:11:32 CEST] <rcombs> yeah, you'd think [17:11:32 CEST] <BBB> it can theoretically happen, but I dont think we should care very much [17:11:39 CEST] <rcombs> so the right thing to do is flush at the end [17:11:46 CEST] <rcombs> but it'd make that code way more complex [17:11:46 CEST] <BBB> yes [17:12:01 CEST] <BBB> I dont think the code would change, would it? [17:12:13 CEST] <BBB> I dont think we need to handle it [17:12:16 CEST] <rcombs> well I'd need to go through all the streams and flush them [17:12:19 CEST] <BBB> I mean, not at the BSF layer [17:12:21 CEST] <rcombs> *flush their BSFs [17:12:31 CEST] <BBB> I dont think so [17:12:39 CEST] <BBB> the whole idea of N:N is that the internal cache needs no flushing [17:12:46 CEST] <BBB> the cached frames are invisible [17:12:54 CEST] <BBB> if the invisible are never to be followed by visible frames [17:12:58 CEST] <BBB> then not coding them has no effect [17:13:07 CEST] <rcombs> I don't mean for super frame in particular [17:13:10 CEST] <BBB> (on visual output) [17:13:12 CEST] <BBB> right [17:13:19 CEST] <BBB> but Im saying that the BSF needs no code changes for that [17:13:24 CEST] <BBB> th BSF API layer maybe [17:13:28 CEST] <BBB> but not the individual filters [17:13:41 CEST] <rcombs> sure, I meant the autobsf code would need a lot of change to support flushing the BSFs [17:13:51 CEST] <rcombs> and also in general to support 1:N [17:14:12 CEST] <rcombs> but since that's not a real case right now, at least with any of the BSFs that anyone's adding with autobsf, I'm inclined to ignore it [17:14:57 CEST] <rcombs> maybe add a FIXME [17:15:47 CEST] <nevcairiel> rcombs: theoretically the mpeg4 unpack filter could be greatly simplified to be 1:N [17:15:54 CEST] <nevcairiel> if someone ever feels like doing that [17:16:01 CEST] <nevcairiel> its internal buffering is rather arcane [17:18:10 CEST] <rcombs> nevcairiel: still, would be a lot of change here and would be hard to test without the mpeg4 unpack code being written first [17:18:31 CEST] <rcombs> I'll do it if someone does the unpack bsf simplification, sure [17:20:35 CEST] <nevcairiel> fair enough [17:24:17 CEST] <jkqxz> When videotoolbox becomes a decoder, how does the output format work? It always outputs AV_PIX_FMT_VIDEOTOOLBOX, which can be hwframe_transfer()ed (or mapped, if someone adds that) to normal frames if desired? [17:25:03 CEST] <wm4> jkqxz: I'd imagine it'd output a sw format by default, but allow an opaque format via get_format [17:44:50 CEST] <nevcairiel> That's how they usually work [17:45:20 CEST] <wm4> I know I did that for mmal [17:46:20 CEST] <rcombs> ^ yeah, that's how I'm doing it [17:46:31 CEST] <rcombs> it's worked fine with mpv so far [18:21:06 CEST] <Angus> In read_packet here: http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.… [18:21:22 CEST] <Angus> can I copy NAL units to the AVIOBuffer? [18:21:30 CEST] <Angus> or partial NAL units? [18:31:00 CEST] <Angus> I seem to have figured out what the problem is. [18:32:20 CEST] <Angus> the code I have seems to be giving NAL units one at a time to FFMpeg. FFMpeg expects a stream of NAL units to read from. [19:09:40 CEST] <Daemon404> 1/g 52 [19:27:01 CEST] <rcombs> https://gist.github.com/72ded33889cbca63e18db5df1e800f9a uhhhhh [19:28:56 CEST] <rcombs> http://i3.kym-cdn.com/photos/images/original/000/234/739/fa5.jpg [19:29:23 CEST] <wm4> eh [19:29:39 CEST] <fritsch> at least he wears glasses [19:29:58 CEST] <rcombs> that diff is weird as hell [19:31:44 CEST] <rcombs> and I had no such problems with the h264 or AAC tests [20:02:34 CEST] <jamrial> rcombs: http://pastebin.com/raw/PDrYbZuV use that to make a hevc_mp4toannexb test [20:03:38 CEST] <wm4> magic data? [20:14:50 CEST] <jamrial> base64. didn't want to bother finding somewhere to host a file and i don't know if he has read access to the ftp [20:15:44 CEST] <wm4> 0x0.st would probably take it [20:19:32 CEST] <Angus> is there a way to compile FFMpeg to disable multi-threading? [20:21:10 CEST] <jamrial> Angus: --disable-pthreads [20:21:25 CEST] <wm4> that's not a good idea [20:21:42 CEST] <Daemon404> ^ [20:22:09 CEST] <Angus> Just want to test something. [20:22:46 CEST] <fritsch> with the ffmpeg binary or with your custom code? if custom code, just disable slice / frame threading when decoding something [20:23:31 CEST] <Angus> custom code. Oh, did not know that was possible. [20:25:11 CEST] <jamrial> wm4: thanks for the suggestion [20:25:26 CEST] <jamrial> rcombs: https://0x0.st/ZUy.mp4 [20:26:01 CEST] <Angus> fritsch: which options needs to be set to disable frame threading? [20:31:01 CEST] <fritsch> Angus: https://www.ffmpeg.org/doxygen/2.7/libavcodec_2avcodec_8h.html#a91bc1a1c1c4… [20:31:05 CEST] <fritsch> start here [20:32:26 CEST] <wm4> just set the thread_count field to 1 [20:32:53 CEST] <fritsch> that's easier, yes [20:33:17 CEST] <fritsch> Angus: on your avctx [20:41:38 CEST] <Angus> and that can be done between find_stream_info and read_frame? [20:42:00 CEST] <Angus> err, after avcodec_open2 [20:42:05 CEST] <wm4> you shouldn't use the AVCodec context from the AVStream for decoding [20:42:06 CEST] <wm4> and no [20:42:09 CEST] <wm4> must be before [20:43:20 CEST] <Angus> http://pastebin.com/1vCf5vK5 [20:43:34 CEST] <Angus> does that make any sense for decoding? [20:43:48 CEST] <wm4> no, don't do that [20:43:52 CEST] <wm4> create a new context [20:45:34 CEST] <Angus> so the proper way to do this, is to create the new AVCodecContext, set the thread_count, then run avcodec_find_decoder_by_name? [20:45:58 CEST] <wm4> probably best to just use avcodec_copy_context (or what's it called) [20:46:38 CEST] <wm4> if you use ffmpeg git, you should use another method [20:48:43 CEST] <Daemon404> avcodec_parameters_to_context or whatever it is [20:49:25 CEST] <wm4> it's hard to tell API users what to do since literally all API is being deprecated/replaced [20:49:48 CEST] <Angus> :( [20:50:02 CEST] <Angus> what's the difference between avcodec_parameters_to_context and avcodec_copy_context ? [21:14:31 CEST] <atomnuker> wm4: what would be needed to port a decoder to the new decode API? [21:18:33 CEST] <wm4> atomnuker: not much, it's just slightly different data flow (although you'd have to lookout for the things the avcodec_decode_video2 and avcodec_decode_audio4 wrappers do) [21:18:59 CEST] <wm4> but for audio decoders it probably wouldn't have any advantages, and for video we'd probably have to redo frame threading first [21:19:40 CEST] <wm4> so I expect that the new API becomes only relevant internally when the deprecation period is over [22:25:59 CEST] <michaelni> ubitux, did you see https://trac.ffmpeg.org/ticket/5350 "A user reported an infinite loop when using FFprobe. This is a regression since 29412821241050c846dbceaad4b9752857659977" ( lavc: allow subtitle text format to be ASS without timing) [22:34:39 CEST] <cone-031> ffmpeg 03Kieran Kunhya 07master:e9a9ca1936ea: avcodec/cfhd: Don't decode coefficients if no end of header tag found. Fixes fuzzed files such as the one in in ticket #5383 [22:50:39 CEST] <atomnuker> I am disappointed, our jpeg decoder doesn't support images using arithmetic coding [22:58:39 CEST] <rcombs> jamrial: add it to samples and I'll add the test? [23:01:20 CEST] <jamrial> rcombs: can't do that. i don't have access [23:01:32 CEST] <jamrial> if you think that sample is good then poke michaelni to upload it [23:01:38 CEST] <jamrial> and in any case, i can write the test if you prefer. i just figured you'd rather do it yourself as part of your bsf patchset [23:04:15 CEST] <rcombs> we _could_ generate an mp4 out of one of the existing hevc samples [23:04:22 CEST] <rcombs> as part of the test [23:19:52 CEST] <durandal_1707> can we finally vote? [23:22:27 CEST] <wm4> vote for what [23:25:05 CEST] <kierank> https://cdn.meme.am/instances/500x/68132114.jpg [23:27:31 CEST] <cone-031> ffmpeg 03Michael Niedermayer 07master:78baa450d993: avformat/ffmdec: Check pix_fmt [23:34:55 CEST] <Angus> https://github.com/FFmpeg/FFmpeg/search?utf8=%E2%9C%93&q=+init_input_stream [23:35:27 CEST] <Angus> hmm. Am I supposed to use InputStream at all? [23:39:18 CEST] <wm4> Angus: what are you trying to achieve at all? [23:40:07 CEST] <Angus> I'm trying to use some functions in ffmepg_vdpau [23:41:03 CEST] <Angus> but it seems the entire VDPAU HWACCEL structure is based off using InputStream [23:41:35 CEST] <wm4> uh that's ffmpeg.c stuff [23:41:38 CEST] <wm4> it's not API [23:41:59 CEST] <Angus> hmm [23:42:02 CEST] <wm4> you'll need to duplicate it (thankfully, it's not that much code if you use git) [23:42:19 CEST] <Angus> Already duplicated it :) [23:42:36 CEST] <Angus> I tried using the h264_vdpau codec, but it seems it leaves the decoded frame inside the GPU [23:42:59 CEST] <wm4> that sounds like the deprecated thing anyway [23:43:18 CEST] <wm4> and hwaccels will always decode to GPU, but the hwframe stuff can easily read it back [23:43:23 CEST] <Angus> oh, is h264_vdpau codec deprecated? [23:43:28 CEST] <wm4> (like ffmpeg_vdpau.c does) [23:43:38 CEST] <wm4> yes, it's deprecated and should have been removed a long time ago [23:43:56 CEST] <wm4> instead you use the h264 vdpau hwaccel [23:44:17 CEST] <wm4> for which you use the h264 codec, set the get_format callback, and then select the vdpau pixfmt [23:44:30 CEST] <wm4> it's not quite straightforward to use [23:44:42 CEST] <wm4> (for what's it worth, the old vdpau h264 decoder is worse) [23:45:34 CEST] <Angus> is there an example somewhere for the get_format callback? [23:45:39 CEST] <durandal_1707> vote to not commit Carl patches for supporting random data [23:47:52 CEST] <wm4> Angus: no, look at the ffmpeg.c impl. (wjich is also too tricky, but whatever) [23:49:19 CEST] <durandal_1707> I will contact saste via mail tomorrow [00:00:00 CEST] --- Fri Apr 29 2016

1 0

ffmpeg.log.20160428
by burek 29 Apr '16

29 Apr '16

[00:25:22 CEST] <prelude2004c_zzz> hey guys.. anyone know what this means " ffmpeg failed to compensate for timestamp delta " [00:39:14 CEST] <madgino> Can anyone tell me if this is correct ffmpeg -re -i http://XXXX/131.m3u8 -vcodec libx264 -acodec copy -f mpegts udp:192.168.23.10:1234 [00:39:49 CEST] <madgino> should I know be able to point a client at 192.168.23.10 and expect it play the stream? [00:46:41 CEST] <BtbN> no, you are sending the data to that IP. [00:46:43 CEST] <petecouture> madgino: mpegts is a file output demuxer [00:47:04 CEST] <petecouture> I'm not an advanced ffmpeg user by any means but I don't think that will work. [00:47:19 CEST] <BtbN> It should work, in general. But it does not do that was described. [00:47:21 CEST] <madgino> that's all good. thanks for answering.. :) [00:48:09 CEST] <madgino> I'll keep reading [00:50:46 CEST] <madgino> petecouture, how would you recommend getting retransmitting that as UDP stream, I've got high latency link so would prefer to use UDP rather than TCP [00:56:37 CEST] <BtbN> ffmpeg just sends the stream to the ip you specify. [00:57:02 CEST] <BtbN> you want to use something like RTP with Multicast if you want a stream people can "connect" to like a http/tcp server. [00:58:05 CEST] <pandb> is having audio data required to broadcast to rtmp? [00:58:40 CEST] <pandb> or is the fact that my program doesn't create an audio stream a possible reason why I can't get it to display on the server i broadcast it to? [01:09:54 CEST] <pandb> what might be the reason I keep getting console output that includes "I:0 P:0 SKIP:920 size=17 bytes"? [01:10:06 CEST] <pandb> this is whenever I call avcodec_encode_video2 [01:15:45 CEST] <spiderkeys> Interesting, if I set use_wallclock_as_timestamps=1 on my input stream, I randomly get Assertion next_dts <= 2147483647 failed at libavformat/movenc.c:874 [01:15:56 CEST] <spiderkeys> what does it meannn [01:16:42 CEST] <spiderkeys> 90% of the time it works and I get happy time stamps, when it fails, I do notice that in my find_stream_info dump it says: [h264 @ 0x7f80bc0008c0] max_analyze_duration 5000000 reached at 5005000 microseconds st:0 [01:45:16 CEST] <prelude2004c_zzz> hey guys.. looking for some serious help [01:45:18 CEST] <prelude2004c_zzz> i am out of ideas [01:45:19 CEST] <prelude2004c_zzz> http://pastebin.com/FPc6xBUG [01:45:32 CEST] <prelude2004c_zzz> the problem i am having is.... the audio / video randomly loose sync [02:44:08 CEST] <spiderkeys> Mavrik: Do you have any ideas for why av_find_stream_info() detects the following: Codec timebase: 1001/30000 Stream timebase: 1/1200000. When the SPS in the NAL units clearly denotes 6006/180000? [02:48:01 CEST] <prelude2004c_zzz> hey, can anyone help me.. still having issues and not sure waht to fix anymore [02:48:10 CEST] <prelude2004c_zzz> Could not writer header '/dev/stdout' now i am getting errors like that randomly [02:55:00 CEST] <tuxlovesyou> I want to pipe a desktop H.264 stream over SSH. Is there a way I can also get keyboard and mouse control? [02:58:43 CEST] <relaxed> prelude2004c_zzz: for support use ffmpeg's nvenc [02:59:28 CEST] <prelude2004c_zzz> the quality when using nvenc is very bad in comparison to using the NVtranscoder one [03:00:15 CEST] <relaxed> are you using the 6.0.1 sdk and the latest drivers? [03:03:12 CEST] <relaxed> if so, then file a bug report showing the difference between ffmpeg's nvenc and using NvTranscoder. [03:03:21 CEST] <tuxlovesyou> anyone? [03:06:26 CEST] <relaxed> prelude2004c_zzz: because I doubt you'll get any support with your current approach [03:07:13 CEST] <prelude2004c_zzz> :( [03:08:35 CEST] <tuxlovesyou> I want to pipe a desktop H.264 stream over SSH. Is there a way I can also get keyboard and mouse control? [03:08:44 CEST] <tuxlovesyou> seriously, no takers? [03:10:18 CEST] <relaxed> tuxlovesyou: explain what you're doing [03:10:48 CEST] <spiderkeys> tuxlovesyou: on irc in general, it would be prudent to never presume you'll get a response within the minute in which you ask [03:11:44 CEST] <spiderkeys> I usually set my expectations to within the half a day... or never. [03:12:06 CEST] <tuxlovesyou> sorry [03:12:24 CEST] <tuxlovesyou> I want to stream games over ssh or netcat [03:13:08 CEST] <tuxlovesyou> do a LAN party with one beefy PC that allows shitty PCs to play [03:15:30 CEST] <relaxed> ffmpeg is a transcoder [03:15:35 CEST] <tuxlovesyou> I know [03:15:43 CEST] <tuxlovesyou> I need something to compliment it [03:15:49 CEST] <tuxlovesyou> for mouse coords [03:16:11 CEST] <tuxlovesyou> I want to pipe an H.264 or JPEG stream [03:18:15 CEST] <tuxlovesyou> I've got the FFMPEG part down, but I have no idea what I'd use for the other stuff [03:18:24 CEST] <relaxed> I think you want VNC or something similar. [03:18:46 CEST] <tuxlovesyou> I do, but with a lower data rate [03:18:58 CEST] <tuxlovesyou> I want H.264 VNC [03:22:49 CEST] <tuxlovesyou> Recording my desktop with ffmpeg is awesome [05:03:08 CEST] <needmorespeed> How do I specify a file path to avio_open, on Windows? For example, I think backslashes are not allowed. [08:22:27 CEST] <ajsharp> anyone have any luck installing ffmpeg on debian jessie? [08:22:36 CEST] <ajsharp> (from apt) [08:34:23 CEST] <Mavrik> ajsharp, just use static builds [08:34:31 CEST] <Mavrik> So much less annoyance [08:34:37 CEST] <ajsharp> @Mavrik would love to [08:34:58 CEST] <ajsharp> where can i find em? need to use an older version -- the builds linked from the site are only latest [08:36:03 CEST] <Mavrik> http://johnvansickle.com/ffmpeg/ ? [08:36:06 CEST] <Mavrik> Ah. [08:36:14 CEST] <Mavrik> Just how old? [08:36:20 CEST] <Mavrik> Since there's latest stable there too. [08:41:34 CEST] <ajsharp> @Mavrik 2.7 [08:41:49 CEST] <ajsharp> lol and that site is 503-ing rn [08:41:55 CEST] <ajsharp> n/m back [09:14:33 CEST] <pandb> I finally got my program to successfully stream live to youtube :D [09:15:13 CEST] <pandb> but I've noticed that it only seems to work if I include an audio stram and send audio packets to the muxer, even though I have no use for sound right now. Is audio a requirement for rtmp? [09:16:30 CEST] <pandb> i've tried not adding an audio stream, or just not generating audio frames, and nothing ever shows up [11:00:56 CEST] <Borkr> Sorry if this is off-topic, but I'm not quite sure where to ask this. I'm creating my own audio visualizer, showing the typical frequencies for a 31 band equalizer. My problem is, it's only showing the amplitude for those specific frequencies, so the spectrum looks more like noise and you don't really feel that it follows the beat. I guess I'll have to average out the amplitudes for the selected frequencies somehow. I have amplitude 22k frequencies between [11:00:56 CEST] <Borkr> 20 and 20k to work with. Any tips on how to create the averages? Taking the average from the frequency between two band frequencies looks rather flat (constant amplitude) when you get over a couple of hundred Hz. [11:03:00 CEST] <durandal_170> it's all described in papers [11:08:30 CEST] <Borkr> durandal_170 I'm not quite sure which keywords to look for. Any suggestions to phrasing or papers would be greatly appreciated [11:20:04 CEST] <Carlrobertoh> Hi! I'm writing a C++ code for screen casting using ffmpeg libraries. I'm able to save the video on disk, but it has no video timeline(duration) and also the video is like 2-3x faster than it should be. Also i'm using H.264 codec. Could someone please tell me what could be te issue here? [12:20:51 CEST] <Wader8> hi [12:21:13 CEST] <Wader8> i was wondering how to extract DVB subtitles, found some old examples but those are too old with old syntax [12:30:14 CEST] <flux> carlrobertoh, well I guess it should be obvious that time stamps are wrong?-) [12:30:26 CEST] <flux> carlrobertoh, or perhaps the track doesn't have a time base [12:30:41 CEST] <flux> carlrobertoh, I suggest you increase the logging verbosity of ffmpeg if you aren't getting diagnostics on that [12:30:53 CEST] <Carlrobertoh> outFrame->pts = frame_count++; outPacket->stream_index = stream->index; outPacket->pts = frame_count++; outPacket->dts = AV_NOPTS_VALUE; [12:31:03 CEST] <Carlrobertoh> AVRational rational = { 1, 25 }; output_codec_ctx->time_base = rational; [12:31:29 CEST] <flux> and are you getting the data in 25 fps? [12:31:50 CEST] <Carlrobertoh> How could i check that? [12:32:02 CEST] <flux> well, output time stamps when you capture a frame, compare them.. [12:32:24 CEST] <flux> or how are you getting those frames anyway? [12:32:38 CEST] <Carlrobertoh> gdigrab [12:33:10 CEST] <flux> in any case, the fix here is not to set the frame rate to 25 [12:33:27 CEST] <Carlrobertoh> here's the code http://pastebin.com/wve66YA4 and here's the video http://www.upload.ee/files/5765237/test.h264.html [12:33:35 CEST] <flux> instead, use a time base such as { 1, 10000 } and the as the pts use the real time from the start of the recording (you measure this time) [12:33:48 CEST] <flux> so in that case the number of seconds * 10000. [12:34:38 CEST] <Carlrobertoh> 1/25 * 10000 ? [12:35:16 CEST] <flux> where are you getting 1/25? [12:35:34 CEST] <flux> ah so you are using ffmpeg for capturing [12:35:48 CEST] <Carlrobertoh> yes [12:35:58 CEST] <flux> doesn't it come with pts data? [12:36:09 CEST] <Carlrobertoh> u mean gdigrab ? [12:36:14 CEST] <flux> yes.. [12:36:25 CEST] <flux> you get a packet in, doesn't it have a valid value in the pts field? [12:36:58 CEST] <Carlrobertoh> GDIGRAB : Set the grabbing frame rate. Default value is ntsc, corresponding to a frame rate of 30000/1001. [12:36:58 CEST] <flux> if you use its values, you should also use the input stream's time base, or either convert the values [12:39:23 CEST] <flux> I don't think it's a guarantee that you get the number of frames per second you request. [12:39:32 CEST] <flux> I mean, you could just ask 1000 frames per second and it's not going to deliver. [12:41:08 CEST] <Carlrobertoh> what should i change in my code? [12:41:17 CEST] <Carlrobertoh> i have no clue [12:41:50 CEST] <Carlrobertoh> where should i put this value ? 30000/1001 [13:23:05 CEST] <Carlrobertoh> damn, i've tried everything, i can't figure this out [13:24:14 CEST] <Carlrobertoh> every value i set to outFram->pts , the result is same. although if i don't set the outFrame , then the quality is going low every second [13:57:35 CEST] <pkajaba> Hello guys, Have you tried to compile ffmpeg with openCV 3.1? [14:02:06 CEST] <prelude2004c_zzz> good morning eeryone.. still struggling here :( [14:06:50 CEST] <Carlrobertoh> flux [14:07:19 CEST] <Carlrobertoh> earlier you mentioned: <flux> you get a packet in, doesn't it have a valid value in the pts field? [14:08:04 CEST] <Carlrobertoh> you mean "av_read_frame( input_format_ctx, packet )" whereas packet->pts has a valid value ? [14:08:33 CEST] <Carlrobertoh> does "packet->pts == 1461845196779119" counts valid ? [14:11:18 CEST] <jkqxz> It looks like the current UNIX time in microseconds. [14:13:03 CEST] <AndrewMock> https://git.videolan.org/?p=ffmpeg.git;a=commit;h=d9791a8656b5580756d5b7ecc… [14:13:40 CEST] <AndrewMock> Is the native aac encoder the best for 256k stereo video recordings? [14:14:39 CEST] <furq> fdk-aac is probably better but you'll struggle to notice any difference at 256kbps [14:14:41 CEST] <AndrewMock> No recent benchmarks or tests. [14:14:46 CEST] <AndrewMock> good point [14:15:04 CEST] <furq> even faac will sound good at 256k [14:15:31 CEST] <AndrewMock> to be fair we got some insane equipment this is played on [14:16:07 CEST] <AndrewMock> but yeah I guess I will use aac to keep it "free" [14:16:26 CEST] <furq> fdk is open-source, it's just not gpl compatible [14:16:50 CEST] <furq> it's probably not worth recompiling though [14:17:15 CEST] <furq> there's always flac in mkv if you need it to sound perfect [14:17:32 CEST] <AndrewMock> trying to dropbox around here is hard [14:18:03 CEST] <AndrewMock> plus when I deliver cinema packages i do that by hand so i can use that kinda bandwidth [14:18:22 CEST] <AndrewMock> thx [14:18:57 CEST] <furq> well there's also opus in mkv [14:19:04 CEST] <flux> carlrobertoh, if it's not AV_NOPTS_VALUE then it's valid [14:19:05 CEST] <furq> that ought to sound the best out of the lossy codecs [14:19:12 CEST] <flux> carlrobertoh, and it's in stream time base units.. [14:19:13 CEST] <furq> assuming the player supports it [14:21:32 CEST] <Carlrobertoh> okey, i checked if it doesnt != AV_NOPTS_VALUE [14:21:52 CEST] <Carlrobertoh> so what gonna i do next? assign this value to outFrame->pts ? [14:23:54 CEST] <flux> yes. also you need to use the input stream's time base. [14:24:38 CEST] <Carlrobertoh> input_format_context doesn't have a time_base [14:26:20 CEST] <Carlrobertoh> or i have to assign output_codec_ctx->time_base = input_codec_ctx->time_base outside while loop ? [14:39:40 CEST] <Carlrobertoh> flux, I got it almost working but the video is still like 1/4 faster than it should be [14:55:50 CEST] <Carlrobertoh> Please could anybody help me? My video playback is like 1/4 faster than it should be. I'm using gdigrab to record my screen and then save it on disk. The output frame pts is taken from input packet and output_codec_ctx time_base is taken from input_codec_ctx time_base [15:02:00 CEST] <flux> carlrobertoh, can you post file you cannot play? [15:02:15 CEST] <flux> preferably with a service that doesn't have so many popups if possible :P [15:02:27 CEST] <Carlrobertoh> um [15:02:35 CEST] <Carlrobertoh> upload.ee isn't good place? [15:02:41 CEST] <Carlrobertoh> :d [15:03:16 CEST] <Carlrobertoh> http://www.upload.ee/files/5765587/test.mp4.html [15:03:19 CEST] <Carlrobertoh> i did in anyways lol [15:05:10 CEST] <flux> true it doesn't play with vlc. it does play with mpv but it complains "No video PTS! Making something up." [15:05:20 CEST] <flux> did you set the global headers flag on as in some of the examples? [15:05:41 CEST] <flux> ah, never mind [15:05:51 CEST] <flux> the file has extension .mp4 but it's not mpeg4, but .h264.. [15:07:30 CEST] <Carlrobertoh> yes. so should i add the global headers flag_ [15:08:07 CEST] <flux> but I guess there's something else wrong because that's no MPEG4 file. also my tools say the file is truncated. [15:13:55 CEST] <Carlrobertoh> okey, thanks flux [15:13:59 CEST] <Carlrobertoh> i'll try to handle that [16:49:29 CEST] <spirou> are there parameters to ffprobe to make it show more information about the file? [16:49:56 CEST] <c_14> yes [16:51:16 CEST] <spirou> to show how compliant the file is, I have a mp4 that ffmpeg complains about the h264 stream in it when trying to convert it, becuase it is missing something, it could be nice if ffprobe could show info about that [16:51:55 CEST] <c_14> https://ffmpeg.org/ffprobe.html [16:52:27 CEST] <c_14> check show_format, or show_streams or show_entries or something [16:56:13 CEST] <spirou> ok [16:58:35 CEST] <spirou> if I understand right the missing "global headers" it complains about is "Sequence Parameter Set (SPS)/Picture Parameter Set (PPS) information for H264 encoding. If this global header is not provided, some devices cant play the encoded file" [17:08:00 CEST] <spirou> ..and that those can't be generated afterwards without destructively recompress the stream? [17:13:39 CEST] <Shiz> Is there a way I can simply make ffmpeg(1) copy all mpeg-ps packets it doesn't recognize? I'm dealing with a file whose audio format is not recognized but all I want to do is replace the video stream [17:14:06 CEST] <c_14> -copy_unknown ? [17:16:53 CEST] <Shiz> it doesn't seem to copy over the PRIVATE_STREAM_1 packets that contain the audio [17:17:25 CEST] <Shiz> using $ ffmpeg -i ~/Downloads/movies/MV000_0003.pmf -i MV0.h264 -map 1:v -codec copy -copy_unknown out.mpeg [17:17:45 CEST] <c_14> you're not mapping the audio stream [17:18:11 CEST] <Shiz> because it doesn't recognize it as an audio stream [17:18:21 CEST] <c_14> map the stream number explicitly? [17:18:57 CEST] <Shiz> rather, it doesn't recognize it as a stream at all [17:20:25 CEST] <Shiz> hmmm.. [17:24:43 CEST] <spirou> btw, there can't be spaces around colons : as used in the examples on the https://ffmpeg.org/ffprobe.html#Main-options [17:24:54 CEST] <Shiz> i made a small patch to ffmpeg to recognize it as an unknown stream, but that gives me this: http://txt.shiz.me/MmNjNzU2ND [17:25:32 CEST] <JEEB> yeah, that won't work [17:35:22 CEST] <Wader8> anyone knows how to extract subtitles ? [17:35:45 CEST] <Wader8> these are in HDTV .TS DVB_SUB [17:35:55 CEST] <Wader8> i'd like to add them to a MKV [17:35:56 CEST] <Shiz> JEEB: seems like that was what copy_unknown was made for but apparently :V [17:39:27 CEST] <spirou> Wader8: I'm not sure what file format do have a dvd subtitle only. I suppose you could store only that stream in some mp4 file or something though [17:39:40 CEST] <furq> he wants dvb subs, not dvd [17:39:54 CEST] <furq> you should be able to remux them into ts, but i'm not sure if they're supported in mkv [17:40:11 CEST] <spirou> the problem with dvd subs is that they are graphics though, so you can't just out to a .srt [17:41:03 CEST] <Wader8> well i would convert them to what MKV can use, no program seems to be able to recognize DVB subs, and MakeMKV doesn't support .TS [17:43:11 CEST] <spirou> There are other subtitle formats that is graphics too? isn't that the "VobSub" format? [17:43:32 CEST] <furq> vobsub is a different format to both [17:43:51 CEST] <spirou> Wader8: you could OCR the text with some program of course to get the text. if you have time. [17:43:55 CEST] <furq> you can convert dvd subtitles to vobsub losslessly because they're both image formats [17:43:59 CEST] <furq> idk about dvb subs, i've never encountered them [17:44:20 CEST] <furq> i don't think you'll have much luck converting them with ffmpeg though [17:45:11 CEST] <spirou> yeah that must be some other program. and probably needs some manual corrections to train it for the font used in that dvd sub. [17:45:48 CEST] <spirou> otherwise you get mixed l and I and O and 0 and such [17:45:52 CEST] <furq> afaik the .idx part of vobsub is the stuff from the ifo and the .sub is the subtitle bitmaps from the vob [17:46:15 CEST] <furq> the data itself is the same but the container is different [17:46:19 CEST] <spirou> ok [17:47:01 CEST] <furq> ffmpeg doesn't have a vobsub encoder though so i think you'll need to use a different tool for converting image bitmaps [17:47:09 CEST] <furq> or muxer, rather [17:49:39 CEST] <furq> Wader8: apparently subtitle edit supports dvb subs in ts [17:49:52 CEST] <furq> you should be able to convert them to a better format with that [17:55:30 CEST] <Wader8> i only found this https://ffmpeg.org/pipermail/ffmpeg-user/2011-September/002471.html [17:58:35 CEST] <Wader8> the file is .TS for HDTV, so i believe it's configured differently than other .TS . since it's from the HDTV's own PVR recorder feature [17:58:53 CEST] <Wader8> the codecs are MPEG2 and AVC for 1080i [17:59:04 CEST] <Wader8> MPEG2 is also interlaced [17:59:19 CEST] <furq> like i said, i don't think ffmpeg can convert them and i don't think mkv supports them [17:59:24 CEST] <Wader8> but the framerates are all whole, 25 [17:59:41 CEST] <Wader8> furq, but I asked how to extract them [18:00:23 CEST] <Wader8> MPC-HC supports them so if the players can do it why can't other programs, i'll find something [18:00:25 CEST] <furq> there is a file format for it (.son) but ffmpeg doesn't seem to have a muxer for it [18:01:28 CEST] <sfan5> can't you extract just the subs to a seperate mkv [18:01:33 CEST] <Wader8> i had 3 files from HDTV, i converted them sucessfully, only 2 contained subtitles, and only one of the files has another companion .idx2 [18:01:40 CEST] <sfan5> and then use mkvmerge to merge the video/audio file and the sub file into a single mkv? [18:01:44 CEST] <Wader8> i'm not saying i want to extract them to a separate mkv [18:02:07 CEST] <Wader8> i believed MP4 probably doesn't support DVB subs so I said MKV out of hope [18:02:32 CEST] <sfan5> mp4 doesn't support dvbsub correct [18:02:38 CEST] <furq> does mkv support dvbsub [18:03:16 CEST] <Wader8> if I have to use TS, i'll use TS then, but I think TSMuxer doesn't even support them, i didn't see em when I opened the original TS [18:04:20 CEST] <Wader8> i'm done recoding, i packed to a MKV, i can still remux to TS with the subs, so I understand that but I believe TSMuxer didn't recognize them or I didn't see, since I never used TSMuxer before [18:05:33 CEST] <Wader8> MakeMKV helped me a ton because it supports DVDs, since handbrake doesn't so it doesn't auto-add markers, but it does from MKV, so I used that combination for that, now I'm mostly done with DVDs i have some HDTV recordings left [18:05:58 CEST] <Wader8> furq, you ask me I have no idea, i have trouble finding anything on the net anyway, it's all 5 years old [18:06:10 CEST] <furq> i was asking sfan5 [18:06:15 CEST] <Wader8> oh [18:06:25 CEST] <furq> a brief google suggests they don't [18:06:29 CEST] <furq> or it doesn't, rather [18:06:47 CEST] <Wader8> btw, it's cable, so the .TS file standard is part of DVB-C [18:06:53 CEST] <Wader8> not DVB-T [18:07:44 CEST] <sfan5> hm [18:07:50 CEST] <sfan5> i'll go make a recording to test with [18:08:36 CEST] <Wader8> well, DVB-C is more of an european thing, not so much anywhere else that's why isn't that supported [18:09:00 CEST] <Wader8> but even then it's mixed among countries [18:09:47 CEST] <spirou> I suppose Transcode would be a ok program for dvd subtitle stuff.. [18:10:06 CEST] <thebombzen> ahhhh segfault :( [18:10:28 CEST] <thebombzen> frustrating [18:10:41 CEST] <spirou> thebombzen: we all love them, right? ;D [18:10:45 CEST] <thebombzen> #thatawkwardmomentwhen ffmpeg works and then you pull it and rebuild it and then it doesn't work [18:11:03 CEST] <thebombzen> well I submitted a report so it'll probably get fixed fairly soon [18:11:07 CEST] <Wader8> MKV should add support for it, since it's such a container as a replacement, and it's kinda silly to have to rely on TS if I have all my stuff in MKV, i hope I'm not making too of a big deal out of this, but it's, I'm making an archive, I'd not like to make crappy recodes, i made sure I added all the subtitles and bonus stuff from DVDs [18:11:45 CEST] <thebombzen> yea MKV should support everything. whenever I don't have any clue what container to put something in I just put it in mkv [18:13:52 CEST] <spirou> thast doesn't mean the player in the other end will like your mkv though [18:14:32 CEST] <spirou> "no global headers in your video stream? no sound for you!" [18:15:19 CEST] <sfan5> Stream #0:7[0x1469](deu): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired) [18:15:24 CEST] <sfan5> Stream #0:2(deu): Subtitle: dvb_subtitle ([255][255][255][255] / 0xFFFFFFFF) (hearing impaired) [18:15:31 CEST] <sfan5> copied into a mkv seems to work [18:16:26 CEST] <sfan5> and it works with mpv [18:16:41 CEST] <sfan5> Wader8: when transcoding just do -c:s copy and it should work [18:17:40 CEST] <Wader8> is there any difference in what kind of MKV it is if it's done with different programs, the version should matter right ? [18:17:59 CEST] <Wader8> like Handbrake, MakeMKV, ffmpeg, if i use ffmpeg i probably have the latest righ ? [18:19:55 CEST] <sfan5> "ffmpeg version 3.0 Copyright (c) 2000-2016 the FFmpeg developers" [18:20:09 CEST] <sfan5> Wader8: here's an example resulting mkv file: https://a.uguu.se/dvyonh_test.mkv [18:20:25 CEST] <Wader8> that's how my HDTV TS DVB subs look in FFProbe [18:20:28 CEST] <Wader8> http://pastebin.com/EiidYnqW [18:21:53 CEST] <sfan5> that's how my file looks too [18:22:30 CEST] <Wader8> MKV may support it, it's just that Handbrake doesn't [18:22:36 CEST] <Wader8> and MKVToolNix neither [18:22:56 CEST] <Wader8> at least the GUI [18:23:39 CEST] <sfan5> i used ffmpeg for converting the .ts [18:23:45 CEST] <sfan5> and that works so ¯\_(Ä)_/¯ [18:24:02 CEST] <Wader8> from .TS [18:24:14 CEST] <Wader8> does MKVToolNix have a trac ? [18:24:32 CEST] <sfan5> huh [18:24:35 CEST] <Wader8> i should send this, it supports dvbsubs from mkv, but not from .ts [18:24:37 CEST] <sfan5> mkvtoolnix seems to read the subs just fine [18:24:59 CEST] <Wader8> this is very important since .ts is the format which comes off the HDTV PVR, so support here is crucial [18:25:01 CEST] <sfan5> if mkvtoolnix supports subs from mkv where's the problem? [18:25:12 CEST] <sfan5> you can just use ffmpeg to put the subs from the .ts into an mkv [18:25:59 CEST] <Wader8> I would be encouraged in future to do more recordings, because i didn't had a plan how to recode i didn't, so now I do, good i figured this out [18:26:06 CEST] <Wader8> i'll see how ffmpeg goes right now [18:27:01 CEST] <Wader8> doesn't really help if MKVToolNicks reads dvbsubs from an input MKV [18:27:10 CEST] <sfan5> it does, you can remux [18:27:14 CEST] <Wader8> it doesn't read them off .TS [18:27:25 CEST] <Wader8> so i guess one more intermediary step with ffmpeg [18:27:26 CEST] <Wader8> for now [18:27:55 CEST] <Wader8> i have the latest toolnix 9.1.0 x64 [18:28:25 CEST] <Wader8> it shows 2 streams, MPEG2 video, MPEG2 audio [18:28:39 CEST] <sfan5> no intermediary for me, i just use ffmpeg for transcoding [18:28:44 CEST] <sfan5> why not just use ffmpeg? [18:28:51 CEST] <Wader8> i am using ffmpeg all the time [18:29:55 CEST] <thebombzen> well it appears the bug I submitted has already been reproduced, and changed from normal -> important. cehoyos is pretty fast apparently [18:30:13 CEST] <Wader8> i switched to MakeMKV and Handbrake for the DVD recodings since it was way faster and all the subs, markers, bonus stuff transferred nicely to a MKV, then Handbrake read the MKV properly and Recoded the video, passed thru the AC3 audio, added the subs, and exported as x264 MKV, it was great [18:31:06 CEST] <Wader8> previously i was trying to concat vobs with ffmpeg manually [18:34:08 CEST] <Wader8> trac for MKVToolNix seem to end up on github [18:34:37 CEST] <Wader8> not sure got some old info [18:45:04 CEST] <ajsharp> anyone here had success creating a static build of ffmpeg? [18:45:24 CEST] <ajsharp> i must not be passing the right flags b/c running ldd still shows lots of links [18:47:03 CEST] <c_14> What's your configure line? [18:47:53 CEST] <ajsharp> ./configure --disable-shared --enable-static --enable-pthreads --enable-libopenjpeg --enable-libfaac --enable-nonfree --pkg-config-flags="--static" --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" --prefix=/home/admin/ffmpeg-install [18:48:32 CEST] <ajsharp> i've taken out a lot of optional features for the moment to cut down on build time while i'm debugging this [18:48:37 CEST] <BtbN> ffmpeg can't magically make all your system libs into static libs [18:48:47 CEST] <ajsharp> trying to create a static build of 2.7.2 [18:49:11 CEST] <BtbN> enable-static only causes the libav* libraries to be linked and created as static libs [18:49:21 CEST] <BtbN> if an external library is static depends entirely on that library itself [18:49:43 CEST] <ajsharp> @BtbN that's fair, but when i try to copy it to a target system, it blows up on non-system libs [18:49:51 CEST] <ajsharp> ffmpeg: error while loading shared libraries: libavdevice.so.56: cannot open shared object file: No such file or directory [18:50:13 CEST] <BtbN> that's basically impossible when you configure it with --disable-shared --enable-static. [18:50:23 CEST] <BtbN> there are no .so files created [18:51:23 CEST] <furq> ajsharp: try adding -Wl,-Bstatic to extra-ldflags [18:51:58 CEST] <ajsharp> @furq thx. also, fwiw, i'm building from the source directory, and for that particular lib, it's located at ./libavdevice/libavdevice.so in the source distribution [18:52:07 CEST] <furq> at a guess it's linking against system shared libs [18:53:20 CEST] <c_14> distclean and try again? [18:53:27 CEST] <c_14> If that .so file exists something is wrong [18:53:53 CEST] <ajsharp> @c_14 in the built binary you mean? [18:54:10 CEST] <ajsharp> (just distclean'd, trying again) [18:54:37 CEST] <c_14> In the build directory [18:54:53 CEST] <ajsharp> tbh, i don't really understand what --extra-cflags and the like are for. are those supposed to be pointing at the source directory? [18:55:05 CEST] <ajsharp> where those libs & includes are located? [18:55:29 CEST] <c_14> where the libs are located [18:55:50 CEST] <ajsharp> in the source distribution? [18:55:59 CEST] <cousin_luigi> Greetings. [18:56:21 CEST] <cousin_luigi> I may have already asked, but how do x265 and kvazaar compare? [18:57:12 CEST] <sfan5> neither is production-ready [18:57:23 CEST] <sfan5> x265 is more production-ready than kvazaar [18:57:29 CEST] <sfan5> and also faster [18:57:56 CEST] <cousin_luigi> sfan5: Does kvazaar have any advantage over x265? [18:58:35 CEST] <kepstin> better name? [19:04:30 CEST] <sfan5> no idea [19:04:32 CEST] <ajsharp> ok so that cut down on the number of shared libs from 68 to 55, and by a quick pass they seem to all be system libs...gonna try a copy to target system [19:05:42 CEST] <ajsharp> yea, last binary was 208k, this one is 14mb :) [19:07:33 CEST] <ajsharp> different failure! [19:07:47 CEST] <ajsharp> libva.so.1 [19:08:21 CEST] <sfan5> disable vaapi [19:09:41 CEST] <spirou> about static compile stuff.. how "static" is the ppa:mc3man/trusty-media build? "Ubuntu Multimedia for Trusty PPA. Provides static binaries from most recent release branch" [19:12:23 CEST] <ajsharp> @sfan5 what does vaapi do? [19:12:34 CEST] <sfan5> hardware decoding [19:12:42 CEST] <ajsharp> ah [19:14:49 CEST] <ajsharp> still seeing dynamic links to things like libvorbis and libopenjpeg -- i must be screwing something up in the flags [19:15:02 CEST] <ajsharp> presumably --extra-ldflags [19:15:15 CEST] <c_14> you probably just don't have static libraries of those libs [19:15:16 CEST] <furq> do you actually have static libs of those on your system [19:15:19 CEST] <ajsharp> and --extra-cflags [19:15:33 CEST] <ajsharp> @c_14 i'd need to build those statically, right? [19:15:40 CEST] <furq> depends on what your package manager provides [19:15:46 CEST] <furq> if you only have shared libs then that's what'll get linked [19:16:10 CEST] <furq> -dev packages on debian derivatives usually contain static libs [19:16:12 CEST] <ajsharp> i was trying to co-opt this but build is failing https://github.com/zimbatm/ffmpeg-static [19:16:23 CEST] <ajsharp> furq right, makes sense [19:18:04 CEST] <furq> fwiw if you want it to be totally portable you'll probably need to static link libc (and libstdc++ if you have any c++ libs) [19:18:15 CEST] <furq> which afaik means building against musl or something [19:18:49 CEST] <ajsharp> @furq yea, i don't need to go that deep, i'm copying to the same os version, so most shared libs should be the same [19:18:55 CEST] <furq> fair enough [19:19:08 CEST] <furq> if it's a reasonably close glibc version then you should be fine [20:12:04 CEST] <ajsharp> with the help of a shitload of packages, i got the 'static' build to work :) [20:26:55 CEST] <vade> TFW you get one more frame from your encode than what you decoded& [20:30:40 CEST] <ajsharp> anyone know what lib-postproc is used for? [20:40:46 CEST] <spiderkeys> ajsharp: My ./configure looks about the same as yours. Here is what I have to use to build my application with static libs: [20:40:47 CEST] <spiderkeys> LDLIBS = -static -lzmq -lmxcam -lmxuvc -lavformat -lavcodec -lavutil -lswresample -lswscale -lx264 -Wl,--whole-archive -lpthread -Wl,--no-whole-archive -ldl -lz [20:41:01 CEST] <spiderkeys> you can ignore the first three of those libs [20:41:56 CEST] <ajsharp> @spiderkeys great, thanks, much appreciated [20:42:22 CEST] <spiderkeys> ajsharp: https://github.com/OpenROV/openrov-ffmpeg/blob/master/build.sh [20:42:40 CEST] <spiderkeys> thats for an older commit of ffmpeg. I had to disable-vaapi in a newer one [20:45:22 CEST] <spiderkeys> it still gives me some weird warnings about libc and static linking sometimes, which only started happening recently. Don't know if its a gcc thing or what, but it doesn't seem to hurt anything [20:46:00 CEST] <spiderkeys> static linking is always such a pain [20:46:59 CEST] <ajsharp> yea, i'm need to use 2.7...i'm basically just trying to create a docker image so i can build it once and be done with it [20:47:09 CEST] <spiderkeys> Now that I think about it, its probably because I built ffmpeg with gcc-4.8.x and since then installed 4.9.x and build my app with that. probably different version of libc/c++ [20:47:23 CEST] <ajsharp> it seems to be working with a bunch of dynamically linked libs via apt, but, whatever [20:55:27 CEST] <needmorespeed> I have a sharing violation on a file written with FFmpeg. I can open the file with VLC, but LockHunter says its still locked by my app. [21:02:44 CEST] <vade> how do I use av_guess_format to properly hint for MP4v2 vs MP4v1 container ? [21:03:40 CEST] <vade> oh. part 14 [21:03:41 CEST] <vade> duh [21:03:48 CEST] <vade> hm [21:04:59 CEST] <Elgul> I have the following problem: having .mp4 anime movie ;)))))))) and .srt subtitles file and I want to hardcode the subs, tried it all, but it wont work for me. [21:05:05 CEST] <vade> so my output codec according to media info is Codec ID : isom (isom/iso2/avc1/mp41) [21:05:17 CEST] <vade> my source is Codec ID : mp42 (mp42/isom) [21:05:36 CEST] <vade> how do I hint my guess format for mp42? :X im likely missing something here [21:05:58 CEST] <c_14> Elgul: ffmpeg -i mp4 -vf subtitles=subtitles.srt out.mkv [21:06:17 CEST] <Elgul> but I need it as mp4 [21:06:24 CEST] <Elgul> because of mimetype [21:06:39 CEST] <Elgul> is there a way to hardcode subs into mp4? [21:06:44 CEST] <Elgul> or will it only work with mkv? [21:07:05 CEST] <c_14> then just change the file ending to mp4 [21:07:12 CEST] <Elgul> actually I did that [21:07:23 CEST] <Elgul> it converted 1h [21:07:27 CEST] <Elgul> but there are no subs [21:07:34 CEST] <Elgul> at least not hardcoded [21:07:48 CEST] <Elgul> alright [21:07:51 CEST] <c_14> maybe add -t 10 before out.mp4 then it will only encode 10s as a test [21:07:52 CEST] <Elgul> gimme a second [21:08:34 CEST] <Elgul> http://hastebin.com/ulozafexek.rb [21:09:30 CEST] <c_14> that's not the command I gave you [21:09:37 CEST] <c_14> That also doesn't hardcode the subtitles [21:09:43 CEST] <Elgul> no? [21:10:00 CEST] <c_14> no [21:10:29 CEST] <c_14> It encodes the subtitles in the mov_text format (a text subtitle format) and places that as a separate stream into the mp4 [21:10:45 CEST] <c_14> Players which then support that subtitle format can show those subtitles, but it's not hardcoded [21:10:46 CEST] <Elgul> I am trying your command now [21:12:48 CEST] <Elgul> https://w0bm.com/out.mp4 [21:12:50 CEST] <Elgul> nope [21:12:54 CEST] <Elgul> http://hastebin.com/zereroneji.sm [21:13:00 CEST] <Elgul> I used your command [21:15:08 CEST] <c_14> Can you upload the subtitle file? Or at least the first chunk of it [21:15:14 CEST] <Elgul> sure [21:15:56 CEST] <Elgul> https://w0bm.com/subs.srt [21:19:33 CEST] <c_14> works fine here [21:19:37 CEST] <c_14> try updating your version of ffmpeg? [21:19:42 CEST] <Elgul> hm [21:19:58 CEST] <Elgul> I am running centos and took ffmpeg from the nux repo I guess [21:20:07 CEST] <c_14> Try a static build [21:20:09 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [21:21:10 CEST] <Elgul> this is willbe pain to get this running [21:21:12 CEST] <Elgul> I am sure [21:21:14 CEST] <Elgul> but I'll try [21:21:18 CEST] <Elgul> cause anime evening is important [21:22:10 CEST] <c_14> the static build should just work" [21:22:23 CEST] <Elgul> lets hope [21:22:37 CEST] <Elgul> I dont like compiling [21:22:51 CEST] <Elgul> especially not when I just want everything to work [21:23:17 CEST] <Elgul> ./configure [21:23:20 CEST] <Elgul> make [21:23:21 CEST] <Elgul> waiting [21:24:10 CEST] <c_14> Get a pc with more cores and make -j32 [21:24:28 CEST] <Elgul> I am doing all this on my dedicated server [21:24:37 CEST] <Elgul> 8 cores [21:24:47 CEST] <Elgul> 4TB Raid 1 [21:24:50 CEST] <Elgul> and shit [21:24:52 CEST] <Elgul> it's too big [21:25:17 CEST] <c_14> what's too big? [21:25:24 CEST] <Elgul> my server for my needs [21:33:49 CEST] <vade> ok, so ffprobe indicates my source is major brand mp42 compatible mp42isom - my libavformat/libavcodec transcode indicates major brand isom compatible isomiso2avc1mp41 [21:34:05 CEST] <vade> how do I get my muxer / output format context to be mp42 major brand? [21:34:39 CEST] <Elgul> now it says: no such filter: 'subtitles' [21:34:41 CEST] <Elgul> this is shit [21:36:34 CEST] <c_14> The one you built yourself? [21:36:37 CEST] <Elgul> yes [21:37:01 CEST] <Elgul> http://hastebin.com/siyugeruyu.vbs [21:37:07 CEST] <c_14> You need to enable libass (and probably fontconfig) [21:37:20 CEST] <c_14> Did you try the static build? [21:37:26 CEST] <Elgul> this is the static one [21:37:29 CEST] <Elgul> I downloaded it [21:37:32 CEST] <vade> libass. *giggle* [21:37:33 CEST] <Elgul> compiled it [21:37:36 CEST] <Elgul> hihi ass [21:37:38 CEST] <Elgul> :> [21:37:58 CEST] <c_14> Eh, the static build I linked is pre-built. i.e. no need to compile it [21:38:24 CEST] <Elgul> ah fuk [21:38:26 CEST] <Elgul> I am stupid [21:38:28 CEST] <Elgul> fuck me [21:40:22 CEST] <Elgul> hehe if it now works you are my man c_14 [21:41:40 CEST] <Elgul> https://w0bm.com/pleasework.mp4 [21:41:44 CEST] <Elgul> I give up [21:42:24 CEST] <c_14> Maybe your computer just hates you? [21:42:32 CEST] <Elgul> http://hastebin.com/ocokosizuy.sm [21:42:34 CEST] <Elgul> cant tell [21:42:41 CEST] <Elgul> just can tell that this is fucked [21:43:58 CEST] <c_14> Maybe your fontconfig doesn't like you and is giving you transparent fonts? [21:44:09 CEST] <c_14> Maybe try ffmpeg -i subs.srt out.ass and then use the ass filter -vf ass=out.ass [21:44:10 CEST] <Elgul> that would be mean [21:44:27 CEST] <Elgul> yep will try now [21:47:00 CEST] <Elgul> nope [21:47:02 CEST] <Elgul> not working [21:47:04 CEST] <Elgul> this is shit [21:47:06 CEST] <Elgul> I hate it [21:48:10 CEST] <smthorwhat> hey guys. anyone know what this means " [graph 1 aresample for input stream 0:2 @ 0x207b280] [SWR @ 0x21de040] Failed to compensate for timestamp delta of 273.516250" [21:48:15 CEST] <smthorwhat> is there something i can use to fix that ? [21:52:16 CEST] <c_14> Elgul: does fc-list output anything? [21:52:30 CEST] <Elgul> nope [21:52:37 CEST] <Elgul> I think my server doesnt have any fonts [21:52:44 CEST] <Elgul> this would explain it, right? [21:52:58 CEST] <c_14> yep [21:53:10 CEST] <c_14> try installing dejavu-sans or something [21:56:17 CEST] <Elgul> need to find it [21:59:15 CEST] <c_14> you can probably just download the package from here http://dejavu-fonts.org/wiki/index.php?title=Download unpack it to i.e. $HOME/.fonts and then run fc-cache $HOME/.fonts [22:01:17 CEST] <Elgul> yes [22:01:21 CEST] <Elgul> I did that [22:01:24 CEST] <Elgul> trying out now [22:04:17 CEST] <Elgul> I do think now its working [22:04:21 CEST] <Elgul> https://files.nogf.club/screenshots/5b5caa04.png cc c_14 [22:04:54 CEST] <c_14> It is, at very least, actually doing things now. [22:05:23 CEST] <Elgul> yes its working :3 [22:05:32 CEST] <Elgul> but the subs are not synced [22:06:50 CEST] <c_14> Are the subs synced if you don't burn them in? [22:07:05 CEST] <Elgul> dont know [22:07:09 CEST] <Elgul> I guess its a sub problem [23:54:14 CEST] <neuro_sys> Hello, I get No such filter: 'colorkey' [23:54:17 CEST] <neuro_sys> error [23:54:39 CEST] <neuro_sys> But then I'm using avconv, is that not part of it? [23:55:06 CEST] <c_14> colorkey is only in recent ffmpeg versions from FFmpeg and not in libav (avconv) [23:55:31 CEST] <neuro_sys> so, I should compile ffmpeg from upstream myself then. [23:55:45 CEST] <c_14> That or use a static build [23:55:58 CEST] <neuro_sys> are they available online? [23:56:03 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [23:56:05 CEST] <neuro_sys> I could use a x86_64 [23:56:09 CEST] <neuro_sys> thanks [23:57:53 CEST] <neuro_sys> yay! [23:59:01 CEST] <needmorespeed> Is there any way to write to a file without locking? I can force it free using LockHunter [23:59:20 CEST] <c_14> ffmpeg itself does not use locking [23:59:23 CEST] <c_14> Blame your OS [00:00:00 CEST] --- Fri Apr 29 2016

1 0

ffmpeg-devel.log.20160427
by burek 28 Apr '16

28 Apr '16

[02:16:08 CEST] <cone-668> ffmpeg 03Michael Niedermayer 07master:566d64d4fbb2: avcodec/h264: Only recover from reference pictures [05:43:07 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:82492c3a9609: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg [05:43:07 CEST] <cone-336> ffmpeg 03Rodger Combs 07release/2.8:36e5854801a8: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354) [05:43:07 CEST] <cone-336> ffmpeg 03Rodger Combs 07release/2.8:7aaab3687429: lavf/mov: downgrade sidx errors to non-fatal warnings; fixes trac #5216 (cherry picked from commit 22dbc1caaf13e4bb17c9e0164a5b1ccaf490e428) [05:43:07 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:69942c4f6dfe: avformat/cache: Fix memleak of tree entries [05:43:07 CEST] <cone-336> ffmpeg 03Boris Nagels 07release/2.8:48c25d0512e7: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT [05:43:08 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:bf76124c51fb: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay [05:43:08 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:d10f4744ff03: avformat/concatdec: set safe mode to enabled instead of auto [05:43:09 CEST] <cone-336> ffmpeg 03Martin Cracauer 07release/2.8:49fc295612ef: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing [05:43:09 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:7dac928e6165: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool [05:43:10 CEST] <cone-336> ffmpeg 03PrzemysBaw Sobala 07release/2.8:4818e074a031: avcodec/imgconvert: Support non-planar colorspaces while padding [05:43:11 CEST] <cone-336> ffmpeg 03Luca Barbato 07release/2.8:d2e473a245a1: indeo2data: K&R formatting cosmetics [05:43:12 CEST] <cone-336> ffmpeg 03Luca Barbato 07release/2.8:d77e1c712bf1: indeo2: Fix banding artefacts [05:43:13 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:e8b1ce8d1b52: avcodec/resample: Remove disabled and faulty code [05:43:14 CEST] <cone-336> ffmpeg 03Mark Thompson 07release/2.8:5c289c932fe4: lavc/hevc: Allow arbitrary garbage in bytestream as long as at least one NAL unit is found. [05:43:15 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:d7c15fb25a65: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored [05:43:16 CEST] <cone-336> ffmpeg 03Ico Doornekamp 07release/2.8:a286f1a5ff5c: avformat/rtpdec_jpeg: fix low contrast image on low quality setting [05:43:17 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:a35e6ec1bd76: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set [05:43:18 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:ef54c144250a: avcodec/h264_slice: Check PPS more extensively when its not copied [05:43:19 CEST] <cone-336> ffmpeg 03Aaron Boxer 07release/2.8:b5d4b1731ead: avcodec/j2kenc: Add attribution to OpenJPEG project: [05:43:20 CEST] <cone-336> ffmpeg 03Marios Titas 07release/2.8:21fb4d128278: avfilter/src_movie: fix how we check for overflows with seek_point [05:43:21 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:4e174d95f59d: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case [05:43:22 CEST] <cone-336> ffmpeg 03Ivan 07release/2.8:70b3e170f97f: avcodec/h264: Fix for H.264 configuration parsing [05:43:23 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:5127cb2e78c0: avcodec/avpacket: Fix off by 5 error [05:43:24 CEST] <cone-336> ffmpeg 03Paul B Mahol 07release/2.8:edc61e3abad0: avcodec/apedec: fix decoding of stereo files with one channel full of silence [05:43:25 CEST] <cone-336> ffmpeg 03Paul B Mahol 07release/2.8:e80a4ce69f0e: avcodec/takdec: add code that got somehow lost in process of REing [05:43:26 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:c6e3682a0c19: avfilter/vf_drawtext: Check return code of load_glyph() [05:43:27 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:05b33258e3ac: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3 [05:43:28 CEST] <cone-336> ffmpeg 03Jan Ekström 07release/2.8:3003277103a2: pgssubdec: fix subpicture output colorspace and range [05:43:29 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:58a750049282: avcodec/ttaenc: Reallocate packet if its too small [05:45:53 CEST] <cone-336> ffmpeg 03Michael Niedermayer 07release/2.8:66443b0cf3be: update for 2.8.7 [09:11:24 CEST] <cone-961> ffmpeg 03Paul B Mahol 07master:1f62a6e7803e: avcodec/shorten: make max frame size bigger if custom block size was used [10:06:17 CEST] <Franciman> Hi all [10:06:29 CEST] <Franciman> Where can I find some examples that use libavfilter? [10:15:08 CEST] <durandal_1707> mpv [10:18:40 CEST] <Franciman> do they create their own filters too? [10:19:19 CEST] <wm4> you can't create your own filters outside of libavfilter [10:19:26 CEST] <Franciman> oh I see [10:19:31 CEST] <Franciman> ok thanks a lot for your help [10:21:56 CEST] <Franciman> Then, if I want to extract samples from an audio stream and process them in order to get the max sample for each 100 samples, is there any filter combination that does that? [10:30:42 CEST] <DHE> https://ffmpeg.org/ffmpeg-filters.html there's volumedetect which might be the closest thing you can use as a basis for making your own [10:35:40 CEST] <Franciman> thanks, again [11:12:26 CEST] Action: rcombs summons reviews [11:16:50 CEST] <wm4> for what? [11:20:32 CEST] <rcombs> mov auto-bsf stuff from a bit ago [11:30:23 CEST] <wm4> there were some comments, and it doesn't seem like anyone is against those patches [11:30:53 CEST] <wm4> so I'd just post updated patches and say that you'll apply in 2 days or so if nothing else is pointed out [11:36:56 CEST] <rcombs> yeah, I'm poking at the comments now [13:17:25 CEST] <cone-020> ffmpeg 03Umair Khan 07master:a2ba50b03a08: avcodec/alsdec: Fix bitstream reading [13:41:46 CEST] <BtbN> Is there a simple way to identify how a set of libav* libraries was built? Non-Free/GPL/LGPL [13:42:33 CEST] <nevcairiel> every library has a fucntion that gets the license string, const char *avcodec_license() etc [13:43:16 CEST] <BtbN> meh, just opened it in a text editor [13:43:32 CEST] <BtbN> Searched for enable-nonfree... and found it. [13:44:13 CEST] <BtbN> "--enable-memalign-hack --enable-gpl --disable-programs --disable-doc --arch=x86_64 --enable-shared --enable-nvenc --enable-libx264 --enable-libopus --enable-libvorbis --disable-debug --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --pkg-config=pkg-config --prefix=/home/packages/win64 --disable-postproc --enable-nonfree" [13:44:47 CEST] <BtbN> So I see a slight issue there. [13:57:14 CEST] <Daemon404> BtbN, I like --pkg-config=pkg-config [13:57:43 CEST] <BtbN> Except for nvenc, this also should be entirely possible to build in lgpl mode? [13:57:54 CEST] <Daemon404> thats recent isnt it [13:57:56 CEST] <nevcairiel> i do that when building 64-bit because mingw-w64 doesnt have a prefixed pkg-config Daemon404 [13:58:08 CEST] <Daemon404> oic [13:58:29 CEST] <Daemon404> also i wish wed just dump memalign havk [13:58:34 CEST] <Daemon404> or make it harder to enable [13:58:39 CEST] <BtbN> what even is it? [13:58:41 CEST] <nevcairiel> let idiots use it, their loss [13:59:07 CEST] <Daemon404> BtbN, a nonstandard hack for aligned alloc [13:59:14 CEST] <Daemon404> technically violates c soec iirc [13:59:17 CEST] <Daemon404> spec* [13:59:23 CEST] <JEEB> BtbN: something for old mingw because it didn't have the windows xp sp2/3 memaligned alloc [13:59:50 CEST] <BtbN> So on mingw w64 it's just a pointless hack? [14:00:02 CEST] <Daemon404> yep [14:00:03 CEST] <JEEB> it isn't enabled by default and yes, you don't need it on mingw-w64 [14:00:16 CEST] <JEEB> since mingw-w64 gives access to the proper function on the platform [14:00:28 CEST] <nevcairiel> you dont even need it on mingw32 anymore these days [14:00:29 CEST] <Daemon404> though funnily enough the msvcrt src does it this way.. [14:00:39 CEST] <Daemon404> but it is allowrd to technically [14:00:47 CEST] <nevcairiel> not to mention that configure turns it on automatically when no native aligned function is found [14:00:54 CEST] <Daemon404> yep [14:04:27 CEST] <rcombs> what makes it invalid C? [14:20:49 CEST] <Daemon404> rcombs, something about a pointer no longer guaranteed being valid if its cast to an int type and back [14:21:04 CEST] <wm4> right, because it uses long [14:21:09 CEST] <wm4> will actually fail hard on win64 [14:21:22 CEST] <rcombs> wat [14:21:34 CEST] <rcombs> why not intptr_t [14:21:37 CEST] <rcombs> or just void** [14:21:49 CEST] <wm4> because it's Old Code [14:22:02 CEST] <Daemon404> and no real life systems i know of even need it [14:22:04 CEST] <wm4> and it's a shitty ifdef mess so nobody dares to touch it ever [14:22:51 CEST] <nevcairiel> it could be updated if someone cares [14:22:54 CEST] <nevcairiel> but why would anyone [14:23:06 CEST] <nevcairiel> apparently it doesnt explode on win64 though, as magical as that is [14:23:39 CEST] <wm4> maybe the usual heap addresses are low enough [14:24:22 CEST] <wbs> the long is only used as an offset [14:24:33 CEST] <wm4> ooh. [14:25:12 CEST] <Daemon404> coursmich went on a big rant/explanation why it's invalid once, so, ill just go with that as my reason [14:25:22 CEST] <wbs> Daemon404: isn't that only about av_freep? [14:25:34 CEST] <Daemon404> wbs, no there was a separate bit about the memalign hack [14:25:40 CEST] <wbs> mmkay [14:25:43 CEST] <Daemon404> but in the end noone cared to fix it [14:25:48 CEST] <Daemon404> because noone uses it [14:25:58 CEST] <wbs> (or because the concern is only theoretical?) [14:26:11 CEST] <nevcairiel> probably [14:26:17 CEST] <wm4> diff = ((~(long)ptr)&(ALIGN - 1)) + 1; [14:26:19 CEST] <nevcairiel> but someone fixed freep [14:26:22 CEST] <wm4> it's not just used as offset [14:26:34 CEST] <wm4> but it affects only the lower bits I guess [14:27:01 CEST] <Daemon404> wbs, its theoretical on the only system where it was ever used [14:27:08 CEST] <Daemon404> like i said, msvcrt more or less does it this way [14:27:16 CEST] <Daemon404> but a libc impl is allowed to [14:27:29 CEST] <nevcairiel> glibc is probably not all that different [14:27:40 CEST] <Daemon404> glibc probably has 9 more layers of abstraction [14:27:55 CEST] <nevcairiel> probably [14:27:59 CEST] <nevcairiel> but i dont dare to try to find out [14:28:03 CEST] <nevcairiel> it would melt my brain [14:28:13 CEST] <Daemon404> and ive actually found msvcrt src pretty readable [14:28:20 CEST] <Daemon404> especially refactored one [14:28:28 CEST] <nevcairiel> if there is a programmer hell, the first level is readin gnu code all day [14:28:34 CEST] <Daemon404> and also a bit simple/naive for some impls [14:29:24 CEST] <BBB> so [14:29:30 CEST] <BBB> why did libav just rewrite get_bits? [14:29:42 CEST] <nevcairiel> noone bothers to ask why anymore [14:29:59 CEST] <nevcairiel> they probably decided in one of their meetings and didnt bother to talk about it on the ML until its all done =p [14:30:06 CEST] <Daemon404> thats a good question [14:30:09 CEST] <BBB> ok [14:30:10 CEST] <BBB> guys [14:30:15 CEST] <BBB> I think this is a bad idea to merge [14:30:25 CEST] <BBB> I think we should more seriously consider stopping merges like this [14:30:43 CEST] <wm4> merging what [14:30:45 CEST] <wbs> BBB: before such a knee-jerk reaction, did you actually read the cover letter? [14:30:52 CEST] <wbs> there's nothing to merge yet, it's just up for discussion [14:31:09 CEST] <wbs> someone non-libav had a suggestion on a faster bitstream reader implementation, and now someone has tried implementing said idea [14:31:10 CEST] <nevcairiel> wbs: i did, and i'm still not convinced its a good idea to bother changing half of avcodec =p [14:31:14 CEST] <BBB> wbs: this is not knee-jerk, my complaint is fair [14:31:21 CEST] <wbs> and noted that it indeed is faster or equally fast for tested cases [14:31:24 CEST] <BBB> wbs: would you like me to discuss this on libav-devel? [14:31:35 CEST] <Daemon404> if it is nontrivially faster there's merit [14:31:38 CEST] <BBB> I tried before, and I got ignored [14:31:45 CEST] <BBB> why not just amend the get_bits api? [14:31:52 CEST] <BBB> I dont understand why everything has to be rewritten from scratch [14:31:55 CEST] <wbs> _that_ is a good question of course [14:32:00 CEST] <BBB> Im full of good questions [14:32:06 CEST] <BBB> Im not some random mplayer jerk [14:32:14 CEST] <BBB> I have fairly good brains and write pretty good code [14:32:22 CEST] <BBB> but libav-devel ignores me when I talk on it [14:32:23 CEST] <wbs> but the gist is "someone had a suggestion on a better implementation, I tried it", that's not something to give quite as much crap as you are giving [14:32:34 CEST] <Daemon404> these are legitimate questions of course [14:32:44 CEST] <wbs> exactly how/where to implement it is of course up for discussion [14:32:53 CEST] <Daemon404> i only think it's a bit suspect to send a giant patchset [14:32:54 CEST] <nevcairiel> wbs: thats fine, but we have seen the past, and once s omeone started doing things, they generally just force them in at some point [14:32:58 CEST] <Daemon404> only THEN to discuss it [14:33:06 CEST] <Daemon404> because "but hey its doen already" mentality [14:33:12 CEST] <wbs> sure [14:33:45 CEST] <Daemon404> i will send a thoughtful reply [14:33:47 CEST] <nevcairiel> but BBB please mention your thoughts on the ML, its not going to change anything in here [14:33:47 CEST] <Daemon404> i.e. not flames [14:33:48 CEST] <wbs> BBB: also, when you say "why did libav just do X", I consider myself part of libav, and I have not known of this patchset before I saw it an hour ago, and I don't consider myself part of those who "are rewriting the bitstream reader" [14:34:01 CEST] <Daemon404> ^ [14:34:09 CEST] <Daemon404> stuff alexa does just generally appears [14:34:11 CEST] <BBB> nevcairiel: ok [14:34:19 CEST] <wbs> so it's not the "please stop the merges" because this isn't in git to be merged yet even [14:34:56 CEST] <Daemon404> urg [14:34:59 CEST] <Daemon404> the patchste is sponsored? [14:35:01 CEST] <Daemon404> thats a bit... uh. [14:35:38 CEST] <nevcairiel> re-inforces the thoughts expressed earlier, doesnt it [14:36:40 CEST] <nevcairiel> more communication would be nice, but that didnt happen, so all we can do now is discuss the finished thing, not our problem if work is lost due to not talking about it earlier [14:37:45 CEST] <wbs> well, tbh, in most cases one could consider this a first WIP patchset as well; I see lots of people doing that on both sides [14:38:00 CEST] <wbs> just get something done so there's something concrete to talk about, instead of talking about unwritten code [14:38:43 CEST] <nevcairiel> one could present the idea first when it concerns a key component touching most of the codebase [14:38:54 CEST] <wbs> sure [14:39:07 CEST] <wbs> you'll find all the reasons you want to diss it, I don't doubt that [14:39:27 CEST] <wbs> but if the key point, if you look beyond api and other shit, is, someone had an idea on a potentially faster bitstream reader [14:39:31 CEST] <wm4> all what matters in the end is performance isn't it [14:39:32 CEST] <wbs> is that a bad thing to try? [14:39:53 CEST] <wbs> if someone on this side would have tried optimizing get_bits, it would have been all praise I'm sure [14:40:27 CEST] <nevcairiel> i doubt reaction to such a patchset without any previous discussion would be any different from those talking here right now [14:41:09 CEST] <BBB> there, I emailed the list [14:41:45 CEST] <BBB> wbs: do you agree with my technical concern that a new API is not really warranted here, using this new implementation with existing API should be possible? [14:42:30 CEST] <wbs> BBB: I haven't read it close enough to say for sure, but in general I would guess that it could be fitted into the old API [14:42:58 CEST] <wbs> (perhaps there are functions that the old bitstream reader could implement efficiently that can't be done as neatly, while other things are faster in the new one, dunno) [14:43:03 CEST] <wbs> but that part is a valid concern yes [14:43:32 CEST] <BBB> ok, ty [14:43:49 CEST] <Daemon404> it is also worth noting i wont stop merges regardless. if theres stuff we dont want, i *skip* those parts. [14:43:51 CEST] <wbs> but the "someone posted a patch on libav, let's stop merging" is what I find knee-jerk [14:44:02 CEST] <BBB> fair enough [14:44:10 CEST] <wbs> also, I gotta go [14:44:29 CEST] <BBB> on a totally different note, did we ever implement a replacement for AVFrame->dct_coef and AVFrame->mb_type? [14:44:39 CEST] <BBB> they got removed a couple of months ago at the latest bump and I didnt see replacements [14:44:47 CEST] <BBB> (someone on stackoverflow asked) [14:44:53 CEST] <fritsch> i +1 what this derek guy wrote on the ML ... without those being answered ... a rewrite is worth nothing [14:45:00 CEST] <Daemon404> fritsch, i am derek [14:45:01 CEST] <Daemon404> thx [14:45:21 CEST] <nevcairiel> if there is any replacement, its in sidedata, but i'm not sure it ever happened because it seems largely unused BBB [14:45:37 CEST] <BBB> sidedata had stuff for motion_vectors only, I believe [14:45:43 CEST] <fritsch> Daemon404: ah okay, sorry :-) [14:45:45 CEST] <BBB> I didnt find side-data types for mb_type or dct_coef [14:45:47 CEST] <Daemon404> who uses dct coeff and mb type? [14:45:47 CEST] <Franciman> Hey I am using the select filter to get scenechanges. I submit frames to the src buffer with av_buffersrc_add_frame, and following an example from ffmpeg I set the frame's pts to best_effort_timestamp. Now when I retrieve the filtered frame, I am interested in its timestamp. Should I get it from best_effort_timestamp, or from FilteredFrame->pts? [14:45:52 CEST] <Daemon404> is it for some sort of deblocking, BBB? [14:46:29 CEST] <nevcairiel> also, when was this removed? we still have the qscale stuff which was deprecated around the same time i though [14:46:41 CEST] <wm4> Franciman: filters use ->pts [14:47:02 CEST] <wm4> Franciman: for both input and output [14:47:15 CEST] <BBB> Daemon404: I dont know, its on stackoverflow& [14:47:50 CEST] <BBB> nevcairiel: qscale became a function in frame.h, and motion_vectors became side-data; mbtype and dct_coef simply disappeared with no replacement, afaics [14:48:16 CEST] <nevcairiel> what exported that anyway? probably only mpegvideo-derived codecs like usual? [14:48:20 CEST] <Daemon404> BBB, SO bothers me. They reward people for answering "how to do x", but not "you should do you instead of x, x is bad" [14:48:23 CEST] <BBB> yes [14:48:24 CEST] <nevcairiel> (ie. mpeg1-4) [14:48:42 CEST] <Daemon404> s/do you/do y/ [14:48:55 CEST] <Franciman> wm4, ah I see, and what's the difference between Frame's pts when decoded and best_effort_timestamp? [14:49:28 CEST] <Daemon404> i dont think best_effort_timestamp ever returns NOPTS, for one thing [14:49:32 CEST] <Daemon404> (dont quote me) [14:50:00 CEST] <wm4> Daemon404: it does if there's no timestamp at all [14:50:14 CEST] <wm4> Franciman: decoders set pkt_pts, pkt_dts, and also best_effort_timestamp [14:50:33 CEST] <wm4> while filters only access the pts field [14:50:47 CEST] <Franciman> I see. Last question, is best_effort_timestamp always set? [14:51:21 CEST] <wm4> if pkt_dts or pkt_pts are set [14:51:39 CEST] <Daemon404> wm4, ah ok [14:52:08 CEST] <Franciman> ok, thanks a lot [15:09:11 CEST] <BBB> so Im thinking about what anton says [15:09:33 CEST] <Daemon404> i read taht, and i would suggest waiting a little while instead of an immediate reply [15:09:46 CEST] Action: Daemon404 knows he writes thinsg he regrets if he doesnt let it gestate for a bit [15:12:10 CEST] <fritsch> Daemon404: https://www.geekme.de/ <- do that ... [15:12:24 CEST] <fritsch> will cost you some seconds for not regretting anything after directly writing [15:12:35 CEST] <Daemon404> it just gave me a trophy in german [15:12:39 CEST] <Daemon404> i dont know whats going on [15:12:49 CEST] <BBB_> my kids disconnected the modem :/ [15:12:50 CEST] <fritsch> yeah, exactly, just press next [15:12:58 CEST] <Daemon404> [14:09] <@BBB> so Im thinking about what anton says [15:12:59 CEST] <Daemon404> [14:09] <@Daemon404> i read taht, and i would suggest waiting a little while instead of an immediate reply [15:13:02 CEST] <Daemon404> [14:09] * Daemon404 knows he writes thinsg he regrets if he doesnt let it gestate for a bit [15:13:05 CEST] <Daemon404> [14:12] < fritsch> Daemon404: https://www.geekme.de/ <- do that ... [15:13:07 CEST] <Daemon404> [14:12] < fritsch> will cost you some seconds for not regretting anything after directly writing [15:13:10 CEST] <Daemon404> [14:12] <@Daemon404> it just gave me a trophy in german [15:13:11 CEST] <BBB_> I said: and I can see his point that the api is kinda random [15:13:13 CEST] <Daemon404> [14:12] <@Daemon404> i dont know whats going on [15:13:15 CEST] <Daemon404> ^ BBB [15:13:22 CEST] <BBB_> and then: so now, am I being a technocratic asshole if I suggest that api renaming and implementation change should probably be done separately to preserve history? [15:13:27 CEST] <BBB_> I guess that was post modem-disconnect [15:13:33 CEST] <Daemon404> no thats pretty sane to me [15:13:52 CEST] <Daemon404> but [15:14:02 CEST] <Daemon404> i dont know if the internal impl would necessitate different macro flows [15:14:11 CEST] <Daemon404> i havent gotten that far yet [15:14:48 CEST] <Daemon404> also you should keep your modem locked up or something [15:14:58 CEST] <Daemon404> tricksy kids like to poke things [15:16:38 CEST] <BBB> well, the cable is on the outside, and they simply disconnected the cable [15:16:46 CEST] <BBB> not quite sure yet how to protect the cable [15:17:01 CEST] <Daemon404> i dunno [15:17:08 CEST] <Daemon404> surround it with veggies? [15:17:11 CEST] <Daemon404> im not good with kids. [15:18:29 CEST] <Compn> surround it with other modems and other cords [15:18:48 CEST] <Compn> then it will be like in the scene from indiana jones and the holy grail. the kids will have to choose wisely which cable to disconnect [15:19:01 CEST] <BBB> theyd probably disconnect all of them [15:19:08 CEST] <BBB> Ill try the veggies or something alike that [15:21:15 CEST] <Daemon404> BBB, that doesnt always work [15:21:26 CEST] <Daemon404> niece/nephew of gf *love* veggies [15:21:34 CEST] <Daemon404> just the culture of the family... [15:21:41 CEST] <Daemon404> personally i think it's weird ;) [15:21:57 CEST] <BBB> depends on the veggies, right? [15:22:01 CEST] <BBB> mine love corn and carrots [15:22:08 CEST] <BBB> but cant really be bothered with green leafy stuff [15:22:14 CEST] <Daemon404> it's all about the greens [15:22:22 CEST] <Daemon404> and peppers [15:23:28 CEST] <nevcairiel> peppers are quite nice [15:23:36 CEST] <Daemon404> as an adult :P [15:23:46 CEST] <Daemon404> i thought they were bitter as a child [15:53:12 CEST] <Daemon404> making tea and scones, then some merges... [15:53:40 CEST] <wm4> so you're a typical british person [15:54:35 CEST] <Daemon404> i usually drink coffee [15:54:54 CEST] <Daemon404> i just decided to buy some some fresh scones at clotted cream today because ill be gone from the uk for a few weeks. [15:54:58 CEST] <Daemon404> also it is delicious. [15:55:36 CEST] <durandal_1707> doing Nop merges for life? [16:05:03 CEST] <wm4> if you open a HLS webvtt stream, avformat_find_stream_info() reads the entire stream [16:05:08 CEST] <wm4> awesome [16:05:25 CEST] <Daemon404> O.o [16:34:51 CEST] <Daemon404> commit bot broken? [16:34:54 CEST] <cone-111> ffmpeg 03Ivan Uskov 07master:b577a54a7c83: qsv: Fix wrong ticks_per_frame for H.264 [16:35:02 CEST] <nevcairiel> just slow [16:35:05 CEST] <Daemon404> indeed [17:08:23 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:9b30f8dd8fa5: h264: remove the svq3-specific code [17:08:24 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:15b0517da986: svq3: make the dsp functions static [17:08:25 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:c73fb9efb22c: svq3: add all the required dsp contexts into SVQ3Context [17:08:26 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:c2a4ca944d90: svq3: eliminate write_back_intra_pred_mode() usage [17:08:27 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:1877712c586d: svq3: move mb_{x,y,xy} to SVQ3Context [17:08:28 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:d6f01c61edee: Merge commit '9b30f8dd8fa5bef5f16904cb98745b4a58f8f776' [17:08:29 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:656b071a8f01: Merge commit '15b0517da986b312fc2fcb364a92db328380b15b' [17:08:30 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:47bb289170aa: Merge commit 'c73fb9efb22c8d66d24de2716f7f9970f234c3c3' [17:08:31 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:7dca13428541: Merge commit 'c2a4ca944d9029a3c162f8f3ddd317b83a7bd600' [17:08:32 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:c18535399d25: Merge commit '1877712c586df2261f2806f45388c77592b89d1e' [17:34:56 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:ecc31f6b0864: h264: move ff_h264_check_intra[4x4]_pred_mode() to h264_parse [17:34:57 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:a2922b5d614c: Merge commit 'ecc31f6b086453ab9811dce2ae5ceb6a7c19e4ad' [17:45:06 CEST] <wm4> does anyone have an idea what could make ffmpeg.c set a time_base different from pkt_timebase on a decoder AVCodecContext, and why? [17:45:50 CEST] <nevcairiel> if you force a specific fps it uses that for the decoder timebase i think [17:46:24 CEST] <wm4> not forcing any special parameters [17:46:35 CEST] <nevcairiel> but why do these even need to match, there is no rule for that [17:46:35 CEST] <wm4> and it's audio [17:46:56 CEST] <nevcairiel> is one of them just the inverse sample rate? [17:47:05 CEST] <wm4> yes, time_base is [17:47:22 CEST] <wm4> oh, utils.c could be setting it, maybe [17:48:22 CEST] <wm4> yes, that's it [17:48:24 CEST] <nevcairiel> gcc 6.1 is final now, btw [17:48:32 CEST] <wm4> this was probably meant for encoding [17:48:36 CEST] <wm4> 6.0 doesn't exist? [17:48:45 CEST] <nevcairiel> they dont do x.0 anymore [17:48:49 CEST] <wm4> lol [17:48:53 CEST] <nevcairiel> its 6.0 during development, 6.1 is the first release [17:50:15 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:527bf5f7c689: svq3: move the pred mode variables to SVQ3Context [17:50:16 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:8eecae77ff6e: svq3: move edge_emu_buffer to the SVQ3Context [17:50:17 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:89a13998a1b5: svq3: rip out the svq3-relevant parts of pred_motion() out of h264 [17:50:18 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:99dde60391ca: svq3: move {ref,mv}_cache to the SVQ3Context [17:50:19 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:463de5625bcb: Merge commit '527bf5f7c6890664b0f1dccd42397f4d204659fe' [17:50:20 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:fed686af2324: Merge commit '8eecae77ff6e2923de57dd883421d24fd53ca61f' [17:50:21 CEST] <nevcairiel> The C and C++ compilers now emit saner error messages if merge-conflict markers are present in a source file. [17:50:21 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:c0b51aa2d2c6: Merge commit '89a13998a1b5074411dff5a461dce3837057b0b8' [17:50:22 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:f09fd96cee97: Merge commit '99dde60391cade40ae026b9e385a5280be6b9882' [17:50:30 CEST] <Daemon404> nevcairiel, lul [17:52:18 CEST] <nevcairiel> Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). [17:52:24 CEST] <nevcairiel> not breaking any big projects are we [17:52:38 CEST] <wm4> lol [17:52:47 CEST] <wm4> and everyone goes using clang [17:53:11 CEST] <wm4> when can the this pointer be legally null? [17:54:08 CEST] <nevcairiel> using -msse now automatically enables -mstackrealign on win32 builds, guess my build is broken then since stackrealign doesnt work in avcodec =p [17:55:22 CEST] <jamrial> oh nice, gcc 6.1 [17:55:41 CEST] Action: jamrial likes to live dangerously and uses gcc 7 trunk [17:56:02 CEST] <DHE> oh! [17:57:31 CEST] <cone-111> ffmpeg 03Anton Khirnov 07master:549fc7727363: svq3: move mb2br_xy to the SVQ3Context [17:57:32 CEST] <cone-111> ffmpeg 03Derek Buitenhuis 07master:6f784c158bd5: Merge commit '549fc77273636d0d02175362af5dcd60c79f7633' [18:04:58 CEST] <Franciman> Hey, when using libavfilter, can I first submit all the frames to the buffersrc [18:05:14 CEST] <Franciman> and then retrieve all the filtered frames at once, when I'm done submitting frames? [18:28:47 CEST] <iive> jamrial: hum, i've missed 6.0 [18:29:48 CEST] <jamrial> read what nevcairiel said above [18:30:24 CEST] <jamrial> gcc changed their numbering scheme. x.0 is development phase. first release is x.1 [18:35:38 CEST] <jamrial> iive: https://gcc.gnu.org/develop.html#num_scheme [18:36:43 CEST] <iive> oh, so that's how they are trying to avoid the ffmpeg curse [18:38:24 CEST] <jamrial> guess it worked, then. 4.9.0 was the last version to be released that miscompiled ffmpeg :p [18:39:06 CEST] <jamrial> it was also the last one to miscompile the latest available version of binutils afaik [18:40:01 CEST] <iive> i think there was more recent version that had known bug at release time. they had fix for it, but it was late for the release, or something like that [18:42:41 CEST] <BtbN> gcc 6 breaks _a lot_ of C++ stuff though [18:42:49 CEST] <BtbN> they came up with the next -fno-strict-aliasing [19:03:26 CEST] <JEEB> hmm [19:04:02 CEST] Action: JEEB looks if SPS/PPS parsing stuff is available within libavcodec [19:06:42 CEST] <wm4> it's quite intermingled with the h264 decoder [19:07:08 CEST] <JEEB> yeah, I remembered that but hoped it wouldn't be too cobbled together [19:07:53 CEST] <JEEB> due to the various degrees of failure in the mediacodec back-ends I thought it would probably be a good idea to do a profile check in the mediacodec decoder [19:08:48 CEST] <JEEB> so that the most obvious stuff can be avoided [19:25:18 CEST] <cone-111> ffmpeg 03Andreas Weis 07master:fb9187129c3d: avutil/log: added av_log_format_line2 which returns buffer length [19:25:19 CEST] <cone-111> ffmpeg 03Andreas Weis 07master:333207224fd8: avutil/log: added test case for av_log_format_line2 [20:01:28 CEST] <fritsch> as someone talked about gcc 6 some minutes ago: [20:01:33 CEST] <fritsch> "Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined." [20:03:30 CEST] <wm4> lol [20:04:04 CEST] <JEEB> :D [20:05:03 CEST] <nevcairiel> i quoted that already =p [20:05:12 CEST] <fritsch> ah you did - fefe reader I assume :-) [20:05:21 CEST] <nevcairiel> no, i dont like him [20:05:24 CEST] <fritsch> hehe [20:05:36 CEST] <nevcairiel> i read the release notes [20:05:38 CEST] <jamrial> but you skipped the part about the workaround option :p [20:05:50 CEST] <nevcairiel> thats boring :) [20:06:20 CEST] <fritsch> the "this pointer of member functions" [20:06:30 CEST] <wm4> just breaking major projects, I wonder if they don't want them to use their compiler [20:08:00 CEST] <fritsch> i currently think of a minimal example where you got a member function of which this ptr is null [20:09:08 CEST] <Daemon404> wm4, compiler devs get off on spec wanking [20:09:11 CEST] <wm4> AcmeClass *foo = NULL; foo->moo(); // non-virtual function, this works right??? [20:09:18 CEST] <Daemon404> "well technically it is undefined so... hnnnnnng" [20:09:21 CEST] <wm4> Daemon404: truth [20:09:33 CEST] <rcombs> why would you do that [20:09:51 CEST] <rcombs> (call member functions on NULL pointers) [20:09:55 CEST] <wm4> rcombs: dunno, maybe they think a method is like a function with an implicit first arg [20:10:04 CEST] <rcombs> well it is [20:10:06 CEST] <wm4> I'm also not sure if this is the gcc case [20:10:09 CEST] <rcombs> that's how it's implemented [20:10:15 CEST] <wm4> yeah, but not how it's spec'ed [20:10:18 CEST] <rcombs> but uh don't do that [20:10:28 CEST] <rcombs> it's UB and always has been [20:10:40 CEST] <fritsch> i don't think that's what they are saying [20:11:07 CEST] <fritsch> it's rather something like: int (A::*x)(void) = &A::f; [20:11:17 CEST] <fritsch> and now you invoke it and A does not exist? [20:11:20 CEST] <wm4> blargh [20:11:25 CEST] <Shiz> gross [20:11:28 CEST] <Shiz> C++ [20:11:33 CEST] <wm4> I hate C++ syntax more than its semantics [20:11:37 CEST] <fritsch> hehe [20:11:47 CEST] <Daemon404> i dont hate its syntax [20:11:52 CEST] <Daemon404> i hate its endless complexity and rules [20:11:55 CEST] <fritsch> i thought before "ranting" about the gcc guys I wanted to understand what they actually say :-) [20:11:56 CEST] <Shiz> wm4: i don't think anything can make me hate something more than recursive variadic templates [20:11:57 CEST] <Daemon404> that no one man can remember [20:12:06 CEST] <wm4> Daemon404: syntax is a very vivid expression of this apparent design goal [20:12:23 CEST] <Shiz> like A::*x [20:12:30 CEST] <fritsch> and then I'd wanted to see a use case in real life, where one could not just make the method static [20:12:40 CEST] <fritsch> where the "this" ptr is obviously not needed [20:12:58 CEST] <Shiz> fritsch: but what if you could call it with either and it does some if(this) stuff?????? [20:13:02 CEST] <Shiz> think of the potential use cases maaan [20:13:03 CEST] <Daemon404> wm4, c++ syntax i can read, eventually [20:13:10 CEST] <Daemon404> some languages i dont even want to try [20:13:11 CEST] <Shiz> (i can see some lunatic implementing singletons with this) [20:13:13 CEST] <Daemon404> (haskell) [20:13:20 CEST] <Daemon404> (prolog) [20:13:22 CEST] <fritsch> Shiz: i can think of some globals that might go away on destruction [20:13:48 CEST] <fritsch> Shiz: and one needs to check if it's still there while you geave your member into some callback method [20:13:51 CEST] <fritsch> hehe [20:14:05 CEST] <wm4> wut [20:14:17 CEST] <fritsch> but I honestly don't know howto code such a thing ... where I really need that :-) [20:14:37 CEST] <fritsch> nevcairiel: ^^ you got an idea, where "the old behaviour" would be needed? [20:19:27 CEST] <cone-111> ffmpeg 03Timo Rothenpieler 07master:bc4137d4aa3a: configure: Don't require nonfree for nvenc [20:26:08 CEST] <rcombs> oh? [20:26:27 CEST] <rcombs> ah [20:26:28 CEST] <rcombs> super [20:40:09 CEST] <RiCON> rcombs: quick question; can chromaprint use ffmpeg and be included in it statically? [20:40:25 CEST] <rcombs> sorry? [20:41:05 CEST] <RiCON> compiling chromaprint with avfft statically and be included in ffmpeg with --enable-chromaprint [20:41:59 CEST] <rcombs> afaik nothing will stop you [20:54:43 CEST] <wm4> woah new dts stuff [20:54:45 CEST] <wm4> whatever it is [21:04:58 CEST] <nevcairiel> DTS Express [21:05:34 CEST] <nevcairiel> its a totally distinct codec [21:06:37 CEST] <rcombs> "turns out piling everything on top of an ancient core bitstream format is really inefficient and some users actually care about that" [21:10:02 CEST] <nevcairiel> its a low bitrate codec for commentary etc [21:10:21 CEST] <nevcairiel> so not exactly HD [21:11:03 CEST] <wm4> why did they invent a codec for that [21:11:39 CEST] <nevcairiel> because DTS had nothing to cover that =p [21:16:18 CEST] <rcombs> because if people use any of the existing multitude of suitable codecs, then DTS gets no money [21:16:47 CEST] <rcombs> so they invented something useless in the hopes it'll bring them royalties through the magic of marketing and standards [21:16:47 CEST] <wm4> and that would be sad [21:17:16 CEST] <rcombs> with any luck it'll be about as successful as eac3 [21:18:15 CEST] <nevcairiel> eac3 is the alternative to dts express for secondary audio tracks on Blu-rays [21:18:27 CEST] <nevcairiel> because its also much more flexible with the bitrate than plain ac3 [22:43:06 CEST] <cone-111> ffmpeg 03Timo Rothenpieler 07master:c4312b1cf44b: avcodec/nvenc: Add missing lossless presets to doc string [23:34:56 CEST] <Angus> hmm, I'm filling a buffer incorrectly [23:34:58 CEST] <Angus> http://i.imgur.com/N2jbBY4.png [23:35:14 CEST] <Angus> how does the AVIO buffer store things? [23:36:04 CEST] <Angus> I seem to be able to change one variable, and instead of the top half being corrupted, it is the bottom half instead [00:00:00 CEST] --- Thu Apr 28 2016

1 0

ffmpeg.log.20160427
by burek 28 Apr '16

28 Apr '16

[00:54:12 CEST] <vade> Hi all - quick question about encoding - do all frames need to arrive in PTS order ? are there any mechanisms to re-roder AVFrames that have been decoded to presentation time? Or is that something one has to roll their own? [05:45:22 CEST] <ajsharp> Trying to overlay one video onto another. Running into an issue where if the main video is shorter than the secondary (overlaid video), then the overlay video stops playing, and both videos remain frozen, but the audio track continues playing to the end. Does anyone know how to keep the overlay video playing until it's finished. [05:46:22 CEST] <ajsharp> specifying the following options: overlay=shortest=0:eof_action=pass:x=main_w-overlay_w-10:y=10 [05:48:05 CEST] <ajsharp> running ffmpeg 2.7-tessus on OS X 10.11.4 [05:52:40 CEST] <Guest14493> Has ffmpeg dropped windows xp support? [07:50:14 CEST] <shouya_> hi [07:51:13 CEST] <shouya_> I'm new to ffmpeg, can I ask a (possibly silly) question about hardware accelerations? I searched on the web and find no clue. [07:51:44 CEST] <JEEB> just ask and stick around [07:51:46 CEST] <shouya_> my goal is to enable hardware acceleration for encoding h264 videos on linux with VAAPI [07:52:49 CEST] <shouya_> I'm on gentoo, and have the latest version of ffmpeg (3.0.1) installed, here's the `configure` output: http://lpaste.net/401919298643165184 [07:53:30 CEST] <shouya_> this shows that h264_vaapi hwaccel is enabled [07:53:51 CEST] <shouya_> but when I type in `ffmpeg -hwaacels` it prints empty list [07:55:47 CEST] <shouya_> I don't have X on this machine, could that possibly be the reason? [09:37:18 CEST] <DHE> shouya_: vaapi is only for decoding right now. I think the only hardware h264 accelerator available is nvenc, nVidia's GPU feature [09:38:16 CEST] <shouya_> DHE: thanks. how can I tell if vaapi is used for decoding? [09:38:45 CEST] <DHE> oh, no there's a quicksync encoder... [09:39:16 CEST] <shouya_> I checked that one, it seemed to be a proprietary software [09:39:47 CEST] <DHE> the point is, it should say which decoder is used in the output [09:42:54 CEST] <shouya_> fflogger: sorry, here it is: http://lpaste.net/9122915165572956160 [09:44:40 CEST] <shouya_> DHE: I expected that, but it seems the word 'vaapi' never appear in the output (see the paste above) [09:46:52 CEST] <DHE> Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) [09:46:57 CEST] <DHE> `dat metadata though [09:48:36 CEST] <shouya_> DHE: native means decoded using vaapi here? [09:49:12 CEST] <DHE> pretty sure it's just the standard software decoder [09:49:16 CEST] <c_14> Don't you have to add -hwaccell vaapi before the input? [09:49:25 CEST] <c_14> -l [09:50:03 CEST] <c_14> hmm, vaapi isn't listed in the manpage [09:50:04 CEST] <shouya_> Unrecognized hwaccel: vaapi. [09:50:04 CEST] <shouya_> Supported hwaccels: [09:50:36 CEST] <shouya_> nothing else is printed after that [09:52:28 CEST] <DHE> my only hwaccel is vdpau. I think it's a rendering accelerator, not an encoding accelerator [09:53:14 CEST] <DHE> wait, you're specifying libx264 as your codec directly [09:53:20 CEST] <DHE> ffmpeg -codecs | grep h264 [09:53:44 CEST] <DHE> ffmpeg -encoders | grep h264 # even better [09:54:13 CEST] <shouya_> DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (encoders: libx264 libx264rgb ) [09:54:31 CEST] <c_14> I just checked the backlog, if you want to encode h264 with vaapi you need a patch that hasn't been merged to master yet. [09:54:31 CEST] <shouya_> seems libx264's the only one available [09:56:01 CEST] <c_14> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188356.html [09:56:05 CEST] <c_14> The ones from this thread [09:56:39 CEST] <c_14> Since it hasn't been merged to master, there might be some issues remaining [09:58:15 CEST] <shouya_> I'll check this one out [09:58:46 CEST] <shouya_> thanks all. before that I want to see if I vdpau works [09:59:06 CEST] <c_14> vdpau is for decoding/presenting and requires a running X server [09:59:54 CEST] <shouya_> c_14: just figured it out... [10:00:27 CEST] <shouya_> on this page https://trac.ffmpeg.org/wiki/HWAccelIntro, it says that vaapi currently only supports AVHWAccel [10:00:42 CEST] <shouya_> what does AVHWAccel mean? [11:27:14 CEST] <kagami_> Hi. How do I save HLS WebVTT streams with ffmpeg? "ffmpeg -i http://... out.vtt" shows a lot of requests but doesn't save anything. [11:28:42 CEST] <relaxed> kagami_: try ffmpeg -i input -f webvtt out.vtt [11:29:28 CEST] <kagami_> relaxed: still the same. Here is output: http://pastebin.com/FCriEUuL Output file is empty. [11:29:53 CEST] <kagami_> It's like it doesn't start downloading like with normal hls video stream. [11:32:12 CEST] <relaxed> maybe, ffmpeg -i input -map 0:s -c:s copy -f webvtt out.vtt [11:32:43 CEST] <relaxed> pastebin.com the command and output if that doesn't work [11:35:18 CEST] <kagami_> relaxed: the same http://pastebin.com/aaLYRaNY It seems to be it tries to download entire WebVTT stream and prints Input info banner only when I press Ctrl+C. [11:57:47 CEST] <kagami_> Should I create issue at bugtracker? Though this stream url won't be available after few hours, I need to somehow host my own webvtt hls server... [12:38:25 CEST] <kagami_> Hm, seems like it just doesn't write intermediate result, but at the end of translation saves entire subtitle file instead. [14:50:53 CEST] <gerion> hi, can you help me? I want to overlay two videos, but the second video should begin later than the first (and is shorter), other said: play first video x secs, then overlay the two until the second ends, then only play the first [14:51:25 CEST] <gerion> searching some kind of delay filter [14:52:25 CEST] <furq> gerion: add -itsoffset x before the input you want to delay [14:53:20 CEST] <gerion> ah nice, thx [15:21:51 CEST] <spirou> can the "global headers" be added to a video stream without having to recompress it completely? [15:34:41 CEST] <sybariten> oh hai [15:36:12 CEST] <sybariten> i have MTS files that cause problems for my Sony Vegas editing suite. What would you reckon is the most lightweight transformatoin i can do, in order to try some other format? Is it for instance possible to make a new mts file where the audio is mp3 instead of ac3? [15:50:00 CEST] <c_14> sure [15:50:10 CEST] <c_14> It depends on what Sony Vegas wants to eat though [15:50:40 CEST] <c_14> to just convert the audio to mp3 use ffmpeg -i input -c copy -map 0 -c:a libmp3lame -b:a 320k out.mts [16:23:11 CEST] <rsevero> Hi. I'm trying to create a libx264/opus file but ffmpeg apparently only allows it to be a MKV file. Tried MP4, OGG and OGV but all of them fail with the same message: "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument" You can see the whole output here: http://pastebin.com/mYNnQMit To be exact I want to create a h264/opus file that is natively supported by Chrome. Ideias? [16:25:55 CEST] <rsevero> AFAICT Chrome supports narively the following containers: Ogg, WebM, WAV and MP4. [16:27:27 CEST] <furq> none of those formats support both h.264 and opus [16:27:44 CEST] <furq> you either need h.264 and aac/mp3 in mp4, or vp8/vp9 and opus in webm [16:28:10 CEST] <furq> the former is more widely-supported [16:28:12 CEST] <rsevero> Humm... Ok. thanks. [16:28:20 CEST] <furq> and also means you don't have to use libvpx [16:30:40 CEST] <kepstin> note that youtube does support h.264 and opus - but it does that by having separate audio and video streams, using DASH. [16:54:57 CEST] <blaataap> does anyone know... I am trying to cut a simple video no transitions. I have used PiTiVi (using gstreamer) and AviDemux (2.6 or something) and the input video is h.264. As output I try x264. The input framerate is 30, output is 30. The frames are getting recoded. [16:55:21 CEST] <blaataap> or at least a transition that took 10 steps in the original now takes 11 steps in the output as the 2nd frame is getting duplicated. [16:55:40 CEST] <blaataap> the frames are really the same but there is now an extra frame in there. [16:56:23 CEST] <blaataap> the same happened when I outputted to mpeg4-2 [16:57:30 CEST] <blaataap> and, now I have tried x265 or something and the result is again the same. [16:58:45 CEST] <vade> what do you want to do ? [16:59:43 CEST] <JyZyXEL> [gif @ 0x123c0c0] ERROR: gif only handles the rgb24 pixel format. Use -pix_fmt rgb24. [17:00:00 CEST] Last message repeated 1 time(s). [17:00:07 CEST] <blaataap> apparently I cannot just delete frames as I will need a new key frame at the beginning so it needs reencoding. [17:00:10 CEST] <JyZyXEL> i don't think "-pix_fmlt rgb24" is even valid? [17:00:24 CEST] <blaataap> and the only thing I'm doing is cutting out a clip (deleting the beginning) [17:00:32 CEST] <JyZyXEL> -pix_fmt[:stream_specifier] format (input/output,per-stream) [17:00:36 CEST] <blaataap> and I want the video to stay the same, frame by frame. [17:01:07 CEST] <blaataap> basically I guess I want to "copy" while getting a new keyframe in the beginning. [17:01:26 CEST] <blaataap> i don't care about transcoding but now an extra frame is constantly getting inserted. [17:01:38 CEST] <blaataap> I just want a perfect copy in that sense. [17:01:48 CEST] <JyZyXEL> Option pixel_format not found. [17:02:56 CEST] <blaataap> all it needs to do is transcode/recode with a new keyframe as starting point, nothing else. [17:03:22 CEST] <blaataap> and I'm surprised and flabbergasted that not any tool can do this.... [17:03:32 CEST] <blaataap> they probably all use the same libraries? [17:04:32 CEST] <vade> blaataap: well you cant move samples from one container to and make up new keyframes without re-encoding [17:05:00 CEST] <vade> if you want a perfect copy you want to just change container formats there are ways to do that. [17:05:12 CEST] <vade> if you want a transition this requires blending and making new frames, and re-encoding them [17:05:25 CEST] <blaataap> sure that's what I'm saying, but how come the length of the scene is changed? [17:05:37 CEST] <blaataap> basically it is now 1/30 th of a second longer [17:06:22 CEST] <blaataap> something that took 10 frames now takes 11, this is not right. [17:06:43 CEST] <vade> are you using -vcodec copy -acodec copy ? [17:07:07 CEST] <blaataap> I don't think it can do that because that would not create a new keyframe. [17:07:18 CEST] <vade> you cant make new keyframes [17:07:26 CEST] <vade> you either re-encode the video totally [17:07:33 CEST] <vade> or you copy samples to a new container as is [17:07:34 CEST] <blaataap> that's what I'm saying man. [17:07:36 CEST] <blaataap> don't repeat me. [17:07:42 CEST] <vade> so you are re-encoding. [17:07:45 CEST] <blaataap> yes [17:08:16 CEST] <blaataap> but the re-encoding changes the length of the scene for every output codec I try in both of these two programs. [17:08:53 CEST] <blaataap> every time the 2nd frame is duplicated. [17:08:53 CEST] <vade> whats your command? or are you doing this with like, libavformat / libavcodec in your own software? [17:09:03 CEST] <blaataap> through a GUI [17:09:15 CEST] <blaataap> probably yes. [17:09:31 CEST] <vade> well, try it with pure FFMPEG command and see if you can re-create [17:09:39 CEST] <blaataap> I mean I could probably use a direct command by inputting the starting key frame [17:10:53 CEST] <blaataap> can I select a starting frame? [17:11:18 CEST] <blaataap> oh -ss [17:12:08 CEST] <furq> -vf select="gt(n\,1234)" [17:12:12 CEST] <vade> any libavformat devs who could help me understand how to handle the properly setting timestamps for AVFrames being sent to avcodec_encode_video2() then passed on to av_write_frame() ? [17:12:14 CEST] <furq> if you want to use the frame number [17:12:22 CEST] <vade> im getting Encoder did not produce proper pts, making some up. [17:12:26 CEST] <vade> Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" [17:13:07 CEST] <vade> Im am currently successfully (I think!) decoding via avcodec_decode_video2, and passing the resulting decompressed AVFrame to avcodec_encode_video2 [17:17:44 CEST] <blaataap> how do I specify a codec for x264? [17:18:17 CEST] <furq> what? [17:19:31 CEST] <blaataap> ok working [17:20:38 CEST] <blaataap> vade: it's the same with pure FFMPEG command. [17:20:45 CEST] <blaataap> thanks for learning me the command though. [17:20:56 CEST] <blaataap> this might be easier in a while. Anyway. [17:22:33 CEST] <vade> interesting - not sure I can help [17:23:43 CEST] <vade> maybe email the list? or post on a forum - might get more eyes on it over-all [17:23:51 CEST] <vade> (or stack overflow?) [17:24:03 CEST] <blaataap> hate on stack overflow ;-). [17:24:13 CEST] <blaataap> I will email the list when I have time I guess. thanks. [17:25:17 CEST] <jbreeden> Can FFmpeg copy an existing data track? `c:d copy` doesn't seem to do anything [17:27:47 CEST] <furq> jbreeden: you can do it with -map using the stream number [17:27:53 CEST] <furq> i don't think there is anything like -map 0:d [17:55:46 CEST] <jbreeden> furq: thanks. I'm looking for something that finds it and passes it through. Bummer. [17:59:10 CEST] <furq> oh apparently 0:d does exist [17:59:16 CEST] <furq> maybe try that then [17:59:29 CEST] <jbreeden> haha yeah, just discovered that literally as you were typing that [18:00:02 CEST] <jbreeden> How do I use 0:d and still get the v/a tracks, if I map data, must I map everything? [18:00:16 CEST] <furq> yeah -map overrides automatic stream selection [18:00:22 CEST] <furq> so -map 0:v -map 0:a -map 0:d [18:00:37 CEST] <furq> i'd have thought just -map 0 would work as well but maybe it'll ignore data streams [18:02:18 CEST] <jbreeden> thanks for your help, this solves my problem [18:02:41 CEST] <jbreeden> I didn't know about map 0:v|a|d [18:27:32 CEST] <DHE> is there documentation on how to deal with PTS/DTS overflow? I'm using the API and after a day (which mathematically overflows the mpegts pts/dts values) my program breaks with "Application provided invalid, non monotonically increasing dts to muxer in stream 0" [18:31:22 CEST] <vade> DHE: a day of encoding? [18:32:23 CEST] <vade> can anyone explain what circumstances init an AVStream* with priv_data = NULL? I am trying to understand why im crashing with exe_bad_access within compute_muxer_pkt_fields [18:32:23 CEST] <c_14> DHE: you might want to ask on the libav-user ml [18:33:13 CEST] <DHE> vade: live streaming. I just leave it running [18:33:32 CEST] <vade> you might need to segment your recordings. [18:34:04 CEST] <DHE> no, ffmpeg the app doesn't have this problem [18:34:06 CEST] <DHE> so something's up [18:34:31 CEST] <vade> examine the resulting PTS/DTS and see if they are different [18:34:36 CEST] <vade> (from your app?) [18:40:39 CEST] <DHE> yeah, I'm going to start debugging. was hoping for immediate guidance... since it takes a day to have it happen, and live source is a pretty bad source to run from [18:40:52 CEST] <DHE> I'm going to generate 1.5 days of test pattern and burn that in instead [18:41:54 CEST] <vade> Well, you can probably see some difference even in the difference between pts / dts ? [18:42:03 CEST] <vade> (for short clips) [18:42:07 CEST] <vade> sorry distracted @DHE [18:43:28 CEST] <vade> @DHE maybe pts_wrap_behavior for AVStream is of interest? [18:43:49 CEST] <pfelt> DHE: could you set an ffmpeg process to stream data pulled from a file and just set, the PTS with the setpts filter, to something high? [18:44:02 CEST] <pfelt> (and dump that stream output into a pipe) [18:46:47 CEST] <DHE> pfelt: interesting idea, I'll give that a whirl [18:46:54 CEST] <pfelt> that way you don't have to a) record a day's worth of data, or b) wait a day to test [18:47:32 CEST] <pfelt> i'd think that something like (psudocode here) pts=pts+(maxpts-someundeterminedvalue) just to get you close [18:47:45 CEST] <pfelt> no idea if that'll work, but i suspect you'd be able to make it get you somewhere clse [18:50:46 CEST] <matthias_> Hello where can i find equivalent arguments, from ffmpeg that i use with rtmpdump ? like -a -s and multiple -C [18:51:21 CEST] <c_14> Read the manpages? [18:51:42 CEST] <c_14> If you tell me what the options do, I might be able to give you hints. [18:54:19 CEST] <c_14> Maybe look at https://ffmpeg.org/ffmpeg-protocols.html#rtmp [18:55:27 CEST] <c_14> Seems like you want rtmp_conn, rtmp_app and rtmp_swfurl [18:55:46 CEST] <matthias_> c_14: -a is Name of target app on server , -s URL to player swf file, -C type:data Arbitrary AMF data to be appended to the connect string [18:56:05 CEST] <c_14> ye, those three options I just listed [18:56:23 CEST] <matthias_> c_14: okay, i will try thanks so far [19:08:36 CEST] <galex-713> Hi [19:08:40 CEST] <galex-713> How can I quickly convert a 1080p movie either in raw either in 720p in order to read it on my slow-hardware bad-res computer? [19:09:08 CEST] <matthias_> c_14: is -rtmp_conn 'S:0 S:23100539 S: O:1' valid ? [19:12:04 CEST] <c_14> The third S: is missing a value, isn't it? Also the last O:1 starts an object which is never ended. Not sure whether that's valid [19:12:25 CEST] <trough> I'd like to overlay a VP9 video in SDL. Would FFmpeg be overkill for this? [19:12:39 CEST] <matthias_> c_14: it is working with rtmpdump -C S:0 -C S:23100539 -C S: -C O:1 [19:13:24 CEST] <c_14> try -rtmp_conn S:0 -rtmp_conn S:23100539 -rtmp_conn S: -rtmp_conn O:1 [19:13:36 CEST] <matthias_> c_14: ok [19:13:48 CEST] <c_14> trough: you want to overlay a video on another video and then display that via sdl? [19:14:38 CEST] <trough> more likely, overlay a video on an image, and display that via SDL [19:15:14 CEST] <c_14> galex-713: ffmpeg -i 1080p -vf scale=-2:720 -map 0 -c copy -c:v libx264 -preset ultrafast out.mkv [19:15:33 CEST] <trough> I wasn't sure whether I should use plain libvpx, ffmpeg, or gstreamer. [19:16:20 CEST] <trough> I am not sure about gstreamer, because it is part of gnome, and I heard some strange things about the gnome build-chain. [19:18:03 CEST] <c_14> trough: you can probably do that with just commandline ffmpeg (even if the outdev support is kind of a hack) by using ffmpeg -i image -i video -filter_complex [0:v][1:v]overlay[v] -map [v] -map 0:a -f sdl [19:18:41 CEST] <c_14> Plain libvpx might be a bit difficult because you'd have to manage overlaying yourself, I can't comment much about gstreamer, and it should be relatively easy with ffmpeg though it might take a bit to get the api usage down right. [19:19:45 CEST] <trough> I already know how to do the overlaying in SDL, and this is going to be part of a game, so I don't think I can use the command line. [19:20:04 CEST] <trough> But I'm expecting to use the libavcodec/format API [19:20:40 CEST] <matthias_> c_14: not working: https://bpaste.net/show/1a4d8ca79086 [19:23:39 CEST] <c_14> matthias_: maybe try this -rtmp_conn S:0 -rtmp_conn S:23100539 -rtmp_conn S: -rtmp_conn 'O:1 NS:srv:72737 NS:sid:5155079152 NS:sessionType:preview O:0' ? [19:23:50 CEST] <c_14> Also try adding -loglevel debug to see if it spits out anything interesting [19:24:23 CEST] <furq> trough: fwiw i don't think gstreamer actually depends on any gnome stuff [19:24:28 CEST] <furq> just glib [19:24:43 CEST] <spiderkeys> are there any good places to ask in depth libav questions besides the mailing list? [19:25:09 CEST] <spiderkeys> didn't get any bites there [19:25:09 CEST] <furq> here if you're lucky [19:26:45 CEST] <trough> that's good to know, furq. Thanks. [19:26:48 CEST] <spiderkeys> well, if anyone has experience working with avformat and avcodec doing muxing, would appreciate having this looked at: http://ffmpeg.org/pipermail/libav-user/2016-April/009063.html [19:30:54 CEST] <galex-713> c_14: thats great it works! \o/ [19:33:05 CEST] <matthias_> c_14: in the debug log: -rtmp_playpath '5155079152' -rtmp_app 'reflect/5155079152' output: Proto = rtmp, path = /reflect/5155079152, app = reflect, fname = 5155079152 and it says trailing options found [19:33:21 CEST] <matthias_> c_14: isn't app cut off? [19:35:42 CEST] <c_14> try escaping the '/' with a '\' ? [19:37:13 CEST] <matthias_> c_14: no difference [19:42:04 CEST] <c_14> hmm, no idea. You might want to ask on the ffmpeg-user ml. Maybe someone else has had a similar issue. [19:43:29 CEST] <matthias_> c_14: or i will pipe rtmpdump to ffmpeg [19:43:42 CEST] <c_14> or that [21:04:07 CEST] <vade> hi all. Im trying to deduce an issue where a resulting file from an encode has the wrong timestamps and is very short. Im unsure if I am handling my main encode loop / PTS logic correctly. https://gist.github.com/vade/a48d2445262a3e94a51bfc12424c55ca [21:04:08 CEST] <vade> should I be using av_rescale_q on the frames being decoded , or on the packets populated from the encoder prior to writing into the muxer? [21:12:57 CEST] <Mavrik> vade, the rescale call looks wrong [21:13:10 CEST] <Mavrik> encoders expect proper PTS though [21:13:13 CEST] <Mavrik> (filter as well) [21:13:26 CEST] <Mavrik> so your PTS going into an encoder needs to be in encoder's codec timebase [21:13:34 CEST] <vade> hi Mavrik - thanks. Interesting. [21:13:41 CEST] <Mavrik> and PTS/DTS then has to be in output format timebase when written to muxer [21:15:15 CEST] <vade> here is a question - im used to AVFOundation (forgive me) - when I pull AVPackets off of the stream, they are all in DTS order - do I need to re-order them to PTS so my AVFrames from the decoder are in the right order for the encoder? In COre Media, you can do this via a CMBufferQueue and request PTS ordering or DTS ordering. Im unfamiliar with the expectation in FFMPEG [21:15:24 CEST] <vade> (thank you in advance btw) [21:15:51 CEST] <Mavrik> Nope, DTS order is fine [21:15:59 CEST] <vade> interesting. unexpected [21:16:02 CEST] <Mavrik> Why? [21:16:12 CEST] <vade> Just was something I noticed while debugging is all :) [21:16:15 CEST] <Mavrik> The point of DTS is that it determines the order of decoding. [21:16:32 CEST] <vade> sure - well, im writing a transcoder [21:16:33 CEST] <Mavrik> So decoder needs them in DTS order to properly decode :P [21:16:42 CEST] <Mavrik> And it can't decode them in any other order than in PTS order :P [21:16:48 CEST] <Mavrik> Due to how references work. [21:16:53 CEST] <Mavrik> Anyway, be careful of timebases [21:16:58 CEST] <vade> oh. interesting. I didnt know that last part [21:17:40 CEST] <Mavrik> Input packets are in input format timebase, decoded frames should be in decoder timebase, encoders expect their frames in encoder timebase and muxers expect frames in the output stream timebase :) [21:17:46 CEST] <Mavrik> (IIRC) [21:18:02 CEST] <Mavrik> (If sample code uses any others, it's probably the right one, talking out of my head :) ) [21:18:07 CEST] <vade> in AVFoundation if you do pass through, you can just pull sample buffers (AVPackets I guess) in decode order and they can be passed in as decode order - but if you want to *re-encode* uncompressed frames they need to come in as PTS only. I guess you do get the in PTS on the way out from the decoder. I think im jus confused and have been staring at this too long haha [21:18:40 CEST] <vade> Interesting. I was unaware of the encoder vs muxer timebase nuance [21:19:00 CEST] <vade> whats a good sample to look at regarding this nuance? [21:33:01 CEST] <Mavrik> hmm, I think decoding_encoding.c or muxing examples should handle that properly? [21:33:37 CEST] <Mavrik> vade, your main issue is that you're trying to change PTS timebase from OUTPUT codec timebase to OUTPUT stream timebase. [21:33:46 CEST] <Mavrik> When you should be changing them from INPUT codec timebase to OUTPUT codec timebase [21:34:07 CEST] <Mavrik> And then after encode from OUTPUT codec timebase to OUTPUT stream timebase (if they're different, commonly they're not) [21:36:42 CEST] <spiderkeys> Mavrik: you sound well versed in handling this muxing issue. I've tried to follow all of the examples, tutorials, mailing lists, etc and put together a muxing application that takes a raw h264 elementary stream and muxes each packet into an mp4 container, but none of the timing info seems correct. could I trouble you to take a quick look at my code and see if I'm doing something wrong with regards to how I'm doing stream identific [21:50:40 CEST] <pandb> I adapted one of the examples on ffmpeg.org to make a program outputs a video from a contiuously updating source of image data [21:52:06 CEST] <pandb> if I output a file it plays fine, but I'm trying to broadcast live to rtmp servers like at twitch.tv or youtube's live stream feature, and in either case nothing displays [21:53:08 CEST] <pandb> can someone who knows about streaming look at my video-related code here: http://pastebin.ca/3584711 [21:53:45 CEST] <pandb> codec and stream settings are set in add_stream() [21:54:31 CEST] <pandb> and write_video_frame()/get_video_frame() are the functions for creating the new frame and writing it [21:58:46 CEST] <pandb> also, wireshark is showing that my data is being sent to whatever rtmp server i specify [21:59:43 CEST] <pandb> (and the debug messages that I receive by calling av_log_set_level(AV_LOG_DEBUG) indicate a successful handshake and data being sent) [22:02:10 CEST] <Mavrik> spiderkeys, you can try, but I can't guarantee I'll have time :) [22:06:13 CEST] <spiderkeys> Mavrik: fair enough :P It isn't too much code, just the update function in this class: https://github.com/OpenROV-Dev/geomuxpp/blob/inproc_rewrite/src/CMuxer.cpp [22:06:17 CEST] <spiderkeys> starts at lines ~131 [22:06:46 CEST] <vade> Mavrik: thanks. Im getting closer [22:06:51 CEST] <spiderkeys> a callback somewhere else is filling the inputBuffer with raw h264 frames (complete nal units) [22:07:28 CEST] <spiderkeys> so i probe for the format, then find the stream info, then create an output stream with stream and codec info copied from the input stream [22:08:11 CEST] <Mavrik> spiderkeys, you should set time_base on the output stream [22:08:11 CEST] <spiderkeys> but the timing info is always weird: see my mailing list post here for the output of my program when it detects the stream info: http://ffmpeg.org/pipermail/libav-user/2016-April/009063.html [22:08:40 CEST] <Mavrik> spiderkeys, and then av_rescale_q the packet pts and dts (if they're not AV_NOPTS) from the input stream time_base to output stream time_base [22:08:44 CEST] <spiderkeys> how do I know what value to set it to? is that a field I find in the codec or the input format? [22:08:57 CEST] <Mavrik> You can just copy it from input. [22:09:01 CEST] <Mavrik> But there are conventions. [22:09:15 CEST] <Mavrik> In TS it's usually 1/90000, in others it's 1/fps [22:11:21 CEST] <spiderkeys> unfortunately, for the input stream it gets AV_NOPTS as the value for the start and duration timestamps: [h264 @ 0x7fcd400008c0] stream: start_time: -9223372036854.775 duration: -9223372036854.775 bitrate=0 kb/s [22:11:57 CEST] <Mavrik> ah [22:12:01 CEST] <Mavrik> That would explain your issue. [22:12:14 CEST] <Mavrik> Which makes sense if they're raw NALs [22:12:18 CEST] <Mavrik> Do you know your FPS? [22:12:29 CEST] <spiderkeys> It is variable, but it should generally be at 30fps [22:12:52 CEST] <spiderkeys> my SPS packet does contain this timing info: timing_info_present_flag :1 num_units_in_tick :6006 time_scale :180000 [22:13:05 CEST] <Mavrik> Hmm. [22:13:47 CEST] <spiderkeys> and doing an avdump produces this guess for the stream: http://pastebin.com/Gkk8082z [22:13:59 CEST] <spiderkeys> the tbc looks correct but the other values are whack [22:14:22 CEST] <Mavrik> Do you get pts and dts set on your avpackets? [22:14:27 CEST] <Mavrik> When reading them? [22:15:33 CEST] <spiderkeys> let me print them real quick. i think they were always invalid, but let me double check [22:17:04 CEST] <spiderkeys> Writing muxed packet. Bytes: 32440. PTS: -9223372036854775808 DTS: -9223372036854775808 [22:17:08 CEST] <spiderkeys> yea, av_nopts [22:17:34 CEST] <Mavrik> That's a bit of an issue for VFR video :/ [22:17:41 CEST] <Mavrik> Do you know which muxer does it use? [22:18:37 CEST] <spiderkeys> should be mp4. I'm pulling in each h264 NAL unit and wrapping each one in an mp4 container as segmented with "movflags", "empty_moov+default_base_moof+frag_keyframe" [22:18:51 CEST] <Mavrik> spiderkeys, on the input, not output [22:19:01 CEST] <Mavrik> (To determine why muxer doesn't set timestamps on packets) [22:19:38 CEST] <spiderkeys> oh, no idea. The camera we have comes straight from an OEM that has some onboard encoding process, sending complete frames over usb [22:20:03 CEST] <spiderkeys> I could ask them at some point what is going on with timing info. is there something in particular I should ask about that would need to be included? [22:20:18 CEST] <Mavrik> hmm [22:20:29 CEST] <Mavrik> Nah, I think it's ffmpeg's "fake" demuxer that's causing you issues [22:21:14 CEST] <Mavrik> spiderkeys, I'm also wondering why you're initializing a decoder which you then don't use [22:21:41 CEST] <Mavrik> spiderkeys, check which demuxer you got in p_InputFormatContext. [22:22:55 CEST] <spiderkeys> alright, I'll do that real quick. I was under the impression that I needed to get all of the codec information in that manner in order to create an output stream. I'm not interested in actually decoding anything, just want to wrap it in an mp4 container [22:26:30 CEST] <Mavrik> Yeah, you may have to call the decoder to generate timestamps tho [22:26:47 CEST] <Mavrik> I think "raw video" fake decoder can handle timestamping. [22:26:54 CEST] <Mavrik> Buuut would have to check the code :) [22:27:22 CEST] <Mavrik> Since timestamps have to be takes from NAL's and applied to AVFrame/AVPacket [22:33:02 CEST] <spiderkeys> Mavrik: strange, not sure how to access the AVCodecTag structure at m_pInputFormatContext->iformat->codec_tag. Getting error: invalid use of incomplete type struct AVCodecTag [22:33:11 CEST] <spiderkeys> even though I've definitely included avformat.h [22:34:21 CEST] <Mavrik> spiderkeys, just print name or long_name ? :) [22:36:21 CEST] <spiderkeys> Ah ok: name: raw H.264 video codec id: 0 [22:37:33 CEST] <spiderkeys> Mavrik: do you know what the name of the field that would contain a timestamp in the NAL is? [22:38:11 CEST] <Mavrik> There is no such field. [22:38:21 CEST] <Mavrik> Since those fields are generic for all formats. [22:38:28 CEST] <Mavrik> They won't have codec specific stuff. [22:39:33 CEST] <spiderkeys> Oh I think I see what you're saying now. The raw frames don't have that info, so it would be the decoder that produces them using the SPS timing info, but since I'm not using the decoder, they never get generated [22:40:41 CEST] <Mavrik> I don't see raw H.264 demuxer setting pts/dts anywhere :/ [22:40:57 CEST] <Mavrik> yeah, pretty much [22:41:13 CEST] <Mavrik> That wouldn't be a problem if you'd have a constant FPS video [22:41:19 CEST] <Mavrik> Then you could just generate PTS [22:41:30 CEST] <Mavrik> Hrmf, even though with B-frames that wouldn't work :/ [22:41:50 CEST] <spiderkeys> I could potentially lock the framerate (since we don't really want it variable) and then do that [22:42:09 CEST] <Mavrik> Yeah, but B-frames will still mess you up. [22:42:19 CEST] <spiderkeys> I think we only have I and P frames, but couldn't be sure B frames wouldnt show up some point in the future [22:42:21 CEST] <Mavrik> I guess you could manually parse the pts/dts ? [22:42:33 CEST] <Mavrik> Maybe someone else has a better solution [22:44:48 CEST] <spiderkeys> If I went that route for now, I would basically just create a 64 bit int, start at 0, and add the duration as calculated from framerate to generate the PTS/DTS for the AVPacket before writing it? [22:45:58 CEST] <vade> ive been having similar but slightly different issues, and ive seen solutions/ sample code that uses that solution [22:46:07 CEST] <madgino> Can I use ffmpeg to convert from HLS to to mpeg-ts? [22:46:11 CEST] <vade> and uses av_rescale_q based on the incrememented packet or frame count [22:46:12 CEST] <Mavrik> spiderkeys, yes, the duration you add has to be in stream timebase [22:46:20 CEST] <Mavrik> spiderkeys, but VFR and B-frames can mess you up [22:46:56 CEST] <spiderkeys> Since we are live streaming this into the browser and pushing the frames into the MSE decoder as fast as we can, it can typically play the data with no problem, and doesnt really care about the timestamps, but when we save the video to an .mp4 file, most media players have trouble figuring out how to play it at all, or if they can, the playback rate is usually wrong [22:47:14 CEST] <kepstin> madgino: sure, but you probably don't have to - HLS is just a bunch of mpeg-ts files and you can simply concatenate them in most cases. [22:48:36 CEST] <spiderkeys> Mavrik: I really appreciate your help, learning the libav internals can be a bit of a chore, and I understand a bit better what is going on now. [22:49:12 CEST] <Mavrik> Yeah, I'm afraid reading the source is pretty much a must for those things :/ [22:50:21 CEST] <spiderkeys> Yea, I've had to do that on a few occasions to figure out how to get the muxer to write out frames without buffering them. I still find it odd that none of the flags created that behaviour and I had to call: ret = av_write_frame(m_pOutputFormatContext, &packet); ret |= av_write_frame(m_pOutputFormatContext, NULL ); [22:50:30 CEST] <spiderkeys> that second null write to force the flush [22:50:35 CEST] <spiderkeys> took me forever to find that [22:58:37 CEST] <kbarry> I'm strugging to get more information on google. I believe i'm just short a word or so. What is the window that appears (the visualization) when using ffplay ? [23:15:46 CEST] <pandb> can someone knowledgable about streaming to rtmp look at my code, tell me if there's anything wrong with my codec settings, or what I do to the frame or the packets I send to the muxer? http://pastebin.ca/3584711 [23:16:50 CEST] <pandb> the files it outputs play fine, but nothing shows up on twitch or youtube live stream if I specify an rtmp server [23:25:55 CEST] <petecouture> Maybe someones run into this before. I have a live stream I'm processing to HLS. I added another output that generates JPG frame images once a second. I'm able to get constant frames generated using frame_%d.jpg where %d is the frame number. However I'm looking to just have the file overwritten every second and it's not working when I just output a single file. I'm getting an error happened: ffmpeg exited wit [23:25:55 CEST] <petecouture> h code 1: Conversion failed! [23:26:46 CEST] <petecouture> Also is there way to generate an image once every 5 seconds? I'm using -r 1 and don't think I can go any lower [23:27:16 CEST] <furq> -r 1/5 [23:27:32 CEST] <petecouture> furq: I figured just didn't try it. Thanks! [23:27:48 CEST] <petecouture> can you put the fraction in like that or use a decimal? [23:27:52 CEST] <furq> either [23:29:28 CEST] <petecouture> Thanks again. Any advice on the filename issue? [23:30:03 CEST] <petecouture> Could it be a read/write conflict? I'm spawning ffmpeg from within Node so there's not much in teh way of errors mesages coming back. [23:31:12 CEST] <furq> use -update 1 [23:31:27 CEST] <furq> otherwise the filename has to be a pattern [23:31:38 CEST] <furq> or the input has to be one frame [23:32:32 CEST] <petecouture> Cheers again! [23:37:01 CEST] <petecouture> Is 'update' a new option? I can't find it in the documentation [23:40:36 CEST] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#Options-5 [23:46:30 CEST] <petecouture> thnx! [00:00:00 CEST] --- Thu Apr 28 2016

1 0

ffmpeg-devel.log.20160426
by burek 27 Apr '16

27 Apr '16

[00:01:19 CEST] <kierank> rkern: how? [00:06:03 CEST] <rkern> I'd create a simple test app, run a short encode with dummy frames (one for each encoder param), then decode those frames and verify the params. [02:48:39 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:512c064cd9e0: avformat/mux: Check that deinit is set before calling it [02:48:40 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:f2e9e4757f7d: avfilter/vf_drawtext: Check return code of load_glyph() [02:48:41 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:4c896d6bd478: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3 [02:48:42 CEST] <cone-124> ffmpeg 03Jan Ekström 07release/3.0:666754c66571: pgssubdec: fix subpicture output colorspace and range [02:49:04 CEST] <michaelni> JEEB, backported to a few release branches (and pushed 3.0) [06:19:22 CEST] <kierank> rkern: but how will you get Mac hardware on osx [06:19:34 CEST] <kierank> Aws* [13:41:18 CEST] <cone-104> ffmpeg 03Vicente Olivert Riera 07release/3.0:a5638dbfbafd: mips: add support for R6 [13:41:19 CEST] <cone-104> ffmpeg 03Shivraj Patil 07release/3.0:83eaaae0057f: configure: build fix for P5600 with mips code restructuring [14:30:52 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:492d229303a8: qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp [14:57:26 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:fa936a307f5c: hevc_parse: rename into h2645_parse [14:57:28 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:3c4ca4c5d799: Merge commit 'fa936a307f5cddfc2664600157a8207ca8080af6' [15:01:58 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:8229eff4b7a9: h2645_parse: add a function for uninitializing the packet [15:01:59 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:8e73574d4f17: Merge commit '8229eff4b7a98ae5d85bb75f3bb072781b4a8ebe' [15:04:55 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:52ec149fbee5: h2645_parse: change the AVCodecContext* parameter to void* [15:04:56 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:b5c10c4c9274: Merge commit '52ec149fbee57b6ca817049c9706212a0774a32c' [15:08:11 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:b667252a41fb: h2645_parse: add support for parsing h264 [15:08:12 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:438ed974b832: Merge commit 'b667252a41fbf5a3f6ea8c67fdbc03db3d748977' [15:15:10 CEST] <Daemon404> what is av_ctz and why does libav have it, and we don't? [15:15:15 CEST] <Daemon404> (next merge makes use of it) [15:17:02 CEST] <Daemon404> ah.. it is ff_ctz here. [15:17:40 CEST] <rcombs> counts trailing zeroes [15:18:41 CEST] <Daemon404> yeah i found this in git history [15:18:49 CEST] <Daemon404> not sure why it is a public func in libav [15:20:46 CEST] <rcombs> I don't think it actually is [15:20:50 CEST] <rcombs> intmath.h isn't installed [15:20:55 CEST] <Daemon404> ah [15:21:00 CEST] <Daemon404> just oddly named [15:21:05 CEST] <rcombs> so it's available av_prefixed because ????? [15:21:22 CEST] <rcombs> maybe backwards compat with some version that had it in a public header? [15:21:27 CEST] <Daemon404> i dunno, but ffmpeg fixed it anyway in its codebase. [15:21:31 CEST] <Daemon404> so /care [15:21:45 CEST] Action: rcombs shrugs [15:27:45 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:90ed6c5cf7f2: h2645_parse: compute the actual data length, without trailing paddding [15:27:46 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:79aafd43fd25: Merge commit '90ed6c5cf7f236bc9efb47c97b40358c666d1386' [16:04:56 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:e481458bc308: h264: factor out pred weight table parsing into a separate file [16:04:57 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:ee38234c43b6: Merge commit 'e481458bc308ee838deaeacac51929514762e7a7' [16:22:05 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:e42ca48a8bdd: svq3: rip out the mb decoding code shared with h264 [16:22:06 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:f8d1bb2f2ce9: Merge commit 'e42ca48a8bddc637a4013ab253598973f07e1a5c' [16:56:08 CEST] <Angus> hmm, running into an Assert in av_free [16:56:10 CEST] <Angus> #1 0x00007ffff70e1e8a in __GI_abort () at abort.c:89 #2 0x00007ffff3b3149e in av_free (ptr=<optimized out>) at libavutil/mem.c:233 [16:57:06 CEST] <fritsch> happens and without further info it will continue to happen [16:57:07 CEST] <durandal_170> more info needed [16:57:10 CEST] <Angus> the piece of memory is allocated via av_malloc( pBufferCtx->iBufferSize) [16:57:21 CEST] <Angus> and is part of [16:57:26 CEST] <Angus> avio_alloc_context(ffBuffer, pBufferCtx->iBufferSize, 0, pBufferCtx, &read_packet, NULL, NULL); [16:57:26 CEST] <fritsch> pastebin, please [16:57:37 CEST] <Angus> pastebin is blocked here :( [16:57:42 CEST] <fritsch> sprunge.us [16:57:46 CEST] <fritsch> paste.ubuntu.com [16:58:01 CEST] <Angus> or not [16:58:01 CEST] <Angus> http://pastebin.com/49xGuicQ [16:58:35 CEST] <Angus> stack trace: [16:58:35 CEST] <Angus> http://pastebin.com/bATZdgbz [16:59:49 CEST] <Angus> I suspect read_packet might be corrupting the memory, if av_free is behaving correctly [17:01:04 CEST] <fritsch> how large is iBufferSize ? [17:01:11 CEST] <jkqxz> Not that it's obviously relevant to your problem, but why do you have MEMALIGN_HACK set? [17:01:57 CEST] <Angus> I'm not really sure; the ffmpeg make config was given to me by someone [17:02:04 CEST] <Angus> fritsch: http://pastebin.com/LexzfKkK [17:02:20 CEST] <Angus> 1206 bytes it seems [17:03:02 CEST] <fritsch> Angus: increase to 4k [17:03:04 CEST] <fritsch> or something [17:03:22 CEST] <Angus> what does memalign-hack do anyway? [17:04:11 CEST] <jkqxz> Don't do that, it will only confuse things. You're using glibc, so you have a perfectly good posix_memalign(). [17:04:50 CEST] <Angus> alright, will try this again without the memalign-hack [17:05:01 CEST] <wm4> Angus: I _think_ you need to alloc the buffer as array [17:05:27 CEST] <jkqxz> It builds aligned allocation out of unaligned allocation, because some platforms in the stone age didn't support that. [17:05:34 CEST] <fritsch> wm4: i don't think sop [17:05:39 CEST] <cone-104> ffmpeg 03Nicolas George 07master:b8fa374fb6eb: lavf/concatdec: remove unrelated change during codecpar merge. [17:05:40 CEST] <cone-104> ffmpeg 03Nicolas George 07master:0cb19c30c6a1: lavf/concatdec: clear extradata when inserting h264_mp4toannexb bsf. [17:05:46 CEST] <wm4> I was wrong [17:06:22 CEST] <fritsch> that buffer is quite small [17:06:25 CEST] <wm4> IMO this code should just work [17:06:27 CEST] <fritsch> yes [17:06:45 CEST] <fritsch> there is nothing wrong I can see, but wasn't there some "minimal" buffer that needs to be used? [17:06:48 CEST] <fritsch> like 4k? [17:06:56 CEST] <wm4> keep in mind that libavformat may free the buffer and replace it with another allocation [17:07:02 CEST] <wm4> (but you still have to free it at the end LOL) [17:07:50 CEST] <Angus> fritsch, I just tried to compile my code with the buffersize set to 4k, and still crashed on the same line. [17:08:22 CEST] <fritsch> can you post your read_packet method? [17:10:37 CEST] <Angus> it's very messy. http://pastebin.com/SRzwHNDw [17:12:04 CEST] <fritsch> can you just return in that method? [17:12:07 CEST] <fritsch> for testing? [17:12:29 CEST] <fritsch> in line 16 i am not sure that >= is what you want there ... but it's basically unreadable :-) [17:13:19 CEST] <wm4> check with valgrind? [17:13:30 CEST] Action: fritsch hints for an off by one :-) [17:13:49 CEST] <fritsch> btw. I highly suggest you clean up that code [17:13:55 CEST] <fritsch> especially the big if and else [17:14:18 CEST] <fritsch> i think you get that done with 4 lines when using min / max and offset [17:14:26 CEST] <Angus> let me check a few things first. Yes, that code will be cleaned once I figure out what's wrong with it. [17:14:38 CEST] <D`K_C> Hi, is there a way to use ffmpeg to get the raw data of an HLS stream? I mean ffmpeg would fetch the different elements of the playlist and I could read raw data using a xx_read function? I tried to use avio_open but (of course) it simply fetches the playlist and does not assemble the multiple parts [17:14:55 CEST] <wm4> what do you even mean by "raw" [17:20:05 CEST] <D`K_C> the playlist is made of ts files, and the application is designed in such a way that it needs to have access to these streams [17:22:04 CEST] <wm4> define raw data [17:23:14 CEST] <D`K_C> ts streams [17:25:10 CEST] <rcombs> D`K_C: use either the HLS protocol (avio_open hls://) or the HLS demuxer (avformat_open_input) [17:25:35 CEST] <rcombs> the protocol if you actually want the TS files concatenated; the demuxer if you want AVPackets [17:28:09 CEST] <wm4> if you just want the ts URLs, it's better if you take 5 mins to write a playlist parser [17:28:43 CEST] <rcombs> ^ yeah [17:36:11 CEST] <cone-104> ffmpeg 03Rodger Combs 07master:95116bf35f1b: lavc/audiotoolboxdec: fix memory leak [17:36:12 CEST] <cone-104> ffmpeg 03Rodger Combs 07master:e1c20485c1d4: lavc/audiotoolboxdec: move to new BSF API [17:37:56 CEST] <D`K_C> okay, I managed to get the TS files using avio_open hls+http://, it was just a quick prototype to test the rest of the application. What would be the advantages of writing a playlist parser over using ffmpeg? [17:43:02 CEST] <wm4> if it works for you, then fine [18:11:29 CEST] <durandal_170> anyone against including bonk decoder? [19:01:21 CEST] <jamrial> durandal_170: what's bonk? [19:02:01 CEST] <durandal_170> jamrial: whery old audio lossy/lossless codec [19:02:27 CEST] <jamrial> i don't see why not, then [19:08:46 CEST] <wm4> is it the companion of bink? [19:17:58 CEST] <durandal_170> lol, nope [19:49:20 CEST] <cone-104> ffmpeg 03Michael Niedermayer 07master:005c61c6b898: avcodec/ttaenc: Reallocate packet if its too small [20:13:25 CEST] <b_amabo> michealni: I am here because I wish to participate in the next round of Outreachy with FFmpeg. please I need guidance on how I can start contributing in preparation for the program [20:15:00 CEST] <JEEB> since outreachy is paid by the organizations themselves, it is never sure if FFmpeg will participate in something. to initialize yourself with the project whatever the future might hold one of the best ways is to try and use it and find things that irk you in one way or another [20:15:15 CEST] <JEEB> then looking into the components and discussing them [20:15:20 CEST] <JEEB> if you have never compiled FFmpeg, start from there [20:15:42 CEST] <JEEB> so you get basic FFmpeg binaries built, which are by default static so you are able to run them right away [20:16:02 CEST] <JEEB> you probably only require git, yasm and basic compilation tools [20:18:53 CEST] <b_amabo> JEEB: thanks you for the heads up! [20:21:04 CEST] <kierank> have a look at the tasks for the previous round [20:25:48 CEST] <b_amabo> kierank: I have gone through the tasks list and I find for creating a fuzzing testsuit for FFmpeg and that for Improving Selftest Coverage intersting to me [20:29:08 CEST] <kierank> b_amabo: ah I see your email [20:29:40 CEST] <b_amabo> okay great! [20:31:30 CEST] <b_amabo> kierank: @JEEB has given me some hints to get started but getting more from you will be a plus [20:36:31 CEST] <kierank> have a look at the patches for fffuzz on ffmpeg-devel [20:36:48 CEST] <kierank> and look at https://fuzzing-project.org/ [20:37:23 CEST] <b_amabo> okay I will do that ASAP [20:53:30 CEST] <Zeranoe> So github has a rather misleading use of "committed on ...". This can be seen here: https://github.com/FFmpeg/FFmpeg/commit/8ff0f6ae8253d394f096b39d69b66e5247e… Github reports "cus committed on Mar 15" yet that's the author date as seen from 'git show -s --format=%ai 8ff0f6a'. The actual committed date (git show -s --format=%ci 8ff0f6a) is '2016-03-26 23:26:27 +0100' [20:54:13 CEST] <wm4> there's a commit date and an author date [20:54:39 CEST] <Zeranoe> I know [20:55:22 CEST] <Zeranoe> GitHub's use of 'committed on Mar 15' would imply it's referring to the committed date, but that's actually the author date [20:58:09 CEST] <wm4> github being github [20:58:14 CEST] <Daemon404> Zeranoe, it gets even more confusing when the person who authors is not the smae as the committed [20:58:20 CEST] <BBB> Daemon404: when are you next in NY again? [20:58:28 CEST] <Daemon404> it says "First Guy committed with Second Guy on <...>" [20:58:33 CEST] <Daemon404> BBB, i arrive this sunday [21:00:55 CEST] <Zeranoe> What a horrible choice of words [21:01:00 CEST] <Zeranoe> on GitHub. [21:01:25 CEST] <Shiz> git config user.name 'a stick up his ass' [21:01:31 CEST] <Shiz> now to send in a patch.... [21:02:08 CEST] <Daemon404> doesnt work [21:02:18 CEST] <Daemon404> github displays the *github* user name in these sentences [21:02:21 CEST] <Daemon404> not the, you know, name in git. [21:02:25 CEST] <wm4> Zeranoe: the worst is that github reorders commits in pull request by author time or so [21:02:46 CEST] <Daemon404> ... you must be jesting [21:02:50 CEST] <Zeranoe> wm4: Lovely. That's the last time I use it for info [21:02:51 CEST] <Daemon404> ive never seen hits behavior [21:02:58 CEST] <Daemon404> this* [21:03:09 CEST] <wm4> it's a common complaint [21:05:54 CEST] <Shiz> Daemon404: a_stick_up_his_ass [21:05:56 CEST] <Shiz> ez fix [21:25:03 CEST] <BBB> Daemon404: so, for colorspace, is there a specific reason you asked, i.e. a specific concern? [21:30:54 CEST] <Daemon404> confusion mostly [21:31:07 CEST] <Daemon404> and hoping a 2nd swscale would not live in tree in lavfi [21:36:28 CEST] <BBB> Daemon404: no, no; if it overlaps significantly, Ill merge them and call it swscale [21:36:33 CEST] <BBB> see wiki/swscale [21:36:48 CEST] <BBB> thats the eventual goal, but its currently strictly separate [21:37:30 CEST] <wm4> <Daemon404> and hoping a 2nd swscale would not live in tree in lavfi <- lol [21:38:38 CEST] <jamrial> we still sorta have an swresample in avcodec :p [21:38:52 CEST] <wm4> because we never remove anything [21:38:53 CEST] <jamrial> it should be gone in the next bump, though [21:39:03 CEST] <wm4> do we still have an deinterlacer in avcodec? [21:39:03 CEST] <BBB> we had a swscale sorta thing in lavc also [21:39:12 CEST] <BBB> I believe its gone now [21:39:15 CEST] <BBB> let me confirm [21:39:20 CEST] <jamrial> wm4: it's deprecated and already (or about to be) two years old, so next major bump will get rid of it [21:39:51 CEST] <BBB> I think it was removed in the last bump [21:39:56 CEST] <BBB> I dont see it anymore [21:40:39 CEST] <BBB> see 41194f065c8e9b138db069417494e2f845c7b275 [21:40:44 CEST] <BBB> lavc: Drop deprecated deinterlace module [21:40:50 CEST] <BBB> Date: Sat Sep 5 17:05:46 2015 +0200 [21:41:17 CEST] <BBB> (or cad40a3833ad81a352e7657ec6f7d637cea3b798, the libav commit that the above merges) [21:44:49 CEST] <wm4> amazing, so we do remove stuff [21:46:12 CEST] <wm4> so can we remove the old vdpau decoder [21:48:27 CEST] <cone-104> ffmpeg 03Michael Niedermayer 07master:4efd3ec50a54: avcodec/svq3: fix assert type (was av_assert2 in h264 from where this was copied) [22:24:38 CEST] <ubitux> BBB: sierra2_4a is a nice dithering too [22:24:49 CEST] <ubitux> see palettegen for various dithering coeff [22:25:45 CEST] <ubitux> sorry i mean paletteuse [22:31:14 CEST] <BBB> ubitux: so, I have to be honest, I dont really see the difference between all these dithering algos [22:31:18 CEST] <BBB> I mean, I see that theyre differen [22:31:27 CEST] <BBB> but I Dont think any one is absolutely better than any other [22:31:39 CEST] <BBB> FSB is widely documented and easy, so I usually just use that one first [22:31:42 CEST] <ubitux> depend on the use case i guess yeah [22:31:53 CEST] <BBB> probably [22:32:01 CEST] <ubitux> for the 256 color case, it has a huge impact :p [22:32:01 CEST] <BBB> FSB is already better than what swscale does :-p [22:32:24 CEST] <ubitux> http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html [22:32:26 CEST] <nevcairiel> error diffusion algorithms like FSB have a few problems with moving images as the dither pattern can change from minimal pixel changes, although its probably only visible in pixel art videos =p [22:32:32 CEST] <ubitux> BBB: look at the end of the post [22:32:35 CEST] <ubitux> for the various comparisons [22:32:53 CEST] <BBB> hm... [22:32:55 CEST] <BBB> lemmecheck [22:33:33 CEST] <ubitux> sierra2 requires 3 lines though [22:34:23 CEST] <ubitux> found most of these from http://www.efg2.com/Lab/Library/ImageProcessing/DHALF.TXT [22:34:54 CEST] <BBB> yeah, sierra2 and related algos use 12 neighbours instead of 4 [22:34:57 CEST] <BBB> thats why theyre slower, I think [22:35:03 CEST] <BBB> (4 = fsb) [22:37:42 CEST] <nevcairiel> fsb's biggest problem is that SIMDing it is really hard [22:37:56 CEST] <ubitux> like all the other actually [22:38:22 CEST] <nevcairiel> thats why i like ordered or random dither, quality is still ok for images (your palette case may be different), and its super easy to code [22:38:46 CEST] <BBB> Im going to try to code a semi-simd layer [22:38:51 CEST] <BBB> I believe it should be relatively fast [22:38:55 CEST] <BBB> and compared to video coding, its trivial [22:39:10 CEST] <BBB> so for 10/12bit sources of high value, the cost of encoding is still much higher than the cost of dithering [22:39:12 CEST] <BBB> and then its all ok [00:00:00 CEST] --- Wed Apr 27 2016

1 0

ffmpeg.log.20160426
by burek 27 Apr '16

27 Apr '16

[00:03:21 CEST] <prelude2004c_zzz> so can anyone tell me how i setup ffmpeg with -timeout -1 [00:03:42 CEST] <prelude2004c_zzz> doesn't seem to work and it keeps exiting when input is missing for a few seconds [00:21:14 CEST] <Sirisian|Work> Does ffmpeg have issues when a device can't keep up with the reencoding? Looks like at 25 of 25 fps I don't see any issues, but if I start to stress the server by running the video on the device the encoding fps drops to 14-18 fps and after 20s to 5 minutes I see http://pastebin.com/1Q3VVyKy I plan to submit a bug, but the issue tracker is down it seems. I assume it's using a circular buffer someplace that might be running out [00:21:14 CEST] <Sirisian|Work> of space and getting corrupted? [00:26:14 CEST] <Sirisian|Work> Yeah this is very easy to reproduce on my end. I'm not sure the devs will feel the same way though. [00:27:26 CEST] <__jack__> Sirisian|Work: not really an issue [00:28:02 CEST] <__jack__> you can't hold stuff forever, it must goes out at least as fast as the input, on average [00:28:09 CEST] <__jack__> else, it will fail [00:29:02 CEST] <__jack__> you must either make an async encode (use the stream with fast encode, then do slower stuff, or add power [00:29:43 CEST] <furq> you can set the buffer size for some protocols but it doesn't look like you can set it for http [00:29:54 CEST] <furq> although either way it'll eventually fail [00:30:44 CEST] <Sirisian|Work> Strange. It just failed after 15 minutes now even when encoding at 25 of 25 fps. Maybe that's not the issue. [00:33:17 CEST] <Sirisian|Work> oh looks like maybe it was at 23 fps for a while. [00:34:26 CEST] <spirou> hypothetically, would it be possible to analyze an existing music file to see what would be the lowest bitrate when making a mp3 without any quality loss? [00:34:43 CEST] <furq> i doubt it [00:36:38 CEST] <spirou> for the sake of argument, if you had a 64k/s mp3, then convert it to a .wav or .flac or something nondestructive, so a program could then find out that "oh! this song can be converted to 64k/s mp3 with no loss :-)" [00:36:57 CEST] <furq> there would be loss though [00:37:09 CEST] <spirou> anyway? [00:38:34 CEST] <furq> you could encode it to 320kbps the second time and it would sound worse [00:38:47 CEST] <furq> every time you do a lossy encode some of the original signal is lost [00:39:00 CEST] <spirou> thats sad [00:39:13 CEST] <spirou> it could be fun it such a thing was possible though [00:39:28 CEST] <furq> that's why all of the reposted jpegs on your uncle's facebook wall have got so much noise around all of the text [00:39:40 CEST] <spirou> and in the simples case a 100% quiet file would be compressed to 0kb/s automatically then :D [00:40:12 CEST] <spirou> yeah thats true, same problem exist for jpg too I guess. [00:41:30 CEST] <spirou> the new compression wastes bits when it tries hard to recreate the artifacts as good as possible thinking they are important [00:42:09 CEST] <furq> yeah the encoder has no way of knowing the difference between signal and artifacts [00:42:29 CEST] <furq> also fwiw if you are doing low-bitrate encodes then vorbis and opus are much better choices than mp3 [00:42:42 CEST] <furq> probably aac too but i avoid that if it's not in mp4 video [00:42:47 CEST] <DHE> Sirisian|Work: if possible, lower the CPU requirements. for libx264 you can use a "fast" preset for example [00:43:28 CEST] <spirou> furq: there is still problems with hardware that only accepts one format though. [00:43:31 CEST] <DHE> second on vorbis or opus. mp3 is actually a pretty bad codec by modern standards [00:43:45 CEST] <furq> mp3 is fine above 128kbps [00:43:59 CEST] <furq> but it's never been able to compete with vorbis below that [00:44:08 CEST] <DHE> spirou: what hardware? AAC, and/or Vorbis actually have fairly decent support in devices I find [00:44:10 CEST] <furq> and opus is better than vorbis if you've got something which supports it [00:44:20 CEST] <furq> and yeah vorbis is fairly well supported and aac even moreso [00:44:42 CEST] <furq> granted i've never owned an mp3 player that i didn't flash rockbox onto, but they both supported vorbis out of the box [00:45:00 CEST] <DHE> iirc vorbis was designed to be patent-free and public domain from day 1. I've seen video games use it for BGM, etc [00:45:13 CEST] <spirou> for example, I have a mp4 film file here, that the TV don't accept. if I let ffmpeg put it in a mkv, then there is no sound :( [00:45:20 CEST] <furq> that might be the principal use for vorbis tbh [00:45:36 CEST] <furq> i've seen it used there more than anywhere else except maybe wikipedia [00:45:37 CEST] <spirou> even if I let ffmpeg recompress the sound track to something else. [00:45:58 CEST] <Sirisian|Work> DHE, yeah I saw those fast and ultrafast settings. Just tested at 30 fps encoding and the most it can do is 24 or 25 fps so definitely not going anywhere near 30. It's taking a long time to fail though sometimes. [00:46:23 CEST] <furq> spirou: mp4 is usually aac audio, but you never know with cheap hardware players [00:46:34 CEST] <Sirisian|Work> yeah there it failed after like 7 minutes. Kind of wish it had a way to recover. [00:47:20 CEST] <furq> doubtless the manual just says "SUPPORT TO MP4 VIDEO EXCELLENCE QUALITY" [00:47:51 CEST] <spirou> furq: yeah this tv is the cheaper kind, some years old. its manual say .mkv can have EAC3 / AC3 sound. [00:48:16 CEST] <spirou> for mp4 it instead say it support "PCM/MP3" [00:48:25 CEST] <furq> oh yeah i think you mentioned this the other day [00:48:40 CEST] <furq> i don't think pcm in mp4 is even a thing [00:48:44 CEST] <furq> or not an official thing, anyway [00:49:01 CEST] <furq> doubtless some dreadful person has hacked it in [00:49:15 CEST] <spirou> as long as I don't recompress the video, even if I remove the audio completely it don't like the file as a mp4. for mkv it don't do sound instead. [00:51:13 CEST] <spirou> (and ywah I bet it support aac for mp4 anyway, I should test with some other film clip, up until now it have accepted anything mp4 I thrown at it) [00:52:20 CEST] <spirou> furq: what is rockbox btw? [00:52:52 CEST] <furq> http://www.rockbox.org/ [00:53:15 CEST] <spirou> not that I ever had any mp3 player that was easy flashable. the one I have is the small no-display kind. [00:53:31 CEST] <kepstin> i'm still sad apple killed the ipod classic; an ipod classic with rockbox is an incredible music player :/ [00:53:32 CEST] <furq> everyone just uses their phone now anyway [00:54:16 CEST] Action: kepstin lost his ipod classic on a bus last year, and replaced it with a 200gb sd card in his phone. [00:55:21 CEST] <furq> i hope after you took the 200GB micro sd card out of the packet, you took a moment to marvel at its existence before putting it in your phone [00:55:24 CEST] <spirou> I don't carry around a phone but I like my small mp3 player sometimes. I doubt there are any manufacturer name printed on it though :D [00:56:10 CEST] <spirou> something I really would like to flash is the TV's software though! [00:56:21 CEST] <furq> i just ended up sticking all my music on google play music [00:56:39 CEST] <kepstin> there's probably some exploitable vulerabilities in your tv :/ [00:56:48 CEST] <furq> they seem to believe i acquired it legally, which is nice of them [00:58:17 CEST] <spirou> simple things like, for some channel if you press the button to get program list then the tv hangs so you have to pull the power :( [00:58:18 CEST] <furq> it's just a shame it transcodes everything to mp3 or else it'd be a nice free backup system [00:59:23 CEST] <furq> i sure am glad i don't own a tv [00:59:39 CEST] <spirou> hehehe [00:59:42 CEST] <furq> i hope they still make completely dumb tvs by the time i have space for one [01:00:21 CEST] <spirou> yeah it is better to buy a big computer monitor really. [01:00:56 CEST] <kepstin> last time my friend bought a tv, it didn't support the video output from some ps1 games :/ [01:01:34 CEST] <TD-Linux> 240p, yeah I guess. [01:01:47 CEST] <kepstin> yeah [01:01:55 CEST] <furq> i would normally make a comment about how it does support the output from an emulator [01:02:02 CEST] <furq> but psx emulators are still remarkably shit [01:03:07 CEST] <kepstin> this guy ended up buying a 'framemeister' upscaler for it. But then he realized that most ps1 games can be played on a ps3. [01:03:26 CEST] <spirou> hehehe [01:03:52 CEST] <TD-Linux> the framemeister is wonderful just for the name alone [01:03:56 CEST] <spirou> does the ps3 have some ps1-emulator built in? I don't think it is same kind of hardware... [01:04:04 CEST] <kepstin> software emulation for ps1 [01:04:06 CEST] <TD-Linux> xiphmont recently mailed be a sony bvm though [01:04:07 CEST] <spirou> ok [01:04:17 CEST] <kepstin> aside from the first-generation ps3 models, some of which contained a ps2 [01:04:25 CEST] <kepstin> which of course contains a ps1 [01:04:32 CEST] <spirou> :D [01:05:07 CEST] <kepstin> the framemeister is even better when you realize that it's japanese, and the creator originally misspelled the name as 'flamemeister' [01:05:23 CEST] <furq> nice [01:06:17 CEST] <furq> http://www.hyperactivebroadcast.com/public/upload_product_image/Sony_BVM_14… [01:06:21 CEST] <furq> that's a nice-looking microwave [01:06:41 CEST] <spirou> About the tv's lack of compassion for this film, would it be that it is something wrong with the video stream that makes it gets lost or not able to use other streams too? [01:06:48 CEST] <spirou> ffprobe say it is "Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 2749 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)" [01:07:11 CEST] <furq> looks fine to me [01:07:16 CEST] <spirou> are there a way to get more information out of it? [01:07:38 CEST] <TD-Linux> furq, this is mine http://people.xiph.org/~tdaede/bvm/20160421_0001.jpg [01:07:54 CEST] <furq> that one doesn't even have a defrost button [01:08:04 CEST] <TD-Linux> it doesn't have any buttons actually [01:08:09 CEST] <TD-Linux> I can't get to the menu as a result [01:08:28 CEST] Action: TD-Linux ordered a "remote" for it [01:08:37 CEST] <TD-Linux> "remote" in quotes because it's a tethered RS-485 1U box [01:08:46 CEST] <spirou> I'm kind of newbie when it comes to this stuff... I guess there is timecodes and ways it interleave the data from the streams and that, that is omporant maybe.. [01:08:58 CEST] <furq> http://ak1.ostkcdn.com/images/products/L1012155.jpg [01:09:03 CEST] <furq> i've still got one of these kicking about [01:09:18 CEST] <furq> except i somehow managed to scratch the antistatic coating [01:11:08 CEST] <furq> just to clarify i mean the monitor and not the space motorcycle [01:11:22 CEST] <spirou> TD-Linux: wonderful design! :D [01:15:22 CEST] <spirou> I didn't know sony could make such a beautiful tv's. a deluxe model too with trinitron. [01:25:17 CEST] <TD-Linux> spirou, if you think that's nice, check out the rear http://people.xiph.org/~tdaede/bvm/20160421_0003.jpg [01:26:15 CEST] <spirou> is it some kind of cooling on the right? [01:26:37 CEST] <TD-Linux> yes, for the power supplies. [01:26:58 CEST] <TD-Linux> the inputs are all option cards that you install http://people.xiph.org/~tdaede/bvm/20160421_0006.jpg [01:27:38 CEST] <spirou> lots of ins and outs! of a tv is always nice heh [02:29:10 CEST] <spirou> How come, when you convert to mp3 by defaul it uses 128 kb/s but when checked with standard unix "file" command it thinks it's 64 kbps ? [02:30:32 CEST] <spirou> but if I during the ffmpeg converting specify -b:a 128k then "file" correctly identify it as "128 kbps" [02:33:02 CEST] <spirou> vlc also says that the using defaults mad version is 64 kbit/s [02:33:07 CEST] <spirou> *made [02:33:50 CEST] <DHE> could be VBR mode which targets 128k. first few chunks are silent so they compress really small. so a heuristic doesn't get it right [02:33:56 CEST] <spirou> (while ffprobe say "Stream #0:0: Audio: mp3, 48000 Hz, stereo, s16p, 128 kb/s" "encoder : Lavc57.16") [02:34:45 CEST] <spirou> oh hmm...ok? (I guess I shouldn't let it use defaults anyway, but still a bit strange) [02:36:48 CEST] <spirou> both files in my test went almost same size though 1920710 "64bit" vs 1920902 "128kbit" [02:43:59 CEST] <spirou> Hmm yeah on the other tab VLC say it is 128 kb/s (+some actual statistics jumping up and down between 125 and 130) [02:44:41 CEST] <Sirisian|Work> Not sure if anyone related to the site is here, but I'm trying to submit a bug report and when I registered an account it won't send me an email. It's been over an hour. Might look into that. [02:47:36 CEST] <spirou> Sirisian|Work: it didn't got stuck in some mail filter or something? the confirm mail should be automatic sent one would think, nobody does such manually... [02:48:05 CEST] <Sirisian|Work> Their site was down for most of the day today for me. Maybe something broke. [02:52:13 CEST] <spirou> yeah perhaps something is still is off. I guess you should check tomorrow [02:52:21 CEST] <spirou> it is the https://trac.ffmpeg.org/register right? [03:04:59 CEST] <Sirisian|Work> yeah [04:27:14 CEST] <prelude2004c_zzz> hey.. anyone know how i can increase PTS for video and audio without transcoding ? [04:27:37 CEST] <prelude2004c_zzz> i have a video that i am segmenting with FFMpeg but... the pvr start time for recording is always -6 [04:27:40 CEST] <prelude2004c_zzz> i need to make it 1 [04:27:43 CEST] <prelude2004c_zzz> or 0 [04:27:58 CEST] <prelude2004c_zzz> i dont know how to increase pts forward without the actual transcoding thing [04:47:19 CEST] <k_sze[work]> When using FFV1 level 1, what's the default `-context`? I don't think I can tell from the console output of ffmpeg. [04:48:14 CEST] <k_sze[work]> It's also doesn't seem to be documented at either https://trac.ffmpeg.org/wiki/Encode/FFV1 [04:48:51 CEST] <kepstin> prelude2004c_zzz: you can try the -avoid_negative_ts output (muxer) option. [04:50:06 CEST] <kepstin> prelude2004c_zzz: documented in https://ffmpeg.org/ffmpeg-all.html#Format-Options [04:54:32 CEST] <prelude2004c_zzz> yup tried that [04:55:12 CEST] <pandb> i modified the muxing.c example to continuously grab image data from an arbitrary window and encode it into a video. However, the resulting video always plays too fast. [04:56:03 CEST] <pandb> i've set the time_base fields to (AVRational){1, 30} for the codec context and stream object for my video [04:56:37 CEST] <pandb> and i increment the pts field for the AVPacket i use in my call to avcodec_encode_video2 [04:56:43 CEST] <pandb> i'm not sure what else to try [04:57:56 CEST] <pandb> the functions for generating the image data and encoding the video are in separate threads, with the images placed on a queue and extracted from the queue in the video thread [04:58:35 CEST] <pandb> if the queue is empty, then the previous image is used to encode a new frame for the video [04:58:58 CEST] <pandb> i've experimented with putting the image-generating thread to sleep for various periods [04:59:22 CEST] <pandb> i've been able to slow playback down to an extent, but it always plays too fast [08:17:18 CEST] <k_sze[work]> When encoding as libx264, is there some restriction to the valid number of slices? [08:47:55 CEST] <spiderkeys> I'm having trouble getting correct timing information from a raw h264 stream using custom AVIO contexts and can't really seem to figure out why. I've looked at an H264 analyzer and the SPS and PPS info is definitely there, but when I use find_stream_info, it only gets some of the stream info. Bitrate, timing info, all seems wrong. My format detection is at CMuxer::Update() if anyone can take a quick look [08:47:57 CEST] <spiderkeys> https://github.com/OpenROV-Dev/geomuxpp/blob/inproc_rewrite/src/CMuxer.cpp [08:49:30 CEST] <spiderkeys> Basically, filling a buffer with a ton of h264 frames, probing it to make sure I get the right format, then using find_stream_info to get the particulars. This is the output that I get: http://pastie.org/10813158 [08:51:50 CEST] <spiderkeys> I've tried all sorts of flags, fiddling with my camera settings, etc, but the timestamps are always equal to AV_NOPTS [08:53:32 CEST] <spiderkeys> analyzer shows inclusion of VUI info: http://i.imgur.com/iwECnmZ.png [08:54:47 CEST] <spiderkeys> cut off of my screenshot: timing_info_present_flag :1 num_units_in_tick :6006 time_scale :180000 fixed_frame_rate_flag :0 [10:59:56 CEST] <navlelo_> I am trying to cache a rtsp stream and then serve the cached stream using ffserver... I am struggling a bit to find the right options for this though. Does anyone know how to do this? [11:52:21 CEST] <otila> I use libx265 to encode movie, -x265-params crf=15:nr-inter=250:nr-intra=250 , x265 debug line shows correct CRF value, but it does not matter what crf I use, 15 or 30,.. it creates output file with the exact bitrate, about 60 Mbit/s [11:52:31 CEST] <otila> could be also x265 bug [13:44:41 CEST] <TenLeftFingers> Can anyone give me a command to do a conversion from mp3 to ADP4? Searching for ADP4 in the man pages turned up nothing but I do see it mentioned in some sources on git. [14:07:32 CEST] <mad_ady> hey guys [14:07:55 CEST] <mad_ady> @JEEB: remember I asked yesterday how I could trigger ffserver to start my ffmpeg stream when the client connects? [14:08:11 CEST] <mad_ady> well, I wrote my own workaround: https://github.com/mad-ady/ffserver-trigger/blob/master/ffserver-trigger.pl [14:08:18 CEST] <mad_ady> it's good enough for my needs [14:09:24 CEST] <Wader8> hello [14:10:30 CEST] <Wader8> is it possible to make FFMPEG show status console output for audio and video separately, the bitrate stuff, as it's quite confusing when it's showing bitrate for the whole file, many times I'd like to see just video bitrate [14:40:14 CEST] <Wader8> here ticket https://trac.ffmpeg.org/ticket/5476#ticket [14:45:15 CEST] <Infiltrator> Is there a way to insert a stream into a file? Or do I just need to do -c copy and then delete the old file(s)? [14:54:12 CEST] <Wader8> if you're dealing with MKVs you can try also combination with MKVToolNix [14:54:26 CEST] <Wader8> there are ways so you can combine stuff [14:55:02 CEST] <Wader8> you can most probably extract the raw video and audio into a file and use that to merge, and add others [14:55:15 CEST] <Wader8> you need to research how to use -map option [15:07:49 CEST] <Infiltrator> Sorry, I wasn't clear. I want to be able append another stream to an existing file instead of creating a new output file and then deleting the old input file(s). [15:11:46 CEST] <Wader8> I've been thinking about that but I didn't need it so I don't know exactly [15:43:08 CEST] <TenLeftFingers> I've left a comment on the ADP4 support that was added here: https://github.com/Nevcairiel/FFmpeg/commit/a66243a2014c4ce689b5514f82effee… [15:43:46 CEST] <TenLeftFingers> Can anyone explain the issue I'm having? [15:44:50 CEST] <furq> TenLeftFingers: the codec name is adpcm_ima_ws [15:44:57 CEST] <furq> although it's decode-only on this build i've got here [15:49:55 CEST] <Carlrobertoh> I'm screen casting my video for 10seconds, but the output video is only 4 seconds. What could be the issue = [15:50:02 CEST] <Carlrobertoh> timestamps ? [15:50:12 CEST] <Carlrobertoh> i've set it correctly, ithink [16:03:00 CEST] <TenLeftFingers> furq: thank you. Can I ask what build you're on? [16:03:18 CEST] <furq> i checked on 2.8.6 [16:03:37 CEST] <furq> it might be worth checking with 3.x [16:04:12 CEST] <TenLeftFingers> furq: great, thank you so much. I was at a complete loss. [16:14:37 CEST] <Carlrobertoh> anyone? [16:48:19 CEST] <Prelude2004c> hey guys... anyone know why none of the closed caption data is not coming through. .i am using scodec copy [16:48:33 CEST] <Prelude2004c> should ffmpeg not keep that in the stream and just pass it on to segment ? [16:48:47 CEST] <DHE> depends. closed captions can also be embedded in the video stream itself [16:48:54 CEST] <Prelude2004c> ${ffmpeg} -i "$stream" -copyts -copytb 0 -codec copy -scodec copy $mapping -avoid_negative_ts 1 -f mpegts - [16:49:17 CEST] <DHE> use ffprobe on the stream. it should indicate a subtitle stream is present, or it may show "Closed Captions" on the video stream [16:49:25 CEST] <Prelude2004c> i am taking the video... and stdin to hardware encoding ( nvidia ) .. and then outputting back to ffmpeg to join audio/video [16:49:40 CEST] <Prelude2004c> ok checking [16:51:38 CEST] <Prelude2004c> doens't show me anything in the stream but may be embeded in the video [16:52:04 CEST] <Prelude2004c> actually yes it has it [16:52:05 CEST] <Prelude2004c> Closed Captions, [16:52:15 CEST] <DHE> yeah, nvenc won't process those [16:52:32 CEST] <DHE> libx264 will if you're up-to-date enough to support the "-a53cc 1" option [16:52:48 CEST] <Prelude2004c> hum.. do you think i should somehow extract it on copy to a file or something and then put it back together on the last ffmpeg session after the encoding [16:53:04 CEST] <DHE> if you have a tool that will do that, sure that might be your best bet [16:53:32 CEST] <Prelude2004c> a tool? i am thinking a script .. this is live content [16:53:37 CEST] <Prelude2004c> has to do it in realtime on decode [16:53:45 CEST] <Prelude2004c> just not sure how i would do that [16:54:46 CEST] <Prelude2004c> maybe it also has omething to do witht he fact that we are at 60fps input and i am converting it to 30fps [16:54:48 CEST] <Prelude2004c> on the output [16:57:44 CEST] <Prelude2004c> any clues on what i could do about this ? [17:55:46 CEST] <kthelgason> Hi [17:56:16 CEST] <kthelgason> I'm building FFmpeg from master, and some actions that worked in 3.0 don't seem to anymore [17:56:38 CEST] <kthelgason> Looking through the changelog I can't find any changes relevant to what I'm donig. Is it possible that master is in a borked state? [18:03:39 CEST] <durandal_170> kthelgason: like what? [18:05:37 CEST] <kthelgason> The command I'm running is ffmpeg -f avfoundation -pix_fmt nv12 -i "0:0" /tmp/out.mp4 [18:05:57 CEST] <kthelgason> this works fine with 3.0, and 3.0.1, but not master [18:10:00 CEST] <jbreeden> Hello all; I'm new here, forgive me if I'm not following etiquette for asking a question. I'm trying to use FFmpeg to extract a KLVA data stream from MPEG-TS, and convert it to WebVTT. Is there a way to create a subtitle output from a 'data' input? [18:12:12 CEST] <durandal_170> kthelgason: please report bug on Trac [18:12:29 CEST] <kthelgason> durandal_170: Ok, I'll do that, thanks. [18:22:16 CEST] <c_14> jbreeden: not without writing a decoder for the input codec [18:44:52 CEST] <Prelude2004c> hey guys.. question.. " ERROR: nvEncodeAPI.h not found. " ... i copied the sdk stuff to /usr/local/include [18:44:57 CEST] <Prelude2004c> and also /usr/include [18:45:10 CEST] <Prelude2004c> ran ldconfig and everything.. not sure why its not seeing it [18:45:30 CEST] <c_14> Is it /usr/include/foobar/nvEncodeAPI.h or /usr/include/nvEncodeAPI.h? [18:45:33 CEST] <c_14> It has to be the second [18:45:40 CEST] <c_14> Or you have to add /foobar/ to the include path [18:51:01 CEST] <jbreeden> c_14: thanks, I've started down that path. The only way I could see to do it was to modify libavformat/mpegts.c to treat KLVA as a AVMEDIA_TYPE_SUBTITLE rather than AVMEDIA_TYPE_DATA. Is there a way to start with data, decode, then reencode as subtitle? [18:52:48 CEST] <c_14> I'm pretty sure you have to add a decoder in libavcodec and register it etc and then it should work [18:52:52 CEST] <sfan5> Prelude2004c: i build with --extra-cflags=-I/usr/include/nvidia-sdk since nvEncodeAPI.h is in /usr/include/nvidia-sdk [18:52:55 CEST] <sfan5> that works finme [18:55:06 CEST] <jbreeden> c_14: yes, but it appears that my decoder's AVCodec struct can either specify a type of AVMEDIA_TYPE_SUBTITLE or AVMEDIA_TYPE_DATA, I don't see the proper way to configure it so that FFmpeg knows that the decoder is starting with data and ending with subtitle [18:56:31 CEST] <c_14> Just set it to subtitle for both input and output? [18:58:12 CEST] <jbreeden> c_14: Yeah, that's what I have right now. It feels like a hack, and I was hoping there is a more elegant solution that I failed to see. [18:58:49 CEST] <jbreeden> I didn't really want to mess with any existing code other than to make my plugin, you know? [19:04:58 CEST] <Prelude2004c> sfan5 i dont have nvidia-sdk folder [19:05:03 CEST] <Prelude2004c> i need the tools ? [19:05:04 CEST] <Prelude2004c> nvidia-cuda-toolkit [19:08:11 CEST] <c_14> afaik you only need the header file [19:12:26 CEST] <sneke> Is ffmpeg able to split a flac based on a cue file or possibly a list of break points?? [19:13:14 CEST] <furq> sneke: not to my knowledge [19:13:29 CEST] <furq> if you need to do it on the command line then use cuetools and shntool [19:14:05 CEST] <sneke> That is what I have used so far, but shntool is unable to split this 3.1GB file I have. [19:14:10 CEST] <furq> fun [19:14:12 CEST] <atomnuker> sneke: https://github.com/atomnuker/luasplit [19:14:26 CEST] <atomnuker> a quick script I wrote just for that purpose [19:14:30 CEST] <furq> if you're on windows then http://www.cuetools.net/wiki/CUETools is excellent [19:14:53 CEST] <sneke> I'll try that out, atomnuker [19:15:55 CEST] <furq> but yeah if you don't care about getting a non-conformant cue or about ar/ctdb verification then it's a bit unnecessary [19:16:34 CEST] <sneke> I'm not entirely sure what you're saying [19:16:58 CEST] <furq> cuetools (the windows one) will write a valid cuesheet for the split files [19:17:22 CEST] <furq> and will attempt to verify that it's a good rip [19:24:28 CEST] <sneke> The script doesn't work for me, atomnuker. It could't get the current dir, and when I fixed that, shnsplit complained about an unknown file format. [19:24:31 CEST] <sneke> furq: ah [19:25:28 CEST] <sneke> I'll try to split it manually with ffmpeg [19:27:00 CEST] <Prelude2004c> furq .. you know this stuff.. nvencodeapi.h missng... how does one get nvidia-sdk ? [19:27:09 CEST] <furq> i've never used nvenc [19:27:31 CEST] <Prelude2004c> oh .. ic.. ok well the sdk i installed but.. for some reason never created the /usr/include-nvidia-sdk [19:27:33 CEST] <Prelude2004c> its odd [19:27:34 CEST] <furq> check config.log to see which paths it's searching for [19:27:53 CEST] <Prelude2004c> its searching for /usr/include [19:27:59 CEST] <furq> 17:45:30 ( c_14) Is it /usr/include/foobar/nvEncodeAPI.h or /usr/include/nvEncodeAPI.h? [19:28:00 CEST] <Prelude2004c> and the files are there.. that is why i am blown again [19:28:02 CEST] <furq> 17:45:33 ( c_14) It has to be the second [19:28:56 CEST] <furq> sneke: maybe decode the flac to wav and then try again with shntool? [19:29:25 CEST] <furq> oh nvm it's a known bug with shntool [19:31:02 CEST] <furq> it looks like the debian package has patches which fix processing large files [19:31:22 CEST] <furq> if you're not on debian then you could maybe try to apply those to upstream [19:32:31 CEST] <furq> http://http.debian.net/debian/pool/main/s/shntool/shntool_3.0.10-1.debian.t… [19:32:55 CEST] <sneke> That's the same version I use, currently [19:33:07 CEST] <furq> on debian? [19:33:55 CEST] <sneke> Arch Linux [19:34:11 CEST] <furq> yeah the patches are from the debian maintainers, i don't think they made it upstream [19:34:22 CEST] <sneke> ah [19:36:18 CEST] <sneke> surprisingly small patches [19:38:42 CEST] <sneke> I believe I know what to do, but in the meantime, is there a time flag for ffmpeg that cuts at a specified time, instead of a duration (specified by -t)? [19:39:49 CEST] <furq> -to [19:40:21 CEST] <sneke> lovely, thanks for the help [20:02:40 CEST] <Pepe> Hello. I saw wish issue for widevine and its there for 2-3 yrs. Is there any progress on it? We would like UPC/Ziggo Horizon for XMBC, but we are waiting for ffmpeg [20:04:58 CEST] <JEEB> widevine is a DRM thing... [20:06:32 CEST] <Pepe> yeah I know.. :/ [20:07:38 CEST] <DHE> DRM vendors tend not to be too open with their specs and libraries [20:09:31 CEST] <durandal_170> no DRM, thanks [20:09:36 CEST] <Prelude2004c> unreal ...... this is silly [20:10:06 CEST] <JEEB> if it's DASH-based it's at least standardized how the encryption is done. *but* the stuff that a DRM vendor puts in the area for "how to get the key" is completely up to the vendor and opaque [20:10:20 CEST] <JEEB> so if you have interest in reverse engineering their current implementation, glhf [20:10:53 CEST] <Prelude2004c> i have done this 10 times.... always worked by copying the sample files to /usr/include .. ( ERROR: nvEncodeAPI.h not found. ) .. ldconfig doesn't update it and it doesn't see it.. i think i am going to need a new pc from banging on keyboard soon [20:10:54 CEST] <JEEB> but not sure if it has a place in FFmpeg, since in general we don't handle implementations of DRM schemes [20:11:23 CEST] <Prelude2004c> the only reason i am doing this.. and mabye there is something else here. one of my ffmpeg version can see the closed captions.. the other one .. i cannot [20:11:44 CEST] <Prelude2004c> is that not weird ? one of the ffmpeg versions is newer adn CC is missing from the input... yet i run the other version and CC is present [20:13:57 CEST] <DHE> I've looked at verimatrix encryption support in HLS... [20:14:26 CEST] <DHE> I have documents of the ultra-high level of how it works, but that's all you get. the DRM layer is black voodoo [20:14:28 CEST] <furq> Prelude2004c: ldconfig has nothing to do with finding a header [20:15:08 CEST] <furq> pastebin the last ~50 lines of config.log i guess [20:17:40 CEST] <Prelude2004c> i think its something opencl [20:17:46 CEST] <Prelude2004c> looking at http://developer.download.nvidia.com/compute/cuda/6_5/rel/installers/cuda_6… [20:19:07 CEST] <jbreeden> Prelude2004c: what is the full path to your nvEncodeAPI.h currently? [20:20:36 CEST] <Prelude2004c> it's /usr/include/nvEncodeAPI.h [20:21:14 CEST] <jbreeden> and you tried it in /usr/local/include and it didn't work either? [20:21:35 CEST] <Prelude2004c> i may need 6.4.. i installed 7.5 before [20:21:47 CEST] <Prelude2004c> yup /usr/local/include.. copied to there.. too [20:21:59 CEST] <Prelude2004c> its odd.. give me a min.. let me see maybe its an opencl issue missing or something [20:23:17 CEST] <Prelude2004c> it it be its not compiled with " /usr/local/cuda-7.5 " ? [20:23:23 CEST] <Prelude2004c> i mean compatible [20:23:41 CEST] <furq> does config.log not tell you why it failed [20:25:16 CEST] <Prelude2004c> http://pastebin.com/PPKq07NY [20:27:04 CEST] <jbreeden> http://askubuntu.com/questions/470796/fatal-error-sys-cdefs-h-no-such-file-… [20:35:35 CEST] <Prelude2004c> jbreeden... it got me closer :) [20:35:55 CEST] <Prelude2004c> needed to put the ../include in the -I/usr/local/cuda-version/include [20:36:04 CEST] <Prelude2004c> thank you [20:36:30 CEST] <jbreeden> :D [21:01:24 CEST] <Prelude2004c> one last thing.. because all that for nothing :P haha [21:01:42 CEST] <Prelude2004c> source shows " Stream #0:16[0x1231]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc " [21:01:52 CEST] <Prelude2004c> so closed caption exists. [21:02:46 CEST] <Prelude2004c> ${ffmpeg} -i "$stream" -copyts -copytb 0 -codec copy -scodec copy $mapping -avoid_negative_ts 1 -f mpegts - .... so the output shows : Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 59.94 fps, 59.94 tbr, 90k tbn, 90k tbc [21:02:54 CEST] <Prelude2004c> where did my closed caption go :( [21:03:07 CEST] <Prelude2004c> -scodec copy is also there.. so :( [21:07:47 CEST] <Prelude2004c> any idea ? [21:11:25 CEST] <DHE> did I already explain that? [21:11:45 CEST] <DHE> wait, you copied the video stream as well? [21:23:28 CEST] <kepstin> Prelude2004c: what is $mapping? [21:42:47 CEST] <Prelude2004c> oht aht [21:42:49 CEST] <Prelude2004c> sec [21:43:19 CEST] <Prelude2004c> "-map i:0x1811 -map i:0x1814 -map i:0x1815" [21:43:25 CEST] <Prelude2004c> its basically the pids i am grabbing [21:43:32 CEST] <Prelude2004c> the video pid , and the two audio pids [21:50:18 CEST] <kepstin> so you're mapping the video and two audio, but not the subtitles [21:50:22 CEST] <kepstin> so you get no subtitles [21:50:44 CEST] <kepstin> if you use -map, you get only the stuff that you map [21:51:34 CEST] <courrier> Hey guys, for some reason my video has a single black frame hidden between two normal frames, making a fast black flash when the video plays, how can I identify and remove that frame? [21:52:16 CEST] <courrier> mpv that allows frame-by-frame playback backwards allowed me to see the actual frame but it doesn't tell the frame id [21:57:02 CEST] <Prelude2004c> that makes sense but the input i see no PID for sub-tabiles [21:57:07 CEST] <Prelude2004c> sub-titles [21:57:11 CEST] <Prelude2004c> where would i find that pid [21:58:24 CEST] <Prelude2004c> i am pretty sure the closed caption is in the video pid [22:13:31 CEST] <Prelude2004c> any hints ? [23:10:25 CEST] <patdavid> best option to transcode 4k mp4/mov from a drone to playback smoothly if space isn't an issue? [23:10:40 CEST] <patdavid> lagarith? ffv1? huffyuv? maybe prores? [23:11:36 CEST] <furq> i doubt those would play back more smoothly than h.264 [23:11:36 CEST] <kepstin> limit is probably io bandwidth with most lossy codecs [23:12:02 CEST] <kepstin> with most lossless or near-lossless codecs* [23:12:37 CEST] <patdavid> is there a better option for smoother playback that is less cpu intensive? [23:14:04 CEST] <kepstin> for 4k video, if you have a hardware h264 decoder you can use, that's probably the best option. [23:14:28 CEST] <patdavid> ok [23:14:46 CEST] <DrSlony> patdavid try mpv [23:14:56 CEST] <DrSlony> https://mpv.io/ [23:14:57 CEST] <patdavid> w/o a hardware decoder, what about ffv1? it seemed pretty quick last time i checked [23:15:21 CEST] <DrSlony> lossless bandwidth kills my hardware [23:15:25 CEST] <TD-Linux> what device are you playing back on [23:15:37 CEST] <flux> are there players that buffer decoded frames? that could smooth out between the impact of decoding p- and i-frames [23:15:47 CEST] <patdavid> one of my wifes students desktop machines in a science lab [23:15:53 CEST] <furq> patdavid: at 4k you're going to be running up against the limits of disk access speeds [23:15:57 CEST] <flux> or do all of them do it :) [23:15:59 CEST] <patdavid> furq, that's what i figured [23:16:09 CEST] <furq> uncompressed at 24fps that's ~300mbps [23:16:12 CEST] <flux> not with ssd :) [23:16:13 CEST] <TD-Linux> patdavid, does it even have a 4k monitor? can you just drop the res to 1080p? [23:16:30 CEST] <patdavid> no, they need the spatial resolution to identify wildlife in their frame [23:16:35 CEST] <patdavid> :( [23:16:43 CEST] <patdavid> i considered proxy video as an option [23:17:02 CEST] <patdavid> at 1080p, then if they get a decent confidence that something might be there, seek in the original 4k footage for it [23:17:25 CEST] <DrSlony> is the 4k interlaces? [23:17:26 CEST] <TD-Linux> that might be reasonable. depending on your vo it might have trouble just displaying the 4k frame [23:17:27 CEST] <patdavid> it's still on the table, just more complicated for natural science undergrads [23:17:29 CEST] <DrSlony> *interlaced [23:17:35 CEST] <patdavid> DrSlony, no [23:17:38 CEST] <patdavid> progressive [23:17:40 CEST] <patdavid> 25fps [23:18:00 CEST] <flux> patdavid, so what is the bottleneck here, why isn't the original video smooth? [23:18:05 CEST] <DrSlony> patdavid what if you copy the video, or a part of the video, to a RAM drive, does it still stutter on playback? [23:18:21 CEST] <patdavid> flux, i'm guessing the h264 decoding on the cpu (+ ram is likely not much) [23:18:31 CEST] <patdavid> DrSlony, haven't checked yet [23:18:34 CEST] <furq> it might be worth trying a different player [23:18:37 CEST] <patdavid> DrSlony, don't have any files handy at the moment [23:18:40 CEST] <furq> but yeah if the bitrate is very high it could be that too [23:18:42 CEST] <flux> patdavid, so it's quite an old pc then if it doesn't have a GPU that accelerates it? [23:18:47 CEST] <DrSlony> if linux, try copying to /tmp or /dev/shm/ [23:18:54 CEST] <patdavid> flux, i am thinking that's the case [23:19:17 CEST] <furq> what player is the machine using [23:19:28 CEST] <patdavid> vlc i think [23:19:32 CEST] <patdavid> not sure which build - could be old [23:19:37 CEST] <TD-Linux> there are codecs that are less complex than H.264, but you might be hitting other limits (like memory bandwidth) on your potatoboxen that make a faster codec less useful [23:19:44 CEST] <furq> maybe give mpv a try then, i know ffmpeg's h264 decoder is pretty well-optimised [23:19:52 CEST] <patdavid> ok, worth a shot [23:19:57 CEST] <patdavid> thank you all for the help [23:19:59 CEST] <TD-Linux> vlc uses the same decoder so maybe [23:20:13 CEST] <patdavid> might need to upgrade to a bigger potato [23:20:18 CEST] <furq> yeah i suspected it might [23:20:19 CEST] <flux> mpv is also a fast seeker and has builtin-support for looping short parts of video interactively [23:20:29 CEST] <flux> it seems to me it would be a nice tool for finding parts from a video [23:20:39 CEST] <furq> i guess mpv is more likely to have the newest lavc though [23:20:51 CEST] <furq> especially if it's not *nix [23:20:51 CEST] <patdavid> wonderinf it wouldn't make sense to dump minutes of vide to frames and loading up in blender for zoom/pan/etc [23:21:05 CEST] <flux> I think decoding 4k video purely CPU-based is not going to happen with h264, though [23:21:13 CEST] <TD-Linux> patdavid, you could try a high quality but lossy intra format, like motion jpeg or relatives [23:21:31 CEST] <patdavid> TD-Linux, thx, i'll try it with some sample footage tomorrow [23:21:44 CEST] <patdavid> flux, yeah, brought my macbook air to its knees... [23:21:52 CEST] <patdavid> (c2013 machine) [23:24:40 CEST] <flux> I have a couple? years old AMD 8350, it takes 260% cores to decode 4k video without hardware acceleration [23:25:27 CEST] <furq> the profile will make a difference as well [23:25:44 CEST] <furq> although if it's come off a gopro i can't imagine it's using anything too intensive [00:00:00 CEST] --- Wed Apr 27 2016

1 0

ffmpeg-devel.log.20160425
by burek 26 Apr '16

26 Apr '16

[00:21:40 CEST] <iive> i really don't understand why they want to get rid of mpegenccontext so badly... [00:22:33 CEST] <iive> all it does is waste cycles and memory [00:22:52 CEST] <wm4> are you saying you like this absolute insane mess [00:23:00 CEST] <wm4> +ly [00:23:29 CEST] <iive> yes [00:24:57 CEST] <wm4> lol [00:26:38 CEST] <iive> calling names is no argument. You can call even the perfectly designed structure "insane mess" if you don't understand it. [00:28:56 CEST] <wm4> I've seen this insane mess myself, so [00:30:39 CEST] <iive> and that is more name calling. [00:31:06 CEST] <nevcairiel> its code, its not a person, its a description =p [00:31:43 CEST] <nevcairiel> and this part of the code is definitely rather a big mess [00:31:47 CEST] <iive> things have names too, e.g. boaty mcboatface [00:32:41 CEST] <wm4> iive: mpegenccontext is not how software should be written [00:32:46 CEST] <iive> well, some people go ape shit crazy if there is even a little bit code duplication... [00:34:13 CEST] <iive> but it is perfectly ok to replicate same structure over and over again for every single codec. [00:35:03 CEST] <wm4> iive: would you mpegenccontext have provide linear search? because that must have been duplicated a 1000 times in ffmpeg [00:35:17 CEST] <iive> wm4: your statements still contain 0 bits of useful information. [00:35:40 CEST] <iive> linear search? [00:35:58 CEST] <durandal_1707> iive, why you care? [00:36:05 CEST] <wm4> I guess I'll go back to doing nothing, which is way more productive than this [00:36:18 CEST] <iive> durandal_1707: i've written codec or two. [00:37:08 CEST] <iive> wm4: no, really. I would like to explain to me, why mpegenccontex is insane mess and how these changes improve anything. [00:37:44 CEST] <iive> objectively, not just stating preferences. [00:37:57 CEST] <durandal_1707> Maintainbility [00:38:00 CEST] <wm4> iive: everything depends on everything if mpegenccontext is involved [00:38:24 CEST] <iive> durandal_1707: that's been abused a lot... be more specific. [00:40:45 CEST] <iive> aka, maintainability means that the developers would understand it easier, and thus be able to work with it. However this again leads to personal preferences. That's why i mentioned that everything you don't understand is "insane mess". [00:41:44 CEST] <nevcairiel> there is a difference between not understanding, and code being extra convoluted to make understanding hard, if many developers have issues figuring out some code, you could already assume something is wrong with it [00:43:24 CEST] <iive> nevcairiel: and how these modifications change that? [00:44:22 CEST] <nevcairiel> separating individual modules out of the spaghetti code clearly makes things simpler to follow [00:46:35 CEST] <iive> we are talking about structures, not code, but [00:46:38 CEST] <nevcairiel> in a perfect world, you would have small individual components with a clearly documented interface to access them - mpegenccontext is none of that, its a huge piece of code with barely any developer knowing the full interaction with all of its fields, many of which are specific to a single codec. so by stripping out some of those single codecs that dont even use the bulk of this context, these codecs get simpler, and the context [00:46:38 CEST] <nevcairiel> itself slowly gets as well [00:47:05 CEST] <iive> separating spaghetti code means code duplication... [00:47:14 CEST] <nevcairiel> so? [00:47:52 CEST] <nevcairiel> also not necessarily, or maybe only very small parts of it [00:48:11 CEST] <iive> it increases maintenance burden, because you have to check and fix same thing on a lot of more places. [00:48:38 CEST] <nevcairiel> or some specific components can be taken out and made to stand on their own, so it can still be shared but with a cleaner interface between them [00:49:58 CEST] <nevcairiel> throwing everything into one component results in something thats not easily understandable, so splitting it into smaller slices it becomes manageable, and can still be shared where appropriate [00:50:02 CEST] <wm4> iive: as these cleanups get done, the truth seems to be more like that barely any code was truly shared [00:50:18 CEST] <wm4> iive: or where it's shared, it can be continued to be shared in a cleaner way [00:50:22 CEST] <nevcairiel> and that, many things ended up in mpegenccontext that still were only used by one codec [00:50:46 CEST] <nevcairiel> i dont think there was much actual duplication of complex functionality [00:51:14 CEST] <nevcairiel> instead it was refactored to have a clean interface, and that shared between components [00:51:31 CEST] <iive> give me example [01:00:52 CEST] <nevcairiel> i had one in mind from quite recently but i didnt find it just now, but i'm tired and its late, so i'll go sleep [01:01:22 CEST] <iive> no hurry, i'm always around. [01:04:19 CEST] <iive> durandal_1707: so you've noticed this 42 byte buffer bug, long before libav committed it to their repo? [01:15:39 CEST] <BBB> iive: mpegenccontext is bad because it suggests theres some functional relationship between mpeg and h264 that somehow relates to mpeg [01:16:00 CEST] <iive> i thought h264 doesn't use it [01:16:01 CEST] <BBB> iive: there is no such relationship, none at all, not even remotely, and any suggestion to the contrary is evidence that youd ignorant about video coding [01:16:09 CEST] <BBB> thats why stuff shouldnt use it [01:16:17 CEST] <BBB> but thats how it was designed [01:16:36 CEST] <BBB> and so it became this piece of crap that has by definition to be useless, otherwise it cant be functionally be shared between codecs [01:16:50 CEST] <BBB> lowest common denominator" [01:17:14 CEST] <BBB> it has to die, it is the only solution [01:17:25 CEST] <BBB> its not the name, the name is fine, but a struct by that name should have to do with mpeg encoding [01:18:24 CEST] <BBB> ../libavcodec/wmv2.h:int ff_wmv2_decode_mb(MpegEncContext *s, int16_t block[6][64]); <- please explain to me how that is proper design [01:18:56 CEST] <BBB> ../libavcodec/h263.h:int ff_h263_decode_mba(MpegEncContext *s); <- and this [01:19:00 CEST] <BBB> (this is so easy) [01:19:58 CEST] <BBB> iive: Im going to assume you have a background in general software engineering, if not, go learn about object oriented programming and suffer java for a bit [01:20:06 CEST] <BBB> iive: its a wonderful lesson in the good, bad and ugly [01:20:12 CEST] <BBB> theres lots of bad and ugly there [01:20:17 CEST] <BBB> but, some of it is genuinely good [01:20:51 CEST] <iive> BBB: you are not the only who have written codecs for ffmpeg, you know. [01:24:11 CEST] <iive> BBB: for your answer, wmv2 shares a lot of similarities with msmpeg4v12 and v34 , that's why ff_wmv2_decode_mb is called by s->decode_mb [01:24:54 CEST] <iive> what do you consider proper design, having every msmpeg4 variant his own context and duplicating all the common code? [01:36:41 CEST] <BBB> why duplicate? [01:37:00 CEST] <BBB> call it mpegcommoncontext if you believe its common to mpeg-like codecs [01:37:05 CEST] <BBB> of which h264 is not one [01:37:12 CEST] <BBB> but dont call it mpegenccontext [01:37:19 CEST] <iive> why are you involving h264 here? [01:37:40 CEST] <iive> it is mpeg common context... [01:37:45 CEST] <BBB> because it used it at some point, and it indicates the ridiculousness of the thing [01:37:51 CEST] <BBB> it was a h264 decoder, by the way, not an encoder [01:37:56 CEST] <BBB> using mpegEnccontext [01:38:25 CEST] <iive> are you sure? [01:38:35 CEST] <BBB> oh am I sure [01:38:49 CEST] <BBB> I worked fair bits on ffh264, yknow - and still do [01:38:54 CEST] <BBB> why dont you git log it [01:39:29 CEST] <iive> ok, I'll take your word on it. [01:39:55 CEST] <iive> but I do remember that h264 split quite early on its development stage. [01:40:06 CEST] <JEEB> uuh [01:40:36 CEST] <BBB> hahahahahahahahha [01:40:52 CEST] <BBB> iive: this is why people ask me, not you, questions about h264 race conditions [01:41:02 CEST] <BBB> $ git log --author rsbultje(a)gmail.com --oneline -- ../libavcodec/h264* | wc -l [01:41:03 CEST] <BBB> 86 [01:41:04 CEST] <BBB> FYI [01:41:56 CEST] <JEEB> h264: deMpegEncContextize [01:42:04 CEST] <JEEB> Sat Feb 16 21:14:00 2013 +0100 [01:42:16 CEST] <JEEB> so yeah, totally early in its development :) [01:42:43 CEST] <JEEB> (that's the date of the merge into FFmpeg) [01:47:48 CEST] <iive> from the look of it, mpegenccontext has been used mostly for stuff like frame allocation, and callback functions. probably some tables and hwaccel. [01:49:50 CEST] <iive> what i'm saying is that h264 have never been forced to fit into mpegenccontext. like somebody above said, every codec could add its own bits in there. [01:50:17 CEST] <iive> and that was not the case with h264. [01:55:20 CEST] <iive> [01:56:13 CEST] <iive> as for the buffer overlow. Libav prise themselves for reviewing every patch before it been committed. But they don't actually do it. [01:57:17 CEST] <iive> the patch that have been submitted for review doesn't contain this comment [01:58:24 CEST] <iive> the reviewer requested better/serious comment... [01:58:58 CEST] <iive> but probably never reviewed the final version, as the discrepancy would have been obvious. [02:04:51 CEST] <BBB> libav review being sucky does not negate mpegenccontext being just as sucky [02:05:31 CEST] <BBB> if its just a bnch of frame allocations (which beg the question, why not just call it av_frame_alloc? or does it do some more that most users dont actually use, like motion vector allocation and mode decoding?), why not just call it commoncontext? [02:06:06 CEST] <BBB> but thats the thing, it does do more, the logic being that we can add block mode tracking to all codecs, except it doesnt go that way [02:06:27 CEST] <BBB> the result is that lavfi depends on lavc for things like how do you translate a quantizer to a common unit [02:06:34 CEST] <BBB> (muhahahahahahahaha) [02:06:46 CEST] <BBB> which is just utterly ridiculous so Im going to leave it at that [02:15:21 CEST] <iive> from the commit message: 1) extracting a simplified version of the frame management code from mpegvideo.c. We don't need last/next_picture anymore, since h264 uses its own more complex system already and those were set only to appease the mpegvideo parts. [02:15:45 CEST] <iive> so, i guess it does do that now. [02:16:14 CEST] <iive> as for the libav review... this is separate topic, that's why i put an empty line, to separate it. [02:18:56 CEST] <iive> the connection is that, this bug have been introduced by splitting x8 into its own context. [02:19:28 CEST] <iive> so I was wondering what is the logic of doing that... [02:19:48 CEST] <iive> i am NOT arguing about h264 here. [02:28:32 CEST] <BBB> iive: I agree 100% that doing away with mpegenccontext and trying to re-figure out what common part are between codecs that use mpegenccontext, is the right thing to do [02:28:51 CEST] <BBB> iive: and I say that with all my experience as a codec developer and a professional software engineer [02:30:29 CEST] <iive> and where do you draw the line? [02:30:56 CEST] <iive> aka, you say 100% that there shell be no shared structure and code among codecs? [02:43:23 CEST] <iive> i'll be leaving for now. I'll just tell you this. saying that because mpegenccontext is bad for h264, then it is bad for everything is logical fallacy. I'm also not somebody who accepts appeal to authority. and using strong language and been aggressive won't help you either. have fun. [03:53:03 CEST] <DHE> I noticed something about HLS players. Most players download whole files into a distinct buffers so per-file downloads are quick, but ffmpeg just slowly feeds the file into a single buffer leaving the TCP Receive buffer mostly full. [03:53:12 CEST] <DHE> Does that sound like something worth changing? [04:19:30 CEST] <Compn> DHE : do you have an example of a stream url that downloads quickly with another player? [04:19:34 CEST] <Compn> so we can test this with ffmpeg. .. [04:19:59 CEST] <Compn> there might be a realtime option somewhere that may do what you want . but not sure it will work with hls [04:22:02 CEST] <DHE> Compn: any stream really, whether live or VOD. ffmpeg seems to read data out of the TCP buffer at exactly the playback rate producing a smooth playback graph, but every other (ie. commercial) app will download the .ts files as quickly as possible resulting in a very spiky graph [04:22:34 CEST] <DHE> I've been playing with an Over-the-air receiver that produces the MPEG-TS right out of the frequency [04:24:00 CEST] <DHE> the only time I've really had problems was when I paused playback of a video. the remote HTTP server timed me out since ffmpeg just sat on a TCP connection [04:26:24 CEST] <Compn> ffmpeg -fflags nobuffer [04:27:12 CEST] <Compn> theres also -re [04:27:23 CEST] <Compn> not sure it solves your pro b lem though [04:28:25 CEST] <cone-291> ffmpeg 03Michael Niedermayer 07master:9ac154d1facd: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3 [04:28:44 CEST] <DHE> it's not related [04:29:25 CEST] <DHE> basically what I'm suggesting would be to implement a supplemental buffer in the hls demuxer such that HTTP downloads are fully downloaded/buffered by the demuxer first [04:29:28 CEST] <Compn> are we talking about ffmpeg or ffplay ? [04:29:51 CEST] <DHE> well, mainly ffplay. I use mpv as a main video player but ffplay as a reference for ffmpeg behaviour [04:29:56 CEST] <Compn> ok... [04:30:01 CEST] <Compn> ffplay is different [04:30:26 CEST] <Compn> and probably that feature is not something that would be implemented by devs [04:30:35 CEST] <DHE> the 2 reasons for this buffer are 1) eliminate the pause issue I mentioned above and 2) it seems to be the behaviour of every other HLS-compatible player I've tried so far, including hardware/set top boxes [04:30:43 CEST] <Compn> yeah , no i get what you are saying [04:30:49 CEST] <DHE> neither is particularly strong I admit [04:31:23 CEST] <Compn> patches welcome i suppose :) [04:31:48 CEST] <DHE> oh? that above ticket sounds like it might be related to a ticket of my own.. [04:31:53 CEST] <Compn> ffplay and ffmpeg have different things [04:31:58 CEST] <DHE> sorry, distracted by the shiny thing [04:32:12 CEST] <Compn> ffplay -probesize 32 -sync ext INPUT [04:32:12 CEST] <Compn> (the sync part tells it to try and stay realtime). [04:32:16 CEST] <Compn> ^^ did you try that ? [04:32:24 CEST] <Compn> https://trac.ffmpeg.org/wiki/StreamingGuide [04:32:33 CEST] <Compn> if you said ffplay before i would have pasted it earlier :P [04:33:30 CEST] <Compn> still wont buffer though, but latency might be reduced :P [04:33:55 CEST] <DHE> I don't think this is something command-line options can fix. This sounds like something specific to chunk-based HTTP-based streaming formats [04:35:37 CEST] <DHE> well, it's late. gotta go. [10:59:46 CEST] <ismail> c [10:59:50 CEST] <ismail> whoops sorry [11:02:41 CEST] <wm4> it can't be forgiven [12:43:16 CEST] <wm4> ubitux: the srt decoder does not handle this well: http://sprunge.us/MRTR [12:43:41 CEST] <ubitux> lol [12:43:58 CEST] <ubitux> yeah well, add it to the stack of tickets [12:44:21 CEST] <ubitux> i'm working on nlmeans these days, i'll go back to subtitles after that [12:46:47 CEST] <wm4> created a ticket [13:49:34 CEST] <BBB> nevcairiel: i never said msvc was broken, its a product of incompetent leadership [13:49:48 CEST] <BBB> but not broken - I mean, its a c89 compiler (or it was, until recently) [13:49:57 CEST] <nevcairiel> I just dont consider DCE in debug to be something that a compiler needs to do [13:50:01 CEST] <BBB> so for it to not support c99 (at that time) is perfectly understandable [13:50:14 CEST] <BBB> I dont consider c99 something that a compiler needs to do :) [13:50:23 CEST] <BBB> I just need+want it myself [13:50:47 CEST] <BBB> so Im pointing out their idiocy publicly so that they get embarassed into having to implement it anyway even if theyd rather watch youtube videos first [13:50:51 CEST] <nevcairiel> DCE is clearly an optimization, it optimizes dead function calls out [13:50:52 CEST] <BBB> (or read facebook, or ...) [13:51:25 CEST] <BBB> I still see it as a purely technical concern [13:51:30 CEST] <BBB> the compiler clearly supports DCE [13:51:39 CEST] <BBB> let me give ana analogy [13:51:50 CEST] <BBB> in x264, I can use preset=veryslow or preset=placebo, right? [13:51:52 CEST] Action: Daemon404 always thought relying on dce was silly fwiw [13:52:04 CEST] <BBB> you probably know that preset=placebo uses a exhaustive me (me=tesa, I believe) [13:52:09 CEST] <Daemon404> breaks random compilers every month or two [13:52:13 CEST] <Daemon404> not just msvc [13:52:14 CEST] <BBB> whereas preset=veryslow uses --me=umh [13:52:29 CEST] <BBB> so & what if I want to use mostly placebo presets, but without the exhaustive search? [13:52:37 CEST] <BBB> I can use preset=placebo me=umh, right? [13:52:40 CEST] <BBB> ok, on to libvpx [13:52:55 CEST] <BBB> vpxenc best uses exhaustive me, and vpxenc good cpu-used=0 is the veryslow analogue [13:52:56 CEST] <nevcairiel> this isnt going to end up being a very good analogy [13:53:06 CEST] <BBB> how do I use exhaustive r/d search without exhaustive me? [13:53:09 CEST] <BBB> I can't [13:53:13 CEST] <BBB> libvpx = microsoft [13:54:00 CEST] <BBB> not well possible to tune specific options in the software because I dont feel like using five minutes of my precious time on making it user-configurable which most clients dont need while Id rather play on [s]google+[/s] facebook" [13:54:03 CEST] <nevcairiel> switching the me algorithm around sounds like a rather simple thing and just a lack of options in the vpx case, while performing dce could rely on the full optimizer to run, which in this case isnt wanted [13:54:31 CEST] <nevcairiel> ie. it may not be as simple as addin an option [13:54:42 CEST] <BBB> hard to say without access to the source code [13:54:59 CEST] <BBB> but still a purely technical limitation, i.e. easy to solve if someone stops facebooking for a few hours and actually gets to work [13:55:21 CEST] <BBB> but facebooking is much more interesting than getting actual work done, esp. if you work for microsoft [13:55:27 CEST] <BBB> ... [13:55:43 CEST] <nevcairiel> you could argue the same about us, we could fix it in a couple hours and be done with it =p [13:56:05 CEST] <BBB> were not the only software using DCE [13:56:10 CEST] <BBB> its a typical 1-to-N problem [13:56:21 CEST] <BBB> to optimize solving the problem, do you solve O(N) or O(1) problems? [13:56:23 CEST] <nevcairiel> i have not seen any other that fails to build without optimizations [13:56:34 CEST] <nevcairiel> its a silly design to rely on that [13:56:41 CEST] <BBB> theres N pieces of software and 1 compiler ;) [13:56:52 CEST] <BBB> well, Im not in love with DCE or anything [13:56:58 CEST] <BBB> Im just giving you one method to solve it [13:57:02 CEST] <BBB> if people object to it, I wont do it [13:57:05 CEST] <wm4> some code rather trickily relies on DCE [13:57:08 CEST] <BBB> its super-trivial, thats all I say [13:57:09 CEST] <wm4> like allcodecs.c [13:59:11 CEST] <wm4> (meaning you wouldn't get too far by just making the simplest changes) [14:00:50 CEST] <BBB> its not trivial is usually only an objection for microsoft-employees [14:00:58 CEST] <BBB> Ill get it working ;) [14:01:03 CEST] <BBB> but only if people want it... [14:02:08 CEST] <nevcairiel> i dont care, lto is shit anyway and debugging works fine for me with a bit of manual trickery [14:02:23 CEST] <wm4> BBB: well I suggested a tricky macro, that might work for this purpose [14:06:12 CEST] <BBB> wm4: if someone can confirm it works, that would be nice (itd be nice if all*.c and *dsp_init.c dont turn into a massive mess) [14:06:24 CEST] <BBB> wm4: even better if libav agrees on the approach so it doesnt complicate merging... [14:07:24 CEST] <wm4> (I had that macro from something someone suggested on #libav-devel) [14:07:42 CEST] <wm4> the original was probably more elegant and simpler, but I don't remember the details [14:10:24 CEST] <BBB> so if majority opinion wants to get rid of DCE and your macro does not complicate the code, I think we have general consensus on the way forward? [14:10:30 CEST] <BBB> (not complicating code is my only concern) [14:10:37 CEST] <BBB> (or uglifying, if you wish) [14:10:47 CEST] <wm4> I think it'd need a view example patches to ensure consent [14:12:19 CEST] <atomnuker> why would we want to eliminate DCE? so msvc can compile ffmpeg without optimizations for debugging? [14:12:51 CEST] <wm4> it doesn't just affect msvc [14:12:57 CEST] <wm4> it even affects debugging with gcc [14:15:28 CEST] <atomnuker> I wouldn't mind as long as it's not that ugly [14:27:20 CEST] <iive> yes, i've also hit gcc dead code elimination, when using -O0 and some of the functions in the eliminated block are not defined/existing. [14:33:42 CEST] <rcombs> while we're on things that break with -O0, there are a few ARM ASM functions that break when not inlined [14:33:58 CEST] <wm4> inline asm strikes back [14:35:06 CEST] <BBB> rcombs: av_always_inline should inline even in -O0, no? [14:35:08 CEST] <rcombs> I didn't know there was an inline asm empire [14:35:14 CEST] <rcombs> BBB: not in my experience [14:35:19 CEST] <BBB> strange... [14:35:24 CEST] <BBB> well life sucks :-p [14:37:31 CEST] <rcombs> but if()ing around the ASM call with __builtin_constant_p works [14:38:19 CEST] <rcombs> so I guess eliminating blocks gated by compile-time constants isn't considered an "optimization" by gcc [14:59:10 CEST] <iive> the problem is with the yasm assembly. the functions are #ifdef-ed totally and the compiler still looks for them. [14:59:10 CEST] <iive> but hey, it is opensource gcc, you can fix it, if it is not fixed already. [15:13:41 CEST] <iive> if consider binutils and gcc separate, then so be it. [15:15:42 CEST] <Daemon404> nevcairiel, do you have time this week to help out with some parser merges? [15:18:38 CEST] <nevcairiel> i guess so [15:19:05 CEST] <Daemon404> its only a few (like 3) right now, and then a ton of svq3 things i can do on my own [15:19:20 CEST] <Daemon404> im just not entirely familiar with our hevc parser code, which differs [15:19:59 CEST] <nevcairiel> there is a simple rule when dealing with such commits that move code and rename it - dont try to merge the move, instead move our copy of the code so nothing gets lost [15:20:27 CEST] <nevcairiel> although these first 4 commits or so seem rather innocent [15:20:27 CEST] <Daemon404> no i know that [15:20:31 CEST] <nevcairiel> the big work comes after svq3 [15:20:31 CEST] <Daemon404> but ours takes a hevc context [15:20:38 CEST] <Daemon404> which may be problematic [15:20:50 CEST] <Daemon404> since teh plan, afaict, is to merge teh two parsers [15:21:05 CEST] <nevcairiel> dont mix up h264_parse with h264_parser [15:21:11 CEST] <nevcairiel> its an unfortunate naming for sure [15:21:29 CEST] <nevcairiel> parse is just the generic bitstream parser used by the decoder [15:21:34 CEST] <Daemon404> well it seems wrong to have a function nam,e h2645_parse that takes a HEVCContext, no? [15:21:34 CEST] <nevcairiel> not what we consider the "parser" [15:22:50 CEST] <Daemon404> anyway, you can look at that rename commit [15:22:55 CEST] <Daemon404> and tell me if im off base or what [15:23:09 CEST] <Daemon404> i'd rather not do it myself, given im not confident in my analysis. [15:23:30 CEST] <nevcairiel> you mean things like ff_hevc_extract_rbsp taking hevccontext? [15:23:40 CEST] <Daemon404> yes [15:23:49 CEST] <nevcairiel> did you notice how it doesnt use it for shit [15:23:55 CEST] <nevcairiel> except checking if its set for some arcane reason? [15:24:00 CEST] Action: nevcairiel goes to blame around in it [15:24:03 CEST] <Daemon404> it sets a member too [15:24:10 CEST] <Daemon404> right under the check [15:24:20 CEST] <Daemon404> unless i got lost in my blame digging [15:24:31 CEST] <nevcairiel> i dont see it [15:24:37 CEST] <Daemon404> oh it was moved to the nal context [15:24:42 CEST] <Daemon404> it USED to be part of hevccontext [15:24:52 CEST] <Daemon404> i suppose thats why the check was there [15:24:57 CEST] <Daemon404> which, btw, was added in a merge commit [15:24:59 CEST] <Daemon404> with no explanation [15:25:21 CEST] <nevcairiel> the rename is otherwise rather innocent, just strip the hevccontext out of that particular function then [15:25:26 CEST] <Daemon404> let me remove the whole hevccontext thing and send a patch to the ML for review [15:25:34 CEST] <Daemon404> just so there is a "paper trail" [15:25:53 CEST] <Daemon404> i dont want to break soem arcane voodoo. [15:26:15 CEST] <nevcairiel> ff_hevc_split_packet also nonly uses the hevccontext so it can pass it to _extract_rbsp [15:26:19 CEST] <nevcairiel> so its unnedded [15:26:21 CEST] <Daemon404> yes i know [15:26:23 CEST] <nevcairiel> needed* [15:26:40 CEST] <Daemon404> ill send a patch regardless for michael to sign off on. [15:27:00 CEST] <nevcairiel> there is a later patch that makes h264 use this new stuff [15:27:05 CEST] <Daemon404> otherwise maybe something like concating ogg files that have hevc and remuxing to nut may break [15:27:09 CEST] <Daemon404> given the levels of voodoo i see often [15:27:15 CEST] <nevcairiel> which will need more thorough looking since h264 has a bunch of extra magic in there [15:27:22 CEST] <Daemon404> yes [15:27:34 CEST] <nevcairiel> but thats after svq3 [15:27:44 CEST] <Daemon404> theres a lot of stuff before teh really painful bit [15:27:47 CEST] <Daemon404> which was pushed yesterday [15:28:16 CEST] <nevcairiel> https://git.libav.org/?p=libav.git;a=commitdiff;h=8d0cc8ca97678f4ca87948eba… .. thats the one we need to really look out for, was in yesterdays batch i think [15:30:01 CEST] <Daemon404> yes [15:32:54 CEST] <Daemon404> i wish git was able to show betters diffs for whitespace changes [15:33:01 CEST] <Daemon404> but i guess thats not a reasonable expectation [15:33:06 CEST] <Daemon404> (removing an if and reindenting) [15:33:52 CEST] <wm4> huh, git can ignore whitespace when making diffs, is that not enough? [15:34:17 CEST] <Daemon404> it can? maybe im just dumb [15:35:54 CEST] <wm4> git diff -w or so [15:49:38 CEST] <wm4> [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame. [15:49:40 CEST] <wm4> what [15:51:06 CEST] <Daemon404> his mail client is REALLY weird [15:51:13 CEST] <Daemon404> all his replies have the oddest quote style ive ever seen [15:52:17 CEST] <ubitux> the single letter thing? [15:52:34 CEST] <Daemon404> ubitux, like for multiple quote levels [15:52:37 CEST] <Daemon404> instead of >> [15:52:39 CEST] <Daemon404> ir does 2> [15:52:40 CEST] <Daemon404> and 3> [15:52:41 CEST] <Daemon404> and such [15:52:47 CEST] <ubitux> :D [15:52:52 CEST] <Daemon404> and really odd spacing and linebreaks [15:52:54 CEST] <Daemon404> its hard to read [15:53:05 CEST] <ubitux> i vaguely remember yeah [17:54:54 CEST] <JEEB> michaelni: I recommend for http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9779b6262471d553c1ed811ff7… to be backported [17:55:01 CEST] <JEEB> into any actively maintained branches [17:55:12 CEST] <JEEB> should cause some happy customers [17:55:32 CEST] <Daemon404> nobody is happen when they have to use subtitles [17:55:35 CEST] <Daemon404> happy* [17:55:37 CEST] <Daemon404> just ask ubitux [17:55:40 CEST] <JEEB> :D [17:56:20 CEST] <JEEB> difference is result is basically https://i.fsbn.eu/pgs.png [17:56:46 CEST] <JEEB> *in result [17:56:52 CEST] Action: ubitux only see a mismatching background image [17:57:01 CEST] <JEEB> ssshh [17:57:08 CEST] <JEEB> also not taken by me but aanyways [17:57:45 CEST] <ubitux> so what else is there to see? [17:58:01 CEST] <ubitux> stronger contrast below? [17:58:34 CEST] <JEEB> the range is properly widened [17:58:48 CEST] <JEEB> and if there was more color it'd have BT.709 colorimetry instead of BT.601 [18:18:58 CEST] <Angus> Hmm, I'm running into a segfault in av_read_frame [18:20:10 CEST] <Angus> does this make any sense? print *s $33 = {av_class = 0x7ffff2ffe920 <av_format_context_class>, iformat = 0x7ffff3000460 <ff_h264_demuxer>, oformat = 0x0, priv_data = 0x6470e0, pb = 0x646fe0, ctx_flags = 0, nb_streams = 1, streams = 0x645b40, filename = '\000' <repeats 1023 times>, start_time = -9223372036854775808, duration = -9223372036854775808, [18:31:19 CEST] <cone-034> ffmpeg 03Derek Buitenhuis 07master:4791a910c0dc: lavc/hevc_parse: Don't take a HEVCContext [19:14:23 CEST] <jamrial> durandal_1707: can you check "libavcodec/exr : Fix slice threading"? [19:14:48 CEST] <durandal_1707> apply it.. [19:15:33 CEST] <jamrial> alright [19:19:54 CEST] <cone-034> ffmpeg 03Martin Vignali 07master:3ce19882c504: libavcodec/exr: move xsize and ysize to thread data [20:59:35 CEST] <atomnuker> Daemon404: neither clang nor gold supports LTO last time I checked [21:00:14 CEST] <Daemon404> gold supports lto via plugin [21:00:15 CEST] <sfan5> clang doesn't do LTO? [21:00:20 CEST] <Daemon404> which is provided by clang. [21:01:59 CEST] <atomnuker> huh, interesting [21:02:19 CEST] <atomnuker> I wonder how it compares to the incredlibly slow gcc lto [21:02:44 CEST] <atomnuker> (not that I've seen any benefit from using LTO, but oh well) [21:03:11 CEST] <nevcairiel> Daemon404: did you see the error report on the ML about the hevc parse change? [21:03:14 CEST] <atomnuker> I think it did reduce the final size of the libraries though, without symbols [21:03:53 CEST] <rcombs> clang supports LTO [21:04:20 CEST] <rcombs> by having the compiler write LLVM bitcode and the linker work with that [21:05:12 CEST] <Daemon404> nevcairiel, yes i have a patch sending now [21:05:25 CEST] <Daemon404> rcombs, yes via plugin to gold [21:05:56 CEST] <rcombs> Daemon404: or the llvm linker, right? [21:06:07 CEST] <Daemon404> yes, but i dont think youd realistically want to use that. [21:06:14 CEST] <Daemon404> also, i gotta say, the 50 different hwaccels are pretty dang annoying [21:06:21 CEST] <Daemon404> they break easily and are a big pita to test [21:06:24 CEST] <Daemon404> if you even can. [21:06:42 CEST] <Daemon404> do we have a fate box that tests them [21:06:44 CEST] <Daemon404> even just to build [21:07:40 CEST] <nevcairiel> the base hwaccels like vaapi, vdpau dxva2 etc do get build tested, external libraries likely not [21:08:07 CEST] <Daemon404> well qsv is the one ve broken twice [21:08:49 CEST] <Daemon404> it took two weeks for someone to even notice [21:09:02 CEST] <Daemon404> libnut had a faster turn around time. [21:19:22 CEST] <jamrial> why do we have qsv decoders when there are already hwaccels? [21:19:59 CEST] <rcombs> because you can't use hwaccels via the decoder API (e.g. ffmpeg.c) [21:20:37 CEST] <nevcairiel> thats a cheap excuse and you know it :) [21:21:14 CEST] <rcombs> a better question for an API like QSV might be "why do we have hwaccels when there are decoders" [21:26:11 CEST] <rcombs> the qsv hwaccel structs don't actually list any functions, which IIUC means they end up just being wrappers around the decoders [21:28:02 CEST] <nevcairiel> they only exist to allow selecting their pixfmt [21:33:55 CEST] <wm4> yeah, thats annoying [23:37:06 CEST] <rkern> Is there an AWS account I can use to test the videotoolbox encoder on their device farm? [00:00:00 CEST] --- Tue Apr 26 2016

1 0

ffmpeg.log.20160425
by burek 26 Apr '16

26 Apr '16

[02:23:32 CEST] <SnakesAndStuff> what is the format when using the -ss option for 100+ hours into a video? [02:23:42 CEST] <SnakesAndStuff> I get an error when I use -ss 229:00:15 [06:12:54 CEST] <blubee> hi guys I have a question about using ffmpeg to record my desktop [06:13:06 CEST] <blubee> but I feel like this is a little verbose and could be cleaned up a bit [06:13:19 CEST] <blubee> can I get some help with this ffmpeg command [06:13:21 CEST] <blubee> http://pastebin.com/QF9bqyRH [09:05:53 CEST] <t4nk200> Hey, is there a way to change the Presentation Timestamp (PTS) into the Systemtimestamp ? [09:35:00 CEST] Last message repeated 1 time(s). [10:35:43 CEST] <t4nk200> how to manage, that every Stream I start has a synchronised Timestamp? [12:02:49 CEST] <A_> LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOLLLLLLLLLLL [12:02:51 CEST] <A_> so much [12:03:46 CEST] <A_> uhm :/ [12:04:05 CEST] <mad_ady> Hello everyone! [12:04:11 CEST] <A_> hi [12:04:13 CEST] <A_> :D [12:04:19 CEST] <mad_ady> I have a question about ffserver... [12:04:48 CEST] <mad_ady> I managed to get it to stream rtsp from a UVC webcam, but I'd like for the ffmpeg stream to be started only when the client connects via rtsp [12:05:04 CEST] <A_> :/ [12:05:12 CEST] <A_> hmmm [12:05:13 CEST] <mad_ady> right now ffmpeg transcodes 24/7 and the client might connect for 5 minutes in one day [12:05:16 CEST] <mad_ady> and it's not efficient [12:05:31 CEST] <mad_ady> any ideas if it could be done via ffserver? [12:05:36 CEST] <A_> so it like event/trigger for user [12:05:59 CEST] <A_> no idea about ffserver yet, because never use that before ._. [12:06:06 CEST] <mad_ady> yes - user connection starts ffm feed [12:06:26 CEST] <mad_ady> no worries, I'll idle around - maybe somebody know about it [12:06:34 CEST] <mad_ady> will google some more, maybe I missed something [12:07:43 CEST] <mad_ady> I have a possible workaround - listen to ffserver's log file and if I see a client connected, fire up the ffmpeg stream [12:07:50 CEST] <mad_ady> but... it seems rudimentary [12:09:51 CEST] <mad_ady> it's a good thing that ffserver and ffmpeg run on the same system so I can do this [12:13:50 CEST] <JEEB> mad_ady: if you are depending on ffserver be ready to become a maintainer since nobody in the main development team wants to keep it around [12:13:59 CEST] <Prelude2004c> hey everyone good morning [12:14:23 CEST] <JEEB> it's a hack that will break with the next major API bump [12:14:29 CEST] <JEEB> in its current form that is [12:14:49 CEST] <Prelude2004c> having a very strange issue... .thi sis what is happening.. i have a channel being encoded.. and i set PVR to record a show... for some reason after i do the playback on the show... the segments are 6 seconds long.. basically the playback is -6 so it only plays for 6 sends from the end... odd.. its like end of file is at 0 and beginning i have no idea.. :(.. i dont even know how to explain it [12:40:46 CEST] <Prelude2004c> anyone, any hints? [13:16:36 CEST] <mad_ady> @JEEB: thanks for the warning. I am prepared for ffmpeg api changes since the avconv fork a while ago... [13:31:24 CEST] <mad_ady> @JEEB: can you recommend an alternative to ffserver that can do rtsp? [13:31:56 CEST] <mad_ady> I only need it for signalling, streaming is already done through ffmpeg [14:15:26 CEST] <Carlrobertoh> Hi! I'm writing c++ code for screen casting. I'm able to get the video but it has no timeline? What can cause this? [14:31:44 CEST] <t4nk016> how to add fix_teletext_pts as mpegts option ? [14:44:02 CEST] <Ximon> Hi, How would I go about having a single encoder write to 2 different outputs asynchronously? I'd like record to disk and also transmit an rtsp stream. [14:44:40 CEST] <Ximon> But when the network is interrupted, the recording task is also interrupted. [15:10:15 CEST] <Carlrobertoh> Hi! I'm writing c++ code for screen casting. I'm able to get the video but it has no timeline? What can cause this? [15:10:37 CEST] <cq1> kevin_newbie: Neat accessibility project. I presume you aren't trying to do this in real time? [15:12:39 CEST] <Ximon> Carlrobertoh, What do you mean by "no timeline"? [15:13:09 CEST] <Carlrobertoh> when i open my video in vlc then the video duration is 00:00 [15:13:26 CEST] <Ximon> But it still plays? What codec are you using? [15:13:31 CEST] <Carlrobertoh> H.264 [15:13:34 CEST] <Carlrobertoh> yes it plays [15:13:39 CEST] <Ximon> And what container? [15:14:11 CEST] <kevin_newbie> cql Nop! I got the *.avi or related, and the proper srt. What I can do is read the srt, and voice them with pyvona or other library. but how I say "hey ffmep put this thing with this timestamps" [15:14:18 CEST] <Carlrobertoh> .h264 [15:14:37 CEST] <kevin_newbie> I can use cat for simple concatenation, not more than that :S [15:16:46 CEST] <Ximon> Carlrobertoh, Sounds like you're writing a raw h264 stream to a file without a container, metadata like video duration is normally written to a container (e.g MPEG4, Matroska), [15:17:39 CEST] <Ximon> Carlrobertoh, What command are you using? [15:17:53 CEST] <Carlrobertoh> i'm writing a code [15:17:57 CEST] <Carlrobertoh> i dont have a command [15:18:27 CEST] <Carlrobertoh> but i could send my output [15:20:22 CEST] <Carlrobertoh> http://www.upload.ee/image/5757630/ffmpeg.png [15:20:31 CEST] <Carlrobertoh> i dont know if that helps [15:21:34 CEST] <Ximon> Can you pastebin the entire output? [15:25:40 CEST] <kevin_newbie> how can i set the ffmepg to sync hundreds of audio_clips in one file? [15:32:58 CEST] <Prelude2004c> hey.. anyone here familair with segmentation on ffmpeg ? [15:33:02 CEST] <Prelude2004c> i need help with that. [15:33:06 CEST] <Prelude2004c> having a very strange issue... .thi sis what is happening.. i have a channel being encoded.. and i set PVR to record a show... for some reason after i do the playback on the show... the segments are 6 seconds long.. basically the playback is -6 so it only plays for 6 sends from the end... odd.. its like end of file is at 0 and beginning i have no idea.. :(.. i dont even know how to explain it [15:34:58 CEST] <BurnerGR> kevin_newbie, do you mean concatenate hundreds of audio_clips in one file? [15:39:17 CEST] <cq1> kevin_newbie: This is my first day in #ffmpeg in about four years. Four years ago when people would come in and ask to concatenate clips they'd just get laughed at -- it was so broken. Maybe concatenation and mixing works now, but back then the solution would pretty much be to decode all the audio yourself, mix it yourself as a big raw file, and re-encode. You should see what others say. [15:40:18 CEST] <Carlrobertoh> Ximon, it practically is entire output [15:45:41 CEST] <kevin_newbie> BurnerGR the only way I can think to this is "convert to voice each speech in srt" and then bind them together but I want them sync lol [15:48:44 CEST] <kevin_newbie> cq1 This is my 1st day ever here lol and use internet since last millennium :p I'm new to python (almost 4 months). but got stuck with the ffmpeg... [15:50:36 CEST] <kevin_newbie> what I want to know if there's a way to put that audio clip in the same timestamp as the str, and multiply by hundreds of them ... [15:51:55 CEST] <kevin_newbie> in the same script to bind in one no-video-but-full-audio-sync-generated-by-my-native-language-subtitles [15:52:26 CEST] <kevin_newbie> I think is this the best explanation lol [16:20:46 CEST] <cq1> kevin_newbie: Can you do all the audio processing yourself? That is, pull all the audio out into one big WAV file, then mix in your clips yourself with python/c++, then re-encode everything? [16:21:01 CEST] <cq1> This solution sort of sucks, but 1) it would work, and 2) I don't know if ffmpeg is good at stuff like this yet. [16:21:59 CEST] <cq1> Then you can also have a lot of manual control over how it's mixed. You could do ducking, and quiet the main track when your audio comes in. [16:26:03 CEST] <kevin_newbie> cq1 I can't follow all your steps, because I never done that before. what I can do is pick the lines from the str, use an API to convert that text to voice, and name the files with the timestamps I found on the srt I think lol :) then your steps/instructions are implemented? lol [16:32:56 CEST] <kevin_newbie> I don't want to make another job obsolete for humankind lol, neither to replace the original audio-track of the movie, just generate a synchronized audio-file in my native-language, therefore my grandfather can see the movie, and listen the translation with some earphones.... [16:33:43 CEST] <kevin_newbie> cq1 do you totally understand this ? lol [16:34:29 CEST] <furq> kevin_newbie: https://docs.python.org/2/library/wave.html [16:34:52 CEST] <furq> i imagine you can just seek to the right point and write [16:35:07 CEST] <furq> the only issue would be timestretching any of the wavs which are too long [16:35:20 CEST] <furq> or delaying the next one [16:36:38 CEST] <cq1> kevin_newbie: What I'm suggesting is a rather brute-force crappy solution. You could load WAVs with the module furq linked, and do all the mixing yourself in one big scratch WAV file. Alternatively, you could transcode to WAVs, then merge in each clip with the ffmpeg filters amerge and apad. I suspect you might only be able to merge in one clip at a time though, so it might be O(n^2) time to apply ffmpeg n times to merge in your n clips [16:36:58 CEST] <furq> doing this with ffmpeg sounds absolutely awful [16:37:17 CEST] <furq> aside from the muxing bit at the end [16:38:11 CEST] <kevin_newbie> lol the ffmeg it's until now the only magic tool i here aware of... [16:38:43 CEST] <kevin_newbie> I'll try to understand the wave module [16:39:35 CEST] <kevin_newbie> furq, and cq1 thanks, but probably I'll pitch you later lol [19:26:19 CEST] <DanielMan> Greetings, I'm banging my head against a problem that, by all the documentation I've read *seems,* like it should work: create a side by side mosaic of two webcam inputs. One consistantly lags behind the other by about 1 second no matter what options I try. [19:26:21 CEST] <DanielMan> http://pastebin.com/VDRwci5S [19:26:46 CEST] <DanielMan> Any help or point in the right direction on where to learn what I'm doing wrong would be grad. Thanks! :) [19:27:26 CEST] <DanielMan> Grand, rather. [19:29:34 CEST] <DanielMan> Incidently ... in the paste, I'm feeding a v4l2loopback at /dev/video3 [19:30:46 CEST] <DanielMan> I have experienced the same delay if I route the output to a file. [19:49:34 CEST] <prelude2004c_zzz> hey guys.. sorry to be a bother.. anyone know why..#EXTINF:6.286700, wsbkhd2M26640.ts #EXTINF:6.006000, wsbkhd2M26641.ts #EXTINF:5.989322, wsbkhd2M26642.ts #EXTINF:6.006000, wsbkhd2M26643.ts .. anyone know why the lenght keeps changing ? [19:49:44 CEST] <prelude2004c_zzz> any way to force it to always be 6 for example instead of .xxxx [19:57:00 CEST] <DHE> your video must have constant keyframe intervals. perhaps set -x264opts no-scenecut [19:57:16 CEST] <DHE> and constant FPS, obviously [20:02:28 CEST] <DHE> using the new codecpar, how do I get the pixel format of a video? eg: AV_PIX_FMT_YUV420P I can't find it after doing avformat_find_stream_info [20:03:35 CEST] <DHE> ran a "git pull" and my custom application just broke into pieces [20:04:16 CEST] <JEEB> then there's a high chance it was using something internal [20:04:31 CEST] <JEEB> you should still have avcodec context available to you from the external APIs [20:04:51 CEST] <JEEB> as far as I can see the demux/decoding example wasn't changed at all f.ex. [20:04:52 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/demuxing_decoding… [20:06:07 CEST] <DHE> all I did was the register calls, avformat_open_input, avformat_find_stream_info, then examine the output in the debugger [20:06:33 CEST] <DHE> avfctx->streams[0]->codec->pix_fmt was AV_PIX_FMT_YUV420P before pulling, AV_PIX_FMT_NONE afterwards [20:07:04 CEST] <DHE> I've used the examples as a main reference, yes [20:08:54 CEST] <DHE> I should bisect this.. [20:10:08 CEST] <JEEB> for more details can you note your container and video format? I'm trying to check how ffmpeg.c is outputting the input pix_fmt [20:11:37 CEST] <DHE> container input is mpegts (UDP source), codecs are MPEG2video and AC3 audio (5.1 surround) [20:12:10 CEST] <DHE> I'll still try bisecting [20:12:41 CEST] <JEEB> ok, seems like ffmpeg.c checks input_stream->decoding_needed [20:12:52 CEST] <JEEB> and avcodec_open2's in case it is needed [20:13:47 CEST] <DHE> so I'm supposed to open the decoder myself and feed it until it's ready/happy? [20:14:00 CEST] <DHE> and avformat_find_stream_info doesn't do that anymore [20:14:31 CEST] <JEEB> I'm trying to make sure of that, but accessing the avctx from avformat could have been a happy accident that worked before [20:18:44 CEST] <JEEB> ffmpeg.c is full of random hacks that you definitely shouldn't take example from but this decoding_needed thing doesn't even seem too new [20:20:28 CEST] <john32> Hello guys. I have a small issue with ffplay which I hope someone may be able to help with! I've been trying stuff for almost a full day without success! I have a 4k monitor and am trying to play a video feed in 1080p. Problem is, as soon as I go full screen, the image is zoomed hugely. How would I force the video to be the correct size?? [20:26:41 CEST] <JEEB> DHE: related to that thing [20:26:42 CEST] <JEEB> 21:20 <@Daemon404> codec->pix_fmt was supposed to keep working after codecpar (it is, in fact, synced with codecpar) [20:26:45 CEST] <JEEB> some shit [20:26:47 CEST] <JEEB> 21:20 <@Daemon404> it depends if he's expecting to update it during decode or [20:27:07 CEST] <JEEB> tl;dr please provide sample and either result from ffmpeg.c or a small C sample [20:29:33 CEST] Action: DHE is finishing up a bisect... [20:33:12 CEST] <JEEB> anyways, I recomend dumping the mpeg-ts with something like tcpdump or vlc's dump mode [20:33:16 CEST] <JEEB> and testing with that [20:33:22 CEST] <JEEB> so that you're testing with the same sample all the time [20:34:04 CEST] <DHE> ... that's a good point [20:34:14 CEST] <JEEB> and I would guess ffmpeg.c finds the pix_fmt just fine? [20:39:44 CEST] <DHE> ffprobe is reading the file just fine.. [20:40:27 CEST] <JEEB> what about just ffmpeg -i hurr.ts [20:42:06 CEST] <DHE> yes that works. everything looks fine in the output [20:42:18 CEST] <JEEB> ok, so it's up to your API usage then [20:42:49 CEST] <JEEB> basically at this point the best way to go forward is to provide a sample and a piece of code and that can then be checked [20:43:05 CEST] <JEEB> either you're doing something wrong, or there's something broken in FFmpeg [20:56:06 CEST] <ferdna> why does my video feed is not live... [20:56:19 CEST] <ferdna> i mean its like real time [20:59:34 CEST] <DanielMan> What are you trying to accomplish ferdna and how is your output not as expected? [21:00:06 CEST] <ferdna> DanielMan, i move my ipcam to record another source like a tv [21:00:16 CEST] <ferdna> but it is not realtime [21:00:31 CEST] <ferdna> it takes a few minutes to get to where the tv is at [21:02:00 CEST] <DanielMan> sound like you are washing everything though a buffer before outputing it. does your command specify a buffer or have you tried -fflags nobuffer? [21:02:13 CEST] <furq> ferdna: pastebin your ffmpeg command [21:02:18 CEST] <ferdna> one sec [21:03:11 CEST] <DHE> .... great, I can't reproduce in anything except this program.... how is that happening? [21:03:40 CEST] <ferdna> DanielMan, furq: http://pastebin.com/hMw8TbgR [21:09:15 CEST] <ferdna> any ideas? [21:09:17 CEST] <DanielMan> ferdna: I'm not familiar with ffserver though it seems like you need to specify that ffserver have at the very least a smaller buffer if you want more real time performance. [21:09:29 CEST] <ferdna> ohhh [21:11:36 CEST] <DanielMan> that 250M file may be where this is happening. it seems like by default it wants to preserve every frame so it uses a buffer to accumulate enough to accomidate for interuptions. [21:12:54 CEST] <DanielMan> try lowering the FileSizeMax? It might not give you real time performance, but at least a shorter delay to start off with. [21:13:40 CEST] <ferdna> what would be a good value? [21:14:32 CEST] <DanielMan> try something like 0 and see if you can trick it into jsut passing everything along, other wize start at say 10M and fiddle with it. [21:14:47 CEST] <Wader8> hello [21:14:47 CEST] <DanielMan> what is your desired performance that you are trying to schive? [21:14:52 CEST] <Wader8> i had a realization today [21:14:52 CEST] <DanielMan> hello there. [21:15:12 CEST] <DHE> JEEB: I tried making a minimal program using the same code as I use for the master program and it works, master doesn't... well, off to the races I go [21:15:38 CEST] <JEEB> enjoy the ride [21:16:26 CEST] <Wader8> so the codec authors only make the documentation, they don't actually make the damn codec, i was extremely surprised by this, then it's open up for implementations whoever does it, so a new codec like HEVCs is labeled as "released" but it's "under heavy development" in ffmpeg and other, which is so weird how this industry works [21:16:57 CEST] <ferdna> DanielMan, thank you for the advice [21:17:04 CEST] <JEEB> usually with a standardized thing you get a) the spec and b) the reference implementation [21:17:05 CEST] <ferdna> my goal is real-time [21:17:08 CEST] <Wader8> so all the x264 videos out there aren't even the same codec, 1000 of different flavours of it from around the years [21:17:49 CEST] <Wader8> so they only do a reference, which nobody uses in the end right ? [21:18:05 CEST] <JEEB> many people base upon it, like in the case of HEVC and x265 [21:18:26 CEST] <JEEB> multicoreware just grabbed HM (the reference encoder/decoder) and start trying to optimize it [21:18:58 CEST] <JEEB> they licensed the name from x264 LLC so they also had the right to use x264's code as long as they made a GPL version of what was to become x265 [21:19:03 CEST] <DanielMan> ferdna: no problem. have you seen this? https://ffmpeg.org/ffserver.html#toc-Tips [21:19:06 CEST] <Wader8> so what happens if nobody else does a better implementation, the world stops, all the web streaming would cease to exist, i mean, some people are working so much probably on their own on this, but I can guess companies pay people to contribute, same with linux i heard [21:19:24 CEST] <ferdna> DanielMan, yes been there... [21:20:24 CEST] <DanielMan> the player starting in the past is an interesting option. Not sure if that would have helped you [21:20:27 CEST] <JEEB> anyways, reference implementations are to prove the decisions and make sure things are being improved in the spec. and generally, the spec and the reference implementation should agree. if they disagree, generally the spec wins. sometimes of course mistakes or uncertainties are found in the spec so it's edited and updated with time like with any documentation [21:20:28 CEST] <Wader8> i never understood the H264 and X264 monikers, i usually delete this from these from filenames, but anyway I think X264 is then an implementation of the H264 right ? [21:20:56 CEST] <JEEB> yes, in MPEG terms MPEG-4 Part 10 aka AVC or in ITU-T terms recommendation H.264 [21:21:19 CEST] <JEEB> and x264 is just one of many implementations, although currently clearly one of the best if not the best [21:22:11 CEST] <Wader8> so these international UN-type organizations make these things like that, that codec is released without really being done and silent updates [21:22:22 CEST] <JEEB> eh [21:23:05 CEST] <Wader8> well, what's the point of HEVC if it's going to take 5 years to reach some okay speeds and maturity [21:23:31 CEST] <JEEB> same was done with AVC [21:23:35 CEST] <Wader8> I have here some stuff, im just going to mux old DVDs into MKV with MPEG2 intact, since I'm tired of bothering 15 hours for HEVC [21:23:38 CEST] <JEEB> it took years for the implementations to improve [21:23:52 CEST] <JEEB> and yes, encoding with x264 used to be slow in '06 or so [21:24:02 CEST] <JEEB> it's nowadays that we really tend to forget how time goes by [21:25:34 CEST] <Wader8> I believe this whole stagnating development non-GPU type of transcoding "taking 10 years" to reach multicore CPUs even is kind of a really broken type of system imo, but im not the expert, I just don't think these UN-type international European Union-type organizations should be given this much credit [21:25:47 CEST] <JEEB> ahahahaha [21:25:51 CEST] <JEEB> excuse me [21:26:23 CEST] <JEEB> but you have no idea of how video compression works if you think that for nice compression formats GPU encoding with the actual GPU thing will be of any help speed-wise [21:26:56 CEST] <JEEB> GPU encoding with the actual GPU is something that you need to specifically design formats for. I'm pretty sure ATi/AMD did that at one point. But the point is, that's not geared for compression [21:27:04 CEST] <Wader8> well what, come on, it's 2016 and there's no proper codec with GPU support, only some god knows where nvidia encoder which is probably outdated ..etc [21:27:12 CEST] <JEEB> because GPUs require *threading* . *massive* threading [21:27:31 CEST] <Wader8> you know, there's no native GPU support in x264 or 5, and I don't have NV card [21:27:54 CEST] <DHE> nvenc actually uses a dedicated encoder chip. running nvenc has no impact on CUDA, opencl or 3d games [21:27:55 CEST] <JEEB> and that is something you just can't get when you are designing a format around actual compression due to having references all over the place :P [21:28:19 CEST] <Wader8> it's been 15 years since x264 came to use so how can't they even have basic GPU support [21:28:21 CEST] <JEEB> aka you have dependencies all over the place and thus you can't freely multithread on the level that GPGPU requires [21:28:44 CEST] <DHE> Wader8: there is opencl support. whether it provides any benefit is workload dependent. I've seen 20% speedups, I've seen it run SLOWER [21:28:45 CEST] <JEEB> tl;dr the *format* has to be made from the ground up for such usage, and *compression* is not something you get out of that [21:29:05 CEST] <JEEB> DHE: also the opencl stuff is a proof of concept as well as only ME lookahead I think? [21:29:24 CEST] <JEEB> because it's one of the few things that could be run separately from the encoding itself [21:29:32 CEST] <Wader8> i read the ffmpeg docs that -hwaccel only works in conjunction with the nv_enc codec, if that is old or still ok info [21:29:55 CEST] <Wader8> and opencl would only affect some filters, not really the core of the encoding process [21:30:02 CEST] <Wader8> is what I heard [21:30:12 CEST] <kepstin> Wader8: nvenc is modern and maintained, but it doesn't use gpu compute - it uses a separate dedicated hardware encoder/decoder implemented on the gpu die [21:30:31 CEST] <JEEB> not really a filter but lookahead for the motion estimation, yes [21:30:32 CEST] <DHE> JEEB: sounds about right. offloading some jobs. CPU still keeps plenty busy [21:30:50 CEST] <JEEB> because the lookahead can be run separately from the main encoding processing [21:31:00 CEST] <Wader8> kepstin, i get it, the one NV added specifically for this, but, does it use the whole GPU to assist, or just that area on the die ? [21:31:15 CEST] <JEEB> they implemented an AVC encoder on the die in an ASIC [21:31:29 CEST] <JEEB> you get exactly what they did in hardware, nothing more nothing less [21:31:32 CEST] <DHE> Wader8: there is a distinct encoder chip on some GPUs. nvenc will fail if that chip is not present on your graphics card [21:31:36 CEST] <Wader8> JEEB, but there's much more than just lookahead in the encoding process ? [21:32:11 CEST] <jkqxz> So did everyone else. Pretty much every SoC you can buy for putting in phones or whatever has H.264 encode and decode hardware on, as does every modern CPU. [21:32:14 CEST] <DHE> JEEB: a GPU consists of a 500+ core CPU with almost no inter-CPU communication [21:32:43 CEST] <DHE> (this is a good way to imagine it) [21:32:56 CEST] <JEEB> Wader8: yes - it was picked for GPGPU because it could be run separately and wouldn't negatively affect the encoding process as long as you could upload images there and back to/from the GPU fast enough (and thus as long as it was running in front of the main process) [21:33:10 CEST] <JEEB> that is because of the limitations of an actual GPU's architecture :P [21:33:29 CEST] <JEEB> as I said, if you want to have something optimal to be done on the GPU, you have to design the format from the ground up for GPUs [21:33:35 CEST] <JEEB> and that means removing compression [21:33:42 CEST] <DHE> and possibly a limitation of implementing encoding in x264 which is already a mature product. conversion to GPU-style encoding paradigms probably means a major rewrite [21:34:06 CEST] <JEEB> because you implicitly gain dependencies on data like other reference frames when trying to do a high compression format [21:34:24 CEST] <Wader8> jkqxz, it has the hardware support, whatever that means, in practise does it really use the whole chip to assist, or only a dedicated area on the chip, is the big question, because if it's not the whole chip, it means that another chip is plasted on like an addon which is a total difference, it's not going to use the total horsepower of the main chip that is branded and has a name [21:34:45 CEST] <JEEB> yes, it's a completely separate ASIC part of the GPU or CPU die :P [21:35:01 CEST] <JEEB> usually just plastered together with the media segment of it [21:35:12 CEST] <Wader8> okay, so that's more like "half-baked GPU-Assisted" [21:35:30 CEST] <jkqxz> It ends up attached to the GPU bits because it wants all of the same memory management, but it won't actually use the GPU cores. [21:35:38 CEST] <DHE> it's still "offload", just to a video encoder chip rather than the GPGPU chip [21:35:55 CEST] <DHE> remember, nvidia wanted people to stream their games. making the encoder separate means no gaming performance loss [21:36:04 CEST] <JEEB> as I've been trying to say for quite a while now, unless GPUs suddenly change in how they work they're just not the tool for the trade for high compression aimed formats [21:36:14 CEST] <iive> see, you can consider the vga and 3d computations a completely separate parts of the GPU [21:36:15 CEST] <JEEB> so trying to expect that from GPUs is just dumb [21:36:42 CEST] <JEEB> please try to read what I've noted and do some research if my words aren't convincing enough [21:36:45 CEST] <iive> the video de/encoding is just another separate part. [21:37:44 CEST] <Wader8> DHE, but then, less area for GPU stream processors, it's really a point of view, and they take the one that has a more customer appealing type of marketing view [21:38:32 CEST] <DHE> umm.. they can build the chip however they want. they can just make it bigger for the additional space needed [21:39:16 CEST] <jkqxz> The thing is mostly bounded by power consumption anyway. Using dedicated hardware to do the video is a massive gain there, you would use at least an order of magnitude more power using the GPU cores to do it. [21:39:18 CEST] <Wader8> but see, they don't, every time there's a new nanometer, there's all talk about shrink and "saving power, saving lives, saving CO2, saving private ryan, saving money, saving saving saving" [21:39:30 CEST] <iive> well, game consoles nowdays record the gameplay in real time all the time. So you can save your last 5 minutes is something interesting happens [21:39:48 CEST] <DHE> yeah, probably with a similar chip involved [21:39:51 CEST] <Wader8> oh i forgot saving wales [21:39:56 CEST] <Wader8> whales* [21:40:10 CEST] <DHE> but in your PC/laptop you can have an HD video conference and let the GPU chip encode the camera video [21:40:45 CEST] <Wader8> I guess GPGPU support is such a big deal then, that these ITU people don't tackle it or what [21:41:30 CEST] <Wader8> JEEB, oh you mean GPUs aren't the type of chips suited for these caluclations, i guess that's fair [21:42:18 CEST] <JEEB> calculations are one thing, but then you have to see how good the architecture of thing you're trying to use is suited in the overall picture, including how threadable all parts of your thing are [21:42:26 CEST] <Wader8> But I don't get why on the CPU it's already such a problem, these SSE MMX stuff is there for ages haven't they figured it all out already [21:42:31 CEST] <jkqxz> They tackle it perfectly - they make a precisely-specified standard which everyone else can implement hardware for, such that they all interoperate. That's exactly what they're there for. The reference implementation is mostly irrelevant, though it is convenient for testing. [21:43:02 CEST] <JEEB> because it's a new format and it's a new thing to optimize!? [21:43:06 CEST] <iive> Wader8: see, intel also have decoder/encoder on the cpu, [21:43:23 CEST] <iive> it is just that they also have a full vga on it too. [21:43:25 CEST] <JEEB> both psychovisually and speed-wise [21:43:50 CEST] <JEEB> if I took you 10 years into the past you'd be saying the same about x264 [21:44:06 CEST] <JEEB> '06 and athlon XP running hot encoding with slow x264 parameters [21:44:07 CEST] <Wader8> iive, so all these years, CPUs and GPUs were never the type of chips suited for codec calculations ? [21:44:18 CEST] <JEEB> or maybe even a k8 [21:44:31 CEST] <Wader8> Can somebody make a Codec Chip PCI-E card then ? [21:44:35 CEST] <iive> hey, you don't need new format. MPEG2 is quite easy to decode in parallel, because each row is separate slice. [21:44:38 CEST] <kepstin> well, cpus are by definition general-purpose, which means they don't particularly excel at anything [21:44:56 CEST] <kepstin> Wader8: sure, nvidia sells those, and you get a gpu too! [21:44:58 CEST] <jkqxz> Wader8: Yes. Separate DSPs for video coding have existed for years. [21:45:25 CEST] <Wader8> jkqxz, but not as big as a GPU 300mm2 core ? [21:45:40 CEST] <iive> yeh, i've read that radeon 9500 have both decoder and encoder. [21:46:23 CEST] <JEEB> also the separate chips aren't much better until the people who make them learn how that format can be efficiently implemented. the format doesn't change, but research gets done in how the quality per bit part can be improved :P [21:46:27 CEST] <kepstin> given that the encoder chip is a relatively small part of the gpu core - and similar encoder blocks are used on e.g. cell phone chips, it should be possible to stuff quite a few on a dedicated chip... if you could sell enough of them to make it worthwhile. [21:46:28 CEST] <Wader8> what does Radeon R7 370 have ? [21:46:36 CEST] <Wader8> if someone knows off the head, i can look up later [21:47:24 CEST] <Wader8> kepstin, nobody making them so obviously nobody's buying them, imo [21:48:01 CEST] <iive> there were some dedicated decoders on pcmpci cards [21:48:09 CEST] <iive> ffmpeg even still supports one of them. [21:48:11 CEST] <kepstin> i'm kind of curious about how well throwing an h264 encoder on an fpga would work [21:48:13 CEST] <Wader8> and I think it would be sold, compared to all the crap that get's done and still sells [21:48:13 CEST] <jkqxz> Yes. I mean things like embedded fixed-point DSP chips (TI C6000 and the like). [21:49:15 CEST] <Wader8> kepstin, isn't it a bit disturbing that nobody tried this yet, i mean, from the community of all the conversion-heads out there, I'm like the lowest guy on the totem pole and I'm the first one with this idea ? [21:49:19 CEST] <anadon> I can't seen to get non-corrupted frames in decode.cpp:decodeToFrames() [21:49:19 CEST] <anadon> https://github.com/anadon/youtubeFS/blob/master/decode.cpp [21:50:34 CEST] <Wader8> not saying im the one, just saying how I'm thinking out of the box but i'm not even converting stuff for very long or knew how [21:52:53 CEST] <jkqxz> Wader8: By dedicated chips doing a lot of video encode, perhaps you are thinking of something like <http://www.ambarella.com/products/security-ip-cameras#S5>? [21:53:57 CEST] <Wader8> Why don't the GPU manufacturers throw this on the GPUs, is it really such a niche and a cost ? [21:54:00 CEST] <iive> Wader8: fpga have been done. after all you need to do it before going to asic [21:54:11 CEST] <carli> Hey, sorry for this quick question! What could be wrong with converting Online GIF to MP4, I get error: Input/output error. If I save this gif beffore converting it then works just fine. [21:55:01 CEST] <Wader8> what is this AMD Drag and Drop Transcoding thing then ? [21:55:17 CEST] <jkqxz> Noone actually needs more than one stream of 1080p60 or so, except for people who are prepared through the nose for bigger chips. It's like why Intel don't bother making consumer parts with more cores, which they could trivially do. [21:55:56 CEST] <Wader8> if there's so many version of x264, how does the HW support then account for the future versions, just throws out in error ? [21:56:37 CEST] <furq> what? [21:56:51 CEST] <DHE> JEEB: I've found out what's wrong. avcodec_open2 is failing on the decoder because... and I don't know how, the codec has some fields out of order and it looks like an encoder instead... [21:56:52 CEST] <Wader8> jkqxz, im more talking about making a card specifically for encoders and the TV/Internet industry, what do they use, ofcourse, they just throw a server farm at it [21:56:58 CEST] <DHE> so clearly something's gone catastrophically wrong somewhere [21:57:06 CEST] <jkqxz> H.264 has been fixed completely since 2005. There have been a few extensions (SVC, MVC), but the base stuff is static. [21:57:29 CEST] <furq> the tv industry is largely still using mpeg-2 [21:57:49 CEST] <furq> they have no use for a pci-e card full of h.265 encoder asics because practically nothing can decode it yet [21:57:52 CEST] <jkqxz> Wader8: Yes, those things all exist. You pay through the nose for them. They are not consumer products. (See link above, say.) [21:58:18 CEST] <furq> and you can encode a lot of concurrent h.264 streams on a halfdecent server cpu [21:58:32 CEST] <Wader8> okay ... [21:59:36 CEST] <Wader8> furq, well, for my case, im archiving, so I look at quality and size, not for streaming, so I use "slower" speed [21:59:55 CEST] <furq> if you're looking at quality then you don't want to use a hardware encoder anyway because they're all optimised for speed [21:59:57 CEST] <Wader8> which is around 5 FPS per second [22:00:28 CEST] <sfan5> 5 frames per second per second [22:00:39 CEST] <Wader8> furq, optimized for speed, hmm, so this is getting really complex now, [22:00:41 CEST] <furq> i'm sure it's possible to make a hardware encoder which is as good as x264 veryslow but i'm not aware of such a thing existing [22:01:01 CEST] <furq> nvenc/qsv/whatever the amd one is called that nobody supports certainly aren't anywhere near that good [22:01:09 CEST] <furq> vce? [22:01:17 CEST] <Wader8> not only is the software config defining how my video is going to look, but then the HW will also affect the quality, i see this as a weird design [22:01:45 CEST] <furq> it's no different from using two different h.264 encoders [22:01:45 CEST] <Wader8> the HW should just claculate, what the software tell em, not have some fixed stuff in HW that overrides software, [22:02:04 CEST] <furq> so you want a software hardware encoder? [22:02:07 CEST] <Wader8> isn't that simpler [22:02:19 CEST] <furq> i've got one of those on my motherboard [22:02:51 CEST] <Wader8> the HW just do calculations, let the quality/speed be decided by, this "optimized for speed" on HW just seems like a shortcut to me, doesn't please both camps [22:03:13 CEST] <Wader8> with the term software, im referring to the codec [22:03:40 CEST] <ferdna> why do i get this warning: [22:03:41 CEST] <ferdna> Setting default value for video bit rate tolerance = 128000. Use NoDefaults to disable it. [22:05:25 CEST] <furq> i expect the majority of the reason for nvenc's existence is people streaming themselves playing bad indie games on twitch [22:05:44 CEST] <furq> all those people care about is that it doesn't make their framerate drop from 98 to 97 [22:05:58 CEST] <furq> or from 15 to 14 if it's a unity game [22:06:04 CEST] <DHE> JEEB: issue identified. a major miscompilation... [22:14:14 CEST] <DanielMan> ferdna are you using ffserver with mpegvideo format? [22:14:32 CEST] <ferdna> no. [22:14:35 CEST] <ferdna> using ffserver yes [22:14:47 CEST] <ferdna> DanielMan, this is what i want to do [22:14:58 CEST] <ferdna> get video from a ipcam... and stream it to webm format [22:15:04 CEST] <ferdna> which i am able to do it [22:15:09 CEST] <ferdna> but not in real time [22:15:13 CEST] <ferdna> i am doing something wrong [22:16:06 CEST] <DanielMan> have you sen this bug report? does if fit your scenario? [22:16:20 CEST] <ferdna> no i havent seen it... [22:16:25 CEST] <ferdna> i wouldnt know if it fits or not [22:16:31 CEST] <DanielMan> https://trac.ffmpeg.org/ticket/4794 [22:18:18 CEST] <ferdna> DanielMan, i am not using mpegvideo [22:19:01 CEST] <DanielMan> ok, well, at least we eliminated some low hanging fruit [22:19:33 CEST] <ferdna> lol [22:19:40 CEST] <DanielMan> What was the result of lowering the FileSizeMax? [22:23:33 CEST] <DanielMan> will a shorter delay fit your needs? I'm not sure how "realtime" you can possibly get with this many layers of translation in the mix. [22:25:16 CEST] <DanielMan> raw->encode->UDP->recode to webm->*shrug*->decode [22:27:16 CEST] <ferdna> DanielMan, do you have other solution for this? [22:27:20 CEST] <DanielMan> mh point being that if you point your cam at a stopwatch and view the output in this system next to the stopwatch, I"m not sure how low you can really get that. [22:27:34 CEST] <ferdna> i dont have to recode [22:27:39 CEST] <TD-Linux> if you need very low delay the usual solution is RTP (or things that use it like WebRTC) [22:27:44 CEST] <ferdna> i just need to stream incoming video from theipcam [22:28:46 CEST] <prelude2004c_zzz> hello boys and girls.. question... i am doing ffmpeg -i $stream&overrun_nonfatal=1.... -f mpegts - | ffmpeg -i - something else..... i have found a problem where sometimes when the first input looses data it stays on because i am running the &overrun_nonfatal=1 but the second one seems to end.. is there any way to make sure the ffmpeg -i - stays alive and waiting for new data ? something like " ffmpeg -i -&overrun_nonfatal=1 .. would [22:28:47 CEST] <prelude2004c_zzz> that even work ? [22:35:19 CEST] <Isaac> just gonna throw this out here: anyone got a resource that explains -rc-lookahead or -lag-in-frames? IŽm having trouble really getting it. [22:35:39 CEST] <ferdna> DanielMan, do you have any config for h264? [22:43:11 CEST] <DanielMan> in what context? [22:43:48 CEST] <prelude2004c_zzz> anyone have any input ? [22:47:36 CEST] <DanielMan> I have not had experience with the issue you are having prelude2004c_zzz [22:47:40 CEST] <ferdna> DanielMan, [22:47:46 CEST] <DanielMan> perhaps you can help me with this ... http://pastebin.com/VDRwci5S [22:47:54 CEST] <ferdna> i need to take h264 from a ipcam... to the same format [22:48:37 CEST] <DanielMan> one camera consistantly lags a few second behind the other where I need them to be within a few miliseconds of eachother for a machine vision application [22:50:40 CEST] <DanielMan> did you try modifying the FileSizeMax or switching you stream protocol to RTP? [22:50:49 CEST] <furq> ferdna: does it need to be over rtsp [22:50:57 CEST] <ferdna> not really furq [22:51:06 CEST] <ferdna> any method is ok [22:51:22 CEST] <furq> i'd advise against using ffserver because it's unmaintained and likely to be removed in a future version [22:51:31 CEST] <furq> and also it's generally a bit crap, and iirc it forces you to reencode [22:51:32 CEST] <ferdna> furq, what do i use then? [22:51:48 CEST] <furq> rtsp would be fine but i don't have a recommendation for another rtsp server [22:51:57 CEST] <furq> i do have a recommendation for a good rtmp server, if that works for you [22:52:10 CEST] <ferdna> i dont know what that ir or the difference [22:52:11 CEST] <furq> you could just send the h.264 stream directly to that [22:52:23 CEST] <furq> rtmp is what flash media server uses [22:52:35 CEST] <furq> https://github.com/arut/nginx-rtmp-module [22:52:37 CEST] <DanielMan> Have you looked at VLC? [22:52:39 CEST] <furq> a lot of people in here use that for streaming [22:52:48 CEST] <ferdna> ohh cool [22:53:01 CEST] <furq> it does hls as well but if you need low latency then that's not much good [22:53:06 CEST] <ferdna> i guess i'll stick to ffserver for now [22:53:09 CEST] <furq> otherwise you need flash or a desktop player [22:53:25 CEST] <furq> s/desktop/standalone/ [22:54:01 CEST] <furq> i feel a bit like a broken record recommending nginx-rtmp so much, but i'm yet to see anyone recommend anything better [22:54:22 CEST] <ferdna> i see [22:54:24 CEST] <ferdna> no worries [22:55:38 CEST] <DanielMan> Hope that helps you, sorry I couldn't be of more help to you. [22:57:30 CEST] <ferdna> no that is okay [22:57:31 CEST] <ferdna> thanks [22:57:52 CEST] <ferdna> furq, you are right: [22:57:52 CEST] <ferdna> That's just because FFMPEG will be dropped in a future Debian release, they're just warning you now not to get too hooked on it and start using AVCONV instead, which is a fork of FFMPEG. [22:58:02 CEST] <furq> er [22:58:02 CEST] <furq> no [22:58:10 CEST] <furq> that's a totally different thing which is thankfully in the past now [22:58:56 CEST] <furq> ffmpeg was dropped from debian a few years ago in favour of libav, but it's back as of the last release [22:59:01 CEST] <furq> and nobody ever spoke of libav again [23:00:32 CEST] <ferdna> ohhh [23:03:16 CEST] <prelude2004c_zzz> thank you daniel [23:03:18 CEST] <pandb> how do I control the speed of a video that i'm encoding? [23:03:56 CEST] <prelude2004c_zzz> anyone else? [23:04:08 CEST] <prelude2004c_zzz> i need to keep the ffmpeg open to listen for stdin without closing [23:04:13 CEST] <pandb> i'm starting out with raw picture data that i run through sws_scale, then avcodec_encode_video2, then finally av_write_frame [23:04:29 CEST] <pandb> the video that's output runs really fast [23:05:36 CEST] <pandb> i've set the time_base fields of the AVStream and AVCodecContext based on my desired frame rate [23:05:36 CEST] <Wader8> hello again [23:05:53 CEST] <Wader8> how do I properly downscale NTSC 720x420 [23:05:59 CEST] <Wader8> a DVD [23:06:10 CEST] <furq> downscale it to what [23:06:17 CEST] <Wader8> and to retain 16:9 DAR [23:06:31 CEST] <furq> don't downscale it [23:06:44 CEST] <furq> leave it at the native res and set the ar in the container with -aspect 16:9 [23:06:53 CEST] <Wader8> don't worry it's for something else, not meant as a main thing [23:06:54 CEST] <pandb> and after avcodec_encode_video I increment the pts of the packet [23:07:20 CEST] <pandb> i'm not sure what else I need to do to control the speed of playback [23:07:21 CEST] <Wader8> i'd like it half down [23:07:42 CEST] <furq> i'm not sure what you're asking for then [23:07:48 CEST] <Wader8> it's for some other thing, a sample [23:08:01 CEST] <furq> -s 123x456 [23:08:02 CEST] <Wader8> downscaling the weird 720x420 [23:08:13 CEST] <Wader8> do you understand [23:08:22 CEST] <Wader8> it has nonsquare pixels, i can't just do that [23:09:04 CEST] <DanielMan> prelude2004c_zzz I'm assuming you've tried -timeout? I know that works for for some input types [23:09:06 CEST] <Wader8> I can't use the table for this [23:09:10 CEST] <furq> table? [23:09:37 CEST] <Wader8> doesn't even exist on the table anyway https://pacoup.com/2011/06/12/list-of-true-169-resolutions/ [23:10:09 CEST] <furq> you can downscale to whatever resolution you want if you set -aspect 16:9 [23:10:14 CEST] <Sirisian|Work> Anyone ever experience a http://pastebin.com/bPsnAgcw "PES packet size mismatch"? I have an h264 stream that I'm reencoding to an rtmp stream and noticed that it runs fine for around 10 seconds to 2 minutes then it starts outputting errors and never recovers. [23:10:28 CEST] <prelude2004c_zzz> hum..... i have not [23:10:30 CEST] <Wader8> NTSC and PAL are such a pile of crap man [23:10:35 CEST] <prelude2004c_zzz> can i set timeout 0 as in never ? [23:10:57 CEST] <Wader8> oh i just got a few more DVDs and I get rid of this nonsense [23:11:31 CEST] <prelude2004c_zzz> -timeout -1 [23:11:32 CEST] <prelude2004c_zzz> going to try [23:11:33 CEST] <furq> don't remind me about all these dvds i need to rip [23:11:52 CEST] <furq> all of these hybrid film/video dvds that i need to deinterlace without ruining [23:11:55 CEST] <DanielMan> put it immediatly preceeding the imput you wish to set it for [23:12:02 CEST] <furq> who thought that was a good idea [23:12:47 CEST] <furq> or everyone's favourite, the entirely-shot-on-film dvd with interlaced credits [23:14:01 CEST] <prelude2004c_zzz> does not like -1 [23:14:06 CEST] <prelude2004c_zzz> timeout option not found [23:14:11 CEST] <Wader8> i'm on a run with a big PC cleanup super archival sorting, so I took a shortcut to just mux the DVDs into MKVs, to get rid of the vob segment nonsense, i'll put a low quality failsafe x264 preview version beside it if the DVD MKV won't run 20 years later, ... it's like they designed it to be as annoying as possible [23:15:04 CEST] <furq> that seems pointless [23:15:07 CEST] <Wader8> i'll maybe redo those MPEG2 interlaced stuff [23:15:11 CEST] <DHE> furq: I once heard somene tell me about a video that had a PIP where the main picture was TFF and the PIP was BFF [23:15:14 CEST] <DanielMan> try a positive number like 2000 [23:15:23 CEST] <furq> there is literally no chance of there not being an mpeg-2 decoder in 20 years [23:15:33 CEST] <Wader8> we'll I have other priorities now, need to finish before summer, other stuff then [23:15:34 CEST] <furq> unless there's been a nuclear war [23:15:36 CEST] <DanielMan> anything longer than your longes dropoutbefor eyou seriously consider there is a total failure in conection [23:15:47 CEST] <furq> DHE: that does not surprise me at all any more [23:15:57 CEST] <DanielMan> you're longest dropouts, rather [23:16:10 CEST] <Wader8> like fukushima isn't already half of it [23:16:35 CEST] <furq> you mean that thing where nobody died [23:16:43 CEST] <Wader8> all those californian coast trendies surfing all day, god help them [23:16:44 CEST] <DHE> garbage in, garbage out. that's my motto. I can't fix it if you give me this garbage. [23:16:56 CEST] <prelude2004c_zzz> anyone else have any other input ? i can't get ffmpeg -timeout -1 -i ..... to work [23:17:02 CEST] <prelude2004c_zzz> complains saying timeout is not an option [23:17:04 CEST] <furq> bbc dvds are terrible for wonky interlacing [23:17:15 CEST] <furq> on the plus side it's all pal so i don't ever need to deal with pulldown [23:17:35 CEST] <Wader8> furq, nobody died at fukushima, you kidding me ? [23:17:42 CEST] <furq> no? [23:17:57 CEST] <Wader8> you watch mainstream media only or what, yeez [23:18:04 CEST] <furq> a lot of people died because of the earthquake and the tsunami and the oil refinery that blew up [23:18:15 CEST] <furq> nobody died because of the nuclear plant [23:18:37 CEST] <furq> also that's the opposite of the picture you'd get from the mainstream media which did nothing but go INVISIBLE DANGER for two months [23:18:45 CEST] <Wader8> furq, it's not the topic I personally dug deepest, but others I know did, but I know precisely that the Japanese govt was telling people to drink milk and smile that will make radiation go away [23:19:11 CEST] <Wader8> on national TV [23:19:13 CEST] <q3cpma> Hello, is this normal if ffmpeg spouts errors and produce a different output than mpcdec when decoding a freshly encoded musepack file? [23:19:35 CEST] <furq> q3cpma: pastebin the command and output [23:20:47 CEST] <Wader8> furq, i guess we could settle with "not yet" but, if you get cancer and die 30 years early, are you going to say it wasn't from that ... so that's what I meant [23:20:52 CEST] <q3cpma> furq: http://pastebin.com/XiRJrgLH [23:22:00 CEST] <furq> if mpcdec works and ffmpeg doesn't then it could be a decoder bug [23:22:04 CEST] <q3cpma> Also, the result is different in length compared to mpcdec. (ffmpeg is 00:03:27.104 and mpcdec is 00:03:28.806) [23:22:38 CEST] <Wader8> well okay, but nobody can know the number for sure later, it's just affecting people health it's already taking half your life away i mean, but I hope MPEG2 survives [23:22:40 CEST] <relaxed> q3cpma: see if it happens with ffmpeg git master [23:24:04 CEST] <DanielMan> hey folks, anyone have any inkling as to why this is delaying one webcam by a full second? http://pastebin.com/VDRwci5S [23:24:26 CEST] <q3cpma> relaxed: Happens too. [23:25:03 CEST] <q3cpma> The file plays fine except thos worrying (BIG RED) errors [23:26:35 CEST] <Wader8> Channel Wide Question: FFMPEG docs say that preset speec changes the speed, but it does clearly affect the quality, it's a night and day [23:26:37 CEST] <relaxed> DanielMan: see if using the same demuxer options for both inputs makes any difference [23:26:53 CEST] <DanielMan> I get that it's an obscure one but thank you to those who have been looking at it. :) [23:26:57 CEST] <Wader8> I mean, it explicitly says it doesn't affect quality, i think [23:27:13 CEST] <Wader8> but that's not true, i mean, at leat for x265 and 4 [23:27:14 CEST] <DanielMan> ok relaxed, I'll give that a shot. [23:27:21 CEST] <furq> where does it say it doesn't change the quality [23:29:13 CEST] <Wader8> i would have to find it [23:30:39 CEST] <DanielMan> relaxed: same options repeated for both inputs with no affect in behaviour. [23:31:20 CEST] <Wader8> the web says it's "slightly" but i've seen a massive differente between ultrafast and slower [23:31:35 CEST] <Sirisian|Work> Interesting. My streaming device has something called "Package A" and "Package B" and only Package B works with the h264 stream. The other one seems to be a corrupted stream. [23:31:51 CEST] <Wader8> im forced to use slow method just for the quality, also lower size ofcourse [23:31:53 CEST] <Sirisian|Work> Can't reproduce my previosu error now so that's good. [23:32:23 CEST] <DanielMan> Just to put it out there, I've experienced the same issue with different camera models in pairs. [23:32:42 CEST] <DanielMan> two ps3 eye's and two ELP's [23:33:21 CEST] <q3cpma> I tested with latest musepack-tools too, and nothing has changed. Should I file a ticket? [23:33:55 CEST] <furq> Wader8: the quality will be different at the same crf value [23:34:00 CEST] <furq> if you don't want to use slow then lower the crf [23:35:13 CEST] <Wader8> oh [23:35:25 CEST] <Wader8> well i can't find it right now, it was somewhere in the ffmpeg docs [23:35:36 CEST] <Wader8> but not on the x264 encoding page [23:51:58 CEST] <Wader8> well [23:53:59 CEST] <Wader8> the HEVC recode from DVD is quite good with 1.5 GB less size, and i didn't use MKV, but MP4, so I put it into ACC 448kb/s, is it worth remuxing from DVD the original AC-3 and putting the whole thing into MKV, another problem, the MP4 HEVC has 4 minutes at beginning cut off, how would I do that when copying audio ? [23:54:15 CEST] <Wader8> if you're still here furq [00:00:00 CEST] --- Tue Apr 26 2016

1 0