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

[burek]

[00:18] <Compn> kierank : its almost like they are teaching this as a 'violate gpl and make money' class in some kind of business school
[00:24] <kierank> I think a good chunk are just genuine mistakes
[00:24] <kierank> the indian team just are clueless
[00:27] <kierank> llogan: I would like to get hold of blue lucy software
[00:27] <kierank> because that's probably violating too
[00:27] <kierank> but they know my name and ignored my last request
[00:28] <llogan> I can try asking
[00:29] <kierank> please do
[00:29] <kierank> note they require an official email address
[00:29] <kierank> not just gmail
[00:30] <llogan> i don't think my gmail would work for that anyway: hungryhungryhobos
[00:30] <kierank> wtf these digimetrics people also statically link xavs
[00:30] <kierank> wtf
[00:51] <cone-22> ffmpeg.git 03Janne Grunau 07master:581c7f0e12b1: arm: make ff_mlp_filter_channel_arm and ff_mlp_rematrix_channel_arm position independent
[00:51] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:824932dc4732: Merge commit '581c7f0e12b1fa39f73d683e54d6ecda0772c5a9'
[00:51] <rcombs> llogan: better yet, an abnormally calm Captain Sullivan
[00:56] <cone-22> ffmpeg.git 03Janne Grunau 07master:4c81613df499: arm: mlpdsp: handle pic offset calculation in a macro
[00:56] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:cb416a7d7954: Merge commit '4c81613df499ba81d64ea102b38d0c6686cc304c'
[01:16] <cone-22> ffmpeg.git 03Janne Grunau 07master:d2f1d42b1878: fate: add dolby true hd tests
[01:16] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:b7bfe17824b6: Merge commit 'd2f1d42b18787e4fcb28864d9d9f701dd64a5747'
[01:24] <cone-22> ffmpeg.git 03Martin Storsjö 07master:95d880fa6436: rtpproto: Fix the input RTP data format check
[01:24] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:bd378acad4e4: Merge commit '95d880fa6436f3b557a9c060428a04b9e4d552df'
[01:52] <cone-22> ffmpeg.git 03Bryan Huh 07master:fa8934d6d6a0: dashenc: log file output progress in verbose mode
[01:52] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:1397cb002d9d: Merge commit 'fa8934d6d6a0bb290010bdf16265c40b331d56fb'
[02:12] <llogan> kierank: sent. unless they have spies here i'll let you know when or if i get it.
[03:32] <cone-22> ffmpeg.git 03Gabor Nagy 07master:ae8168074eb1: avformat/avidec: Increase dshow_block_align use threshold by 1
[08:48] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:d43d5c570753: avcodec/x86/hevc_mc: remove dead branch from EPEL_FILTER
[12:43] <cone-34> ffmpeg.git 03Luca Barbato 07master:2c3f29c4894e: xcbgrab: Support empty filename string correctly
[12:44] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:81a045fe17d5: Merge commit '2c3f29c4894ee50635b846f202296ad79a7c0d33'
[13:42] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:a2fa1889a69f: avfilter/vf_perspective: add av_assert0() to help gcc see that there are no uninitialized variables
[13:42] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:0fadbd3623cf: avformat/flvdec: fix potential use of uninitialized variables
[15:00] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:52a17972defa: avformat/yuv4mpegdec: fix "warning: field_order may be used uninitialized in this function"
[15:00] <cone-34> ffmpeg.git 03Michael Niedermayer 07master:ae93965359e7: avcodec/hevc_refs: fix potential use of uninitialized min_idx
[15:45] <wm4> lol
[15:50] <av500> its always a new developer
[16:05] <ubitux> ok so i'm trying the lavfi approach to timelines
[16:05] <ubitux> and this is typically what it looks like: http://pastie.org/9772342
[16:05] <ubitux> i'm not sure if i should be proud or not
[16:05] <ubitux> (warning: it's not yet correct)
[16:05] <av500> ubitux: no XML?
[16:06] <ubitux> well lavfi doesn't parse filtergraph in xml yet
[16:06] <ubitux> but it could, it's just a matter of syntax
[16:18] <wm4> ubitux: my reaction is "dear god no"
[16:19] <wm4> anyway, IMO the main problem with edit lists is that they would require seeking streams independently from each others
[16:21] <ubitux> that will be exported only on demand
[16:21] <ubitux> and you can just send it to libavfilter
[16:22] <ubitux> 0 api change required (except maybe a micro bump for the option)
[16:22] <ubitux> and this mechanism can also help with mkv timeline
[16:22] <ubitux> (since you can movie=... :D)
[16:22] <ubitux> i'm going to bring so much hate on me :')
[16:23] <ubitux> anyway, i'm almost there
[16:23] <ubitux> just a small timing overlap currently
[16:23] <ubitux> then i'll check how it looks like for automatic filter insert in ffmpeg and ffplay
[16:27] <wm4> ubitux: you assume a lot of stuff about applications
[16:27] <wm4> but if you intent it to work only for ffplay and ffmpeg.c, sure
[16:27] <ubitux> well, i'm looking for solutions
[16:28] <ubitux> the api solution kind of work but isn't extendable, the demuxer solution can't work, and the filtergraph solution is as effective as the first one except it doesn't need api changes and is more extendable
[16:29] <ubitux> i'm aware it's not perfect, but it's still a solution that covers a bunch of issues
[16:32] <wm4> so what's the reason you have to export a fucked up lavfi graph, instead of actual edit lists?
[16:35] <ubitux> wm4: exporting the actual list needs to define an api
[16:35] <ubitux> which could be done obviously
[16:36] <ubitux> but i'd like to wait for more "timeline" examples in other formats
[16:36] <ubitux> like, at least mkv
[16:36] <wm4> but the thing is, since edit lists apparently can reference arbitrary parts per track, an API user couldn't use this
[16:36] <wm4> unless you open the file multiple times, once per track
[16:36] <wm4> or if you risk excessive buffering
[16:37] <ubitux> most of the time it's just small delays
[16:37] <ubitux> because it looks like the point is to cut between keyframes
[16:37] <ubitux> like, you have a gop of 250 and you want to cut in the middle; you remux the whole group and use the edit list to cut in the middle
[16:37] <ubitux> so far it looks like the most common usage
[16:41] <ubitux> basically for the editor it's simpler because it can defines exact cut by just working at muxing/format level
[16:42] <ubitux> so it hard cuts at keyframe packets, and define the accuracy at edit list level
[16:42] <ubitux> at least that's my understanding so far
[16:44] <wm4> Paranoialmaniac: what do you say? does a demuxer need to support edit lists that reference source parts that are very far away between tracks at the same presentation time?
[17:03] <Paranoialmaniac> wm4: ?
[17:04] <wm4> Paranoialmaniac: libavformat has the problem that it has to seek all tracks at once (and to the same position)
[17:06] <av500> is that not what edit lists are about?
[17:06] <av500> referencing random parts of the video?
[17:08] <Paranoialmaniac> wm4: you mean libavformat can't seek the same frame by different presentation timestamps?
[17:12] <wm4> Paranoialmaniac: I mean: if one edit list entry references a video frame at time 0, and an audio frame at position 453523
[17:12] <wm4> and both tracks are in the same file
[17:13] <wm4> libavformat can seek either to position 0 or 453523
[17:13] <wm4> it can't seek the tracks independently
[17:13] <wm4> so it can't support such files
[17:14] <av500> right
[17:14] <Paranoialmaniac> what time do you mean? dts? cts? or pts?
[17:14] <av500> the one you pass to seek
[17:14] <wm4> not sure, that's probably the dts
[17:15] <wm4> what's cts?
[17:16] <Paranoialmaniac> cts = composition timestamp. pts is cts after applying edit list
[17:19] <Paranoialmaniac> the same cts/dts is referenced by different pts
[17:19] <Paranoialmaniac>  /s/is/may be/
[17:19] <av500>  still lavf cannot see to two different timestamps, one at the start and one at the end of the file
[17:19] <av500> seek*
[17:20] <av500> but an edit list could demand that, take audio from here and video from there, no?
[17:21] <Paranoialmaniac> wm4: so, your problem is libavformat uses sequential access after seek per file, not per track
[17:21] <Paranoialmaniac> ?
[17:21] <wm4> Paranoialmaniac: yes
[17:21] <wm4> the API was made for file formats with use interleaved audio and video data
[17:21] <wm4> like avi, mkv, etc.
[17:24] <Paranoialmaniac> yeah, it is realy annoying for random access per track with massive different delays. 
[17:25] <wm4> and ubitux was wondering if he can just ignore this issue
[17:25] <wm4> and assume that all referenced samples for one presentation sample are close enough together
[17:29] <Paranoialmaniac> wm4: i'm also annoyed for accurate seek with libavformat on frame-based editor. i use multiple avcormatctxs for a solution to that
[17:30] <Paranoialmaniac> avformatcontext per track
[17:31] <Compn> wonder how far the rm rewrite thing is , if anyone even started it ?
[23:17] <ubitux> michaelni: if you apply the uspp filter, don't forget to bump
[23:18] <ubitux> but saste might want to do it
[23:21] <ubitux> also missing a few comments i made
[23:21] <ubitux> but oh well, i'll just fix after
[23:58] <cone-470> ffmpeg.git 03Christian Suloway 07master:97b65f612617: avformat/hlsenc: added segment file deletion
[00:00] --- Thu Dec 11 2014