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

burek burek021 at gmail.com
Fri Nov 1 02:05:02 CET 2013


[00:03] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:cb52d6da0a9c: avcodec/bink: fix seeking to frame 0
[00:06] <llogan> version.sh gives a weird revision number on a shallow repo that got "git pull"-ed
[00:06] <llogan> N-57649-gcc0e47b (normal) vs N-38493-gcc0e47b
[00:54] <llogan> ooops..forgot to set as "wish"
[01:01] <BBB> ubitux: --cpu-used=0 deals correctly with it yes
[01:01] <BBB> ubitux: other values I don't know
[01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/1.2:fd8af7510991: avcodec/bink: fix seeking to frame 0
[01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.0:beb28bc55dc7: avcodec/bink: fix seeking to frame 0
[01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.1:1cd5797f8ec8: avcodec/bink: fix seeking to frame 0
[01:52] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:b73900b8a6c0: avformat/http: fix cookies
[01:55] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.1:d8be5bda1b96: avformat/http: fix cookies
[02:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:2b1056e4e27b: avformat/thp: fix variable types to avoid overflows
[02:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:6c4b87d3d6ae: avformat/thp: force moving forward
[06:53] <Persanker> Hi
[06:53] <Persanker> Is there anybody?
[06:54] <Persanker> I have a question of using a function.
[06:55] <Persanker> Can anyone help me?
[07:27] <Persanker> hi
[10:13] <cone-709> ffmpeg.git 03Mickaël Raulet 07master:7c8b65f688ea: hevc: add partial support for interlaced(cherry picked from commit 44b592ae6d323445c076ef3ec966ebf9daa8bccf)
[10:14] <nevcairiel> nooo, not interlaceeeed
[10:15] <Paranoialmaniac> interlaced should die
[10:18] <Paranoialmaniac> this commit is only affected as sei?
[10:18] <nevcairiel> afaik, hevc doesnt have special interlaced coding, only info signaling
[10:19] <ubitux> haha
[10:19] <Paranoialmaniac> hevc interlaced is implemented as a pair of top and bottom field coded pictures like avc
[10:19] <Paranoialmaniac> no mbaff. but there is paff
[10:23] <Paranoialmaniac> i like the idea which signals interlaced only but i dislike paff coding. so i dislike hevc :P
[10:24] <mraulet> nevcairiel, yes
[10:24] <mraulet> it is not yet finished the implementation I did
[10:25] <mraulet> it is parsing but not deinterlacing yet
[10:25] <Paranoialmaniac> deinterlacing??
[10:25] <mraulet> when I try abc with field only it got a deinterlaced yuv
[10:26] <Paranoialmaniac> deinterlacing is a task of post processor. not a decoder task
[10:26] <mraulet> in hevc I am outputting 2 fields
[10:26] <mraulet> true
[10:26] <mraulet> but I am not able to activate it yet
[10:27] <Paranoialmaniac> well, libavcodec h264 decoder always waits for completion of frame even if field coded
[10:29] <Paranoialmaniac> :O i didn't notice that my hevc parser patch is already in
[10:30] <mraulet> it is yes
[10:30] <mraulet> I haven't checked if you did further modifications
[10:31] <mraulet> was busy with standardisation
[10:35] <ubitux> http://git.libav.org/?p=libav.git;a=commitdiff;h=293fe6da01b6cb2f85c6551553ed765a7408ca23http://lists.libav.org/pipermail/libav-devel/2013-October/052569.htmlhttp://lists.libav.org/pipermail/libav-devel/2013-October/052591.html
[10:35] <ubitux> it never ends :')
[10:36] <ubitux> they can't even make up their mind with the style
[10:36] <nevcairiel> haha the latest patch now undoes vertical alignment added in the earlier commit, so funny
[10:36] <ubitux> yeah :D
[10:37] <nevcairiel> wonder if i should post that on the ML :P
[10:37] <ubitux> nevcairiel: should i?
[10:38] <nevcairiel> sounds like a good opportunity to troll their re-styling :p
[10:38] <durandal_1707> ubitux: we should make documentary
[10:41] <ubitux> i'm not sure 3 people are enough yet for cosmetics
[10:41] <ubitux> they need a 4th one
[10:43] <saste> K&R is hard
[10:43] <saste> it takes many attempts
[10:43] <nevcairiel> the worst part is the obsession with 80 characters
[10:44] <nevcairiel> take http://lists.libav.org/pipermail/libav-devel/2013-October/052569.html for example
[10:44] <nevcairiel> the last two hunks dont make anything better
[10:44] <nevcairiel> worse even, imho
[10:45] <ubitux> consider yourself lucky the script (or luca?) didn't break after the first coma too
[10:45] <ubitux> like it often happens, as i pointed out last time
[10:45] <durandal_1707> K&R is final state of mind
[10:52] <mateo`> i wonder if they plan to add a git hook to call indent ...
[10:53] <ubitux> i'm pretty that's the final utopy
[10:53] <ubitux> when everything is "consistent"
[10:53] <ubitux> but given they can't even make their mind on the style on a single trivial files
[10:53] <ubitux> i doubt it will happen soon
[10:53] <ubitux> they will just fuck up the blame/history
[10:53] <ubitux> and readability sometimes
[10:54] <ubitux> (and introduces functional changes and bugs at times)
[10:57] <durandal_1707> but michaelni still like to merge such changes
[10:58] <nevcairiel> if you dont, merging actual functional changes later is a pain
[11:00] <durandal_1707> finding later changes needs pain killers
[11:21] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:fa6fa2162b73: avcodec/cabac: support UNCHECKED_BITSTREAM_READER = 0
[11:26] <ubitux> wm4: "eventually, probably" ;)
[11:27] <ubitux> wm4: basically, a probable "wish" afaiu, with nothing really planed
[11:28] <wm4> well I just found a bug in my own code because of this
[11:28] <wm4> and I'd consider myself an experienced API user
[11:28] <wm4> so I'll use my failure as proof that the API "fucking sucks"
[11:28] <nevcairiel> better then face your own faults, i'm sure
[11:28] <nevcairiel> :P
[11:29] <av500> wm4: which one?
[11:29] <wm4> providing a single, supported way would fix the API
[11:29] <wm4> av500: avcodec_alloc_frame vs. av_frame_alloc, also refcounting
[11:29] <BBB> lol @ ununchecked cabac
[11:29] <BBB> didn't I implement that years ago and doesn't that include all assembly etc.?
[11:29] <av500> wm4: ah
[12:25] <ubitux> wm4: maybe someone should write a paper about moving from the old to the new api
[12:25] <ubitux> :p
[12:26] <wm4> how about not giving a fuck
[12:26] <av500> i'd rather we break the new API
[12:26] <wm4> it seems every API user just has to go through the pain
[12:26] <wm4> like a ritual
[12:27] <wm4> like the klingon initialization rite
[12:27] <wm4> just that it happens every 6 monthd
[12:27] <wm4> *months
[12:27] <wm4> to confirm that he is a worthy API users
[12:28] <av500> its the API "tax"
[12:28] <ubitux> wm4: i'm still wondering what your point is, or what you want :D
[12:29] <wm4> ubitux: op confusing differences between refcounted and "old" API... which is possible to accomplish
[12:29] <wm4> at least as soon as the deprecated get_buffer is removed
[12:30] <ubitux> op=me?
[12:30] <ubitux> i think everyone is confused about the old2new api anyway
[12:30] <wm4> s/op/no/ (how did this happen)=
[12:30] <ubitux> ah
[12:52] <durandal_1707> so instead of fixing/improving example we troll about api
[12:53] <wm4> sorry I don't think it's reasonable to have both avcodec_free_frame and av_frame_free and have them do completely different things
[12:54] <wm4> perhaps not _really_ the problem of the example
[12:55] <durandal_1707> wm4: yes i find it confusing too
[12:55] <wm4> but why make users (possibly) use them
[12:56] <durandal_1707> and have 2 different paths is pain
[12:57] <saste> someone has to explain what i gain from saving users pain (in change of my own pain)
[12:57] <saste> since i get nothing from users anyway
[12:58] <saste> ah i forgot, i do it for the public good
[12:58] <durandal_1707> you are doing something wrong....
[12:59] <wm4> saste: you can spare yourself hour long discussions on IRC about bad APIs
[13:34] <ubitux> wm4: so, can i use new api without ref counting?
[13:35] <wm4> not sure...
[13:35] <nevcairiel> anton claims you can, i still have my doubts
[13:35] <ubitux> (aka without the need to set the option or unref the frame after decode)
[13:35] <ubitux> ok i'll try then
[13:35] <wm4> you still have to unref the frame before decode though
[13:35] <wm4> or it'll leak
[13:35] <wm4> not sure why this has to be this way, but whatever
[13:35] <ubitux> before?
[13:35] <ubitux> dafuck
[13:36] <wm4> yes decode will just memset the AVFrame, essentially
[13:36] <nevcairiel> if refcounting is off, you should only need to free the frame once when you shutdown
[13:36] <ubitux> ok let me try then
[13:36] <nevcairiel> it stores the buffers internally to free them on the next call, iirc
[13:36] <wm4> so before decode you still need: if(refcounting_enabled)av_frame_unref(frame);
[13:37] <ubitux> gonna improve the example to make multiple new api modes
[13:37] <ubitux> yay, gonna love it
[13:37] <nevcairiel> well with refcounting you need to free it between decode calls, indeed
[13:37] <nevcairiel> thats really the only big difference
[13:37] <wm4> hm maybe av_frame_unref is ok even if refcounting is disabled, but that's questionable
[13:38] <nevcairiel> should be OK, but should be a void operation
[13:38] <nevcairiel> short of clearing all the other fields
[13:38] <nevcairiel> if antons theory is right, anyway
[13:38] Action: nevcairiel is not convinced yet
[13:39] <wm4> anyway, my point is: would decode unref the frame automatically, you wouldn't have to care about this
[13:39] <nevcairiel> you mean even with refcounting?
[13:39] <wm4> yes
[13:40] <wm4> and then, when get_buffer is removed, refcounting could be enabled by default
[13:40] <nevcairiel> some users of the old api allocated a new frame for evey decode call, which would then still leak
[13:40] <nevcairiel> so it would be inconsistent still
[13:40] <wm4> then user wouldn't have to care about refcounting, and could just use the av_frame_ref functions when he needs it
[13:40] <wm4> hm
[13:43] <cone-709> ffmpeg.git 03Diego Biurrun 07master:c7f25d4c7f65: build: Ensure that strip commands are run silently
[13:43] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:532ca12300f1: Merge remote-tracking branch 'qatar/master'
[13:46] <ubitux> it seems to work
[13:46] <ubitux> mmh well
[13:47] <ubitux> i was trying fate-samples/lossless-audio/luckynight-partial.shn but it doesnt decode well with the example
[13:49] <ubitux> maybe that's just the end though
[13:55] <ubitux> wm4, nevcairiel, http://pastie.org/pastes/8445428/text
[13:55] <ubitux> with that patch: http://b.pkh.me/0001-doc-examples-demuxing-show-how-to-use-the-reference-.patch
[13:57] <ubitux> so, it seems ok
[13:57] <wm4> what's that lock manager bit?
[13:57] <ubitux> no idea
[13:58] <wm4> also in the default lock manager code it's strange that create doesn't allocate, while destroy does allocate
[13:58] <wm4> oh well
[13:59] <nevcairiel> the default lock manager code was rather weird
[13:59] <nevcairiel> with its volatile variable
[13:59] <nevcairiel> not sure why thats there
[14:05] <ubitux> so anyway
[14:05] <ubitux> who's gonna fix the filtering_{audio,video}.c examples now? :)
[14:07] <wm4> are they broken?
[14:07] <durandal_1707> something broke?
[14:08] <wm4> they look ok on a quick look
[14:15] <ubitux> wm4: they are broken
[14:15] <ubitux> they crash out of the box
[14:15] <ubitux> or leak, or both, can't remember
[14:21] <ubitux> also, those examples don't handle multiple decode per packet
[14:23] <wm4> that's needed for audio only
[14:36] <cone-709> ffmpeg.git 03Carl Eugen Hoyos 07master:e4b0a77021a2: libavfilter/decimate: Add pts of first frame to all frames.
[14:36] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:045214e3d981: Merge remote-tracking branch 'cehoyos/master'
[14:36] <durandal_1707> f&*()
[14:37] <cone-709> ffmpeg.git 03Paul B Mahol 07master:49287bbfd322: doc/filters: add few more examples for blend filter
[14:38] Action: durandal_1707 #ffmpeg You're not a channel operator
[17:19] <wm4> ubitux: do you know/care about dvdsubdec? I have a file here where lavc returns duration=0, while the duration is correct with mplayer's dvd sub decoder
[17:20] <ubitux> i did some changes to it recently but i wouldn't say i know about it
[17:20] <ubitux> but yeah feel free to share
[17:21] <wm4> sample: http://www1.datafilehost.com/d/9b99a2 (first subtitle event is affected, you can see it appear for 1 frame in ffplay)
[17:24] <ubitux> Invalid file ID.
[17:25] <wm4> try this: http://www1.datafilehost.com/d/9b99a2bf
[17:25] <wm4> right, I missed two characters
[17:26] <wm4> looking further into thus, mplayer's spudec.c has an additional mysterious chunk of code that does alternative reading of end timestamp, which appears to be missing from lavc
[17:26] <ubitux> no idx?
[17:26] <ubitux> erm yeah sure no idx.
[17:26] <wm4> it's a normal mpeg stream
[17:27] <wm4> from a DVD
[17:28] <wm4> av_dlog(NULL, "unrecognised subpicture command 0x%x\n", cmd); <- should perhaps not be a dlog
[17:28] <ubitux> agree
[17:28] <ubitux> i won't have time to look at it soon though
[17:29] <ubitux> i'll probably open a ticket, unless you don't feel lazy
[17:29] <wm4> I'm trying to debug it, if I give up and have no patch, I'll open a ticket
[17:46] <wm4> hm actually, the mplayer sub decoder doesn't determine a duration either
[17:46] <wm4> but at least you know that the duration is unknown
[17:56] <wm4> ubitux: yeah, never mind, at most it's a ffplay bug and a shortcoming of the subtitle API
[17:56] <ubitux> yeah ffplay doesn't support well the bitmap subs
[17:56] <ubitux> :P
[17:57] <wm4> actually
[17:57] <wm4> the duration of these subtitle packets seems to be set to 0
[17:57] <wm4> hm
[17:58] <wm4> "Duration of this packet in AVStream->time_base units, 0 if unknown."
[17:58] <wm4> so... what if the duration is _actually_ 0?
[17:59] <wm4> and yes there are subtitles that use duration==0 if the sub shouldn't be shown at all
[18:19] <durandal_1707> safari can play vp8?
[18:21] <{V}> durandal_1707, maybe this is helpful: http://caniuse.com/webm
[18:24] <durandal_1707> i have same strange issues with h264 and seeking
[18:37] <wm4> why does vf_copy exist?
[18:42] <beastd> "Add copy filter, useful for testing the avfilter_draw_slice() copy code."
[18:45] <wm4> lol
[18:45] <wm4> draw_slice is gone
[18:46] <beastd> wm4: that seems what was the original reason. maybe it also serves as a starting point for writing a completely new filter from scratch.
[18:47] <saste> well it was still useful, to test a few reference copy issues
[18:50] Action: durandal_1707 blames libmpcodecs
[18:51] Action: beastd assumes durandal_1707 does random blaming
[18:52] <saste> ffmpeg -i input -v:c copy -t  10 foo.mp4 => silly bug of the day
[18:52] Action: durandal_1707 blames beastd for libmpcodecs
[18:53] Action: saste blames durandal_1707 who blames beastd for libmpcodecs
[18:54] Action: durandal_1707 blames saste for copy filter
[18:54] Action: beastd starts another blame game
[18:54] Action: durandal_1707 blames everyone who stopped writing filters
[18:55] Action: saste blames filters, people should use vapoursynth instead
[18:55] Action: durandal_1707 bans saste
[18:57] <durandal_1707> setpts='PTS*25*90',fps=24 eats memory
[19:08] <wm4> ubitux: I think your vobsub fixes didn't make it into the release branches
[19:08] <ubitux> not all of them indeed
[19:09] <ubitux> since i had no review and the changes were not trivial
[19:09] <ubitux> i didn't want to backport them immediately
[19:09] <ubitux> (and indeed a nasty bug was spotted later)
[19:12] <durandal_1707> how you can do slide transition with lavfi - you can't
[19:14] <wm4> vf_powerpoint
[19:15] <ubitux> wm4: http://trac.ffmpeg.org/ticket/1985
[19:15] <durandal_1707> would ffmpeg sponsor scripting filter?
[19:16] <wm4> oh my
[19:18] <durandal_1707> there is open bug for converting doc/xls...
[19:19] <mark4o> it would be cool if the concat filter supported transitions though
[19:20] <durandal_1707> there are alfread filters that do transitions
[19:21] <durandal_1707> adding transitions inside concat would be big clusterfuck
[19:21] <mark4o> alfread filter?
[19:21] <wm4> just use vapoursynth
[19:22] <wm4> transitions would be easy to script with it
[19:22] <durandal_1707> i will kick anyone who mentions it again
[19:23] <ubitux> haha
[20:08] <durandal_1707> michaelni: why is HEVCLocalContext allocated when it can be inside context?
[20:13] <durandal_1707> btw why hevc does not use ONLY_IF_THREADS_ENABLED
[20:17] <cone-792> ffmpeg.git 03Carl Eugen Hoyos 07master:5ab1efb9d0dc: Fix a crash on oom when decoding hevc.
[20:32] <durandal_1707> git log
[20:32] <durandal_1707> stupid shell
[20:33] <ubitux> that's not a shell durandal_1707 
[20:33] <ubitux> this is the irc window
[20:33] <durandal_1707> want to be my shell?
[20:34] Action: ubitux : command not found: want
[20:34] <durandal_1707>  /deop ubitux
[20:34] <ubitux> :(
[20:35] <Compn> ehe
[20:35] <durandal_1707> why you take everything so serious?
[20:48] <cone-792> ffmpeg.git 03Compn 07master:6173b0fea71a: aacdec: fix small comment, update decoder features comment
[20:49] <Compn> cone is fast :D
[20:52] <durandal11707> this commit was not approved
[21:09] <Compn> durandal11707 : michael reviewed part of it on -cvslog 
[21:09] <Compn> it was
[21:09] <Compn> pre-approved!
[21:25] <smarter> https://trac.ffmpeg.org/ is broken?
[21:26] <JEEB> yup, the http side of things seems to work tho
[21:27] <llogan> it's back
[21:37] <llogan> did anyone get the exact error message referring to the database?
[21:41] <cone-792> ffmpeg.git 03Marton Balint 07master:e1573d714746: MAINTAINERS: add myself as libzvbi-teletextdec maintainer
[21:43] <smarter> llogan: here: http://pastebin.com/24wmhnhb
[21:45] <ubitux> beastd ^
[21:45] <beastd> smarter: hmm, ok. thanks.
[00:00] --- Fri Nov  1 2013


More information about the Ffmpeg-devel-irc mailing list