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

[burek]

[00:18] <Savvkin> Hey, everyone!
[00:19] <Savvkin> Any devs online?
[00:21] <ubitux> still no one to write/port some ivtc-related filter? :((
[00:21] <Savvkin> I got a suggestion about mp4 moof atoms. And already ready to donate XD Anyone? =)
[00:22] <ubitux> what's the suggestion?
[00:23] <Savvkin> ffmpeg got movflags isml for MS Smooth Streaming... And I feel unfair there is no such flags for Adobe FME
[00:24] <ubitux> you mean f4m stuff?
[00:25] <ubitux> hds?
[00:26] <Savvkin> fragments (both duration and size) works fine. moof atoms created in right order, but they are missing atoms flash player need. Atoms are 'rtmp' inside first moov, then afra and abst inside any following moof atoms.
[00:26] <Savvkin> I mean f4v for steaming
[00:27] <ubitux> right hds then, http dynamic streaming
[00:27] <Savvkin> http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf - Annex C. HTTP Streaming: File Structure
[00:27] <ubitux> yes right, i started looking at that at some point at work
[00:27] <ubitux> but it sucks so much i left my job
[00:28] <ubitux> though, from a technical PoV it should be possible without much pain
[00:28] <ubitux> but i don't wanna do it
[00:28] <ubitux> Savvkin: is HDS really used?
[00:29] <ubitux> from the little i saw, the f4f splitter thing from adobe is not really maintained, and is kinda broken
[00:29] <ubitux> also, the base64 binary blobs in the manifest are kinda wtf
[00:30] <Savvkin> Well, I didn't use HDS. For now I'm trying to produce file, that can be actually played by flash player
[00:30] <ubitux> so my question is: any reason to prefer hds over hls, dash or even hss ms thing?
[00:31] <ubitux> flash player doesn't support hls?
[00:31] <ubitux> at least some flash players seems to deal with it
[00:31] <Savvkin> Only thru commercial library I belive
[00:32] <ubitux> interesting
[00:32] <Savvkin> Also, I'm looking into live streaming
[00:33] <Savvkin> And I feel like HLS is more for static content streaming
[00:34] <ubitux> i'd suggest you to open an issue on the trac, mentioning you are willing to donate
[00:34] <Savvkin> HDS should be way faster, because we don't really need to store/read anything. All is made on mem.
[00:35] <ubitux> faster? at playback?
[00:35] <Savvkin> Faster at server IO
[00:36] <Savvkin> Since mp4 moof fragments are actually don't need to be stored/read from hdd
[00:36] <Savvkin> For live feed
[00:41] <ubitux> that sounds like a pretty wrong design choice to me
[00:41] <Savvkin> Why? What do you think is better?
[00:42] <ubitux> you need to read the fragment anyway when needed
[00:42] <ubitux> so i don't see what's wrong in having the header info in each fragment
[00:43] <ubitux> and having all the fragment headers in memory is hardly an advantage, or at least i don't see it
[00:43] <ubitux> but maybe i'm misunderstanding something
[00:44] <ubitux> all the fragments have the same duration, so for a given time you know which fragment to request
[00:44] <ubitux> so i don't get your point
[00:44] <Savvkin> For example, we have 5 sec fragments, then only one moof and one mdata in in memory at one time
[00:45] <Savvkin> Why should we keep past fragments in case of live streaming?
[00:45] <ubitux> they aren't
[00:45] <ubitux> afaik
[00:46] <Savvkin> When client connected, we push last cached fragment...
[00:46] <Savvkin> And keep pushing
[00:47] <ubitux> ah right you were talking about live stuff sorry; i was confused with hds for static delivery, where it's the similar to hls with a complex manifest
[00:47] <ubitux> dunno about live stuff
[00:47] <Savvkin> hls is just fine for static.
[00:49] <Savvkin> So, did you try to make file accordin ref doc? Do you have any live free/real adobe example file, so I can examples for missing sections?
[00:50] <Savvkin> live feed*
[00:51] <ubitux> not really, i left that stuff a while ago
[00:51] <ubitux> anyway, it's late, so 'night :)
[00:51] <Savvkin> Hey, maybe you want my donate? XD
[00:51] <ubitux> no thx ;)
[00:52] <Savvkin> Ok, do it for free? =)
[00:52] <ubitux> nope :)
[00:52] <Savvkin> So you wasn't success and dropped that stuff?
[00:52] <ubitux> priorities changed so i couldn't finish it
[00:52] <Savvkin> Or just was lazy / not motivated to continue?
[00:53] <ubitux> and it wasn't particularly interesting anyway
[00:53] <Savvkin> Was it hard, non-linear?
[00:54] <ubitux> it was a pain for several reasons, but i didn't really had time to work very much on it
[00:54] <Savvkin> I'm not sure what's "not much" time? evenings? days? weeks?
[00:55] <ubitux> a few days, with things in parallel, trying to figure out how it worked from the broken adobe tools, the very few samples in the wild, and messing with the insane base64 blobs in manifests
[00:57] <Savvkin> manifests = atoms?
[00:57] <Savvkin> or f4m file?
[00:57] <ubitux> the xml file
[00:57] <Compn> huh what
[00:57] <Savvkin> ahh, ok
[00:57] <ubitux> describing the fragments
[00:57] <Compn> theres a downloader
[00:57] <Compn> hds downloader
[00:57] <Compn> from KSV
[00:57] <Compn> its a php script...
[00:57] <Compn> to download adobe hds
[00:57] <ubitux> @_@
[00:58] <Compn> AdobeHDS is a php script to join HDS fragments into flv file. you can either use manifest switch or use any download manager with batch capabilities to download the fragments. f4f extension is optional.
[00:58] <Compn> https://github.com/K-S-V/Scripts/wiki
[00:59] <Savvkin> We are about generating them, rather downloading =)
[00:59] <Compn> heh
[00:59] <Compn> well theres the f4f > flv tool
[00:59] <Compn> you should be able to reverse it for the encoder :P
[00:59] <Daemon404> written in php because THERE IS NO GOD
[01:00] <Savvkin> I don't think his scripts reads custom adobe atoms, like rtmp afra abst
[01:00] <Compn> custom atoms
[01:00] Action: Compn shoots himself in head
[01:01] <Compn> Savvkin : anyways, adding moov atoms isnt difficult
[01:01] <Compn> nor is it even that much work
[01:01] <Compn> email the last person who added atoms
[01:02] <Savvkin> I bet f4v > 4lv just drops rtmp, afra and abst atoms
[01:02] <Savvkin> No way reverse will help understan what I need to put into them
[01:02] <Compn> yeah, sorry, i didnt know what you were doing
[01:02] <Compn> i still dont haha
[01:02] <Compn> why not just use adobe crap tools ?
[01:03] <Savvkin> You aswered. They're crap...
[01:04] <Savvkin> I need generate f4v with fragments using ffmpeg... But devs seem in love with M$... Implemented support for their Smooth Streaming...
[01:04] <Compn> lol
[01:04] <Savvkin> And forgot about Adobe
[01:04] <Compn> thats because everyone on the internet hates adobe
[01:04] <Compn> :P
[01:05] <Savvkin> Compn, wanna donate for that func in ffmpeg? XD
[01:05] <Compn> ask martin, he wrote the smooth streaming fragmenter
[01:05] <Compn> maybe he can be persuaded to write adobe hds encoder
[01:05] <Savvkin> Whats hes email?
[01:05] <Compn> wbs = martin
[01:05] <Compn> hes here on irc
[01:05] <Compn> or you can find his email on the ffmpeg list
[01:05] <Compn> no, i hate adobe too
[01:06] <Savvkin> martin who in ffmpeg list
[01:06] <Compn> Martin Storsjö
[01:06] <Savvkin> foundMartin Storsjö <martin at martin.st>
[01:06] <Compn> yep
[01:06] <Compn> 22k lines for smoothstreamingenc.c
[01:06] <Compn> ehe
[01:07] <Savvkin> He got to be difinetley in love with MS
[01:07] <Compn> hes a smart developer who has worked on many protocols
[01:07] <Compn> including rtsp and rtmp, for multiple projects
[01:08] <Savvkin> I bet
[01:17] <Savvkin> Ok, wrote him a letter, lets hope =)
[01:17] <Savvkin> Thanks everyone, bye
[03:32] <cone-276> ffmpeg.git 03Michael Niedermayer 07769354348a3a: PRINT_CODEC_SUPPORTED: fix used variable
[10:36] <cone-414> ffmpeg.git 03Diego Biurrun 076ca60d4ddd9b: x86: h264_intrapred: port to cpuflags
[10:36] <cone-414> ffmpeg.git 03Luca Abeni 07e004d175fe24: rtpenc_aac: Fix calculation of the header size
[10:36] <cone-414> ffmpeg.git 03Justin Ruggles 0700f8ad41c78d: add 24-bit FLAC encoding to Changelog
[10:36] <cone-414> ffmpeg.git 03Justin Ruggles 073ba416408aef: avconv: rescale packet duration to muxer time base when flushing encoders
[10:36] <cone-414> ffmpeg.git 03Justin Ruggles 073a2731cbd31d: flacenc: ensure the order is within the min/max range in LPC order search
[10:36] <cone-414> ffmpeg.git 03Michael Niedermayer 071b5a6d3c4966: Merge remote-tracking branch 'qatar/master'
[12:21] <cone-414> ffmpeg.git 03Michael Niedermayer 07ce1ebb31a9a0: tiffdec: use checked reads for tget*()
[12:22] <cone-414> ffmpeg.git 03Michael Niedermayer 076d1c5ea04af3: tiffdec: check count in metadata reading.
[12:49] <cone-414> ffmpeg.git 03Michael Niedermayer 07909a18f73b30: mjpegbdec: dont return a picture when there is no picture.
[12:55] <juanmabc> that last one is nice
[13:31] <cone-414> ffmpeg.git 03Michael Niedermayer 075ee008e01d5a: qdm2: check that coding_method is valid before using it.
[13:31] <cone-414> ffmpeg.git 03Michael Niedermayer 0713451f5520ce: atrac3dec: Check coding mode against channels.
[14:35] <mateo`> Tjoppen: if the edit_rate.{den|num} set to 0, should i set the sample_count to 0 and issue a warning or just fail ?
[14:36] <ubitux> i'd say go as far as you can in case of a demuxer
[14:37] <snagnever> hey! i have a converting question... im developing a web system that might have video converting feature. i would like to know which would be the best way to work with batch converting and which server would be the best deal for that. thx ;]]
[14:37] <ubitux> snagnever: ask #ffmpeg please
[14:37] <Tjoppen> mateo`: default to 48 kHz perhaps?
[14:37] <Tjoppen> or uh.. hm
[14:37] <vega13> hi, if I only have avpacket.data and thus not the rest of the packet information, how do I calculate avpacket.size?
[14:37] <snagnever> ubitux, ok
[14:37] <Tjoppen> 25 Hz perhaps :)
[14:42] <mateo`> Tjoppen: sounds better than having sample_count set to 0 :)
[14:46] <Tjoppen> yep
[14:46] <av500>  http://wondermark.com/884
[14:46] <av500> oops
[15:00] <cone-414> ffmpeg.git 03Michael Niedermayer 074c6e7c2d4d98: ivi_common: dont dereference null pointers.
[15:00] <cone-414> ffmpeg.git 03Michael Niedermayer 077ec1fe1f472c: lavf: Dont compare absolute to relative timestamps in duration gcd
[15:00] <ubitux> anyone sent a mail to peter for the valgrind problem?
[15:01] <ubitux> (lavf-wtv)
[16:31] <j-b> m
[16:43] <beastd> ubitux: i have some minor comments for vf tile patches. will send an email on-list later today.
[16:43] <ubitux> ok
[16:45] <beastd> ubitux:  also about sharing tables for shared windows build. IIRC there is other solution that avoids the duplication
[16:46] <ubitux> i can think of various solutions
[16:46] <beastd> i did not have a close look. but i remember i had a similar problem years ago. dunno what i did back than and if the code was removed in all those years...
[16:46] <ubitux> i really went with the simpler and obvious one because of lazyness
[16:46] <beastd> i will try to find out what i came up with (and if and why it failed)
[16:47] <beastd> also I am fine with commiting the duplication with comments for now. IMHO build fixes should get in
[16:52] <ubitux> imo the saner thing to do is:
[16:53] <ubitux> mmh
[16:54] <ubitux> well, make the duplicate only once
[16:54] <ubitux> one in lavc and one in lavf
[16:54] <ubitux> and eventually make the binary duplicate based on one common header
[16:54] <ubitux> so the list appears only once in the code
[16:55] <ubitux> but all of this for just a small 16B table might not be worth the noise
[17:04] <juanmabc> hi, so, does libswscale have some support for image compression as output?, i know of PIX_FMT_RGB24 and PIX_FMT_RGBA, but i would like to know about PIX_FMT_S3TC or something that i could pipe to opengl glTexSubImage faster than raw rgb(a), thanks
[17:07] <juanmabc> seems avutil/pixfmt.h gives me nothing but DXVA2_VLD regarding DirectX9
[17:08] <juanmabc> would be nice to speed up this opengl pipe
[17:26] <cone-414> ffmpeg.git 03Michael Niedermayer 079195377bc581: vp56dec: Fix handling of alpha configuration changes.
[17:26] <cone-414> ffmpeg.git 03Michael Niedermayer 077989f7e0b522: xmv: Fix integer overflow
[18:53] <cone-414> ffmpeg.git 03Michael Niedermayer 07fb6a72cde525: iff: avoid out of array reads, due to too many planes.
[18:53] <cone-414> ffmpeg.git 03Michael Niedermayer 07e481ba2ed794: vqf: check samplerate, avoid division by 0.
[18:53] <cone-414> ffmpeg.git 03Michael Niedermayer 07b8dc5f8bb3b1: twinvq: check bitrate for validity avoid division by 0
[20:03] <cone-414> ffmpeg.git 03Michael Niedermayer 0702a325cb6fdc: tiffdec: check rps, fix infinite loop.
[20:03] <cone-414> ffmpeg.git 03Michael Niedermayer 07623cfc93d9ba: pngdec: check that format matches too not just dimensions
[21:07] <cone-414> ffmpeg.git 03Michael Niedermayer 07ac7ff0963bf3: aacdec: fix temporary array size
[21:07] <cone-414> ffmpeg.git 03Michael Niedermayer 07b8551f8ea71b: pcmdec: check that channels is valid.
[21:07] <cone-414> ffmpeg.git 03Michael Niedermayer 072fbb37b51bbe: iff/ilbm: check remaining buffer size.
[22:13] <ubitux> mmh so av_export would solve the problem as well?
[22:15] <beastd> ubitux: yes. IIRC this is the mechansim i used back then after i created libavutil
[22:31] <beastd> ubitux: well my implementation was deleted by mans but it did use the same mechanism
[22:32] <beastd> but IIRC there was some catch to it that made it hard to implement properly
[22:33] <ubitux> mmh it already has av_export
[22:34] <nevcairiel> the problem is that it has it
[22:34] <nevcairiel> but its required to export the symbol in a dll
[22:34] <nevcairiel> or rather, its required when you import the symbol from a dll
[22:35] <beastd> ubitux: Which table was it again?
[22:35] <nevcairiel> so the right solution is to define av_export conditionally, but because ffmpeg consists of multiple libraries, you really need one symbol per library which you can then conditionally define appropriately
[22:35] <ubitux> beastd: avpriv_mpeg4audio_sample_rates
[22:40] <ubitux> nevcairiel: i must say i have a hard time figuring out a good way of fixing that stuff
[22:41] <nevcairiel> the right way is rather complicated because there is multiple libraries with cross-deps
[22:41] <beastd> ubitux: maybe i am mistaken but IIRC for the shared build i needed to define it on the declaration when included in the lib where it is not defined and have it not defined on when used in the same lib where the table is defined
[22:47] <beastd> I do not know why my code was removed apart from it would fix the mingw build. (I am sure I especially tested the mingw build multiple times with shared and without shared.)
[22:48] <nevcairiel> mingw doesnt need this
[22:48] <nevcairiel> its only for msvc
[22:49] <beastd> nevcairiel: I am sure it was needed at some point when building shared. Maybe there was something added to mingw later that made it unnecessary or unsupported.
[22:57] Action: beastd goes AFK
[22:58] Action: Daemon404 has started releasing a few plugins using msvc-built ffmpeg
[22:59] <Daemon404> the size difference is shocking
[22:59] <Daemon404> 2.5mb vs 913kb
[23:51] <cone-414> ffmpeg.git 03Michael Niedermayer 0798b377004d9c: twinvq: make ibps check unsigned
[23:51] <cone-414> ffmpeg.git 03Michael Niedermayer 07c63e76ba3553: ebml_read_binary: use fast_padded_malloc()
[23:51] <cone-414> ffmpeg.git 03Michael Niedermayer 07a93c7ca6ef62: ivi_common: more MV Checks, fixes out of array reads
[00:00] --- Sat Nov 10 2012