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

[burek]

[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/Video/MMALCodec.cpp
[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.html
[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#a91bc1a1c1c4a3cc6db54d59705fded0b
[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