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

[burek]

[00:00] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:7f2af3f56b3d: avformat/rtsp: add av_assert0() to clarify that the else case is supposed to be unreachable
[00:00] <cone-216> ffmpeg.git 03Andrey Utkin 07master:08e6832a94cc: avformat/rtsp: pass return code from ffurl_open() on its failure
[01:59] <jamrial> BBB: since you are the one that wrote the atomic operations support on lavu, what do you think about replacing the legacy __sync functions in atomic_gcc.h with the new __atomic ones introduced with gcc 4.7.0?
[02:00] <jamrial> https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/_005f_005fatomic-Builtins.html
[02:03] <jamrial> __atomic_{load,store}_n() seems more reliable than __sync_synchronize()
[02:04] <BBB> I have no problems with that
[02:04] <BBB> I suppose you ont want to support both?
[02:05] <BBB> (Im not insisting you do, just wondering about your opinion)
[02:08] <jamrial> there's a pthreads and win32 fallbacks, so i guess we can replace them instead of keeping both
[02:11] <jamrial> i'm indifferent since i don't use gcc 4.6.x or older (where a fallback would be used instead)
[02:11] <jamrial> replacing them would mean less of a maintenance burden
[02:21] <iive> maintenance burden is argument abused by deleteonists. Keep the old one and remove it when it breaks something.
[04:21] <hungnv> rcombs, about the issue ffmpeg changes duration of video file and frame yesterday, the command ffmpeg -i in.ts -acodec copy -vcodec libx264 -b 1000k -s 640x360 -vf scale=640:-1 -keyint_min 50 -copyts -mpegts_copyts 1 -vsync 0 -f mpegts out.ts, output duration and start time is exactly as input, but pts&dts time of frames totally changed
[04:22] <hungnv> I thought it worked, but it did not, output sound and video are terrible :(
[05:43] <t4nk511> Hello. I'm trying to submit a patch to ffmpeg-devel at ffmpeg.org but for some reason it doesn't seem to be making it to the mailing list (for example when I check here: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-October/date.html).
[05:43] <t4nk511> The commands I run are `git format-patch -1 --subject-prefix='FFmpeg-devel] [PATCH'`
[05:43] <t4nk511> That outputs a .patch file, which I then try to submit with: `git send-email blah.patch`
[05:44] <t4nk511> which asks for confirmation, then I say yes, and it then says Result: OK
[05:49] <jamrial> no need to add any prefix. [PATCH] is added by format-patch, and [ffmpeg-devel] by the mainling list
[05:50] <jamrial> did you register to the mailing list? if not, then your email is awaiting moderator approval
[05:51] <t4nk511> I did register for the mailing list. I've been receiving ffmpeg-devel messages for a few days now...
[05:53] <t4nk511> A few days ago I submitted with no subject-prefix, and I did see that [PATCH] was automatically added. But when i look at my "sent" messages I saw that there is no [FFmpeg-devel] in the subject, so that's why i tried again with adding it in. I thought that was the reason it wasn't showing up in the list
[05:58] <jamrial> well, unless the email was too big (which will be held until approved) or triggered some sort of spam filter, the problem is probably on your end. either git send-email or maybe your provider
[06:10] <t4nk511> hmm ok thanks. I will try sending an email manually then
[10:21] <arwa> Here is the code
[10:21] <arwa>  http://pastebin.com/k4qs1vgu
[10:21] <arwa> And I am getting this error
[10:22] <arwa> libavfilter/vf_xbr.c:42:5: error: no previous prototype for ‘d’ [-Werror=missing-prototypes]
[10:23] <ubitux> make it static
[11:07] <ubitux> i like that {codec,format}_whitelist
[11:07] <ubitux> michaelni: what's the risk if the av_strdup() fails?
[11:08] <ubitux> isn't this going to actually allow any codec/format?
[11:08] <ubitux> (it's unlikely but still...)
[11:09] <ubitux> we could imagine a scenario where resources exhausts on a particular system and circumstances could somehow make the strdup fail, which would lead to a sudden whitelisting of everything
[11:09] <ubitux> kind of unlikely but well...
[11:14] <michaelni> ubitux i did say that thw whole local whitelist system is a fragile and insecure mess
[11:15] <ubitux> ok
[11:15] <michaelni> the global one is better, if you want security
[11:15] <ubitux> global one = --disable-X?
[11:15] <michaelni> no
[11:16] <michaelni> avcodec_register_list(), the patch is on the ML, review is welcome
[11:20] <wm4> michaelni> ubitux i did say that thw whole local whitelist system is a fragile and insecure mess <- then why did you add it, even though nobody asked for it
[11:21] <wm4> <michaelni> avcodec_register_list(), the patch is on the ML, review is welcome <- that is bullshit, I told you
[11:21] <wm4> it doesn't work, it can't worl
[11:21] <wm4> *work
[11:21] <wm4> the only "secure" way is compiling ffmpeg with these codecs disabled
[11:23] <ubitux> wm4: it's useful on the command line (the local whitelist system)
[11:23] <michaelni> wm4, some system is needed for applications like chrome, some distributions dont "allow" duplicated libs. so no whitelist doest work
[11:24] <michaelni> and people where against the way this can be done solidly which is globally at register thats why i added the local variant
[11:24] <wm4> bullshit
[11:24] <wm4> it can not be solidly the global way
[11:24] <wm4> +done
[11:26] Action: rcombs appears to have missed something
[11:26] <wm4> this discussion is relatively old
[11:26] <michaelni> yep
[11:28] <michaelni> wm4 if you can exploit the global code where a codec wasnt registered and the AVCodec struct overwritten then its exploitable and not solid, if you cant it is solid from a security point of view
[11:28] <michaelni> the local variant is not secure due to strdup failure and easily having similar issues being missed
[11:29] <michaelni> ill of course fix issues like te strdup one but iam afraid i will miss some
[11:29] <wm4> I can't believe you're selling off global mutable state as security feature
[11:32] <rcombs> wm4: explain?
[11:32] <wm4> rcombs: there's a global linked list of "registered" codecs
[11:33] <rcombs> yup
[11:33] <wm4> this has no reason to exist, and at least currently, has absolutely no use for the API user
[11:33] <wm4> and it's unsafe (not thread-safe, not library-safe)
[11:33] <wm4> but michaelni had the idea to disable codecs globally by allowing to register only some codecs
[11:34] <cone-692> ffmpeg.git 03Martin Storsjö 07master:1bd0bdcdc236: lavu: Add av_gettime_relative
[11:34] <wm4> nevermind that any library in the same process could just enable all codecs anyway...
[11:34] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:e96ca404eae8: Merge commit '1bd0bdcdc236099d5c0d179696951f35f5310fa5'
[11:36] <rcombs> what makes that a security feature?
[11:36] <wm4> codecs can contain bugs
[11:36] <wm4> especially obscure ones
[11:38] <rcombs> so, it lets an API user enable only codecs that they presume to be safe?
[11:38] <wm4> yes
[11:39] <ubitux> well at least it reduces the attack surface if you have control over your process
[11:39] <ubitux> which is kind of often the case
[11:40] <michaelni> "nevermind that any library in the same process could just enable all codecs anyway..." <-- that would be a bug
[11:53] <J_Darnley> Can someone explain why the global linked list is unsafe?  I thought it was only created once and never touched again therefore making it thread safe (if I understand that ther correctly)
[11:56] <cone-692> ffmpeg.git 03Olivier Langlois 07master:6fdf35fe35d8: lavc: Use av_gettime_relative
[11:56] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:8fd07fa6cc37: Merge commit '6fdf35fe35d8c1c467708238100648a7a47c930d'
[12:00] <wm4> J_Darnley: a library could call the register function at any time
[12:00] <wm4> unless you use atomics or a mutex, it's not safe against concurrent mutation
[12:07] <cone-692> ffmpeg.git 03Olivier Langlois 07master:e205429fcf9d: tools: Use av_gettime_relative
[12:07] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:63001833c51c: Merge commit 'e205429fcf9de3182bce2f4cfd1d6401596a8666'
[12:29] <cone-692> ffmpeg.git 03Martin Storsjö 07master:248d8fb60c59: avplay: Use av_gettime_relative
[12:29] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:872e087305a4: Merge commit '248d8fb60c59c8e044d9c8f78f23383b7cdecf72'
[12:38] <cone-692> ffmpeg.git 03Martin Storsjö 07master:d0c093021943: avconv: Use av_gettime_relative
[12:39] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:2896b981830e: Merge commit 'd0c093021943e9b9c23528b12cd61ca2a5b01b4f'
[12:39] <hungnv_> rcombs, are you available?
[12:40] <rcombs> hungnv_: yes, but I probably can't provide any additional insight on your timestamp problem
[12:41] <hungnv_> ha ha, ok, I will try myself. Actually -mpegts_copyts 1 -vsync 0 -copyts -acodec copy work (for the ffmpeg application), but not work when I implement using API.
[12:43] <rcombs> ah, interesting
[12:45] <cehoyos> hungnv_: Why don't you use the same command line (with -f segment) for the second encoding as you used for the first encoding?
[12:45] <cehoyos> michaelni: I pushed a patch to support Go2Meeting 5 to github: I didn't believe it myself but for the sample we have, there is no decoding error that I found.
[12:46] <hungnv_> cehoyos, I am writing a web server, user request original file -> serve file already segmented using ffmpeg (the application), when user request lower bitrate, take the origin file -> transcode and deliver it to user. That's why...
[12:47] <cone-692> ffmpeg.git 03Martin Storsjö 07master:6df9d9b55d3f: lavf: Use av_gettime_relative
[12:47] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:2c5ae5777690: Merge commit '6df9d9b55d3f56ee7782639a7678eeeaf77f14ea'
[12:47] <hungnv_> actually I am close to success, just a few step behind 
[12:48] <cehoyos> You original command line contains "-f ssegment -segment_list playlist.m3u8 -segment_time 5" and the one you tested after I asked you to used hls encoding: Of course the output isn't identical.
[12:49] <cehoyos> Now just take the encoded file and reencode it with lower bitrate but not a completely different command line.
[12:50] <hungnv_> cehoyos, with options provided by rcombs, the output's pts is the same as input, just the quality changed, that's what I want. (ffmpeg -y -i 759.ts -vcodec libx264 -vb 500000 -s 640x360 -f mpegts -aspect 16:9 -g 25 -keyint_min 50 -vf scale=640:-1 -copyts -mpegts_copyts 1 -vsync 0 -acodec copy ~/hung.ts) 
[12:51] <hungnv_> Now I implement that command using the api, start frame has right pts, duration changed, it's less than the original one, last frame has wrong pts, maybe some frame was dropped 
[12:52] Action: hungnv_ remembers last night it worked, then he slept for some hours, stay up and it stops working...
[12:53] <hungnv_> rcombs, can you take a look at my code?
[12:53] <cehoyos> hungnv_: Of course this will work (and it sounds like the correct solution) but please remember my question why are you trying difficult things if the easy things should work fine...
[12:54] <hungnv_> cehoyos, I cannot use the application, that's why. 
[12:57] <hungnv_> cehoyos, I appreciate your advices but, my situation is, I want to use ffmpeg api to transcode mpegs -> mpegs, not to transcode the whole playlist (although transcoding the whole playlist does not work in this case), not to use the application to transcode
[12:58] <cone-692> ffmpeg.git 03Anton Khirnov 07master:99143140dea1: mp3dec: fix reading the Xing tag
[12:58] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:899d3706d8fd: Merge commit '99143140dea12363af680d02e23cb42cfe191679'
[13:00] <cehoyos> Yes, and using the API you still have to decide the output format: Just use segment with the same options you used for original encoding.
[13:01] <hungnv_> it don't get your idea, how can I apply options to segment to file that's already segmented 
[13:01] <hungnv_> the command showed above is what I want to implement
[13:01] <cehoyos> You fead the m3u8 file to libavformat: It will be read just like a single file
[13:01] <cehoyos> Then you tell libavformat to write "segment" (just as you did from the command line).
[13:02] <hungnv_> problem is, transcode the whole playlist takes too much time, transcode a segment takes second
[13:02] <cehoyos> Did you try seeking?
[13:02] <cehoyos> I didn't realize you are reencoding on the fly.
[13:02] <hungnv_> with seeking, my solution works
[13:03] <cehoyos> I meant: If you don't want to transcode the whole m3u8 "file", why don't you seek to the position that you want to start encoding from?
[13:04] <hungnv_> take this for example : http://221.132.35.210:9090/ , the first is the origin, the second I am trying to finish, although people around here think it works already
[13:04] <cehoyos> I still believe that switching segments may not always work.
[13:04] <cone-692> ffmpeg.git 03Anton Khirnov 07master:c63418e0a3af: doc: reword the mp3 muxer documentation
[13:04] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:7ad34f445648: Merge commit 'c63418e0a3afbcdbc59fd65c270d45efafe092ce'
[13:04] <cehoyos> I am not saying it shouldn't work but it currently does not and I feel that for some encoding options, it cannot work
[13:04] <cehoyos> (You may not be using those)
[13:05] <hungnv_> which options ? :D
[13:05] <hungnv_> I need just a hint
[13:05] <cehoyos> Like using another audio codec.
[13:05] <hungnv_> I don't encode audio, just muxing them, (-acodec copy)
[13:06] <cehoyos> I believe you misunderstood:
[13:06] <cehoyos> I said it may be impossible to generally solve the problem you reported (different file length), for example because of different audio codec.
[13:06] <cehoyos> I already wrote above that "-acodec copy" probably (also) fixes your problem and probably suitable anyway.
[13:07] <cehoyos> "your problem" != "the problem you reported (different file length"
[13:07] <hungnv_> cehoyos, but in case ffmpeg application works for 1 file, if I implemented right, my application using ffmpeg api must produce same output as ffmpeg application 
[13:07] <cehoyos> ... and is probably more suitable anyway.
[13:08] <cehoyos> Of course (or do I misunderstand?)
[13:09] <cehoyos> Sorry, gtg
[13:09] <hungnv_> for example, if I takes list of ts filed that's ALREADY segemted, using the command ffmpeg above to transcode all of them, every file has right duration, and startime, and play well without any problem
[13:09] <hungnv_> ah, ok...
[13:15] <cone-692> ffmpeg.git 03Anton Khirnov 07master:88b32673db39: avconv: copy stream-level side data when streamcopying
[13:16] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:6ef5e292200b: Merge commit '88b32673db39440422a73ec3047d3326c96b4fb2'
[15:33] <ubitux> arwa: so is it bitexact with the reference?
[15:40] <arwa> sorry, I didn't get your question
[15:40] <ubitux> arwa: is it pixel value exact with the reference implementation?
[15:41] <ubitux> like no ±1 difference in values
[15:41] <ubitux> i'm reviewing the patch anyway, you can answer on the ml
[15:57] <arwa> okay
[15:58] <arwa> Well, I guess yes.
[15:58] <ubitux> review sent
[16:12] <arwa> I am no getting how to replace float with int?
[16:13] <arwa> I went through the hqx code, there they took uint32
[16:13] <arwa> but dont we need uint24?
[16:14] <arwa> Also, how do I combine the rgb value to get a uint24 format?
[16:18] <ubitux> arwa: see 236aa4de2a103d36b5f3381717150a6780c46697 for example
[16:18] <ubitux> but adjust to your needs
[16:21] <cone-692> ffmpeg.git 03Anton Khirnov 07master:ef363ebd596d: mp3enc: write full LAME frame
[16:21] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:e744e9a30589: Merge commit 'ef363ebd596da18f889a7d4845023a23dfac84c9'
[16:21] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:2dbee1a3935a: avformat/mp3enc: Squeeze our mp3 encoder tag into the 9byte shortname instead of randomly truncating
[16:40] <kierank> c
[19:00] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:279b2a4deb3b: avformat/mp3dec: also accept Lavc as shortname to read delays
[19:00] <cone-692> ffmpeg.git 03Benoit Fouet 07master:e56425d1a718: avcodec/aacdec: warn user when remapping streams.
[19:11] <arwa> How to convert a rgb value to uint24?
[19:23] <wm4> arwa: bit shifts?
[19:25] <arwa> is this correct - ( r | (g<<8) | (b<<16))
[19:27] <cehoyos> I believe shift is stronger than or...
[19:27] <cehoyos> (r | g << 8 | b << 16)
[19:41] <nevcairiel> although the preferred order is with the highest shift first
[19:44] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:4641ae352ec5: avformat: Add and use ff_copy_whitelists()
[19:44] <cone-692> ffmpeg.git 03Eric Zimmerman 07master:4ba5420e4d36: Added support for G2M5 codec
[20:07] <ubitux> cehoyos: can we have a tag for  the license violations?
[20:13] <cehoyos> https://trac.ffmpeg.org/query?status=!closed&type=license+violation
[20:13] <cehoyos> ?
[20:13] <cehoyos> ?https://trac.ffmpeg.org/query?type=license+violation
[20:14] <cehoyos> How do you install Medialooks?
[20:14] <cehoyos> I am curious to see the software license, I would be surprised if it is compliant...
[20:15] <cehoyos> (Ticket 3241)
[20:21] <ubitux> ah, there is a "type"
[20:21] <ubitux> i don't see it displayed in the tickets
[20:21] <ubitux> ah, on top, meh.
[20:37] <kierank> all the gpl violators are stalking me on linkedin
[20:38] <ubitux> haha
[20:39] <ubitux> just to check if you might attack them probably
[20:39] <ubitux> and see if it's worth the effort complying
[20:43] <Compn> haha
[20:43] <iive> kierank: can you post some ambiguous message, like "today we are going to hit another gpl violator. watch the news."
[20:44] <ubitux> :D
[20:44] <wm4> "mplayer developer makes death threat on the internet
[20:44] <wm4> "
[20:44] <iive> i was thinking of swat team swarming their building...
[20:45] <iive> and taking anything computer related :)
[21:32] <jamrial> unless i'm missing something, __atomic_compare_exchange_n() can't be used instead of __sync_val_compare_and_swap() without changing the avpriv_ wrapper
[21:32] <jamrial> which means changing the other implementations as well and waiting for a major bump
[21:35] <jamrial> the other three functions should be ok, though
[21:40] <wm4> jamrial: what's the problem?
[21:43] <jamrial> return type is different, it also tries to write to oldval if it fails
[21:48] <jamrial> __sync_val_compare_and_swap(*ptr, oldval, newval) compares *ptr and oldval, if equal writes newval to *ptr, and always returns the value of *ptr as it was before the operation
[21:49] <jamrial> _atomic_compare_exchange_n(*ptr, *oldval, newval, ...) compares *ptr and *oldval, if equal writes newval to *ptr and returns 1, if not equal writes *ptr to *oldval and returns 0
[21:50] <jamrial> the value of *ptr as it was before the operation is apparently lost if it succeeds
[22:33] <wm4> jamrial: can't you copy oldval?
[23:18] <jamrial> mmh, you're right. oldval will always be equal to *ptr as it was before the operation
[23:24] <cehoyos> kierank: Do you see an EULA when installing Medialooks?
[23:24] <kierank> don't know - was a long time ago
[23:25] <cehoyos> How is it supposed to be installed?
[23:25] <kierank> It's a dll if i remember rightly
[23:26] <kierank> not on a windows pc right now so can't check
[23:26] <kierank> cehoyos: I would like to get a hold of blue lucy
[23:26] <kierank> their other products
[23:26] <kierank> but you need to register and they know my name now
[23:27] <cehoyos> What is a blue lucy?
[23:27] <kierank> https://trac.ffmpeg.org/ticket/2908
[23:27] <cehoyos> I succeeded installing Medialooks (wine msiexec): It shows no EULA...
[23:27] <kierank> blue lucy have other products apart from a media player
[23:27] <kierank> I was at a meeting where they said it was "retired"
[23:27] <cehoyos> It does show an EULA: It is empty;-)
[23:28] <cehoyos> The Bluelucy link does not return a zip file...
[23:28] <kierank> yes because they retired that program
[23:28] <kierank> after i complained about enable nonfree
[23:29] <kierank> but they have other software that's almost certainly gpl violating
[23:29] <kierank> http://bluelucy.com/browse-proxy-transcoder/
[23:29] <kierank> almost certainly ffmpeg
[23:32] <cehoyos> I don't disagree but is this software really free? Why are they doing such an effort to keep it secret?
[23:33] <kierank> because then they can get the email address of sales contacts
[23:33] <kierank> so they can sell them more gpl violating software
[23:33] <kierank> it's a loss leader
[23:33] <cehoyos> Ok
[00:00] --- Sat Oct 25 2014