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

[burek]

[00:05] <michaelni> llogan, made one myself
[00:05] <michaelni> logo i mean not f.book
[00:08] <michaelni> http://ffmpeg.org/ff64logo.png
[00:52] <BBB> Skyler_: sure - I've put them on my list to try, just haven't gotten to it yet
[00:57] <Skyler_> BBB: I think some of the copies (e.g. 1881-1886) can be replaced with COPY64
[00:57] <Skyler_> since you're copying 0,0 to 1,0 and 0,1 to 1,1 etc
[00:57] <Skyler_> I guess we'll want to make sure we align the mvs
[01:17] <BBB> I believe I wnted to try to remove them, since I believe we're not using them
[01:18] <BBB> but I had to get the decoder functional first and then forgot
[01:46] <cone-427> ffmpeg.git 03Matt Oliver 07master:1ff42685fee2: avformat/libssh: Fix libssh defaulting to shared linkage.
[03:44] <cone-427> ffmpeg.git 03Marton Balint 07master:8e41240047db: lavfi/frei0r: load plugins from lib64 folders as well on 64bit builds
[03:55] <cone-427> ffmpeg.git 03James Almer 07master:6c12b1de064d: x86: add missing XOP checks and macros
[09:29] <pross-au> any reason why gsoc2011 is not mentioned on the 2014 page. that was the year there was split b/tween libav & ffmpeg.
[09:50] <superware> in my video player I have two threads, one for decoding and one for playback, should I queue packets or frames in the decoding thread?
[10:04] <thardin> superware: do what ffplay does
[10:09] <superware> thardin: but it uses SDL, I'm not
[10:12] <thardin> so?
[10:12] <thardin> that's just a difference in how you display the frames, not how you decode/queue them
[10:12] <superware> well, maybe unrelated. but ffplay.c is VERY complex (for me)
[10:13] <thardin> from experience I'd say it's better to adapt something that works (like ffplay) than to write something new
[10:13] <thardin> unless you're doing it just for fun :)
[10:13] <superware> but it does much more than I need, I just need to sync video frames for display, no audio
[10:13] <superware> heh
[10:16] <thardin> so just strip the audio stuff :)
[10:16] <superware> should I queue packets, process them on a dedicated thread and queue video frames and process them on yet another thread?
[10:17] <superware> I think it's more than that, it seems ffplay relies on audio for sync
[10:17] <thardin> not if the file doesn't have audio it doens't
[10:17] <thardin> but I say demux and decode in the same thread, enqueue for another thread
[10:18] <superware> enqueue packets or frames?
[10:18] <thardin> frames
[10:21] <superware> so the dequeue thread is pulling a frame, how much time should it delay before rendering it considering it's pts and prev frame pts?
[10:26] <thardin> the difference between the two?
[10:27] <thardin> or rather: compare the first frame's pts to your wall clock
[10:27] <thardin> then sync subsequent frames to the clock
[10:28] <superware> but on a live stream frames can come late, sometimes on time, but never early
[10:29] <thardin> oh. uh, dunno
[10:29] <thardin> delta-pts I suppose
[10:30] <thardin> keep in mind there's a rather course granularity to sleep()
[10:32] <superware> what do you mean?
[10:34] <thardin> try sleep(25):ing in a loop and see how accurate it is
[10:34] <thardin> or something like that
[10:35] <thardin> you'll have to experiment
[11:24] <superwar> thardin: how can I convert from one AVPixelFormat to another? sws_scale seems to also do it, but I don't need to rescale.
[11:26] <thardin> just use the same dimensions
[11:26] <thardin> iirc sws is quite clever
[11:26] <thardin> and will "get" that you only want to change pixel format
[11:26] <superwar> so there's no dedicated way?
[11:27] <nevcairiel> no, swscale is the only thing we have
[11:27] <nevcairiel> if you provide the same dimensions, it'll not scale
[11:27] <nevcairiel> well, some pixel format conversions require scaling
[11:28] <nevcairiel> because the size of the chroma planes change
[11:28] <thardin> if you convert say 4:4:4 to 4:2:0 it's scale chroma down
[11:28] <thardin> I think
[11:28] <thardin> yeah
[11:28] <superwar> oh
[11:31] <superwar> is there a way to decode straight to say AV_PIX_FMT_BGR0 ?
[11:31] <thardin> codecs decode what they decode to
[11:31] <thardin> except certain special cases
[11:32] <superware> I see
[11:32] <thardin> so for instance jpeg can decode to 4:2:0, 4:2:2 or 4:4:4 depending on input
[14:07] <Compn> why are people putting svq3 in mkv
[14:11] <rcombs> why are people putting svq3 in *anything*
[14:19] <thardin> I much prefer svq1
[14:19] <wm4> Compn: what muxing method? vfw?
[14:21] <wm4> ubitux: about frame based subtitles, I think we should add a DISPOSITION flag to signal frame based, and in that case make the timestamp the frame number (with a time base to get a "reasonable" fallback fps)
[14:22] <ubitux> timestamps are always frame number anyway
[14:22] <ubitux> (for frame based subs)
[14:23] <wm4> yeah, that should just be documented, not that it's broken later because it was merely implicit
[14:33] <Compn> wm4 : no idea, going from bug 3256
[14:33] <Compn> https://trac.ffmpeg.org/ticket/3256#comment:10
[14:33] <Compn> ffmpeg remux
[14:33] <wm4> ok
[14:33] <wm4> QT muxed
[14:33] <wm4> disgusting
[14:49] <Daemon404> libx265 wrapper is done -- just need soe bugs fixd upstram before i submit it
[14:52] <ubitux> libx265 does stable release?
[14:52] <Daemon404> they do, but thats not the issue :P
[15:03] <Daemon404> ubitux, im mostly waiting for a working pkg-config :P
[15:04] <Daemon404> and soname
[19:06] <JEEB> did someone here e-mail or something that mp3 gets misdetected as mp1 sample to cehoyos? because he e-mailed me and seems to have very bad understanding of what multimedia frameworks are
[19:07] <JEEB> I mean, I _know_ lavf/lavc developers never think of these libraries being used for separate components instead of one monolithic thing like mplayer/mplayer2/mpv/VLC etc.
[19:07] <JEEB> but this level of herp and derp kind of makes me do an inner barrell rol
[19:07] <JEEB> *roll
[19:08] <wm4> yeah, mp3 detection has many issues
[19:09] <wm4> and all of these players you listed actually do have extra abstraction layers between the libav* libs
[19:09] <JEEB> yes but they generally don't have anything else in there that could get used
[19:10] <wm4> somewhat true
[19:10] <JEEB> first exchange http://up-cat.net/p/4b24e3fb , second exchange http://up-cat.net/p/29f910f2 , and then the latest http://up-cat.net/p/18eef479
[19:10] <wm4> mplayer and vlc have tons of other decoders, especially audio decoders, though
[19:10] <JEEB> I hope someone can at least take that as funny .-.
[19:10] <JEEB> because I'm kind of getting aggravated
[19:11] <wm4> wait, so if you give libavcodec "mp1", it decodes it fine even if it's really mp3?
[19:11] <JEEB> yes
[19:11] <wm4> funky
[19:11] <JEEB> it switches automagically or something
[19:12] <JEEB> I bet cehoyos will just say "lower the MS filter's merit" or "heighten your merit"
[19:12] <JEEB> which has nothing to do with the actual issue
[19:13] <JEEB> and do note, that I am actually being nice
[19:13] <JEEB> And yes, of course I could just "if (format==mp4 && codec==mp1) codec
[19:13] <JEEB> = mp3;" but that is a horrible hack. I am just wondering if more of
[19:13] <JEEB> the stream could be analyzed for a more correct tagging of the stream
[19:13] <JEEB> (or something like that). If not, then of course other alternatives
[19:13] <JEEB> have to be looked into on my side.
[19:13] <wm4> can mp1 be in mp4?
[19:13] <wm4> (also damn these names)
[19:13] <JEEB> in theory yes
[19:14] <wm4> then the situation is rather fucked up
[19:14] <JEEB> since that specific way of muxing is for all of ISO/IEC 11172-3
[19:14] <JEEB> which contains "mp1", "mp2" and mp3
[19:17] <wm4> but yeah, he's trying to discuss away the real issue
[19:17] <wm4> instead of looking how to fix it
[19:19] <JEEB> ok, I don't even know how to reply to his newest reply
[19:20] <JEEB> http://up-cat.net/p/ba0c2cad
[19:21] <Daemon404> "u r fagget"
[19:21] <Daemon404> proper internet response
[19:21] <JEEB> someone bring me a 12pack of beer and I will do that
[19:21] <JEEB> otherwise I'm way too good-minded
[19:24] <wm4> lol
[19:25] <wm4> so why doesn't he put that proposed hack into lavf?
[19:25] <wm4> if mp1 in mp4 supposedly does not exist in the wild
[19:26] <ubitux> < JEEB> did someone here e-mail or something that mp3 gets misdetected as mp1 sample to cehoyos? // he back logs this channel
[19:26] <JEEB> ok
[19:45] <JEEB> http://up-cat.net/p/b937564b
[19:46] <JEEB> I feel horrible after writing this
[20:20] <ubitux> Daemon404: sorry i missed the changelog entry on top
[20:23] <Daemon404> i noticed
[20:23] <Daemon404> :P
[20:28] <wm4> JEEB: lol
[20:29] <JEEB> wm4, there have been such times only rarely when I have felt the urge to punch someone in the face
[20:30] <wm4> reminds me of sending 1 line patches to ffmpeg-devel, and somehow ending up in flames
[20:31] <Daemon404> JEEB, welcome to carl
[20:31] <Daemon404> join the job
[20:31] <Daemon404> there are liek a dozen of us
[20:33] <nevcairiel> wm4: why do you think i so rarely upstream my changes :d
[20:40] <ubitux> Daemon404: btw, LGPL?
[20:41] <JEEB> Daemon404, I don't want to have negative feelings about the guy, but it seems like I can't help it :P
[20:41] <Daemon404> ubitux, x265 is gpl
[20:41] <Daemon404> making the wrapper lgpl is pointless.
[20:42] <Daemon404> oh indeed it's lgpl
[20:42] <Daemon404> in which case it's a no-op anyway
[20:42] <Daemon404> :D
[20:42] <ubitux> you have a gpl "dep"
[20:43] <ubitux> if you keep it,
[20:43] <ubitux> update LICENSE
[20:43] <Daemon404> it is a d ep
[20:43] <Daemon404> x265 is GPL
[20:43] <ubitux> then add it to the appropriate section in LICENSE
[20:43] <ubitux> sorry i didn't notice earlier
[20:43] <Daemon404> gotcha
[20:44] <JEEB> libx264 wrapper is LGPL IIRC as well
[20:44] <Daemon404> at least you didnt tell me i a missed aligning an =
[20:44] <ubitux> having the wrapper LGPL is useful for one reason
[20:44] <ubitux> if the library get relicensed
[20:44] <ubitux> you don't have to query every single contributor to the wrapper
[20:47] <Daemon404> lol
[21:03] <BtbN> Is it possible to tell the configure script to generate a static ffmpeg binary? disable-shared enabled-static doesn't achive that.
[21:04] <nevcairiel> it should
[21:04] <BtbN> the libav* libs are static, but it still depends on a lot of shared system libs
[21:05] <ubitux> BtbN: http://ffmpeg.gusari.org/static/
[21:05] <ubitux> see how those are done
[21:05] <nevcairiel> probably needs --extra-ldflags="-static"
[21:06] <nevcairiel> maybe also in cflags, idk
[21:10] <Daemon404> careful
[21:10] <Daemon404> that with static link glibc
[21:10] <Daemon404> which is Not Good
[21:10] <Daemon404> (on glibc systems anyway)
[21:11] <nevcairiel> he wanted static
[21:11] <nevcairiel> too bad its not so trivial to link extra libs static but libc shared
[21:14] <BtbN> it's linking in stuff like libpulse 4.0, which isn't available. So for a test binary static glibc should be ok
[21:14] <BtbN> isn't available on most systems
[22:34] <ubitux> Daemon404: you sure you sent v2?
[22:34] <ubitux> i still see trailing comma after {NULL}, bad project copyright etc
[22:37] <Daemon404> fuck i forgot the copy right
[22:37] <Daemon404> and i purpsely left { NULL },
[22:37] <Daemon404> purposely*
[22:38] <Daemon404> we do this a lot throughout the codebase
[22:39] <ubitux> that's just bad copy paste
[22:39] <ubitux> and we don't at least in lavfi
[22:40] <ubitux> there is no reason to keep that comma since we will never add an entry after it
[22:41] <ubitux> [~/src/ffmpeg]- git grep '{ *NULL *}$'|wc -l
[22:41] <ubitux> 487
[22:41] <ubitux> [~/src/ffmpeg]- git grep '{ *NULL *},'|wc -l
[22:41] <ubitux> 155
[22:44] <Daemon404> sure ok
[22:44] <Daemon404> i will both before i push
[22:44] <Daemon404> ive fixes teh licensed locally already
[23:03] <cone-297> ffmpeg.git 03Maxim Poliakovski 07master:d6d78518018a: g2meet: factor out seeking to the chunk end
[23:04] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:852dcf336bc5: Merge commit 'd6d78518018a12fb495baab5663708a830f3aab6'
[23:12] <J_Darnley> Did somebody forget to upload a few HEVC files to th fate sample server?
[23:18] <michaelni> J_Darnley, try again
[23:19] <J_Darnley> Yes, rsync copied the files
[23:20] <cone-297> ffmpeg.git 03Kostya Shishkov 07master:6477449243db: g2meet: make JPEG tile decoder operate on 8x8 block mask
[23:20] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:bde58d990158: Merge commit '6477449243db4aab15a4db356e8354c60b5366ec'
[23:29] <J_Darnley> and now fate finishes without error
[23:37] <cone-297> ffmpeg.git 03John Stebbins 07master:52771346dc78: lavc: set AVFrame pkt_pts and reordered_opaque in reget_buffer
[23:37] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:707a07f3c2b5: Merge remote-tracking branch 'qatar/master'
[00:00] --- Wed Feb 12 2014