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

[burek]

[02:01] <cone-169> ffmpeg.git 03Ronald S. Bultje 07master:2c85d7c01548: h264: add 3 pixels below for subpixel filter wait position.
[02:04] <Daemon404> michaelni, there look to be some small differences like
[02:04] <Daemon404> -    9.463782453291253760e+17, 1.052965658439974912e+18, 1.162323703413866496e+18, 1.274318858307502080e+18
[02:04] <Daemon404> +    9.463782453291253760e+17, 1.052965727159451648e+18, 1.162323840852819968e+18, 1.274318858307502080e+18
[02:04] <Daemon404> "small"
[02:04] <Daemon404> mind you, these are present whenever we use libm.h impls at runtime as well
[02:05] <Daemon404> only for the cbrtf replacements
[02:09] Action: Daemon404 sends a proper reply
[02:16] <kierank> i wonder if the intel aac encoder is any good
[02:16] <Daemon404> is it sw or hw?
[02:16] <kierank> dunno, installing now
[02:16] <Daemon404> lul
[02:17] <Daemon404> for now, i fairly satisifed with fdk
[02:17] <Daemon404> though i wish it had a proper vbr mode
[02:17] <Daemon404> well, 'quality' mode.
[02:33] <llogan> kierank: so...how was it?
[04:30] <joshack> ffmpeg noob here.  Looks like I got most things installed well excpet mencoder/mplayer
[04:30] <joshack> and apparently I need that working for stitching teh avi files ffmpeg whipped up for me
[04:31] <joshack> after ./configure and make && make install .. some of the output tells me the place it's going to be installed
[04:31] <joshack>   Install prefix: /usr/local
[04:31] <joshack>   Data directory: /usr/local/share/mplayer
[04:31] <joshack>   Config direct.: /usr/local/etc/mplayer
[04:31] <joshack> yeah, there's nothing there and then v
[04:31] <joshack> -bash: mencoder: command not found
[04:32] <joshack> anyone want to point a loser in the right directoin
[04:33] <highgod> Hi I want to ask a question,does mpeg2video has 444 or 422 format?thanks.
[04:58] <Compn> highgod : i could not get anyone to review your patch :(
[05:06] <highgod> Compn,I'm fixing the patch now,hehe.
[05:16] <highgod> Compn:when I finish the the patch,can I submit again?
[05:16] <michaelni> highgod, mpeg2 allows 422 and 444
[05:18] <highgod> @michaelni,I want to check whether the mpeg2 is 420 at the codec init stage.I how can I get the format? I use av_parser_parse2, but I didn't get it
[05:20] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:31c4a1b7d0a0: h264: do not mess up cur_chroma_format_idc during thread update
[05:24] <michaelni> highgod, the info is stored in the ext sequence header or whatever its called
[05:25] <michaelni> might be tricky to access this reliably from codec init
[05:26] <michaelni> with parser split it might end in extradata but not sure how reliable this is
[05:28] <Compn> michaelni : i think highgod needs to know the 444/422 for passing to hwaccel ...
[05:28] <Compn> michaelni : btw highgod is author of the dxva2 patch , need someone to review it :)
[05:28] <Daemon404> does 4:4:4 even exist in practice?
[05:28] <Compn> highgod : yes, submit new patch when you are finished
[05:30] <Compn> Daemon404 : dunno
[05:30] <Compn> its in the specs and there seems to be a few encoders for it
[05:57] <bcoudurier> why do I know iso number of mpeg-2 by heart ? :)
[05:58] <bcoudurier> actually you cannot encode 444 because it's not allowed in any profile
[05:59] <bcoudurier> even high is 420 or 422
[06:07] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:2d372d3a3ffb: h264: document h264_set_parameter_from_sps() re-calling behavior
[06:07] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:5c6283e5c3bf: mpegvideo: Increase MAX_MV for HD video
[06:07] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:bbe56bcd6bef: motion_est: Limit motion vector search range to MAX_MV
[06:08] <michaelni> bcoudurier, btw, ill commit the chunk patches tomorrow or so with "[PATCH 2/2] mux/chunked interleaver: better align duration chunks."
[06:09] <michaelni> that should mostly solve the issues
[06:25] <highgod> I want to check whether the mpeg2video is 420,if it is not,I will stop the hardware decoder process.
[08:16] <highgod> I find a function try_decode_frame, can I write a function like it to get the mpeg2 chroma info 444 or 422 or 420
[08:52] <highgod> Can I add a function like mpeg_decode_sequence_extension to get the mpeg2 chroma format at init stage in my added file?thanks
[09:25] <j-b> 'morning
[11:28] <cone-942> ffmpeg.git 03Stephan Hilb 07master:36810215fa25: lavd/v4l2: improve debug message
[11:28] <cone-942> ffmpeg.git 03Stephan Hilb 07master:f245a2086a10: lavd/v4l2: update broken link to v4l2 video capture example
[11:49] <cone-942> ffmpeg.git 03Diego Biurrun 07master:0b22107d9504: rv34_parser: Adjust #if for disabling individual parsers
[11:49] <cone-942> ffmpeg.git 03Justin Ruggles 07master:23098bbd5093: vf_fps: add final flushed frames to the dropped frame count
[11:49] <cone-942> ffmpeg.git 03Diego Biurrun 07master:dae1d507af94: x86: Add PAVGB macro to abstract pavgb/pavgusb instruction via cpuflags
[11:49] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:68f92a70f1f4: Merge commit 'dae1d507af94261bafd3b11549884e5d1eca590e'
[11:55] <durandal_1707> what is CONFIG_RESAMPLE_AUDIOPHILE_KIDDY_MODE ?
[11:56] <durandal_1707> it appears it was removed
[12:03] <michaelni> its a mode for thouse who can hear a needle drop on the moon from earth
[12:05] <cone-942> ffmpeg.git 03Joakim Plate 07master:f924d52975ec: dvdsubdec: Support palette in mkv
[12:05] <cone-942> ffmpeg.git 03Ronald S. Bultje 07master:fb845ffdd335: h264: add 3 pixels below for subpixel filter wait position
[12:05] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:06af724c56c9: Merge commit 'fb845ffdd335a1efd6dfd43e8adeb530397b348e'
[12:10] <mateo`> durandal_1707: does the data size of an aiff chunk should be always even ? (even if the declared chunk size is odd)
[12:12] <cone-942> ffmpeg.git 03Martin Storsjö 07master:3130fa51a5d6: lavu: Add a fate test for the HMAC API
[12:12] <cone-942> ffmpeg.git 03Martin Storsjö 07master:c2603aa25b75: lavf: Add a fate test for the SRTP functions
[12:12] <cone-942> ffmpeg.git 03Martin Storsjö 07master:0eecafc948b7: configure: Make the new srtp protocol depend on the rtp protocol
[12:12] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:9ea65c65f700: Merge commit '0eecafc948b74c247ebbc59f18f508db5d590d0b'
[12:12] <mateo`> durandal_1707: in that case if (size & 1) file_size--; could be ok
[12:16] <durandal_1707> michaelni: it is not exported from configure
[12:16] <divVerent> durandal_1707: don't you see it? it's the placebo flag
[12:16] <durandal_1707> mateo`: i do not remmember, find spec
[12:17] <divVerent> sort of like using gold plugs for digital audio for better audio quality
[12:17] <durandal_1707> than name it PLACEBO and not AUDOPHILE_KIDDIE
[12:17] <divVerent> but then the kiddies would know
[12:17] <cone-942> ffmpeg.git 03Martin Storsjö 07master:42364fcbcac9: srtp: Mark a few variables as uninitialized
[12:17] <cone-942> ffmpeg.git 03Martin Storsjö 07master:977d4a3b8a2d: rtpdec_mpeg4: Check the return value from malloc
[12:17] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:1459f34251c3: Merge commit '977d4a3b8a2dbc2fb5e747c7072485016c9cdfaa'
[12:17] <mateo`> durandal_1707: i didn't find any specification for the ID3 chunk :(
[12:17] <divVerent> but seriously, it does something, but there is no way to set it on configure
[12:18] <divVerent> it mainly does all resampling decisions in foating point instead of integer
[12:18] <michaelni> divVerent, double precission floating point!
[12:18] <divVerent> yes
[12:18] <divVerent> change it to long double NOW!!!1
[12:18] <durandal_1707> mateo`: aiffenc put_meta use  FFALIGN(size, 2)
[12:18] <divVerent> ;)
[12:19] <michaelni> divVerent, sent patch and lets make a news entry on the front page
[12:19] <durandal_1707> how many bits it takes?
[12:19] <divVerent> michaelni: haha
[12:19] <divVerent> michaelni: extra points if for some reason, it doesn't even DO the caluclations as long double? ;)
[12:19] <durandal_1707> at least ha folks will be happy
[12:20] <divVerent> wonder if that can be snuck in somehow
[12:20] <divVerent> i.e. an accidental conversion to double
[12:21] <divVerent> haha
[12:21] <divVerent> this "extra point" is already given
[12:21] <divVerent>         dst[dst_index] = av_clip_int16(lrintf(val));
[12:21] <durandal_1707> mateo`: lol, i wrote that aiff code
[12:21] <divVerent> so we convert to float first
[12:21] <divVerent> then to int16
[12:21] <divVerent> luckily float DOES have enough precision ;)
[12:21] <durandal_1707> mateo`: i used sox/libsndfile as reference
[12:22] <divVerent> michaelni: haha, that should do ;)
[12:22] <divVerent> if we change the type to long double
[12:22] <divVerent> the filter array is STILL built using double math
[12:22] <divVerent> so chanigng this from double to long double seems to be a pure placebo
[12:23] <divVerent> at least the resampling itself is done using long double math then
[12:24] <cone-942> ffmpeg.git 03Nicolas George 07master:0e79fe37e5c5: lavd/v4l2: init return value.
[12:25] <divVerent> michaelni: http://dpaste.com/878947/ don't commit this ;)
[12:26] <divVerent> it's 100% placebo as the filter is still done using double math
[12:26] <michaelni> haha :)
[12:26] <michaelni> anyway resample now resides in libswresample
[12:26] <divVerent> that too
[12:26] <divVerent> makes it EVEN more pointless
[12:27] <michaelni> and it has a double precission mode without ifdefs ;)
[12:27] Action: divVerent just imagines coat hangers with golden 3.5mm audio plugs attached
[12:27] <divVerent> you do remember this test where some guys ABX'd coat hangers vs expensive cables
[12:27] <divVerent> and the coat hangers won
[12:27] <michaelni> lol
[12:28] <divVerent> http://gizmodo.com/363154/audiophile-deathmatch-monster-cables-vs-a-coat-hanger I think this is it
[12:28] <michaelni> are we missing a AV_SAMPLE_FMT_LDBL :/
[12:28] <divVerent> no, it was a draw
[12:28] <divVerent> well, the coat hangers DO have an advantage
[12:28] <divVerent> they're quite thick, thus very low resistance
[12:29] <divVerent> a long double sample format... unlikely we ever need this
[12:29] <durandal_1707> michaelni: yes we are missing it because you never know how it can be used (not just for pure listening)
[12:29] <pross-au> michaelni: no i want AV_SAMPLE_FMT_EVAL.
[12:29] <divVerent> long double is nasty unaligned stuff
[12:29] <divVerent> pross-au: you mean AV_SAMPLE_FMT_SYMBOLIC?
[12:30] <divVerent> which uses symbolic math and a computer algebra system to calculate stuff?
[12:30] <durandal_1707> and how would you encode/convert to id?
[12:30] <durandal_1707> *it
[12:30] <pross-au> that might please 'em
[12:30] <divVerent> convert TO it? easy
[12:30] <divVerent> convert FROM it? easy, once the values of all the variables are known ;)
[12:30] <wm4> btw. does anyone know how important 24 bit formats are for audio APIs 
[12:30] <pross-au> .m matlab file
[12:31] <divVerent> matlab is not symbolic math
[12:31] <divVerent> so we still need a CAS
[12:31] <wm4> because ffmpeg doesn't support that format
[12:31] <mateo`> durandal_1707: for the metadata chunk, quoting the aiff spec "ckSize is the size of the data portion of the chunk, in this case the text.
[12:31] <divVerent> a CAS that produces matlab formulas though
[12:31] <divVerent> so once you ran ffmpeg, you can then use matlab to do the real processing
[12:31] <divVerent> ;)
[12:31] <divVerent> wm4: IIRC it's somewhat important, can't tell for which APIs
[12:31] <divVerent> the main advantage is that it's "close" to 32bit float
[12:32] <mateo`> durandal_1707: + http://muratnkonar.com/aiff/index.html mention that  "chunkSize is the number of bytes in the chunk, not counting the 8 bytes used by ID and Size fields nor any possible pad byte needed to make the chunk an even size."
[12:32] <durandal_1707> mateo`: yes, but next chunk may still be aligned
[12:32] <divVerent> but sound APIs tend to rather use 32bit float
[12:32] <mateo`> durandal_1707: so i guess FFALIGN should not be used to write the size of the chunk there
[12:32] <wm4> that would require extra hacks to do the conversion past lavr's/swr's ass
[12:32] <durandal_1707> mateo`: it is for compability
[12:32] <mateo`> durandal_1707: howerver if (size & 1) avio_w8(pb 0) is still relevant
[12:32] <divVerent> was mainly saying, if your input is 24bpp, this can be losslessly converted from/to float32
[12:32] <mateo`> durandal_1707: ok ...
[12:33] <wm4> input is never 24 for the user, because lavc doesn't have that
[12:34] <wm4> not sure what it does with 24 bit raw input
[12:34] <divVerent> S32, I suppose
[12:37] <saste> av_probe_input_buffer() always fails if max_probe_size < PROBE_BUF_MIN
[12:38] <saste> so my question, is, does it make sense to be able to specify a probesize lesser than PROBE_BUF_MIN?
[12:39] <divVerent> "yes", because PROBE_BUF_MIN is not defined/documented in the header
[12:40] <divVerent> in other words, I wouldn't blame the caller for not knowing PROBE_BUF_MIN is 2048
[12:43] <saste> right now ffmpeg fails with invalid argument (correct), but with no hint to the user of what's going wrong
[12:43] <saste> in each it may be senseful to raise the minimum value accepted by probesize
[12:43] <saste> *in each case
[12:44] <divVerent> maybe just document the fact that EINVAL may be returned when max_probe_size is "too small" to get a clear result?
[12:45] <saste> divVerent, it is an application level problem, i'm going to add a message in the lib
[12:46] <divVerent> you mean in the header file?
[12:46] <divVerent> or an av_log one
[12:51] <saste> divVerent, av_log
[12:51] <cone-942> ffmpeg.git 03Martin Storsjö 07master:a7ba3244131d: rtpdec_mpeg4: Check the remaining amount of data before reading
[12:51] <cone-942> ffmpeg.git 03Justin Ruggles 07master:e034cc6c60c7: lavc: Move vector_fmul_window to AVFloatDSPContext
[12:51] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:5c7e9e16c961: Merge remote-tracking branch 'qatar/master'
[14:09] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:cae11e40315a: mux: fix chunked_duration rounding anomaly
[14:09] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:f0cf017dee3c: configure: suppress "enumerated type mixed with another type" for icc
[15:11] <kierank> durandal_1707: the error message is not strange at all
[15:28] <durandal_1707> mateo`: what is unclear to you about id3 tag?
[15:28] <durandal_1707> in aiff it is always 2byte aligned
[15:29] <durandal_1707> so skiping 1 byte if not aligned is enough
[15:29] <durandal_1707> and that is already done for metadata
[15:31] <durandal_1707> kierank: messages that telly you that arbitary bug is not going to happen are weird
[15:31] <mateo`> durandal_1707: this is clear now. however in the case i explained, do you agree that the declared chunk size is invalid ?
[15:34] <durandal_1707> the one in file?
[15:36] <mateo`> durandal_1707: the id3 chunk size is one byte less than the actual read data
[15:46] <durandal_1707> mateo`: yes, if all read data is used
[15:50] <mateo`> durandal_1707: at least they are consumed by the ff_id3v2_read function
[16:08] <cone-942> ffmpeg.git 03Nicolas George 07master:0942aa463736: lafv/matroska: add A_OPUS/EXPERIMENTAL codec name.
[16:37] <mateo`> do we have g726 samples ?
[17:45] <saste> anyone experience with HLS streaming? how much can latency be reduced?
[17:47] <kierank> you are limited by the chunk size afaik
[17:47] <saste> kierank, also i noticed that i can hardly control what the player displays
[17:48] <kierank> yes it's rather black magic
[17:48] <kierank> because of the wide range of implementations
[17:48] <kierank> this is why i don't work on HLS :)
[17:48] <saste> the problem is that it is advertised like "live" streaming when in the truth you can hardly control the latency
[17:49] <saste> for an interactive application 10 seconds is not "live" anymore
[17:49] <kierank> this is what i say to all the people who think adaptive streaming is as good as broadcast tv
[17:49] <kierank> 10 seconds is ridiculous to say the least
[17:49] <kierank> not including cdn caching etc
[17:52] <saste> kierank, 10s delay for VOD is not that bad
[17:52] <kierank> yes that's true
[17:52] <saste> it is a *big* problem if you have an interactive application (for example a guy talking on the other hand)
[17:52] <kierank> but channel surfing is a problem
[17:53] <kierank> (zapping)
[17:53] <saste> flash/rtmp is suited for that, but now people is trying to use HLS for doing the same stuff
[17:54] <kierank> flash/rtmp allows you to set a buffer time
[17:54] <kierank> all adaptive streaming etc is implementation defined
[17:54] <saste> so it seems
[19:21] <burek> hi guys :)
[19:21] <burek> happy ny and all the trailing holidays :)
[19:46] <burek> http://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[19:46] <burek> ‘segment_time time’
[19:46] <burek> Set segment duration to time. Default value is "2".
[19:46] <burek> is this in seconds, milliseconds, .. ?
[19:47] <burek> also ‘segment_times times’
[19:50] <saste> burek: they are duration specifications
[19:50] <burek> also, is it correct to write "-segment_list_flags +live" or "-segment_list_flags live" (documentation is not precise about the usage of +)
[19:50] <burek> saste [hh:mm:ss.mmm] ?
[19:50] <saste> +foo => add foo to the current value
[19:51] <saste> burek: see ffmpeg-utils(1)
[19:51] <burek> hm, it should be documented in some more clear way
[19:51] <burek> imho
[19:53] <burek> btw, if -segment_time 2 means 2 seconds, then there might be a bug in segment muxer http://ffmpeg.gusari.org/viewtopic.php?f=12&t=772 (provided that the guy is using the latest ffmpeg)
[19:55] <saste> burek: no, all are complaining about the same thing, noone reads (carefully) the docs
[19:55] <saste> it depends on I-frames on the input
[19:56] <burek> well if many are complaining, it might be a good idea to put a note there or something, to lower the number of complaints
[19:56] <burek> btw, this guy is re-encoding, he doesn't use -codec copy
[19:57] <saste> burek, it is already in the docs, i'll make it more explicit
[19:58] <burek> thank you :)
[20:05] <Compn> is there any warning message for user
[20:05] <Compn> when he selects -codec copy but uses encoder options ?
[20:05] <Compn> 'warning, you are copying video, any encoding options will be ignored...'
[20:06] <Compn> or e.g. ffmpeg -vcodec copy -vf yadif ... the vf will be ignored
[20:06] <Compn> mencoder also lacks this warning message
[20:09] <burek> yes, that would be highly useful if possible to implement
[20:10] <saste> we lack developers...
[20:24] <burek> is it possible to create vobsub (.idx/.sub) form .bmp files?
[20:25] <burek> using ffmpeg
[20:25] <burek> from*
[20:27] <Compn> have to check if we have vobsub muxer
[20:27] <Compn> i dont think so
[20:27] <Compn> demuxer only ?
[20:28] <burek> well, i think demuxer only would help too, if we can save the output into something useful
[20:28] <burek> that ffmpeg supports
[20:30] <burek> a guy has got a lot of bmp images, that he ripped using subrip from some video and he edited those bmp images and now would like to put all that into some subs format or so
[20:30] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=12&t=788
[20:31] <Compn> well there are bmp2vobsub tools ...
[20:33] <shahriman> guys, who looks after the mpeg-ps demuxer?
[20:35] <burek> Your search - bmp2vobsub - did not match any documents. :)
[20:37] <Compn> but uh
[20:37] <Compn> then i'm wrong
[20:37] <Compn> but i think ubitux was talking about bmp and vobsub
[20:38] <durandal_1707> shahriman: there is bug ?
[20:38] <shahriman> durandal_1707: yep. http://git.videolan.org/?p=ffmpeg.git;a=commit;h=759901f817cb481c989af7bec48f24377ec25735
[20:38] <shahriman> this is the culprit commit
[20:38] <shahriman> problem is
[20:38] <shahriman> i can't share sample
[20:39] <Compn> why not shahriman ?
[20:39] <shahriman> i don't own it
[20:39] <Compn> its covered under fair use 
[20:39] <shahriman> no it's not
[20:39] <Compn> if you mark it private, we will delete it after bug fixed
[20:40] <shahriman> IANL
[20:40] <shahriman> IANAL*
[20:40] <Compn> i've followed copyright law for a long time. its covered under fair use
[20:40] <Compn> but i'm no lawyer either :)
[20:41] <shahriman> sometimes users upload stuffs under CC, sometimes they allow anyone to download the original
[20:41] <shahriman> but in this case, the user didn't do any of those
[20:42] <Compn> it doesnt matter
[20:42] <Compn> for educational or research purposes , especially a small clip , runs under the fair use in us copyright law
[20:44] <durandal_1707> what is bug about?
[20:46] <durandal_1707> perhaps only first say 1023 bytes is needed to reproduce it?
[20:59] <Compn> since when does michael work on ogg code? :)
[20:59] <Compn> chained ogg
[21:09] <durandal_1707> if i type git clean -f i get : Not removing doc/examples/pc-uninstalled/
[21:10] <durandal_1707> perhapts it should be added to .gitignore?
[21:13] <shahriman> durandal_1707: http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/mpeg.c;h=f01e905982a4555c5c626822847d6f05ba97a282;hp=904399c113a32e86251a776d2d88fe32bdd62b00;hb=759901f817cb481c989af7bec48f24377ec25735;hpb=ce7cf600be62d81cddefb302c2f098672130774b
[21:13] <shahriman> it's the fourth hunk
[21:13] <shahriman> that's responsible
[21:14] <shahriman> I don't know where the number 6 came from
[21:14] <shahriman> i don't have the spec, so can't verify
[21:15] <durandal_1707> that still does not explain bug/crash
[21:15] <durandal_1707> where it crashes?
[21:17] <durandal_1707> michaelni: you have sample for above mentioned commit?
[21:22] <shahriman> durandal_1707: i never said it crashes
[21:22] <durandal_1707> so what is problem?
[21:22] <shahriman> it just breaks the audio decoding
[21:23] <shahriman> i get corrupted audio output
[21:23] <durandal_1707> it is detected as wrong codec?
[21:23] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:b7bc49a957a1: mips: move vector_fmul_window_mips to libavutil
[21:23] <cone-942> ffmpeg.git 03Michael Niedermayer 07master:1191db31c1ed: mux: fix chunked interleaver
[21:24] <michaelni> durandal_1707, i might have one but i dont know how to find it ...
[21:24] <michaelni> maybe searching trac would produce a sample
[21:24] <michaelni> or ask carl
[21:25] <shahriman> it's not really enough to have a particular sample
[21:25] <shahriman> you need the spec to be sure that the decoder is doing the right thing
[21:25] <shahriman> i doubt if the user submitted sample is broken
[21:26] <shahriman> i.e. broken muxer
[21:26] <shahriman> or encoder
[21:27] <shahriman> durandal_1707: it's not detected as a wrong codec, because I can still hear the original audio. only with a lot of clicking artifacts
[21:28] <shahriman> and this error:
[21:28] <shahriman> [pcm_s16be @ 0x7f2830000e00] Invalid PCM packet, data has size 2 but at least a size of 4 was expected
[21:28] <shahriman> Frame changed from size:0x0 to size:720x576
[21:28] <shahriman> [pcm_s16be @ 0x7f2830000e00] Invalid PCM packet, data has size 1 but at least a size of 4 was expected
[21:28] <shahriman> ofc windows media player plays it fine
[21:32] <michaelni> if someone provides me with a sample that doesnt work then i can try to fix it ...
[21:33] <michaelni> otherwise without spec and without sample i have no idea ...
[21:34] <shahriman> michaelni: well you accepted a patch without any reference in the first place which caused the breakage
[21:35] <durandal_1707> shahriman: looks like extra skip is done
[21:37] <durandal_1707> so if you undo 4th and 5th hunk it plays fine?
[21:39] <nevcairiel> this is the original issue that the patch fixed, http://roundup.libav.org/issue1731 .. there was a sample once, no idea if its still in incoming
[21:39] <shahriman> durandal_1707: undoing 4th does the trick
[21:39] <nevcairiel> DVD Audio isn't exactly a format that has documentation available everywhere on the web =p
[21:40] <shahriman> understandable
[21:43] <durandal_1707> i cant understand how by undoing 4th hunk issue is fixed
[21:46] <shahriman> durandal_1707: yeah sorry 4 and 5
[21:50] <durandal_1707> shahriman: same :(
[21:59] <cone-942> ffmpeg.git 03Paul B Mahol 07master:641bbd967119: vima: switch to init_get_bits8()
[23:36] <saste> wtf is this the segmenting year?
[23:36] <cehoyos> durandal_1707 : You asked January 5th about commit 697b476c075a - it was about ticket #1747
[23:37] <kierank> saste: yes
[23:41] <Daemon404> carl on irc? wtf
[23:41] <Daemon404> my world is shattered
[23:41] <saste> well rtsp issues also are going strong
[23:42] <saste> who want to debug a mov issue for me ?
[23:43] <Daemon404> lavf's mov/mp4 demuxer is the bane of my existence
[23:43] Action: Daemon404 is seriously considering writing liblsmash.c
[23:44] <Daemon404> (read: no wayyyyy)
[23:45] <saste> Daemon404, i got a nice crash coming from the hls demuxer
[23:45] <saste> chained crash
[23:45] <Daemon404> not touching hls
[23:45] <llogan> what if i said..."c'mon!"?
[23:59] <burek> "Please setup a official RPM Repository, where latest releases are updated."
[23:59] <burek> I think we spoiled our users with those static builds :)
[00:00] --- Thu Jan 17 2013