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

[burek]

[00:00:06 CEST] <yvear> wm4, I completely agree
[00:00:30 CEST] <nevcairiel> Just include it in your build, disable the internal decoder, voila, you get what you want
[00:00:34 CEST] <wm4> but probably won't happen
[00:01:28 CEST] <nevcairiel> to make things easier, someone could suggest moving it up in the priority chain, possibly sending a patch as a discussion basis
[00:01:32 CEST] <jamrial> patches to "port" the libdcadec decoding bits into ffdca are very much welcome i'd say :p
[00:01:40 CEST] <nevcairiel> good luck
[00:01:43 CEST] <nevcairiel> the dca decoder is a mess
[00:02:11 CEST] <nevcairiel> without actually understanding both the code and the codec itself, its probably going to be very hard
[00:02:20 CEST] <jamrial> yes, it would basically mean a rewrite of the decoder (the parser seems ok, though)
[00:03:14 CEST] <jamrial> foo86 sent a patch a week or so ago to fix a bug in the parser. maybe he has further plans
[00:04:22 CEST] <nevcairiel> I fixed the same bug differently a few years back, but quite a bit more complex, ie. by actually parsing frame sizes, but it doesnt work in 100% of all cases because it requires access to more than the state variable can carry
[00:04:41 CEST] <nevcairiel> its annoying that it may be conceivable that a parser gets one byte at a time...
[00:06:09 CEST] <nevcairiel> its even more annoying that the dts bitstream allows aliasing of start codes and doesnt have some magic to protect itself
[00:08:23 CEST] <yvear> is the parser the bit responsible for displaying info about the file?
[00:08:49 CEST] <nevcairiel> no
[00:09:19 CEST] <yvear> that's decoder also?
[00:44:32 CEST] <rcombs> nevcairiel: I did suggest that in here
[00:44:38 CEST] <rcombs> nevcairiel: and then someone filed a ticket in trac about it
[00:45:08 CEST] <nevcairiel> two wrong way to start a discussion that is supposed to actually have a constructive outcome. ;)
[00:45:12 CEST] <nevcairiel> *ways
[00:45:31 CEST] <rcombs> kek
[00:45:37 CEST] <rcombs>  <jamrial> but in this case the change allows ffmpeg to link to both 8bpp and 16bpp libraries without having to recompile, so a changelog line sounds good
[00:45:41 CEST] <rcombs> ^ wtb this for libx264
[01:09:07 CEST] <cone-134> ffmpeg 03Michael Niedermayer 07master:3ecc06332238: avcodec/hevc: Fix order of operations in hls_decode_neighbour()
[01:18:43 CEST] <rcombs> nevcairiel: hmm, just looked into how we do this for native RTMP vs librtmp
[01:18:56 CEST] <rcombs> ffrtmpcrypt_protocol_deps="!librtmp_protocol"
[01:19:11 CEST] <rcombs> would that make sense to do here?
[02:37:05 CEST] <baptiste> kierank, you around ?
[04:19:12 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:59db9e694962: avformat/internal: Fix warning about struct declaration
[04:19:12 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:acf4925f4446: tools/graph2dot: use larger data types than int for array/string sizes
[04:41:05 CEST] <BBB> if I set avctx->refcounted_frames = 1, do I own a reference to each frame returned from avcodec_decode_videoN()? or should I take a reference after the function returns?
[04:41:19 CEST] <BBB> (and then release it when Im done with the frame)
[09:09:35 CEST] <wm4> I think you own it
[09:09:49 CEST] <wm4> but you need to have a "fresh" AVFrame for the next decode call then
[10:22:10 CEST] <nevcairiel> rcombs: i think its fine to allow both in one binary, just that codec auto-selection should prefer libdcadec if its enabled .. like someone else argued the other day, if you are going to build with a specific decoding library, its safe to assume that you want it used as well
[10:22:45 CEST] <rcombs> alright, sensible enough
[12:04:58 CEST] <rcombs> ^ that's a weird one
[12:05:45 CEST] <nevcairiel> one thought, the overlay filter doesnt cope with the output timebase change that yadif uses
[12:06:48 CEST] <rcombs> sounds non-absurd
[12:08:47 CEST] <nevcairiel> you could test that theory by putting yadif into the mode that doesnt double the framerate
[12:09:56 CEST] <rcombs> yeah, looking into that now
[12:10:04 CEST] <nevcairiel> hm, apparently that is the default mode
[12:10:07 CEST] <nevcairiel> odd
[12:10:16 CEST] <rcombs> but it looks like vf_yadif always fucks with the time base
[12:10:50 CEST] <nevcairiel> ah hm
[12:15:41 CEST] <rcombs> and I just tried both modes; no difference
[12:15:59 CEST] <cone-429> ffmpeg 03foo86 07master:0670acc4f1c4: dca_parser: Extend DTS core sync word and fix existing check
[12:16:00 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:85bbe1dbd1cc: Merge commit '0670acc4f1c4ceb16968818a654e07a3f550a8c9'
[12:16:10 CEST] <nevcairiel> yeah if it always messes with the timebase it wouldnt
[12:16:25 CEST] <nevcairiel> you could re-order it, use overlay before yadif, but that would slightly degrade quality
[12:18:37 CEST] <rcombs> or I could track down and fix the bug
[12:18:54 CEST] <nevcairiel> don't go crazy!
[12:19:40 CEST] Action: rcombs disregards nevcairiel's advice; goes crazy
[12:24:53 CEST] <cone-429> ffmpeg 03Carl Eugen Hoyos 07master:da5c6a97bbfe: riff: Add MultiScope II fourcc MSC2 as MJPEG
[12:24:54 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:2ce2462ba857: Merge commit 'da5c6a97bbfe34d4b30a89e72150dd400299ddce'
[12:38:47 CEST] <rcombs> nevcairiel: you are, indeed, correct
[12:44:10 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:37efad4e5b66: fate: Test pullup and fieldmatch with 5 instead of 1 frame
[13:33:33 CEST] <cone-429> ffmpeg 03Marton Balint 07master:93cc5ca7ed14: lavf/img2dec: add option to disable pattern matching
[14:04:07 CEST] <Compn> rcombs : does it work with other deinterlacing codecs ?
[14:04:17 CEST] <Compn> er deinterlacing filters
[14:04:19 CEST] Action: Compn wakes up
[14:07:24 CEST] <rcombs> Compn: same issue with kerndeint
[14:09:50 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:94e293a83cd7: avfilter/af_aphaser: reject too small delay
[14:11:16 CEST] <Compn> http://spdblotter.seattle.gov/2015/01/05/a-dazzling-bodycam-video-and-notes-from-our-hackathon/
[14:11:33 CEST] <Compn> interesting bodycam , trying to find out how to redact/censor sensitive materials
[14:14:46 CEST] <ozzay> Hey everyone, I am working on MP4 http streaming software and I've got it working to every browser, except the one of the apple Ipad. I was wondering if someone could help me.
[14:15:11 CEST] <ozzay> The problem is this: an ffmpeg generated MP4 works flawlessly in the Ipad browser, but my MP4 does not. My file uses the same moov box structure, but different stco interleaving and stsc entries. Does Apple require something specific that I am missing here?  Thanks in advance.
[14:17:51 CEST] <Compn> ozzay : i'm guessing yes. there is a mailing list for using the libs in your own program
[14:17:59 CEST] <Compn> if i knew the answer i'd tell you :P
[14:19:02 CEST] <ozzay> Oh well, thank you for trying anyway :)
[14:19:20 CEST] <ozzay> I'll take an extra look at the libs
[14:39:16 CEST] <JEEBsv> ozzay: I recommend comparing stuff with L-SMASH's boxdumper or something
[14:39:34 CEST] <JEEBsv> it will output the file structure in text
[14:42:35 CEST] <ozzay> I will look into that, thanks!
[14:44:34 CEST] <BBB> so if I load a hevc file, avformatctx->duration and avformatctx->streams[i]->duration are both not set, so how do I find the length of the file now?
[14:44:55 CEST] <BBB> (like any .bit file from the conformance suite)
[14:45:29 CEST] <wm4> BBB: is this a raw stream? libavformat can't know the length without reading all frames _and_ having timestamps/frame durations
[14:45:55 CEST] <BBB> what option do I set for that? yes its annexb
[14:46:12 CEST] <wm4> there's none
[14:46:34 CEST] <BBB> I want to call avformat_open_input, avformat_find_stream_info and perhaps some magic third call and it should just work
[14:46:41 CEST] <wm4> haha
[14:46:51 CEST] <BtbN> The information you are looking for is just not present in the file.
[14:46:52 CEST] <wm4> ffmpeg's API is being called terrible for a reason
[14:46:59 CEST] <BBB> BtbN: I know that
[14:47:10 CEST] <BBB> Im quite familiar with video codecs and their raw streams
[14:47:10 CEST] <wm4> you could probably keep reasing avpackets
[14:47:12 CEST] <wm4> and count them
[14:47:13 CEST] <BBB> but Im not using posix
[14:47:15 CEST] <BBB> Im using ffmpeg
[14:47:18 CEST] <BBB> theres a reason for that
[14:47:23 CEST] <BBB> I want $tool to take care of $shit for me
[14:47:32 CEST] <BBB> otherwise I wouldnt use $tool to do $easyTask
[14:48:05 CEST] <BtbN> You want to know the length of a chain of raw frames. Without any timestamps. That information simply doesn't exist.
[14:48:46 CEST] <BtbN> The best you can do is just keep reading frames, until there are none left. Then you know the amount of frames.
[14:49:01 CEST] <wm4> even if it has timestamps, libavformat would do something utterly stupid like guessing the file duration by btirate of the first packets
[14:50:09 CEST] <Compn> BBB : come up with a function that reads the whole file ?
[14:51:07 CEST] <wm4> a full indexing mode would be useful
[14:51:16 CEST] <wm4> but libavformat still can't do anything without frame durations
[14:51:43 CEST] <Compn> lav* libs were originally (afaik) made for video playback. so reading entire files would be slower than guessing. now that people want more of those features, its a good time to add them
[14:51:45 CEST] <wm4> well, maybe it could use frame numbers for timestamps
[14:52:24 CEST] <wm4> Compn: not really, it took a long time until video players (even mplayer) started using libavformat by default at all
[14:52:44 CEST] <BBB> I dont understand any of this
[14:52:50 CEST] <BBB> ivf has no timestamps or nothing
[14:53:05 CEST] <BBB> for ivf, I can simply read frames and it assigns timestamps fine
[14:53:08 CEST] <Compn> wm4 : yes but it was all designed by mplayer devs :P
[14:53:12 CEST] <BBB> why cant annexb do that?
[14:53:23 CEST] <BBB> ignore seeking or duration for now, lets start with just pts
[14:53:33 CEST] <wm4> what's ivf?
[14:53:35 CEST] <BBB> why cant annexb assign pts
[14:53:41 CEST] <BBB> ivf is vp8/9s variant of annexb
[14:53:50 CEST] <Compn> or worked on by mplayer devs. something. its been a while since i looked at early ffmpeg history
[14:54:11 CEST] <BBB> well thats a lie, ivf has some file headers, but anyway, its about as empty as a container gets
[14:54:16 CEST] <wm4> BBB: AFAIK libavformat discards the timestamps in annexb, because nothing uses them at all
[14:54:32 CEST] <BBB> aha
[14:54:38 CEST] <BBB> thats evil
[14:58:42 CEST] <BBB> so without a pts, I should assume seeking doesnt work either, even after indexing?
[14:59:06 CEST] <BBB> and even if I went through the whole file using av_read_frame() manually, the index still wouldnt tell lavf what the duration of the 100% parsed file is?
[15:00:33 CEST] <av500> the index holds iframes only
[15:00:46 CEST] <av500> so the time of the last iframe would be roughly the duration
[15:02:51 CEST] <BBB> painful...
[15:04:33 CEST] <wm4> the index also uses timestamps
[15:04:37 CEST] <wm4> and seeking uses timestamps
[15:04:42 CEST] <wm4> there is no seek by frame number
[15:04:50 CEST] <wm4> you might want to try something like ffms2
[15:05:06 CEST] <BBB> Ill install gstreamer
[15:05:08 CEST] <BBB> like, right
[15:05:16 CEST] <BBB> I dont need 17 wrappers on top of posix
[15:05:39 CEST] <av500> and how does gst get the duration?
[15:05:59 CEST] <BBB> by not using ffmpeg, presumably
[15:06:08 CEST] <av500> well
[15:06:28 CEST] <av500> there's your solution
[15:06:41 CEST] <av500> I bet there is an emacs macro to do it
[15:08:43 CEST] <BBB> < vim user :-p
[15:14:06 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:c3671e1d5760: avformat/riffenc: Use size_t for strlen in ff_riff_write_info_tag()
[15:18:25 CEST] <nevcairiel> BBB: the difference between ivf/vp8/9 and h264/hevc in annexb is that pts in h264/hevc is non-trivial because of bframes :d
[15:21:04 CEST] <wm4> how so? (I know nothing about annexb timestamps)
[15:21:18 CEST] <nevcairiel> annexb doesnt have timestamps
[15:21:22 CEST] <nevcairiel> its a pure raw format
[15:21:25 CEST] <nevcairiel> only frames
[15:21:29 CEST] <nevcairiel> not a single bit of container
[15:21:51 CEST] <wm4> yes, but there are optional timestamps in some header, aren't there?
[15:22:13 CEST] <BBB> at the very least, theres the poc field in the bitstream
[15:22:29 CEST] <BBB> that can reasonably be used as a basic display counter (aka pts)
[15:22:47 CEST] <nevcairiel> not exactly timestamps, but some h264 headers at least can contain some timing info, but its not as easy as assigning it a pts
[15:23:07 CEST] <nevcairiel> avformat could read them at some point, did that get removed?
[15:24:01 CEST] <Daemon404> if it does get read, its in the parser
[15:25:28 CEST] <wm4> I think I saw code that just skips these...
[15:26:47 CEST] <saste> nevcairiel, any specific reasons why you implemented DXVA2 support in ffmpeg?
[15:26:59 CEST] <nevcairiel> why wouldnt i?
[15:27:09 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2ba68dd044ca8fc591139c05563840f546a9c0c0
[15:27:13 CEST] <nevcairiel> thats the code i meant
[15:27:18 CEST] <nevcairiel> it uses values set by the h264 parser
[15:27:31 CEST] <nevcairiel> but was removed
[15:38:50 CEST] <kierank> there is VUI framerate info
[15:38:56 CEST] <kierank> if fixed_frame_rate=1 then you can generate timestamps
[16:00:18 CEST] <saste> nevcairiel, thanks!
[18:18:24 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:81198a68370e: avformat/rtpenc_jpeg: Check remaining buffer size for SOS
[18:18:25 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:aa5169935e16: avformat/rtpdec_xiph: Check upper bound on len in xiph_handle_packet()
[18:18:26 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:a23379a0a68a: avformat/rtpdec_xiph: Move pkt_len onto one side of the check
[18:53:59 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:56abf35151c6: avformat/nutdec: Fix use of uinitialized value
[18:54:00 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:171af59d58fc: avformat/matroskadec: Cleanup error handling for bz2 & zlib
[18:54:01 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:70e022cfc5e3: avformat/idcin: Remove redundant chunk size check
[19:39:55 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:7a27aa15ec94: avformat/hls: Handle read_buffer allocation failure
[19:39:56 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:2cddc0b19a20: avformat/hevc: Check cpb_cnt_minus1
[19:39:57 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:b62b3292d8e2: avformat/hevc: Check num_negative_pics and num_positive_pics
[20:39:00 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:1431b4cf77d6: avfilter/vf_fftfilt: Add MAX_PLANES and change it to 4
[20:39:01 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:0d0540648295: avfilter/vf_cover_rect: Handle the case where the cover rectangle is as large as the input
[20:39:02 CEST] <cone-429> ffmpeg 03Michael Niedermayer 07master:d3c9f1fdbe05: avfilter/avf_showcqt: Fix gamma comparisons
[21:28:26 CEST] <cone-429> ffmpeg 03Andreas Cadhalpun 07master:ec38a1ba404b: aacdec: don't return frames without data
[00:00:00 CEST] --- Wed May 13 2015