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

[burek]

[04:09:04 CEST] <Zerowalker> is it possible to tell ffmpeg to copy instead of encoding data in code?
[04:09:27 CEST] <Zerowalker> like the "-acodec copy" thingy
[04:12:12 CEST] <cone-812> ffmpeg 03Philip Langdale 07master:91f1115a0e02: avcodec/vc1dec: Re-order init to avoid initting hwaccel too early
[04:15:14 CEST] <michaelni> Anssi, carl says in https://trac.ffmpeg.org/ticket/4797 that its a regression since da7759b3579de3e98deb1ac58e642b861280ba54, or maybe EXT-X-BYTERANGE dont work with .mp4
[06:23:29 CEST] <andrewrk> I switched from libav to ffmpeg for my music player, and it broke gapless playback. I'm not complaining - I'm looking for troubleshooting clues. Any suggestions?
[06:23:45 CEST] <andrewrk> I pipe all the decoded audio through a ffmpeg filter graph
[06:24:02 CEST] <andrewrk> I rebuild the filter graph in the seam between tracks
[06:25:45 CEST] <andrewrk> I suppose I could try an older version of ffmpeg and see if it was a recent commit that changed things
[06:26:17 CEST] <andrewrk> Also I suppose I should join #ffmpeg instead
[07:33:07 CEST] <durandal_1707> andrewrk: commands, code?
[07:34:10 CEST] <andrewrk> durandal_1707, well, I could link you to the existing codebase if you wanted to have a look. Or I could work on a small self contained example to demonstrate the problem
[07:35:12 CEST] <andrewrk> durandal_1707, here's a link: https://github.com/andrewrk/libgroove/blob/master/src/playlist.cpp#L668
[07:35:40 CEST] <andrewrk> I don't expect you to read all this, but hey I'll throw it out there.
[07:53:24 CEST] <durandal_1707> andrewrk: and how it behaves, that makes it incorrect?
[07:56:23 CEST] <andrewrk> durandal_1707, when line 711 happens, we seek to the beginning of a song which is supposed to have gapless playback, but instead, there is a small glitch heard
[07:58:25 CEST] <andrewrk> it is calling av_seek_frame and avcodec_flush_buffers on the second file's AVFormatContext
[07:58:40 CEST] <andrewrk> I wonder, would that cause a glitch sound?
[08:06:00 CEST] <andrewrk> ok yes it is that, I have narrowed it down
[08:07:22 CEST] <andrewrk> durandal_1707, ok so the problem is that I'm seeking to 0 and that is causing a glitch in the playback
[08:27:48 CEST] <durandal_1707> are you using abuffersink filter?
[08:30:14 CEST] <andrewrk> durandal_1707, yes
[08:40:44 CEST] <andrewrk> I wonder if it is an ogg vorbis specific problem
[08:42:35 CEST] <andrewrk> durandal_1707, aha, I do not experience the problem with flac
[08:42:40 CEST] <andrewrk> it must be an ogg thing
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f55cc579115e: aac: move the TNS tables from aacdectab to the shared aactab
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:20962b567b4d: lpc: create a simplified Levinson-Durbin LPC handling float samples
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:949a4892fa1d: aacenc: change FF_PROFILE_UNKNOWN to AAC-Main if prediction is enabled
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:44ddee945a2e: aacenc_pred: rework the way prediction is done
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:1cd5daee2060: aac: remove now-unused redundant array
[08:48:45 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f20b67173ca6: aacenc_tns: rework the way coefficients are calculated
[08:48:45 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f04d86c16a5d: aacenc: remove TNS from the todo list
[08:48:46 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:fe12ba6f3012: fate: reenable TNS test
[08:48:46 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:4ff897a5364f: fate: add a test for encoding AAC-Main prediction
[09:08:17 CEST] <wm4> andrewrk: seek to start time
[09:09:57 CEST] <andrewrk> wm4, how?
[09:11:13 CEST] <andrewrk> wm4, currently I am passing 0 for timestamp and 0 for flags in av_seek_frame
[09:11:22 CEST] <andrewrk> is there a different way to seek to start time?
[09:11:49 CEST] <wm4> yes by using the start time
[09:12:10 CEST] <andrewrk> how does one obtain the start time?
[09:13:11 CEST] <wm4> (also, no idea if this is really the cause)
[09:13:39 CEST] <andrewrk> ah, AVStream::start_time
[09:16:49 CEST] <andrewrk> wm4, just checked, start_time is reported as 0 which is what I was already passing
[09:16:59 CEST] <andrewrk> thanks for the suggestion though
[09:19:42 CEST] <andrewrk> so, if I remove the seek-to-0, gapless playback works perfectly
[09:19:58 CEST] <andrewrk> but I need that seek in there because sometimes I want to play a file again without closing and re-opening it
[09:20:45 CEST] <andrewrk> I think this is enough info to open an issue
[09:20:57 CEST] <andrewrk> and if more evidence is needed I can produce a test case
[09:21:08 CEST] <nevcairiel> if we're talking about mp3 files exclusively, you can just use a byte seek to position 0 and see if that helps
[09:21:19 CEST] <andrewrk> this is ogg vorbis
[09:21:24 CEST] <andrewrk> I don't expect gapless playback to work with mp3
[09:21:24 CEST] <nevcairiel> oh well
[09:22:11 CEST] <andrewrk> this works in libav btw, maybe I could look at a code diff
[09:25:05 CEST] <wm4> it should work in ffmpeg too
[09:25:37 CEST] <wm4> I fixed it to make mp3 gapless actually work
[09:26:05 CEST] <wm4> there are fate tests too
[09:26:14 CEST] <andrewrk> oh wow, let me try a couple songs from my library...
[09:26:31 CEST] <nevcairiel> seeking will likely still break something
[09:26:39 CEST] <andrewrk> even seeking to 0?
[09:26:49 CEST] <andrewrk> It seems like that should be a special case that should always work
[09:30:41 CEST] <nevcairiel> just track if you actually n eed to seek and avoid it if not, it'll save you a bunch of problems in general
[09:32:38 CEST] <andrewrk> hmm good point
[09:32:48 CEST] <wm4> I specifically fixed seeking with gapless mp3
[09:35:15 CEST] <andrewrk> wm4, I'm excited, about to try this out
[09:35:35 CEST] Action: andrewrk gets out Another Brick In The Wall, Part 2
[09:38:20 CEST] <andrewrk> wm4, I heard a small skip. but couldn't that be the fault of the ripper?
[09:38:52 CEST] <andrewrk> I thought that mp3 files had to have frames of a certain length, so they ended up getting padding and you just can't have gapless mp3
[09:40:22 CEST] <andrewrk> hmm let me try again without seeking to 0
[09:44:11 CEST] <andrewrk> nevcairiel, so, this is an incomplete solution, because let's say I have tracks 1 and 2 on a playlist. So I open both the files, and play them both and never call av_seek_frame
[09:44:24 CEST] <andrewrk> nevcairiel, then I go back and play them again
[09:44:43 CEST] <andrewrk> now the tracks must be seeked since they were played once, and we lost gapless playback
[09:45:03 CEST] <andrewrk> if I wanted such a workaround I would be forced to close the file and re-open it. but that seems silly
[09:45:09 CEST] <andrewrk> also it introduces race conditions
[09:45:25 CEST] <andrewrk> I think the right thing to do is special case seeking to 0 in ffmpeg codebase
[09:45:28 CEST] <nevcairiel> you could just re-open them, keeping them open permanently seems like a odd situation anyway, if you play a playlist of 5 tracks, do you keep all of them opened, and not close them when advancing to the next one?
[09:46:35 CEST] <andrewrk> nevcairiel, I keep the 5 tracks before the current song in the play queue and 5 tracks after the current song in the play queue open
[09:47:54 CEST] <andrewrk> they're not permanently open, it's just a resource caching problem
[09:48:06 CEST] <andrewrk> I keep them open if they're likely to get played
[09:50:25 CEST] <andrewrk> ok I'm just going to have a look at the ogg code and see if there's an obvious solution
[09:57:49 CEST] <andrewrk> the only difference between ffmpeg and libav is ogg_reset(s) called twice in ogg_read_seek
[10:28:13 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:8323d9b8afbc: fate: adjust AAC encoder TNS test fuzziness
[12:09:38 CEST] <ubitux> wm4: 0 length? you mean the duration of an event?
[12:10:04 CEST] <wm4> ubitux: yes
[12:10:07 CEST] <ubitux> unknown as in "next sub will replace previous one"?
[12:10:32 CEST] <wm4> I found lrc uses -1 to signal unknown length (while the API says 0), so I just started using that (because a user complained)
[12:10:45 CEST] <wm4> yes, or as in the last event is shown forever
[12:10:47 CEST] <ubitux> for standalone text sub this is handled with lavf/subtitles, which will deal with the duration itself
[12:10:58 CEST] <ubitux> ah yeah, except the last one
[12:11:27 CEST] <ubitux> i don't think we wrote a given convention
[12:14:52 CEST] <ubitux> yeah so basically, a duration=-1 will be replaced by the appropriate duration in the finalize step for standalone subs
[12:14:59 CEST] <ubitux> except for the last sub which will keep that -1
[12:15:46 CEST] <ubitux> you should get a packet with duration=-1, not 0
[12:16:01 CEST] <ubitux> (which will result in the ASS max time in the decoded form though)
[12:16:06 CEST] <ubitux> (iirc)
[12:19:10 CEST] <wm4> yes but the API docs say unknown lengths use 0
[12:19:16 CEST] <wm4> so I suggest we change the docs
[12:19:22 CEST] <ubitux> oups, yeah
[12:19:23 CEST] <wm4> and then fix whatever cases there are
[12:19:36 CEST] <ubitux> it might be different for bitmap subs
[12:19:43 CEST] <ubitux> which were there in the first place
[12:20:26 CEST] <wm4> yes htey need to be fixed
[12:20:37 CEST] <wm4> in fact I'd like if av_init_packet inits duration to -1
[12:20:53 CEST] <ubitux> it's a bit tricky with stuff like dvb subs iirc
[12:21:55 CEST] <ubitux> wm4: in which case duration=0 is meaningful?
[12:22:09 CEST] <ubitux> invisible sub?
[12:22:26 CEST] <wm4> yes
[12:22:27 CEST] <ubitux> (because of time scale differences ?)
[12:22:33 CEST] <wm4> no
[12:22:53 CEST] <wm4> ASS subs definitely have events with duration of 0 that need to be invisible
[12:23:38 CEST] <ubitux> question about this: are they supposed to impact the positioning of overlapping subs?
[12:23:58 CEST] <ubitux> question not clear, let me reword
[12:24:31 CEST] <ubitux> when you have a dialogue printed on the screen, and another dialogue appears overlapping with the second one, it goes above
[12:24:49 CEST] <michaelni> atomnuker, fate-aac-tns-encode fails with assertion failure on builds with  --assert-level=2
[12:24:57 CEST] <ubitux> but if the first dialogue disappear (or do not actually appear bc of duration=0)
[12:24:58 CEST] <wm4> I have no idea how it's supposed to be handled
[12:25:06 CEST] <ubitux> is the above dialogue going down or stay above?
[12:26:10 CEST] <wm4> libass would probably respect only actually rendered events
[12:27:04 CEST] <ubitux> what would be the purpose of these invisible dialogue?
[12:27:13 CEST] <ubitux> if they have 0 impact on the output?
[12:27:37 CEST] <wm4> so you're suggesting the demuxer should discard them?
[12:27:47 CEST] <ubitux> no it's a real question
[12:27:50 CEST] <ubitux> i'm just wondering
[12:28:07 CEST] <wm4> I'd say they still need to be representable
[12:39:29 CEST] <michaelni> atomnuker, fate-aac-tns-encode also shows out of array reads under valgrind
[12:42:24 CEST] <michaelni> atomnuker, http://pastebin.com/wWVU727t
[12:51:03 CEST] <kurosu__> "levinsion" ? levinson you mean
[13:32:15 CEST] <saste> all gsoc projects were successfull, good
[13:32:40 CEST] <kierank> there was one bad iirc
[13:32:45 CEST] <saste> michaelni, what about an IRC meeting before the next VDD?
[13:32:52 CEST] <saste> kierank, yes it failed at midterm
[13:38:05 CEST] <michaelni> saste, sure, pick a day/time thats convenient for most people ...
[13:38:54 CEST] <saste> I could create a doodle, or settle for the next Saturday
[14:29:45 CEST] <y2k> hi! in a dumuxer, I don't know how many frames I have written. how do I add support for chapters in such formats (when the number of frames written is not known). the underlying codec is mp3. is there some neat magic in ffmpeg to do this?
[14:30:43 CEST] <Compn> you talk about demuxers and writing frames
[14:30:48 CEST] <Compn> which is usually a muxer thing...
[14:31:08 CEST] <Compn> what format are you talking about specifically? mkv ordered chapters ?
[14:46:25 CEST] <ubitux> https://pornel.net/deringing/ old?
[14:52:37 CEST] <durandal_1707> ubitux: what are you doing?
[14:55:15 CEST] <cone-442> ffmpeg 03Clément BSsch 07master:b48d8fa3ac38: avfilter: add allrgb
[14:55:44 CEST] <ubitux> durandal_1707: i'm back on selectivecolor, nothing related to the above link
[14:57:12 CEST] <ubitux> we should use allrgb/allyuv for 1:1 color pixel filters
[14:57:22 CEST] <ubitux> in fate
[14:58:50 CEST] <ubitux> michaelni: atomnuker: fate also fails here with:
[14:58:52 CEST] <ubitux> Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157
[14:59:04 CEST] <ubitux> in aac-tns-encode test
[15:08:00 CEST] <ubitux> fate also fails on on api-seek and asf-repldata with --disable-everything
[15:18:32 CEST] <durandal_1707> release with major bumps should be 3.0
[16:08:37 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:16229fae9c0d: avfilter/vf_vectorscope: add yet another mode
[18:41:24 CEST] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:47b41feb7283: avfilter/af_apad: use the name 's' for the pointer to the private context
[19:02:28 CEST] <atomnuker> ubitux: on it
[19:04:19 CEST] <ubitux> see also the valgrind error from michaelni 
[19:06:43 CEST] <jamrial> ubitux: allrgb.png 34.8MB, post "optipng -o7" it becomes 58kb :P
[19:06:57 CEST] <ubitux> jamrial: haha nice
[19:07:00 CEST] <jamrial> much better than allyuv
[19:07:39 CEST] <ubitux> i wonder if it would have been that compressable with a different layout
[19:08:13 CEST] <wm4> jamrial: can you upload that anywhere?
[19:09:07 CEST] <jamrial> wm4: ffmpeg -f lavfi -i allrgb -vframes 1 allrgb.png && optipng -o7 allrgb
[19:10:25 CEST] <jamrial> wm4: but in case you don't have optipng http://i.imgur.com/8aFtnrh.png
[19:13:16 CEST] <jamrial> wm4: you said there may be some obscure avoptions to get better compression with our encoder, but ffmpeg -h encoder=png doesn't show anything
[19:14:04 CEST] <ubitux> jamrial: try -compression_level 
[19:14:20 CEST] <ubitux> (generic option)
[19:15:47 CEST] <ubitux> i wonder if the squary layout isn't detected somehow by optipng
[19:17:19 CEST] <jamrial> -compression_level 4 and above are all the same. 3 and below are slightly bigger
[19:17:26 CEST] <Timothy_Gu> jamrial: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/pngenc.c#L1046-L1048
[19:19:06 CEST] <jamrial> webp lossless is still better. 9kb
[19:32:17 CEST] <durandal_1707> what about 256x256x256 frames, this needs less memory
[19:34:34 CEST] <durandal_1707> atomnuker: so you are writting spectrogram, have you considered doing it using lavfi?
[19:43:39 CEST] <atomnuker> I was thinking of using lavc and libfftw3
[19:44:19 CEST] <atomnuker> but it should be easy to modify the current showspectrum to figure out a length in pixels such that it would never wrap
[19:47:14 CEST] <Timothy_Gu> atomnuker: we have our own fft: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avfft.h
[19:48:12 CEST] <atomnuker> yes, I know, just a fan of that library
[19:48:49 CEST] <atomnuker> I'll see what can be done to showspectrum first
[20:01:13 CEST] <wm4> I don't see any point in making a release with all the old API
[20:24:37 CEST] <jamrial> wm4: probably to please distros, since apparently dropping three years old apis is a big deal
[20:24:55 CEST] <durandal_1707> atomnuker: cache frames like showwaves
[20:26:09 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:0818705bf37e: aacenc_tns: fix triggering an assertion with assert-level=2
[20:26:10 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:49854c56c234: aacenc: initialize LPC context with MAX_LPC_ORDER
[20:26:11 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:902ac9ca74d5: aacenc_tns: actually apply TNS filter to the coefficients
[20:26:12 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:e924967fd5ec: aacenc_tns: fix out-of-bounds array access
[20:26:46 CEST] <jamrial> next version will be after the bump, and if some distros can't be bothered to update their ffmpeg-dependent packages they'll at least have a version newer than 2.7 to use
[20:26:55 CEST] <atomnuker> michaelni: valgrind exits without any errors for me
[20:27:47 CEST] <atomnuker> kurosu__: on it
[20:33:03 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:141d80ded779: lpc: rename ff_lpc_calc_levinsion to ff_lpc_calc_levinson
[21:30:19 CEST] <philipl> which nick is Paul? i forget.
[21:32:38 CEST] <wm4> philipl: durandal_1707 ?
[21:33:32 CEST] <durandal_1707> yes
[21:45:09 CEST] <philipl> I got bored and started trying to implement support for the packed yuva444 format that vdpau uses
[21:45:47 CEST] <philipl> i tried copying the ayuv64 swscale code and clipped values to 8 bits but everyhing looks very dark
[21:46:13 CEST] <philipl> i wonder if i messed that up or its a colourspace conversion problem on the vdpau side
[21:52:17 CEST] <durandal_1707> philipl: you need to shift more
[21:53:33 CEST] <philipl> i shifted 23 in place of your 15.
[21:53:38 CEST] <philipl> that seems logical.
[22:04:49 CEST] <durandal_1707> you only do output?
[22:05:22 CEST] <philipl> In this case it's output only. Taking a 444planar source and sending it to vdpau
[22:05:41 CEST] <philipl> I wrote the input path in swscale too but that's trivial by comparison.
[22:07:58 CEST] <philipl> durandal_1707: https://github.com/philipl/FFmpeg/commit/fd4eb7c10c169d9699223391817939b1170bf0e6
[22:11:16 CEST] <durandal_1707> and if you use format filter it displays correctly?
[22:11:51 CEST] <philipl> I haven't tried. I put it through mpv into vdpau and it shows up very dim, but with the right basic colours.
[22:11:58 CEST] <philipl> Let me try format filter
[22:12:22 CEST] <philipl> I mean, I used the format filter in mpv to trigger conversion from yuv444p to this and then sent that to vdpau
[22:13:31 CEST] <durandal_1707> but try back from it to yuv444p
[22:13:56 CEST] <durandal_1707> assuming input path is correct
[22:14:36 CEST] <durandal_1707> Also look at yuv2422*template
[22:15:02 CEST] <wm4> did you confirm that mpv allocates the 444 packed surface correctly? (lots of messiness here due to interaction with pixdesc)
[22:15:42 CEST] <philipl> wm4: I think so. I see recognisable output on the screen, just very dim.
[22:23:12 CEST] <philipl> whelp. Back and for conversion did not produce anything reasonable.
[22:23:13 CEST] <philipl> *sigh*
[22:24:06 CEST] <philipl> I take that back.
[22:24:14 CEST] <philipl> I got something recognisable but all shades of green.
[22:24:22 CEST] <philipl> Different from what i saw through vdpau playback
[22:43:07 CEST] <Anssi> michaelni: ok thanks, I'll take a look at https://trac.ffmpeg.org/ticket/4797
[23:07:10 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:21bfeec27f93: aacenc_tns: do not limit the filter size
[00:00:00 CEST] --- Sun Aug 30 2015