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

[burek]

[00:29] <cone-186> ffmpeg.git 03Stefano Sabatini 0708d0969c1402: lavu/opt: change the way default pixel and sample format value is set
[01:21] <burek> "I have a few mp4 files that have captions embedded into them, however I would like to do some HLS segmenting with ffmpeg and have it also segment the caption track as well as the video track. Is this possible in ffmpeg? Thanks!"
[01:21] <burek> is that possible?
[01:24] <saste> burek: not that easy since subtitles are sparse
[01:25] <saste> when you have subtitles spanning two segments, you lose the information stored in the first part
[01:26] <burek> i see
[01:26] <burek> ok, thanks a lot for the explanation :)
[01:33] <ubitux> rhaa why the dvd packets aren't muxed properly :(
[01:37] <ubitux> saste: about the bump & stuff, i think nicolas wants it because there is a lavfi filter in mplayer
[01:37] <ubitux> he is the author, and it seems to be using start_frame & stuff
[01:37] <ubitux> at least the avfilter_start_frame funcs
[01:38] <saste> isn't mplayer using an internal ffmpeg?
[01:38] <ubitux> yes
[01:38] <ubitux> mplayer1 at least
[01:38] <saste> well in that case I think it is safe to bump, but we shouldn't advertise in APIchanges internal API
[01:38] <ubitux> and only upstream is supported
[01:38] <ubitux> yes i agree
[01:47] <Compn> what
[01:47] <Compn> lavfi thing isnt enabled in mplayer
[01:47] <Compn> we should enable it
[01:47] <Compn> because its awesome :)
[01:48] <ubitux> it likely doesn't build anymore
[02:56] <ubitux> question in mpegps_read_pes_header: in case of PACK_START_CODE, it will browse the data until the next start code; why not make a smart skip?
[02:57] <ubitux> (like using the size at p[13] + 14)
[02:57] <ubitux> before looking again for startcode
[03:00] <ubitux> and maybe in some other cases as well btw
[04:19] <cone-216> ffmpeg.git 03Michael Niedermayer 07a2f680c7bc76: mjpegdec: check h/v_count, fix context becoming inconsistent and causing out of array accesses.
[04:19] <cone-216> ffmpeg.git 03Michael Niedermayer 07bc16031a410e: mjpegdec: print error message when quant_index is invalid
[05:38] <wm4> michaelni: why does mplayer prefix the filename passed to avformat_open_input() with "mp:"?
[05:38] <wm4> ubitux: there's a very fun thing in libavfilter: it depends on both libavresample and libswresample
[05:38] <wm4> just... wat
[05:39] <wm4> also, why is there no configure option to disable libmpcodecs? this makes it impossible to do static linking with mplayer or clones
[05:45] <ubitux> wm4: lavfi has no deps on avr nor swr; some filters do
[05:45] <ubitux> libav's filters depend on avr, ours depend on swr
[05:45] <ubitux> wm4: --disable-filter=mp
[05:46] <ubitux> btw, just finished my vobsub demuxer \o/
[05:46] <ubitux> and it works \o/
[05:49] <ubitux> now i need to fix the mkv muxer&
[05:50] <ubitux> write a proper subtitles seeking
[05:50] <ubitux> and then profit.
[05:52] <wm4> ubitux: does this vobsub demuxer handle .idx/.vob pairs of files?
[05:52] <ubitux> yes
[05:53] <wm4> how is that handled on the api level?
[05:53] <ubitux> no
[05:53] <ubitux> you "open" the .idx file
[05:54] <ubitux> then it gives you dvd subtitles packets
[05:54] <cone-216> ffmpeg.git 03Michael Niedermayer 07d9bec3b6a29a: lavc: fix duplicate stats_out line.
[05:54] <ubitux> the problem is with the seek, i need to finish another patchset; when it's done it will be usable for mplayer
[05:54] <ubitux> right now you can for instance remux a VobSub into a mkv
[05:55] <wm4> with mplayer's -subfile you mean
[05:55] <ubitux> it's a bit special, i don't remember how -subfile works
[05:55] <ubitux> but it's not like text subtitles files
[05:56] <ubitux> you can't decode everything a send it to the renderer
[05:56] <ubitux> (at startup)
[05:56] <wm4> -subfile opens subtitles with a demuxer
[05:56] <ubitux> vobsub needs special handling
[06:11] <ubitux> ffmpeg is kind of slow to mux mkv&
[06:31] <wm4> ubitux: speaking of making everything complicated, will lavfi have a subtitle format type too? (additional to audio and video)
[06:33] <ubitux> wm4: that's the plan, but i don't think it will happen soon
[06:33] <ubitux> Nicolas was talking about data filtering too
[06:33] <ubitux> wm4: why are you interested in this?
[06:33] <ubitux> i sent yesterday a patch for hardsubbing all kind of subtitles
[06:33] <ubitux> (text) subtitles
[06:34] <ubitux> i think that covers most of the use cases :p
[06:41] <wm4> how do you handle rendering subtitles onto images?
[06:42] <ubitux> libass
[06:43] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134900.html
[06:46] <wm4> I meant blending subtitle images and images
[06:47] <ubitux> lavfi has a blending api
[06:47] <ubitux> (internal)
[06:47] <ubitux> the drawutils contains several useful features
[06:48] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/drawutils.c;hb=HEAD#l332
[06:48] <wm4> I know
[06:48] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_ass.c;hb=HEAD#l166
[06:48] <ubitux> so that's what i use
[06:48] <wm4> I don't think that handles blending of paletted images
[06:50] <ubitux> possible, dunno
[06:50] <wm4> ubitux: also this drawutils things, it doesn't upsample the image before blending?
[06:50] <ubitux> i don't think so
[06:51] <ubitux> it supports most of the yuv pixfmt directly afaict
[06:51] <wm4> well, mplayer's vf_ass upsamples for quality reasons AFAIK, not because handling subsampling "directly" would be harder
[06:52] <ubitux> i don't know, i'm not familiar with this
[07:41] <wm4> are libavformat demuxer names not unique? why?
[10:19] <cone-739> ffmpeg.git 03Carl Eugen Hoyos 07ccf771cd7964: Correctly skip strf tag for subtitles when decoding avi.
[11:28] <wm4> ubitux: even so, libavfilter.pc fails to correctly declare the dependency on libavresample, please fix
[11:29] <wm4> ubitux: and --disable-filter=mp really should be the default
[11:29] <durandal_1707> really? I do not have libavresample installed
[11:29] <durandal_1707> contact l
[11:29] <wm4> durandal_1707: if you enable libavresample explicitly, libavfilter will use it, but not list it as dependency
[11:30] <durandal_1707> wm4: is same in libav?
[11:31] <wm4> no idea
[11:32] <durandal_1707> thing is here we do not touch libavr related code at all
[11:33] <wm4> I'm still blaming you, though
[11:48] <cone-739> ffmpeg.git 03Paul B Mahol 0750b5c2296ab3: iff: MAUD support
[11:48] <cone-739> ffmpeg.git 03Paul B Mahol 071560c3295db0: iff: fix some incorrect interpretations of invalid files
[11:51] <cone-739> ffmpeg.git 03Paul B Mahol 07d4c59f77b683: adpcm/thp: cosmetics: reindent
[11:54] <durandal_1707> anyone working on merging gif patches?
[14:06] <ubitux> wm4: you need to add an entry around configure:4420 
[14:09] <ubitux> it seems l doesn't have these dep at all btw
[14:11] <ubitux> in l you just have a dep to libavutil
[14:20] <ubitux> wm4: about mp wrapper, it's pretty useful for users, so i'd better not disable it by default
[14:20] <ubitux> though, you are welcome to contribute porting the filters so we can get rid of it :)
[14:20] <wm4> are there any useful filters left
[14:20] <ubitux> telecine & interlacing filters mostly
[14:22] <ubitux> (sorry configure:4500)
[14:27] <cone-739> ffmpeg.git 03Clément BSsch 078119d8b01f83: configure: add lavfi avr dep to .pc when required.
[14:27] <ubitux> wm4: ^
[14:27] <ubitux> try and tell me
[14:28] <wm4> thanks
[14:28] <ubitux> durandal_1707: i'm not working on merging gif patches
[14:55] <cone-739> ffmpeg.git 03Janne Grunau 073ae69b91668e: flashsv: make sure data for zlib priming is available
[14:55] <cone-739> ffmpeg.git 03Janne Grunau 07c1fcf563b130: h264: check context state before decoding slice data partitions
[14:55] <cone-739> ffmpeg.git 03Diego Biurrun 07cc7d5cfeec94: img2: K&R formatting cosmetics
[14:55] <cone-739> ffmpeg.git 03Diego Biurrun 079d46eaec7a90: build: The FLAC encoder also depends on the flacdsp code
[14:55] <cone-739> ffmpeg.git 03Michael Niedermayer 07db29a7c7c282: Merge commit '9d46eaec7a90bd8f5cd9e45398c6d17804182320'
[15:06] <cone-739> ffmpeg.git 03Martin Storsjö 0715caccb9be2a: cmdutils: Use a configure check for enabling CommandLineToArgvW
[15:06] <cone-739> ffmpeg.git 03Martin Storsjö 0715816c8e8bd5: avutil: Include io.h with a separate condition from MapViewOfFile
[15:06] <cone-739> ffmpeg.git 03Michael Niedermayer 07034a1afbd85e: Merge remote-tracking branch 'qatar/master'
[15:51] <Compn> wow rockbox has a lot of fixed point decoders
[15:51] <Compn> that would be nice to import back :)
[15:51] <Compn> http://git.rockbox.org/?p=rockbox.git;a=tree;f=lib/rbcodec/codecs
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 07c5fe41c7680c: Add meaningful error codes and constants.
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 0791499f4ee825: Prepare gif decoder for use in conjunction with gif demuxer.
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 07de0cb7f070dc: Additional checks to prevent overread.
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 07005cb97e3e71: Move some definitions to header file.
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 075603b2bf6e00: Gif demuxer
[15:59] <cone-739> ffmpeg.git 03Vitaliy E Sugrobov 07f83657fcf609: Add exception for "gif" in image2 probe() method.
[16:03] <Compn> bam! gif!
[16:03] <cone-739> ffmpeg.git 03Paul B Mahol 07d56b15017a1e: undo file modifiers that suck in
[16:04] <ubitux> and it works \o/
[16:04] <ubitux> nice :)
[16:04] <ubitux> i can ffplay bbb.gif \o/
[16:05] <wm4> time to remove demux_gif from my mplayer fork
[16:05] <wm4> can this demuxer seek?
[16:05] <ubitux> seems not :(
[16:05] <durandal_1707> mplayer one can?
[16:06] <wm4> durandal_1707: no
[16:06] <durandal_1707> are there such big files where seeking make sense?
[16:06] <Compn> not really
[16:06] <wm4> no, but being able to skip back to the beginning would be useful
[16:06] <wm4> e.g. for looping
[16:06] <Compn> some gifs may go for a minute or two tho :P
[16:06] <Compn> mplayer gif -loop 0
[16:07] <Compn> loop loop loop loop
[16:07] <Compn> oh you meant incomplete loop
[16:07] <durandal_1707> gifs do not have keyframes except first one, but you could cat several of them into one .... 
[16:07] <Compn> mplayer -frames 10 -loop 0 gif
[16:08] <Compn> ubitux : do you remember last mail talking about ffmpeg crowd funding ?
[16:08] <Compn> i forgot the subject cant find it
[16:09] <ubitux> Donations via ffis
[16:09] <ubitux> ?
[16:09] <ubitux> maybe.
[16:09] <ubitux> ask saste otherwise
[16:09] <Compn> that sounds like it
[16:09] <Compn> thx
[16:10] <ubitux> would be nice if the demuxer could honor loops
[16:10] <Compn> oh, looped gifs
[16:10] <Compn> you really want it playing forever tho?
[16:10] <Compn> i guess users want to do dumb stuff...
[16:11] <durandal_1707> are loops stored in gifs?
[16:11] <ubitux> there is a loop flag yes
[16:11] <wm4> ubitux: I think it'd be better to set a metadata flag for that, and let the application handle looping
[16:12] <ubitux> no idea
[16:12] <wm4> the file is not infinite, it just has a loop flag set
[16:12] <wm4> it should be treated as such
[16:13] <ubitux> what if the format doesn't support seek, except a particular one for looping?
[16:13] <ubitux> doesn't it make it an infinite stream?
[16:14] <wm4> which format would that be
[16:14] <ubitux> gif?
[16:14] <Compn> wm4 : we're saying , if you use ffmpeg -i file.gif out.avi , and the loop flag is set (and ffmpeg supports loop) ... wouldnt it encode forever ?
[16:14] <Compn> how many loops would it encode ?
[16:15] <nevcairiel> one unless you tell it otherwise? :d
[16:15] <ubitux> i'd make a private option instead but well
[16:15] <ubitux> -noloop demxuer option or something
[16:15] <Compn> heh
[16:15] <ubitux> -honor_loop 0/1
[16:15] <Compn> rather have a -loop like mplayer/mencoder has
[16:15] <Compn> that way anything can be looped
[16:16] <Compn> reguardless of format
[16:16] <ubitux> ffplay has a -loop
[16:16] <Compn> regardless*
[16:16] <ubitux> it doesn't work with gif because seek is not supported
[16:16] <Compn> ah
[16:16] <Compn> then ignore me :D
[16:20] <Compn> hmm
[16:20] <Compn> crowdfunding site from brazil
[16:20] <Compn> http://catarse.me/en
[16:20] <Compn> dunno about being called 'cat arse' tho
[16:21] <cone-739> ffmpeg.git 03Michael Niedermayer 0750cbe09d8ced: smacker: check smacker_decode_tree() return value
[16:21] <cone-739> ffmpeg.git 03Michael Niedermayer 072c69fcc2ffe6: smacker: more complete vlc length check, fixes out of array read
[16:34] <durandal_1707> hmm why is seeking for gif enabled if it does not work at all
[16:55] <ubitux> wm4: still no website, with differences info, irc channel etc for your fork?
[16:56] <durandal_1707> ubitux: #mpv-player
[16:56] <durandal_1707> and mpv-player on github
[16:56] <ubitux> yes but there is not much about the projet
[16:56] <ubitux> thx for the channel
[16:57] <wm4> no real "website" to speak of, but DOCS/man/en/changes.rst has a small list of changes
[17:00] <durandal_1707> its goal is to not be bloated like mplayer
[17:09] <Compn> delicious mplayer bloat
[17:09] <Compn> wm4 : you should make pulse or jack the only audio output and remove all others :D
[17:10] <wm4> I'd rather remove pulse and jack if the code removal should go that far
[17:12] <cone-739> ffmpeg.git 03Paul B Mahol 0757b00d7ab1e3: gifdec: remove width and height from demuxer context
[17:54] <cone-739> ffmpeg.git 03Paul B Mahol 07daede25f0b33: update Changelog
[18:22] <TheJK> have looked thru the mailing list, and seen that Adobe HDS (http dynamic streaming) isn't supported.  Just curious, if anyone is actively working on ffmpeg support for it?
[18:24] <Compn> TheJK : someone said they were interested in working on it on the list
[18:24] <Compn> or maybe on irc
[18:25] <Compn> let me see i fi can di g it up
[18:25] <Compn> might be on bugtracker
[18:25] <Compn> hmmm
[18:25] <TheJK> ah, you referring to: [14:32] <ubitux> no idea, i'm going to look at hds now 
[18:26] <TheJK> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2012-August/000846.html
[18:26] <Compn> TheJK : http://ffmpeg.org/trac/ffmpeg/ticket/1964
[18:26] <Compn> ubitux did a WIP on it
[18:26] <Compn> if you want to continue developing that
[18:27] <Compn> (yes, i realize ffmpeg has too many communication methods, spread everywhere)
[18:27] <Compn> irc, mailing list, bug tracker, wiki
[18:28] <Compn> TheJK : are you interested in developing it , or just want that feature ?
[18:31] <TheJK> Thanks Compn for that link.  Sorry, at this point -- I just "need" that feature :(
[18:33] <Compn> TheJK : why not use the adobehds script to save your file ?
[18:33] <Compn> stream/whatever its called
[18:33] <Compn> adobehds.php
[18:34] <TheJK> Compn - I'm looking at this ticket, and it seems to be for ffmpeg playback on desktop?  Trying to look to convert something into Adobe HDS.  Checking adobehds.php
[18:37] <Compn> oh you want to stream using adobe hds
[18:37] <Compn> sorry, adobehds.php is only for saving streams ...
[18:37] <Compn> why not use adobe products to server then? :P
[18:38] <TheJK> Gotcha, do you know if anyone is actively working on 'hds streaming' via ffmpeg?  Like how you support it with HLS?
[18:39] <Compn> i dont know of anyone working on it
[18:39] <Compn> you could ask on the list for best results
[18:39] <TheJK> k, tnx, appreciate the help
[18:39] Action: ubitux just saw Rain Town, and it's awesome
[18:49] <saste> TheJK: we usually suggest to create a ticket, and add as many information as possible (e.g. a link to the spec)
[18:49] <ubitux> a ticket is opened
[18:49] <ubitux> #1964
[18:49] <saste> also patches are welcome, so if you need that feature and you want/can implement it we will help
[18:50] <saste> ok
[18:56] <ubitux> unrelated, a nice testing gif: https://upload.wikimedia.org/wikipedia/commons/1/10/Waving_reeds_cinemagraph.gif
[19:05] <cbsrobot> ubitux: when does it stop ?
[19:06] <cbsrobot> I prefer http://bunkstrutts.files.wordpress.com/2010/03/robot-ape-monster_mogadoia-100301.gif
[19:06] <ubitux> :)
[19:06] <ubitux> https://upload.wikimedia.org/wikipedia/commons/6/65/Steak_on_the_Grill.gif this one is nice as well
[19:07] Action: cbsrobot feels this channel will become the new imgur
[19:07] <ubitux> :))
[19:07] <cbsrobot> ubitux: you could change the topic before it's too late !
[19:08] <ubitux> :)
[19:09] <cbsrobot> for michaelni http://bunkstrutts.files.wordpress.com/2012/11/quasicrystals-enlarged.gif
[19:09] <cbsrobot> ah sorry this I meant: http://bunkstrutts.files.wordpress.com/2012/11/quasicrystals-as-sums-of-waves-in-the-plane.gif
[19:10] <ubitux> @_@
[19:12] <ubitux> i love this
[19:12] <cbsrobot> we should provide a new protocol handle like: ffmpeg:http://bunkstrutts.files.wordpress.com/2012/11/quasicrystals-as-sums-of-waves-in-the-plane.gif that would automaticly open ffplay ...
[19:12] <ubitux> saste: we need a crystals source!
[19:12] <ubitux> or adapt life
[19:13] <saste> ubitux, how is it generated?
[19:14] <ubitux> no idea but that's pretty nice
[19:16] <wm4> does ffmpeg have an internal caching layer of some sorts? (for network streaming)
[19:21] <saste> ubitux: http://mainisusuallyafunction.blogspot.it/2011/10/quasicrystals-as-sums-of-waves-in-plane.html
[19:22] <saste> BTW I managed to datamosh through the bitstream API, but the API itself is pretty limited
[19:24] <ubitux> http://www.jasondavies.com/animated-quasicrystals/
[19:24] <ubitux> huhu
[19:25] <ubitux> saste: haha so you're doing the datamosh thing? :)
[19:26] <saste> ubitux, I wrote a simple filter based on noise, which simply returns a 0-sized packet if the packet is a keyframe
[19:27] <saste> but it lacks configurability, at least we should be able to select which frames to drop, and to duplicate frames in order to implement all aviglitch functionality
[19:27] <ubitux> ok :)
[19:42] <ubitux> michaelni: the split side data thing really is causing problems
[19:42] <ubitux> michaelni: i have one with -c copy between srt here now
[19:43] <ubitux> can't we just get rid of this?
[19:53] <michaelni> ubitux, what side data in what case is causing what problem ?
[19:55] <ubitux> position side data in srt demuxing
[19:55] <ubitux> if you codec copy
[20:01] <Compn> ubitux : michael probably wants something quick he can reproduce , sample + command line :P
[20:01] <wm4> ffplay yv12input.mkv -vf "scale,format=yuv444p12,scale" produces a nice deep green tinted image
[20:02] <wm4> I suppose that's a libswscale bug
[20:09] <michaelni> ubitux, how is this design supposed to work with srt in some random container, mkv, nut, ... ?
[20:09] <ubitux> they ignore that extradata
[20:10] <ubitux> in mkv you might be able to put it in some extra area
[20:10] <michaelni> so the side data is optional and srt works if its "Lost" ? 
[20:11] <michaelni> iam curious why half the data is stored as data and half as side data
[20:11] <ubitux> yes it works
[20:12] <ubitux> the position isn't honored that's all
[20:12] <michaelni> so why does the demuxer add the side data at all ?
[20:13] <michaelni> hmm
[20:13] <michaelni> if i underatand you correctly
[20:13] <michaelni> with side data theres position, and if the side data is droped theres no position
[20:13] <michaelni> ?
[20:14] <ubitux> well it will be displayed at the default position
[20:14] <ubitux> but yeah that's the idea
[20:14] <michaelni> thats a very broken design
[20:14] <ubitux> the thing is, this data is shared with the timing info, and can't be part of the payload
[20:14] <ubitux> and it's event specific
[20:17] <michaelni> with this design i suspect that the most functional results would be achived by calling the side data split in the demuxers that support srt side data
[20:18] <michaelni> s/demuxers/muxers/
[20:18] <michaelni> the other muxers would store the merged side data and it may preserve the position
[20:18] <michaelni> with luck ...
[20:19] <ubitux> is this side data splitting really necessary?
[20:19] <ubitux> i mean, i don't mind helping to fix the projects doing evil things instead of this
[20:20] <michaelni> without the split / merge, with how many muxers does srt work ? one ? none ?
[20:20] <michaelni> it requires code in every muxer to do something with the side data
[20:21] <michaelni> or the position is lost
[20:24] <ubitux> yes, but it's likely coded differently in every muxer
[20:24] <ubitux> in a "srt" output, it's as text along the timing information
[20:24] <ubitux> in mkv it might be stored in a particular field
[20:24] <ubitux> in some other containers, it's likely unsupported
[20:25] <ubitux> it really is extradata in its pure sense :p
[20:25] <ubitux> there is the exact same design problem with webvtt btw
[20:25] <ubitux> there are extradata along with the timing information
[20:25] <ubitux> and it's stored in a particular field in webm (iirc)
[20:25] <michaelni> mpeg1 has timing and quantization and other "extradata" too but no such problem arrises
[20:26] <michaelni> its stored the same way everywhere
[20:26] <ubitux> because it's not "text" i guess
[20:26] <michaelni> hmm
[20:26] <michaelni> id say the problem arrose because mkv choose to store it differently than raw srt
[20:26] <ubitux> every muxer will store it differently
[20:27] <wm4> btw. it might be rather easy to construct an ass file that breaks with ffmpeg, but not with other demuxers
[20:27] <ubitux> how would you store them in, let's say, nut?
[20:27] <ubitux> remember, you have: the timing information, the extradata, and the payload
[20:27] <michaelni> nut requires it to match raw srt i think without checking the spec
[20:27] <ubitux> you can put timing + extradata into the payload, but it sucks
[20:28] <ubitux> right, but mkv is packetizing srt
[20:28] <ubitux> it's muxing "subrip" packets
[20:28] <ubitux> srt is the container for subrip packets
[20:28] <ubitux> and that containers store timestamps in text, and extradata in text along the timing
[20:28] <ubitux> and then the payload
[20:29] <ubitux> the subrip packets will be stored differently in every containers
[20:29] <ubitux> there might be no place for the extradata, but& it's extra, so no worry
[20:32] <wm4> so shall I report the issue with this, or is it a known problem: ffplay yv12input.mkv -vf "scale,format=yuv444p12,scale"
[20:34] <llogan> green-o-vision. that's a feature.
[20:39] <ubitux> wm4: seems i can reproduce just with ffplay -f lavfi testsrc -vf format=yuv444p12
[20:40] <Compn> do filters support 12bit 444 ?
[20:40] <Compn> :P
[20:41] <michaelni> ubitux, if the problem is that the muxer sees merged side data, the solution is to split it. That can be done in the muxer itself or in something like av_write_frame()
[20:42] <wm4> Compn: it's a bug in libswscale, it doesn't have to do with filters
[20:46] <ubitux> michaelni: i believe that stuff really is a pain :(
[20:47] <ubitux> does it have any benefits except supporting very old apps (which ones?)
[20:48] <michaelni> srt is a pain
[20:48] <ubitux> not that much
[20:48] <ubitux> it will be the same with webvtt
[20:48] <ubitux> and maybe some others
[20:50] <michaelni> requireing code specific for each codec in a muxer is broken
[20:50] <ubitux> i don't understand
[20:50] <wm4> hm the test file didn't quite give the result I expected
[20:51] <ubitux> michaelni: isn't a muxer supposed to arrange the data available in the way it wants it?
[20:51] <michaelni> ubitux, how many codecs do we support? how many containers?
[20:51] <ubitux> those data being timestamps, durations, payload, extradata
[20:51] <michaelni> imaging every codec and container worked like srt is designed
[20:51] <ubitux> it's extradata, it's not mandatory :)
[20:51] <michaelni> mpeg1 has timestamps and durations too
[20:52] <michaelni> they too are not mandatory in the same sense
[20:52] <wm4> ubitux: http://bpaste.net/show/7xvdze7gR1x3gjPfk2pQ/
[20:53] <wm4> ubitux: strangely, it seems my mplayer-svn (and my fork too) doesn't deduplicate anything at all, so there must be a bug somewhere
[20:53] <ubitux> wm4: what's the bug?
[20:53] <ubitux> how to reproduce?
[20:53] <ubitux> michaelni: well, then what about let's say, a palette extradata?
[20:54] <michaelni> belongs in extradata is global or payload if not
[20:54] <michaelni> its put in sidedata and well that causes problems
[20:54] <wm4> ubitux: the first rectangle should be less transparent than the second (lower/right) one
[20:54] <wm4> ubitux: anything else is a bug
[20:54] <wm4> ubitux: try seeking too
[20:54] <wm4> ubitux: mkvmerge -o test.mkv arbitraryinput.mkv sub.ass
[20:55] <wm4> I think using mplayer -ass with -demuxer mkv and -demuxer lavf should work
[20:55] <wm4> for the purpose of a comparison
[20:55] <wm4> actually scratch that
[20:55] <ubitux> michaelni: then maybe we need two kinds of extradata or something?
[20:56] <ubitux> (but i still don't see the point of mixing the extradata in the payload :p)
[20:56] <ubitux> wm4: no problem?
[20:56] <michaelni> ubitux, i fail to understand what problem you try to solve
[20:56] <wm4> ubitux: no, mplayer1 doesn't do anything correctly
[20:57] <wm4> ubitux: seeking in mplayer1 will mess up semi-transparent subtitles no matter what
[20:57] <michaelni> if its that merged side data hits a muxer its 1 line of code to fix
[20:57] <wm4> mplayer2 doesn't handle ffmpeg-style ass packets
[20:57] <wm4> ubitux: either way, ffmpeg still does it demonstratably wrong
[21:02] <ubitux> michaelni: AVFMT_FLAG_KEEP_SIDE_DATA?
[21:02] <ubitux> wm4: will look in a moment
[21:03] <ubitux> michaelni: btw, you have a look to the latest seek patch and ass demuxer rewrite so i can move ahead?
[21:03] <ubitux> i've quite a bunch of pending text subtitles patches in a lot of branches
[21:03] <ubitux> so i'm a bit lost to demonstrate anything :p
[21:05] <michaelni> ubitux, av_packet_split_side_data()
[21:05] <wm4> ubitux: see ticket #1924
[21:06] <michaelni> where would you want to set AVFMT_FLAG_KEEP_SIDE_DATA ?
[21:07] <ubitux> michaelni: i was wondering if you were talking about disabling the feature for one muxer or something
[21:08] <ubitux> wm4: i'll look at this tonight
[21:10] <michaelni> ubitux, there are 2 ways
[21:10] <ubitux> arg i really need to do a lot of things for subtitles
[21:11] <michaelni> either disable it for all muxers or disable it for the ones that support extracting side data
[21:11] <michaelni> both variants have different problems
[21:11] <michaelni> but they are more a consequence of srt than anything else
[21:12] <ubitux> i'll first make the srt muxer honor them
[21:12] <ubitux> then if someting is available in the matroska as well
[21:12] <ubitux> and then i'll see how to drop the extradata from the payload :p
[21:12] <ubitux> anyway, i "need" to push the other standing patches first
[21:15] <wm4> ubitux: that's confusing... it seems ass_process_data() (the libass function ffmpeg forces you to use) doesn't actually check for duplicate events
[21:16] <wm4> ubitux: so you'd have to delete all events on seeking, which would make playback worse
[21:17] <ubitux> yes
[21:17] <ubitux> process_data is a "file" mode
[21:17] <ubitux> it can't really work well
[21:17] <wm4> but apparently it was added only for this purpose (ffmpeg demuxing)
[21:17] <ubitux> i know we need to address that issue, i still don't know the best way to change this
[21:17] <ubitux> yes.
[21:18] <wm4> the only problem is backwards compatibility, right?
[21:18] <ubitux> exactly
[21:18] <ubitux> and l compat too
[21:18] <wm4> l?
[21:18] <ubitux> libav
[21:21] <ubitux> michaelni: ok so, i need access to the extradata in the muxer
[21:21] <ubitux> i'm supposed to call av_packet_split_side_data within the muxer?&
[21:21] <ubitux> it's not received right now
[21:22] <ubitux> i mean, it's either in the payload or inexistant
[21:22] <ubitux> (with the keepside flag)
[21:22] <ubitux> i now need to read it and honor it in the srt muxer
[21:22] <ubitux> (and in the matroska muxer i'll need to ignore it, or maybe write it somehow)
[21:23] <ubitux> (right now it seems ignored)
[21:24] <trovao> Hey there. What's the best way to submit a patch to the mailing list? I've created one with "git format-patch". Now what? Do I attach it to a new mail file or send it inline?
[21:24] <ubitux> michaelni: http://pastie.org/5459797  i want to do this
[21:25] <ubitux> trovao: hi, you can use git send-email directly
[21:25] <ubitux> or inline it (don't do it with web mailer, they often wrap it badly)
[21:26] <ubitux> trovao: https://www.ffmpeg.org/contact.html second paragraph
[21:26] <trovao> ubitux: thanks
[21:26] <michaelni> ubitux, if its in the payload the sidedata must be split out somewhere, demuxer->decoder splits in decoder demuxer->muxer should split in muxer
[21:28] <ubitux> note that decoders might use it
[21:29] <ubitux> (and the subrip decoder actually does)
[21:30] <ubitux> michaelni: doesn't this require apps to do that as well? :/
[21:30] Action: ubitux still doesn't get the point of this complexity
[21:31] <llogan> trovao: if you're not subscribed your message will get placed in a moderation queue and it may take a day for it to get approved (or ping me)
[21:33] <burek> You attempted to reach www.ffmpeg.org, but instead you actually reached a server identifying itself as lists.ffmpeg.org. 
[21:33] <llogan> also, if you decide not to subscribe, in your message you can ask to be CC'd on replies to your patch
[21:33] <ubitux> durandal_1707: are you inventing yourself all these formats or they actually exist? :D
[21:34] <llogan> burek: how did you get that message?
[21:34] <burek> https://www.ffmpeg.org/contact.html
[21:34] <durandal_1707> ubitux: my formats would not suck that mutch
[21:34] <michaelni> <ubitux> note that decoders might use it <---- decoders call the function
[21:34] <michaelni> the muxer does not
[21:35] <durandal_1707> ubitux: use gforce
[21:35] <michaelni> did you try to call the split function ?
[21:35] <ubitux> nope, not yet, cause i don't like that solution that much anyway :p
[21:35] <michaelni> well, then stop using side data
[21:35] <ubitux> :(
[21:36] <michaelni> you arent really suggesting that we break 70% of applications because you dont like adding 1 function call
[21:36] <ubitux> what apps would that break? and how so?
[21:37] <llogan> burek: i guess the cert is only valid for lists.ffmpeg org and ffmpeg.org, but not www.ffmpeg.org?
[21:38] <burek> i guess yes, it says ssl error
[21:38] <michaelni> ubitux, every application that does not explicitly support side data would break
[21:38] <burek> in the title
[21:38] <ubitux> can you give a specific example? i have a hard time understanding what kind of data would be lost or anything
[21:39] <michaelni> ubitux,  exaple srt, you get NO side data in the decoder
[21:39] <michaelni> because a application does not pass it along
[21:40] <michaelni> which application, i think most if not all
[21:41] <ubitux> assuming they demux with lavf, they get a pkt with extradata, which they simply pass along to the decoder, no?
[21:41] <michaelni> no
[21:41] <michaelni> the application has its own structures
[21:41] <michaelni> the extract data size pts 
[21:41] <michaelni> and thats all you get if at all
[21:42] <llogan> burek: maybe it would be easiest/laziest to simply force a redirection to non www. i dont know.
[21:42] Action: llogan hasn't web admined in a long time
[21:42] <burek> i agree
[21:43] <burek> no need for both www. and non www
[21:43] <ubitux> michaelni: you mean if they do the demuxing themselves?
[21:44] <wm4> ubitux: you can take mplayer as example
[21:44] <michaelni> ubitux, if you write an application, you likely choose a common format/struct to be used between your decoders and demuxers and muxers ...
[21:44] <michaelni> if the application has native demuxers and decoders this will likely not be AVPackets
[21:44] <wm4> ubitux: VLC, gstreamer and directshow won't use ffmpeg native structures as well
[21:45] <michaelni> and such application will not pass AVPackets between demxuer and decoder even if it is lavf + lavc
[21:45] <michaelni> compare this to us using libvorbis and someone writing a libogg based demuxer
[21:45] <michaelni> we also would not pass OggPackets or what they where called
[21:45] <michaelni> but would copy things into AVPackets
[21:46] <llogan> burek: is there a better way than using a RewriteRule?
[21:46] <llogan> (not that I can fix it, but just curious)
[21:46] <burek> htaccess? servername/serveralias ?
[21:47] <llogan> yes, via htaccess or whatever (virtual) conf file
[21:48] <burek> the idea is to tell apache those 2 are really one thing
[21:48] <burek> now, im not sure about ssl issue
[21:48] <burek> if its hard coded in the certificate, well then...
[21:49] <ubitux> michaelni: you mean the app would demux to pkt, copy data/size to its own structure, mess with it, then recreate a new AVPacket with these data/size to send it to the decoder?
[21:49] <michaelni> ubitux, yes
[21:50] <Guest84410> llogan: Alright. So I'll send it and tell you I did so, ok?
[21:50] <ubitux> michaelni: well they probably need to keep a lot of other information
[21:50] <ubitux> such as destruct etc
[21:50] <ubitux> why not extradata?
[21:51] <llogan> trovao_: sure, but i may be afk for a while in a few minutes.
[21:52] <trovao_> llogan: no problem
[21:53] <michaelni> ubitux, extradata is global data, its called side data
[21:53] <ubitux> arg i'm sorry
[21:53] <michaelni> also i like to do some usefull work still today
[21:53] <ubitux> i meant side data all the time
[21:53] <ubitux> :p
[21:53] <ubitux> sorry
[21:54] <michaelni> its a 1 line fix, whats the big problem with adding that call ?
[21:54] <michaelni> droping the merge feature can breal really alot
[21:54] <ubitux> i was just trying to understand why it is necessary
[21:54] <ubitux> because it seems to cause more harm that solve anything to me
[21:54] <michaelni> applications prior to the addition of side data certainly did not copy it unless they used AVPAckets itself
[21:56] <michaelni> if we suddenly require that copy, that is a ABI/API break
[21:56] <michaelni> we cant do that before the next major bump
[21:56] <michaelni> and iam not sure its a good idea then either
[21:57] <ubitux> all libav apps are broken regarding this? :P
[21:57] <ubitux> [apps linked against libav]
[21:59] <ubitux> or do we have a special use of these side data?
[22:02] <ubitux> wm4: so the conclusion, is there something to fix in ffmpeg or not?
[22:02] <wm4> ubitux: yes
[22:02] <ubitux> ok, will read.
[22:02] <wm4> the ASS packet format is Wrong
[22:03] <wm4> because it's not possible to distinguish identical ass events
[22:03] <wm4> the ReadOrder issue is related, but not passing ReadOrder can break other things too
[22:03] <ubitux> right, that's still the issue about the ass packets
[22:03] <ubitux> or something else?
[22:05] <wm4> not from me
[22:10] <trovao_> llogan: Sent it. This was the first time I used git send-email and I added the --compose argument. The introductory message didn't seem to get through the mail, though.
[22:11] <trovao_> Feel free to drop it if it doesn't match the lists' standard.
[22:17] <Compn> trovao_ : dont worry about list standard lol
[22:17] <Compn> we arent that evil
[22:18] <wm4> yes you are
[22:19] <ubitux> :D
[22:19] <trovao_> :)
[22:20] <trovao_> Now I see. The message was split in two. The first one, with the patch explanation, had no subject. The second one has a subject, and the patch. I just cancelled the first one.
[22:38] <cone-663> ffmpeg.git 03Michael Niedermayer 077205e896a1ce: dxa: check reference frame availability before use.
[22:38] <cone-663> ffmpeg.git 03Michael Niedermayer 07991e23519ac5: aacps: check iid/icc_par more completely.
[22:52] <llogan> trovao_: approved
[23:25] <saste> I wonder if we should add an opt type for setting a channel layout...
[23:34] <ubitux> saste: are you talking about your recent patch for swr?
[23:34] <ubitux> if that's not compatible with opt_int thing i don't think that's a good idea
[23:34] <ubitux> for where we'll have a compat with avr
[23:34] <saste> we have a channel_layout_opt handler in ffmpeg, but ffplay doesn't support it
[23:34] <saste> so you have to specify in input an *integer* for a channel layout
[23:35] <saste> that's not very nice
[23:56] <saste> http://wealoneonearth.blogspot.it/search/label/quasicrystal
[23:57] <saste> expect a new lavfi source soon :)
[00:00] --- Sat Dec  1 2012