burek021 at gmail.com
Fri May 16 02:05:02 CEST 2014
[01:50] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:7efe83996c02: tests/fate-run: add runecho command to run a test and display its output
[01:50] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:565c321cd0d1: tests/fate/libavutil: run cpu test and display the cpus detected feature set
[02:51] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:3af7e7b501d9: avfilter/vsrc_mandelbrot: use av_malloc_array()
[02:51] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:f6d17d2aa98e: avformat/matroskaenc: use av_mallocz_array()
[02:51] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:09cd22860fef: avformat/libnut: use av_mallocz_array()
[04:47] <cone-808> ffmpeg.git 03Alex Sukhanov 07master:8b96f31817be: libavformat/mov: Elimitate double reading of COVR metadata if MOV_EXPORT_ALL_METADATA is enabled
[11:41] <plepere> it's aliiiiive !
[11:42] <plepere> doing more testing, but hevc ASM dbf should be good to go very soon
[14:44] <nevcairiel> Daemon404: GCC 4.8.3 release candidate was cut today, 4.8.3 final is scheduled for the 23rd.. iirc you wondered about it before
[14:44] <Daemon404> oci
[14:44] <Daemon404> oic
[14:45] <Daemon404> 4.9.1 is more interesting, but also ages away
[14:45] <nevcairiel> yeah that'll be 2 month at least
[14:45] <nevcairiel> they dont change their release timing just because of a compiler bug
[14:45] <nevcairiel> :)
[14:46] <Daemon404> they dont have timing
[16:41] <plepere> nevcairiel, ASM dbf patch sent
[16:43] <J_Darnley> I'll download it an test it on win64 in just a moment
[16:50] <ePirat> Hello
[16:50] <ePirat> can someone tell me where is the sourcecode for the hls muxer? I can only find segment muxer and hls demuxer
[16:51] <nevcairiel> the segment muxer can mux in hls format
[16:51] <nevcairiel> and it has more features as the hls muxer, so why not use that?
[16:51] <nevcairiel> in any case, the hls muxer is in libavformat/hlsenc.c
[16:52] <ePirat> hmh the manual recommended using the hls muxer for apple hls streams&
[16:53] <nevcairiel> dunno, i use the segment muxer successfully for hls streaming, just set segment_list_type to hls
[16:53] <ePirat> there is no hlsenc file
[16:53] <nevcairiel> then your code is wrong or out of date, i'm looking at it right now
[16:54] <ePirat> oh I see
[16:55] <ePirat> I have a problem with latest ffmpeg
[16:55] <ePirat> it tells me hls_base_url is unknown: https://gist.github.com/ePirat/00710e09e36ef9fee85a
[16:55] <ePirat> but as I can see in the code the option is defined
[16:57] <nevcairiel> hls_base_url is new, its not in ffmpeg 2.2.1
[16:57] <ePirat> oh
[16:57] <nevcairiel> if you were to use the segment muxer, it had such a feature for a long time already :D
[16:57] <ePirat> would be nice if the docs would point that out
[16:57] <nevcairiel> anyway, need to go
[16:58] <ePirat> thank you very much
[16:58] <ePirat> :)
[17:22] <ubitux> ah, it seems diego wants to drop --build-suffix
[17:23] <ubitux> ofc in theory it could be used to differenciate the -ffmpeg and -libav flavor of the libav* libraries on some systems
[17:23] <ubitux> i guess he doesn't want that
[17:25] <nevcairiel> I use build suffix. Screw him
[17:27] <Daemon404> indeed i replied
[17:27] <Daemon404> and linked to nevcairiel
[17:28] <Daemon404> nevcairiel, did you forget to actually write something in your email
[17:34] <nevcairiel> Phone mailing is hard
[17:35] <nevcairiel> I wrote a proper one tho
[17:36] <nevcairiel> In before "that's FFmpeg"
[17:43] <ePirat> hls muxer seems a bit unusable in 2.2.1, paylist/segments generate with segment muxer cannot be played with quicktime or my iPhone. works in vlc. weird&
[17:44] <nevcairiel> Try segment. :D
[17:44] <ePirat> I did
[17:45] <nevcairiel> Oh right. May need to set a bunch of options. Format to mpegts, and that option that only generates headers for first and last
[17:45] <nevcairiel> That had success for me
[17:46] <nevcairiel> Don't have the code in front of me since I'm on the subway. :p
[17:46] <ePirat> I'll try, thanks
[18:24] <ePirat> wow
[18:24] <ePirat> discovered it after 2 hours
[18:32] <compn> ePirat : so what was problem ?
[18:33] <ePirat> mpegts seems not be playable
[18:33] <ePirat> it worked with h264/aac segments for which i had to use -vbsf h264_mp4toannexb
[18:34] <ePirat> and the -write_header_trailer option
[18:47] <cone-725> ffmpeg.git 03Anton Khirnov 07master:b70d7a4ac72d: lavc: add a native Opus decoder.
[18:47] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:2c7d3ecfc962: Merge commit 'b70d7a4ac72d23f3448f3b08b770fdf5f57de222'
[18:47] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:96cb4c871837: swresample: swr_close()
[18:47] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:ffa05e0802fd: avcodec/opusdec: switch to swresample
[18:56] <ePirat> any idea how I can force ffmpeg to generate more acurate segments?
[18:57] <ePirat> specified length 5, videos total has 16 seconds
[18:57] <ePirat> first segment: 6, 2nd: 6, 3rd: 3, 4th: 1
[19:10] <cone-725> ffmpeg.git 03Carl Eugen Hoyos 07master:beeb7551d6ab: Fix make checkheaders if VDA is not available.
[19:21] <cone-725> ffmpeg.git 03Anton Khirnov 07master:0c1959b056f6: lavf: add AVFMT_FLAG_BITEXACT.
[19:21] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:eacf7d650dfe: Merge commit '0c1959b056f6ccaa2eee2c824352ba93c8e36d52'
[19:31] <cone-725> ffmpeg.git 03Anton Khirnov 07master:c9281a01b78c: lavf: drop the zero-sized packets hack
[19:31] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:f478e8500a3d: Merge commit 'c9281a01b78cc3f09e36300a0ca3f5824d1c74cf'
[19:37] <cone-725> ffmpeg.git 03Anton Khirnov 07master:efc7df6c1f11: lavc: preserve the original private data in avcodec_copy_context()
[19:37] <jamrial> michaelni: wouldn't it be better to let the opus decoder work with avr if ffmpeg is configured with it and not swr?
[19:37] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:9b7cb02319b6: Merge commit 'efc7df6c1f11b20a48e60c3f743ce2331b661973'
[19:38] <jamrial> hardcoding it for swr is as bad as hardcoding it for avr
[19:38] <wm4> the APIs are slightly different
[19:38] <wm4> just enough to annoy users
[19:38] <wm4> the real solution would be to merge swr improvements into avr, and dropping swr
[19:41] <jamrial> in this case it's a matter of some ifdeffery. no need for drastic measures
[19:49] <cone-725> ffmpeg.git 03Anton Khirnov 07master:3b2fbe67bd63: lavc: properly handle subtitle_header in avcodec_copy_context()
[19:49] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:098a699867e0: Merge commit '3b2fbe67bd63b00331db2a9b213f6d420418a312'
[19:49] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:97f856a4c271: avcodec/options: avcodec_copy_context() Check subtitle_header_size instead of setting it
[19:52] <michaelni> jamrial, i know and maintain swr code, so its alot easier for me to use it and deal with it if something doesnt work, using avr sometimes and using swr sometimes means strictly more code that can cause bugs, so i think its not a good idea unless theres some gain from that, is there ?
[19:56] <jamrial> i was simply thinking that just like libav hardcoded the decoder to lavr, we hardcoding it to swr alienates half the user base that chooses one library over the other
[19:57] <michaelni> hmm, i see the argument, and i dont object if you want to maintain support for avr-opus
[19:58] <michaelni> but then i dont vounteer to help if it breaks somehow, i already wondered why opus-avr broke make examples today
[20:03] <jamrial> alright, i'll see how problematic it might end up being and think about it
[20:06] <kurosu_> michaelni, hi
[20:06] <kurosu_> there are people posting to libav about implementing h23's unquantize for neon
[20:07] <kurosu_> I'm wondering if it's actually worth it, considering one may unquantize on the fly while parsing
[20:07] <kurosu_> I'm not sure because of the AC prediction in h263+/mpeg4 part2
[20:09] <michaelni> wm4, the sugested solution seems hard given the existing hostilities. Also if anyone from avr wants to work together, everyone is welcome in ffmpeg or swr.
[20:09] <kurosu_> the alternative would be (albeit slowly) to convert to "unquantize on the fly" and remove dsp fucntions/set it to return functions
[20:29] <michaelni> kurosu_, an optimized dequant would be useful for a encoder which otherwise doesnt use many timeconsuming features
[20:30] <michaelni> unless someone wants to try to implement on the fly dequant for encoders
[20:31] <michaelni> also it would be nice if these discussions would be on ffmpeg-devel ...
[20:31] <kurosu_> unless there's some coeff optimization like r/d-optimized quantization, why wouldn't the encoder have the same info as a decoder would ?
[20:32] <kurosu_> michaelni, agreed, though I was asking to see if it was worth even investigating
[20:33] <kurosu_> oh, I see for the encoder, it might be difficult to remember where they are located
[20:33] <kurosu_> *where the coeffs are located (in the coeff buffer)
[20:36] <michaelni> the encoder probably could use the same on the fly dequant but it doesnt currently
[20:38] <ubitux> michaelni: how large are the samples?
[20:40] <michaelni> ubitux, opus? 122mb
[20:40] <ubitux> aw
[20:40] <ubitux> wtf?
[20:40] <ubitux> wasn't opus supposed to compress well? :))
[20:40] <michaelni> fate hevc-conformace is just 63mb
[20:41] <michaelni> its raw pcm float files
[20:41] <ubitux> can't be generated with aevalsrc or something?
[20:42] <ubitux> mmh wait why would you need raw pcm?
[20:46] <kurosu_> last question: so as to compute stddev and max diff; but you can indeed compress the files losslessly (to half the size?) and it may even reduce test runtime (less data to read)
[20:53] <jamrial> ubitux: same as dts tests, to compare the decoded data with the reference pcm file in question. md5/crc is out of the question for float
[20:58] <wm4> we should add support for NSA fuzzy md5 /troll
[20:59] <cone-725> ffmpeg.git 03Olivier Langlois 07master:af31d58a635b: doc: Add udp broadcast option description
[21:06] <cone-725> ffmpeg.git 03Janne Grunau 07master:5e2ba41d4b94: build: add avresample after avcodec to FFLIBS
[21:06] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:fcb5849a62e5: Merge commit '5e2ba41d4b94de1fa5267081d6c4b6b262c8d86f'
[21:13] <cone-725> ffmpeg.git 03Tristan Matthews 07master:7c5ca546a074: configure: fix enable-libopus help string
[21:13] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:91d7d790d176: Merge commit '7c5ca546a0747a20c7f7fb5550455c3042699ee9'
[21:16] <jamrial> i'm glad i wrote the float resample asm for swr seeing how opus uses it unconditionally in most cases
[21:20] <cone-725> ffmpeg.git 03Janne Grunau 07master:d3f5b94762fb: aarch64: opus NEON iMDCT and FFT
[21:20] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:30cdf384d143: Merge commit 'd3f5b94762fb803c0f3b29f9ad6c5eaa813998ba'
[21:21] <mraulet> michaelni, what is the purpose of key_frame? I think the patch is not totally correct if the goal is to recover Radom Access Point
[21:22] <michaelni> purpose is to be a point from where decoding can start
[21:24] <mraulet> okay so a RAP
[21:24] <michaelni> yes
[21:31] <mraulet> michaelni so I am missing the purpose of the patch since key frame since to be already managed
[21:32] <mraulet> might be a bug somewhere else in the code
[21:32] <michaelni> should i revert it ?
[21:34] <mraulet> I would prefer yes
[21:34] <mraulet> I would like to get a bitstream
[21:34] <mraulet> I can check then
[21:40] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:f8de1caa6e98: Revert "avcodec/hevc: fix outputted AVFrame.key_frame"
[21:41] <michaelni> mraulet, done, if you want to ask the patch author see "[FFmpeg-devel] HEVC decoder always outputs key_frame equal to 1"
[21:42] <mraulet> I was writing an email to him
[21:42] <mraulet> ccing you
[21:43] <michaelni> ok thx
[22:53] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:e9602dcb4d7e: ffmpeg: bitstream filters require split out side data
[22:53] <cone-725> ffmpeg.git 03Michael Niedermayer 07master:7a4424e5ed3a: avcodec/opus: fix doxygen comments to be associated with the correct fields
[23:26] <cone-725> ffmpeg.git 03Christophe Gisquet 07master:d1310c591eb2: x86: sbrdsp: implement SSE qmf_deint_neg
[00:00] --- Fri May 16 2014
More information about the Ffmpeg-devel-irc