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

[burek]

[00:00] <michaelni> i tend to be too terse
[00:01] <peper03> Ok.  So if I add a flag similar to 'm->sofdec' like 'm->dvd' and set that based on the current conditions (length of packet and first byte), and then use that flag afterwards instead of inspection, that would be ok?
[00:03] <michaelni> from that it sounds ok
[00:04] <peper03> Ok, cool.  That should be do-able.  I'll put together another patch and post it to the ML.
[00:09] <cone-776> ffmpeg.git 03Alexander Kojevnikov 07master:d30ee5ef59d3: mpegaudio_parser: Don't ignore information from the first frame
[00:37] Action: saste confused again by coded_w/h stuff
[00:38] Action: saste led to insanity by opencl stuff
[00:58] <Compn> saste : just review it for api bugs and rubber stamp it :)
[00:59] <saste> Compn, what i'm doing indeed
[01:13] <saste> really, do you need all this c**p to use opencl?
[01:14] <Compn> direct accessing the kernel ?
[01:15] <Compn> are you wondering if theres a libopencl that moves all of that functionality into the library instead of the decoder ?
[01:15] <Compn> or filter, whatnot
[01:15] <iive> saste: what is the problem with opencl ?
[01:15] <Compn> iive : opencl deshake filter patch on ffmpeg-devel
[01:35] <saste> iive, that's not the right question
[01:36] <saste> the right question is: what's sane about opencl?
[01:39] <iive> saste: i've heard it is far more sane that cuda
[01:39] <iive> than
[03:40] <cone-107> ffmpeg.git 03Carl Eugen Hoyos 07master:de4811e9108c: Force using a 64bit intermediate when calculating calendar time with av_timegm().
[03:40] <cone-107> ffmpeg.git 03Carl Eugen Hoyos 07master:53e3bc3024dc: Add dependencies for the aac encoding fate tests.
[03:40] <cone-107> ffmpeg.git 03Carl Eugen Hoyos 07master:0edfda7977ba: Add dependencies for the flac encoding fate tests.
[03:40] <cone-107> ffmpeg.git 03Carl Eugen Hoyos 07master:a21fd660279c: Add dependencies for the voice fate tests.
[03:40] <cone-107> ffmpeg.git 03Carl Eugen Hoyos 07master:199db97fbdd9: Close output codecs if input codec initialisation fails.
[10:37] <wm4> ubitux: looking at the subtitle converters again... why does vf_subtitles process codec private data of subtitles always as ASS private data? I see no reason why it would be guaranteed that the data is ASS
[10:37] <wm4> ubitux: I'm talking about the ass_process_codec_private() call
[10:38] <wm4> ubitux: second question, does the decoder have state?
[12:57] <masa-> do you know if someone is already working on dxtory support? the current version does not work for my videos, i'm getting a "Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome" and "[dxtory @ 0x1b200e0] Unknown frame header 21000001" errors
[12:58] <Compn> masa- : kostya might be, try /msg kshishkov 
[12:58] <Compn> masa- : do you have new or old files ?
[12:59] <masa-> new, recorded with the latest 2.0.121 version
[13:00] <masa-> i'm new to dxtory, just purchased it, so those are my first test clips
[13:00] <masa-> i'm not sure if i can use some other codecs with dxtory that would work and still give good performance and quality etc
[13:14] <Bor0> what's the most efficient way to implement frame stepping backwards using libav*?
[13:20] <wm4> that's a good question
[13:20] <wm4> you can't decode backwards
[13:20] <wm4> and you can't demux backwards either
[13:22] <Bor0> do you have information how does QuickTime implement it?
[13:22] <cptspiff> typically you seek to keyframes then linear search forward..
[13:23] <Compn> could losslessly keep frames in a buffer so you can do that :D
[13:23] <wm4> cptspiff: can xbmc step backwards?
[13:23] <Bor0> how do I seek by keyframes? I thought something of stream_seek() -> calculate difference between N and current frame -> skip distance frames
[13:23] <cptspiff> wm4: aye
[13:24] <wm4> cptspiff: can it play backwards too?
[13:24] <cptspiff> sorta, but it's rather buggy :)
[13:24] <wm4> so what exactly does it do to step backwards?
[13:24] <cptspiff> what i said.
[13:25] <Bor0> cptspiff: is my solution something similar to that?
[13:25] <cptspiff> Bor0: yes, that's the same.
[13:25] <Bor0> great!  at least I know I'm on the right track.
[13:25] <cptspiff> you can also set a flag and have libav do it for you iirc
[13:25] <cptspiff> ehrm, ffmpeg!
[13:25] <cptspiff> sorry lol
[13:25] <Bor0> what kind of flag?
[13:25] <cptspiff> two ticks
[13:26] <Bor0> do you mean by stepping n frames forwards?
[13:32] <cptspiff> Bor0: yeah, looks like the flag is deprecated, you had a flag for 'accurate' seeks, but seems its gone
[13:33] <Bor0> I already implemented stepping n frames forward, by decoding while is->step != 0
[13:33] <cptspiff> right. and to get backwards play, you have to cache up those frames as you do that.
[13:33] <Bor0> why is the need of cache? won't seekpos() be enough?
[13:33] <cptspiff> depends on your source..
[13:34] <Bor0> oh, backwards play, yeah. all I need is backwards step, not playback
[13:34] <cptspiff> right. step you just toss them away obviously.
[13:34] <wm4> I think easiest might be to just save the timestamps, and then just to decode again until you reach the TS of the previous frame?
[13:35] <Bor0> I'm missing a couple of definitions, I think. video has keyframes, stream_seek is used to jump to them?
[13:35] <Bor0> or, to be more precise, what does a keyframe mean?
[13:35] <cptspiff> that means the whole frame is stored
[13:36] <cptspiff> remember, video is stored as delta data
[13:36] <Bor0> okay, how are keyframes generated?  I suppose not every frame has a keyframe?
[13:37] <cptspiff> you start with some picture, then encode the *changes* from that reference frame. keyframes are those reference frames.
[13:37] <Bor0> I see, how many reference frames do we have a video with, say 300 frames?
[13:38] <Bor0> or is that a variable
[13:38] <cptspiff> depends on whatever the encoder found necessary to not drop too much info during encoding
[13:38] <cptspiff> and the bitrate and etc.
[13:38] <Bor0> I see, so encoder decides when to store keyframes, and I can use stream_seek (for not so accurate frame seeking) to step to keyframes
[13:38] <cptspiff> yes.
[13:39] <Bor0> excellent, thank you very much!
[13:39] <cptspiff> np
[14:29] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:8978c743fb1d: aacsbr: Check for envelope scalefactors overflowing
[14:29] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:eab49f4fb53f: Revert "aacdec: Reconfigure output as needed, disable pop_output_configuration()"
[14:29] <cone-723> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/heads/release/1.2': unknown revision or path not in the working tree.
[14:29] <cone-723> Use '--' to separate paths from revisions
[14:29] <cone-723> refs/heads/release/1.2:HEAD: Revert "aacdec: Reconfigure output as needed, disable pop_output_configuration()"
[14:50] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:80f91a70be5f: MAINTAINERS: update for 1.2
[15:03] <cone-723> ffmpeg.git 03Reimar Döffinger 07master:12c5c1d3e390: avstring: Add locale independent versions of some ctype.h functions
[15:03] <cone-723> ffmpeg.git 03Reimar Döffinger 07master:efa7f4202088: Use the avstring.h locale-independent character type functions
[15:03] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:6c17ff84ad8f: Merge commit 'efa7f4202088c70caba11d7834641bc6eaf41830'
[15:17] <cone-723> ffmpeg.git 03Diego Biurrun 07master:06b54e84254e: build: Fix error_resilience code dependencies
[15:17] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:b094931ab911: Merge commit '06b54e84254e4834b4978ff5b27cc2b7ee8d7a98'
[15:22] <cone-723> ffmpeg.git 03Martin Storsjö 07master:d88738e4038b: mpegvideo: Conditionally build error_resilience bits
[15:22] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:43c6c1869011: Merge commit 'd88738e4038b162708dc2f5342e10c1694edfd89'
[15:29] <cone-723> ffmpeg.git 03Diego Biurrun 07master:5f401b7b7123: Add missing error_resilience includes to files that use ER
[15:29] <cone-723> ffmpeg.git 03Diego Biurrun 07master:bcd0a7137e4a: configure: Add missing h264chroma dependencies to vp5, vp6
[15:29] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:c32cc7e3a40d: Merge commit 'bcd0a7137e4aca0f6f598593b90ca8f338444c51'
[15:36] <cone-723> ffmpeg.git 03Diego Biurrun 07master:dbd2a34ba5e5: build: cosmetics: Group hw accelerator Makefile entries together
[15:36] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:e9fbb9783c82: Merge commit 'dbd2a34ba5e5e46b6835e4425c360723c643b7a8'
[15:41] <cone-723> ffmpeg.git 03Diego Biurrun 07master:870add0de95d: configure: Add missing videodsp dependencies to some decoders
[15:41] <cone-723> ffmpeg.git 03Martin Storsjö 07master:4be368b504c6: avstring: Fix isxdigit to not accept non-hex characters
[15:41] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:1f3a577353ed: Merge commit '4be368b504c6f4a03051448728fc62cd0ed506b2'
[15:46] <cone-723> ffmpeg.git 03Alexander Kojevnikov 07master:eae0879d961b: mp3dec: Fix VBR bit rate parsing
[15:46] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:23eed00925c1: Merge commit 'eae0879d961b78717dd2a0899809ad22819ae9e3'
[15:55] <cone-723> ffmpeg.git 03Ronald S. Bultje 07master:65f1d45dcc71: lavu: add support for atomic operations.
[15:55] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:e92ba51fd78d: Merge commit '65f1d45dcc71186ede72fff950996099d23359bd'
[16:05] <cone-723> ffmpeg.git 03Anton Khirnov 07master:8e401dbe90cc: lavu: add a new API for reference-counted data buffers.
[16:05] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:36099df521b5: Merge commit '8e401dbe90cc77b1f3067a917d9fa48cefa3fcdb'
[16:16] <cone-723> ffmpeg.git 03Anton Khirnov 07master:1cec0624d0e6: AVBuffer: add a new API for buffer pools
[16:16] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:532f31a695c9: Merge commit '1cec0624d0e6f48590283a57169b58b9fe8449d3'
[17:42] <saste> michaelni, can you comment about the ffprobe coded_w/h patch?
[17:43] <saste> it's the second time I fail to fix it, because I can't understand how this coded_w/h is handled (and it just looks wrong to me)
[17:43] <michaelni> saste, didnt i already comment on the w/h thing ?
[17:44] <saste> michaelni, don't think so
[17:44] <saste> you sent a patch, but i raised a few perplexities about that approach
[17:44] <michaelni> i suggested how to fix it with a one liner in utils.c 
[17:45] <michaelni> if you dont like my patch then iam not sure how i should help ?
[17:45] <saste> i'd go for the oneliner, but understanding what's the underlying logic would be nice 
[17:45] <saste> i expressed my confusion in a reply
[17:47] <michaelni> replied
[18:01] <ubitux> wm4: because the decoder outputs to ass; it's different from the demuxer extradata which is specific to the format
[18:01] <ubitux> what do you mean by state?
[18:02] <ubitux> most demuxers have a local context
[18:02] <ubitux> decoders... they might have one but i don't remember if it's the case in practice
[18:03] <saste> about the opencl megapatch
[18:04] <saste> the guy is going to add a public libavutil interface, which will be used by libavfilter and libavcodec
[18:04] <saste> i need the comments of someone who actually knows something about opencl
[18:06] <michaelni> saste, or  we leave the opencl side to the patch author if you find noone to review that
[18:07] <saste> michaelni, yes but it's a public interface and it is still messy
[18:08] <wm4> ubitux: I mean state that's kept between frames, and which might make the output dependent on the number and order of input packets
[18:09] <wm4> ubitux: and maybe I'm blind, but it looks like you're adding extradata from the sub demuxer, not the sub decoder
[18:09] <wm4> ubitux: and the sub demuxer is not always ASS
[18:15] <saste> michaelni, so H.264 uses coded_w/h also for cropping?
[18:16] <ubitux> wm4: dec_ctx = st->codec, and that's dec_ctx->subtitle_header
[18:17] <wm4> ubitux: oh ok so I am blind
[18:17] <ubitux> i'm still not sure about your state question
[18:17] <wm4> I got confused by reusing the AVCodecContext from the demuxer
[18:18] <ubitux> note that most of the (at least text) subtitles demuxers preload everything
[18:18] <wm4> which btw. I find disgusting and I won't do it
[18:18] <ubitux> in a list of subtitles event
[18:18] Action: wm4 hopes there aren't any hidden fields that the decoder needs in order to work
[18:18] <ubitux> sort them etc
[18:18] <ubitux> and then the read packet from the demuxer just pick the next subtitles packet
[18:18] <wm4> well, I also want it to work when demuxing from a file
[18:18] <ubitux> and the seek re-adjust the current position in the list
[18:18] <wm4> err, from an interleaved file
[18:19] <wm4> what seek?
[18:19] <ubitux> i was talking at demuxer level
[18:19] <ubitux> decoders are mostly stateless afaik
[18:23] <wm4> so what does the demuxer do? you said something about preloading, and then something about seeking
[18:23] <wm4> wouldn't preloading just mean it reads the entire file linearly?
[18:24] <ubitux> it does, for subtitles formats
[18:24] <ubitux> typically a .srt, a .sub, etc
[18:24] <wm4> yes, talking about subtitle-only formats
[18:24] <wm4> excluding stuff like .mks
[18:24] <ubitux> and yes it preloads everything for various reasons
[18:24] <ubitux> typically re-ordering the events
[18:25] <ubitux> or for events depending on the next one
[18:25] <ubitux> (to get the duration etc)
[18:25] <ubitux> so basically the whole events are put into a kind of AVPacket list
[18:25] <ubitux> sorted, duration fixed, etc
[18:25] <ubitux> then the read_packet from the demuxer just raise the packet from the list
[18:25] <ubitux> and the seek is basically an event id adjustement in that list
[18:26] <wm4> btw. did you know that libass corrupts input buffers?
[18:26] <ubitux> ?
[18:26] <ubitux> what do you mean?
[18:26] <wm4> http://code.google.com/p/libass/issues/detail?id=88
[18:26] <wm4> might be relevant here
[18:27] <wm4> didn't check whether it applies
[18:27] <ubitux> mmh
[18:28] <ubitux> if the data packet is altered that might be a problem
[18:29] <wm4> btw. is there a flag already that tells whether a decoder outputs ASS?
[18:29] <ubitux> there is one to say not bitmap
[18:29] <ubitux> and since there is only two kind
[18:30] <ubitux> you can just safely use it
[18:30] <ubitux> just like it's done in vf subtitles
[18:30] <saste> ubitux: what's libv4l2 good for?
[18:30] <ubitux> saste: support creepy devices
[18:30] <wm4> ok
[18:30] <saste> ubitux, like?
[18:31] <ubitux> like very old non-standard webcams
[18:31] <wm4> ubitux: how are formats with no timestamps handled again?
[18:31] <ubitux> timestamps are generated at demux level
[18:32] <ubitux> wm4: microdvd demuxer read the fps from the file itself
[18:32] <ubitux> aqtitle, you can use a demuxer option
[18:32] <ubitux> -subfps
[18:32] <saste> ubitux, what's wrong with old non-standard webcams?
[18:32] <ubitux> to force the input framerate
[18:33] <ubitux> saste: they use crazy pix fmt unrecognized
[18:33] <wm4> uh that maps directly to an AVOpts I guess... can I safely set this without breaking timestamps for those that have it?
[18:33] <ubitux> libv4l2 makes some kind of transparent mapping to support them
[18:33] <saste> which are supported by libv4l2, but not from libswscale?
[18:34] <ubitux> i have a webcam with something like "c410" or something like this
[18:34] <ubitux> i have no idea what it is
[18:34] <ubitux> look at libv4l2 repository, you'll find some stuff in it
[18:34] <saste> ubitux: ok, thansk
[18:34] <wm4> ubitux: also, the libquvi developer wants to add subtitle support
[18:34] <ubitux> wm4: yes, avopts, should be safe
[18:35] <ubitux> oh?
[18:35] <ubitux> that would be GREAT :)
[18:35] <wm4> and I think he's looking at converting youtube whatever to ASS
[18:35] <wm4> (actually I suggested ASS to him...)
[18:35] <ubitux> what's youtube-whatever?
[18:35] <ubitux> libquvi shouldn't do that
[18:35] <wm4> if you think it's a better idea to convince him of something else, do it now
[18:35] <wm4> some XML format
[18:35] <ubitux> libquvi is not supposed to remux or transcode your video files
[18:36] <ubitux> so same for subtitles
[18:36] <ubitux> he should just bother about dumping the sub files
[18:36] <wm4> that's possible too
[18:36] <wm4> I'm not sure if there's anything coded yet
[18:36] <ubitux> i think that would be wise
[18:41] <ubitux> saste: http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/lib/libv4lconvert/libv4lconvert.c
[18:41] <ubitux> i think i have one like V4L2_PIX_FMT_SN9C10X
[18:41] <ubitux> but there are all kind of shit like this :p
[18:42] <wm4> quick, someone add these formats natively to ffmpeg
[18:42] <ubitux> :D
[18:42] <wm4> after all you have MONOWHITE and MONOBLACK too
[18:42] <wm4> and no less than 4 formats that are 4 bit RGB
[18:42] <saste> wm4, monow/b is useful
[18:42] <ubitux> yes
[18:42] <ubitux> for life
[18:43] <wm4> (this is a feature request to remove these formats)
[18:43] <saste> for example for xface
[18:43] <wm4> hahaha xface
[18:43] <ubitux> :)
[18:43] <saste> we like legacy formats
[18:43] <wm4> I mean, one 1-bpp format would be ok
[18:43] <wm4> but why 2?
[18:43] <wm4> and the audio chain has the reverse approach
[18:44] <wm4> and doesn't even support 24 bit, which is kind of common
[18:44] <saste> so you have more choices
[18:44] Action: ubitux remembers seeing flac 24-bit support recently
[18:45] <merbanan> wm4: 24bit native is kind of bad alignment wise
[18:45] <wm4> merbanan: so? there are plenty of pixel formats that are kind of bad for native access
[18:45] <wm4> starting with endian swapped formats
[18:46] <merbanan> wm4: you mean it isn't supported ?
[18:46] <merbanan> 24bit audio that is
[18:46] <wm4> it isn't, not as sample format
[18:47] <nevcairiel> 24-bit lives in 32-bit with an extra bitdepth value
[18:47] <merbanan> and this is not sufficient ?
[18:48] <wm4> merbanan: apparently it is, but for pixel formats, it appears even the endian swapped formats are needed
[18:48] <wm4> and I wonder why
[18:49] <merbanan> legacy
[18:53] <ubitux> saste: http://lists.libav.org/pipermail/libav-devel/2013-March/044394.html
[18:53] <saste> ubitux, yes i read
[18:54] <saste> i wonder if we should keep it
[18:54] <saste> since it has less cruft/features than tinterlace
[18:55] <saste> otoh i can't say if some "features" of the original filter are useful at all
[18:55] <wm4> I wasn't aware that the evil plan was actually pushed
[18:56] <wm4> so what's the plan?
[18:56] <ubitux> michael branched out a 1.2
[18:56] <wm4> I noticed
[18:57] <ubitux> so master can become a chaos i guess
[18:57] <nevcairiel> and started merging the easy commits
[18:57] <nevcairiel> probably working on the bigger ones now
[18:57] <michaelni> anyone wants to check/update the changelog in 1.2 ?
[18:57] <ubitux> should i push vf curves in 1.2?
[18:57] <michaelni> maybe write release notes if needed
[18:57] <ubitux> @_@
[18:58] <Daemon404> that's an epic header for interlace
[18:58] <Daemon404> for such a simple/tiny piece of code
[18:58] <michaelni> ubitux, feel free to add any filters to 1.2 as long as they cannot break existing features
[18:58] <ubitux> ok
[18:58] <nevcairiel> Daemon404: you mean the authorship?
[18:59] <ubitux> michaelni: btw, carl wanted me to re-enable by default iconv
[18:59] <Daemon404> nevcairiel, yes
[18:59] <saste> ubitux, why?
[18:59] <ubitux> michaelni: since it's in 1.2, what do you think?
[18:59] <ubitux> saste: because it's not for specific formats
[18:59] <ubitux> it's for a generic features
[18:59] <michaelni> ubitux, does it work on all platforms now ?
[18:59] <ubitux> michaelni: seems to yes
[19:00] <michaelni> if the issues where fixed sure i dont mind
[19:00] <ubitux> you'll still have to --disable-iconv on the fate instances who don't have the particular cp from the fate test
[19:00] <saste> Daemon404: that's what happens when you port code
[19:00] <ubitux> ok
[19:00] <saste> you can't discard all the contributors, in that case we had MPlayer -> FFmbc -> FFmpeg -> Libav
[19:01] <ubitux> don't forget to pick the changes from mplayer2 and mpv
[19:01] <ubitux> also, xine and handbrake
[19:01] <nevcairiel> is it the best interlace filter there is now at least?
[19:02] <ubitux> no idea, no one ever used it
[19:02] <saste> nevcairiel, what's so special about interlacing?
[19:02] <saste> the feature is basically trivial
[19:02] <nevcairiel> no idea, but since it was ported over so many projects, it must be special :p
[19:03] <saste> nevcairiel, :D
[19:03] <nevcairiel> dont you just discard a bunch of lines and call it a day
[19:03] <nevcairiel> i should find out how it works
[19:03] <wm4> it was ported because it was rotting in libmpcodecs
[19:03] <wm4> and libmpcodecs can only be removed when everything is ported
[19:04] <wm4> so there's no question every filter should be ported
[19:04] <Daemon404> lol
[19:04] <saste> wm4, yes, but we had at least one user who was pushing for the port
[19:04] <wm4> sorry for sarcasm
[19:04] <nevcairiel> a bunch of things that didnt work in the first place were deleted recently, i think =p
[19:05] <ubitux> about 25 filters left
[19:05] <ubitux> but i think we can end up with porting only 10 of them
[19:06] <ubitux> especially with the ivtc port... which i should be doing right now
[19:09] <Daemon404> some of it might be hard to port
[19:09] <Daemon404> like the abilty to use a 2nd clip to grab farmes form
[19:09] <Daemon404> instead of pp
[19:11] <ubitux> the most complex thing with the ivtc port will be the frame queueing thing
[19:11] <ubitux> when you see how it looks in yadif or overlay...
[19:12] <ubitux> that's kind of tricky
[19:13] <Daemon404> heh
[19:13] <saste> ubitux, btw did you have some benchmarks related to mp=tinterlace/tinterlace?
[19:14] <ubitux> nope
[19:14] <ubitux> when i tried mp=tinterlace
[19:14] <ubitux> it forked bomb my desktop
[19:14] <ubitux> well, it memory bombed it
[19:14] <wm4> wat
[19:14] <ubitux> and after the reboot i forgot
[19:14] <ubitux> wm4: yeah don't ask me
[19:16] <cone-723> ffmpeg.git 03Anton Khirnov 07master:1afddbe59e96: avpacket: use AVBuffer to allow refcounting the packets.
[19:16] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:2653e1252045: Merge commit '1afddbe59e96af75f1c07605afc95615569f388f'
[19:23] <Daemon404> guess ill wait for all the merge epicness before i update ffmpeg
[19:34] <cone-723> ffmpeg.git 03Anton Khirnov 07master:1a5e9130162b: pthread: avoid copying input packets when possible.
[19:34] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:d9d97f9b3374: Merge commit '1a5e9130162b8adc898e5f6aea82b6372d1e4e6c'
[19:36] <peper03> If avio_skip returns a negative value, is it safe to assume that no skip has been performed (i.e. the read pointer is still at the same place as before the call)?
[19:42] <cone-723> ffmpeg.git 03Anton Khirnov 07master:ad0c9f2d5d81: lavc: move AVFrame.hwaccel_picture_private to Picture.
[19:42] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:fee484edaff7: Merge commit 'ad0c9f2d5d81e22207c6ccecc426bf7306acc327'
[19:49] <michaelni> peper03, yes i think so
[19:50] <peper03> michaelni: Ok, so if I get an error, I'll skip forwards instead of back.  Forwards should presumably always work (barring critical failures), I presume.
[19:52] <peper03> michaelni: What about the bit of code dealing with detecting 'Sofdec'.  Which alternative do you find most acceptable/least unpleasant?
[19:59] <Daemon404> hmm
[19:59] <Daemon404> is there a to have ffprobe output the cropped height
[19:59] <Daemon404> form an avc file
[19:59] <Daemon404> a way*
[19:59] <Daemon404> i.e. 544 cropped to 543
[19:59] <saste> Daemon404, sure, if you can extract that info somehow
[20:00] <Daemon404> heh
[20:00] <Daemon404> mediainfo can
[20:00] <Daemon404> i thought libavcodec supported it
[20:07] <Daemon404> ........................
[20:07] <Daemon404> seriously?
[20:08] <Daemon404> you cant specify WHERE to crop
[20:08] <Daemon404> with teh crop filter?
[20:08] <Daemon404> (i.e. top vs bottom)
[20:08] <Daemon404> wtf
[20:08] <Daemon404> oh isee
[20:08] <michaelni> peper03, yes forward should work if not thats some external problem abount which not much can be done
[20:08] <Daemon404> it uses some convoluted position system
[20:08] <nevcairiel> Daemon404: x/y and w/h i guess?
[20:08] <Daemon404> terrible idea...
[20:08] <Daemon404> crop top:bottom:right:left
[20:08] <Daemon404> too eays i guess
[20:09] <Daemon404> needs to be more convpluted1
[20:09] <saste> Daemon404, you/we can add top/bottom/right/left options
[20:09] <saste> possibly you
[20:09] <Daemon404> i wouldnt add them
[20:10] <Daemon404> i wuld remove this overcomplicated mess entirely
[20:10] <nevcairiel> the shorthand seems to be x:y:w:h, which technically is not a totally uncommon format, at least if you know how directshow does cropping rectangles =p
[20:10] <Daemon404> an add just tjem + expr
[20:10] <saste> or a cropeasy variant
[20:10] <Daemon404> well basically
[20:10] <Daemon404> i despise the lavfi internal api
[20:10] <Daemon404> and im not writing plugins for it
[20:10] <Daemon404> :)
[20:10] <Daemon404> its massively painful compared to avs or vs
[20:10] <saste> Daemon404, yes we know that story ;)
[20:10] <Daemon404> (and im just about ready to transition entirely to VS)
[20:11] <Daemon404> so i can not use it \o/
[20:11] <nevcairiel> i wonder how much effort it would be to use VS as a post-processor inside directshow .. needs a custom source and sink, i guess
[20:12] <BBB-work> what's vs?
[20:12] <BBB-work> visual studio?
[20:12] <nevcairiel> vapour synth
[20:12] <BBB-work> what a name for a product
[20:12] <BBB-work> anyway ok
[20:13] <Daemon404> nevcairiel, you wanna shutup all the ffdshow fanboys?
[20:13] <Daemon404> "omg whars my pp" ?
[20:13] <nevcairiel> well i dont want to implement any silly post-processing myself, and that would finally shut them up indeed
[20:14] <Daemon404> :P
[20:16] <nevcairiel> first i need to silence all those anime people with their silly linked segments
[20:17] <Daemon404> lol
[20:17] <Daemon404> nevcairiel, close
[20:17] <Daemon404> but i think you mean: linekd segments AND virtual timelines
[20:18] <nevcairiel> those always go together
[20:18] <Daemon404> no they dont :P
[20:18] <nevcairiel> but its really not that hard
[20:18] <Daemon404> i have plenty of 2cd moviesi n matroska
[20:18] <Daemon404> wit segment linking
[20:18] <Daemon404> no virtual timeline
[20:18] <Daemon404> from the Bad Old Days
[20:18] <nevcairiel> oh yeah, but thats actually not that common anymore these days
[20:18] <Daemon404> also
[20:18] <Daemon404> whatabout edition support? ;)
[20:19] <nevcairiel> thats also really the same feature
[20:19] <Daemon404> slightly separate
[20:19] <nevcairiel> if you have virtual timelines, switching around between different ones is just a small step
[20:19] <Daemon404> yea
[20:20] <kierank> Daemon404: regretably pp is the only useful way to get deblock
[20:20] <Daemon404> kierank, thats not what we were to when we say pp
[20:20] <Daemon404> oh
[20:20] <Daemon404> nvm
[20:20] <Daemon404> you meant it the same as i
[20:20] Action: Daemon404 thought kierank meant libpp for a sec
[20:21] <ubitux> libpp is dun
[20:21] <ubitux> fun
[20:24] <ubitux> so anyway
[20:24] <ubitux> any objection for vf curves? can i push?
[20:37] <cone-723> ffmpeg.git 03Michael Niedermayer 07release/0.11:5df2dc0f945f: aacsbr: Check for envelope scalefactors overflowing
[20:37] <cone-723> ffmpeg.git 03Michael Niedermayer 07release/1.0:98dfe0d8bd1f: aacsbr: Check for envelope scalefactors overflowing
[20:37] <cone-723> ffmpeg.git 03Michael Niedermayer 07release/1.1:41313bdcc511: aacsbr: Check for envelope scalefactors overflowing
[20:39] <nevcairiel> ubitux: considering master is about to change lavfi filters to AVFrame, maybe wait and adjust it to that then?
[20:40] <ubitux> nevcairiel: it might take some time..
[20:40] <cone-723> ffmpeg.git 03Anton Khirnov 07master:7ecc2d403ce5: Move AVFrame from lavc to lavu.
[20:40] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:c4e882173299: Merge commit '7ecc2d403ce5c7b6ea3b1f368dccefd105209c7e'
[20:40] <nevcairiel> only 2 more commits!
[20:42] <ubitux> nevcairiel: including the 10k LOC diff?
[20:42] <nevcairiel> 2 more until lavfi gets converted to avframe
[20:42] <nevcairiel> there is plenty others after that
[20:42] <Daemon404> not 2 more
[20:43] <Daemon404> there's a slew of bug fixes form wbs after
[20:43] <ubitux> nevcairiel: ffmpeg has about 2x more filters than libav, something like 50
[20:43] <ubitux> it will take a while to change them
[20:43] <ubitux> i don't mind helping this though
[20:44] <nevcairiel> i agree, however it looks like an easy task, just replacing which fields are used
[20:44] <nevcairiel> plenty work, but not hard work in most cases
[20:44] <ubitux> until you realize libav has dropped some stuff we use
[20:44] <ubitux> which might get tricky in some cases
[20:47] <Compn> cool, arm optimized yuv2rgb :)
[20:48] <Compn> http://code.google.com/p/chromium/issues/detail?id=71403
[20:49] <Compn> http://wss.co.uk/pinknoise/yuv2rgb/
[20:49] <Compn> too
[20:49] <cone-723> ffmpeg.git 03Anton Khirnov 07master:77b2cd7b41d7: AVFrame: add side data.
[20:49] <cone-723> ffmpeg.git 03Michael Niedermayer 07master:307dc32a1a71: Merge commit '77b2cd7b41d7ec8008b6fac753c04f77824c514c'
[20:53] <michaelni> Daemon404, if you know of post "buffer-ref" bug fixes please make a list of them or something so i can apply them on top before testing
[20:54] <nevcairiel> the real fixes only were to the build system of the new atomic functions on fringe setups
[20:54] <cone-723> ffmpeg.git 03Clément BSsch 07master:160979f4b4cd: lavc/utils: make sure the iconv descriptor can be opened only once.
[20:55] <cone-723> ffmpeg.git 03Martin Storsjö 07master:309d6f5077e4: atomic: Add include guards to the implementation headers
[20:55] <peper03> michaelni: Which of the 'Sofdec' detection alternatives do you find least unpleasant?
[20:59] <michaelni> peper03, random idea originlen==len ? firstbyte : avio_r8()
[21:00] <michaelni> but really doesnt matter anything  that works is ok, if seek -1 always works thats fine too
[21:02] <peper03> michaelni: Ok.  I was trying to keep the operation of the original Sofdec detection as untouched as possible.  I looked at a couple of the sample files and their packet sizes are not the same as DVD NAV packets but since there are presumably no specifications (based on how the detection code works), it seems unnecessarily risky to assume it can't happen.
[21:04] <peper03> As it works at the moment, it isn't necessary to determine whether you're checking the first byte or not.  The problem is trying to determine whether you called avio_r8 and need to decrement 'len' or not.  That makes the code unwiedly and ugly.  Do-able, but ugly.
[00:00] --- Sat Mar  9 2013