[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/Vi... [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.h... [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#a91bc1a1c1c4a... [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