[Ffmpeg-devel-irc] ffmpeg.log.20160824
burek
burek021 at gmail.com
Thu Aug 25 03:05:01 EEST 2016
[00:05:50 CEST] <D`K_C> when using av_parser_parse2, does the input buffer have some constraints on its size/alignment?
[00:22:25 CEST] <kadiro> I have many wmv videos, the problem each one have 3 videos stream+ 1 audio stream , i converted one of them ( operation too slow ), it look is fine ( didn't check the whole video ), my question: Is it fine with ffmpeg to convert WMV videos that have many stream inside them, and if yes why the generated video have only one video stream ?
[00:22:55 CEST] <kadiro> here is the ffprobe sample file: http://dpaste.com/13WVNFN
[00:23:37 CEST] <durandal_1707> by default ffmpeg picks one video and one audio stream
[00:24:13 CEST] <kadiro> the duration of the source video wmv and the resulted mp4 file are same
[00:25:39 CEST] <kadiro> durandal_1707, how to tell ffmpeg to convert all streams?
[00:26:11 CEST] <durandal_1707> mapping them iirc
[00:26:49 CEST] <kadiro> durandal_1707, i have about 52 or like so, you mean to convert one by one, as i want to do a for loop
[00:27:41 CEST] <kadiro> i hope they have 3 stream for each one
[00:27:45 CEST] <durandal_1707> if every file have same number of them, use -map
[00:28:04 CEST] <durandal_1707> see docs...
[00:30:50 CEST] <kadiro> cool each one have 3 video streams , i did a loop with ffprobe + grep , thanks durandal_1707
[00:37:57 CEST] <kadiro> I used: -map 0:1 -map 0:2 -map 0:3 -c:v libx264 -map 0:0 -c:a aac but it doesn't seem to work, it say: Output file #0 does not contain any stream
[00:39:41 CEST] <kadiro> tried map 0:v same thing
[00:40:57 CEST] <durandal_1707> remove last map
[00:43:20 CEST] <kadiro> it is audio stream i think
[00:43:41 CEST] <kadiro> oops my bad i forget the '-i' o_o
[00:44:08 CEST] <kadiro> thanks durandal_1707 and sorry to be very annoying :D
[00:49:40 CEST] <kepstin> kadiro: this is why we usually ask folks to show the complete commandline :)
[00:50:11 CEST] <kadiro> kepstin, you're right :) thanks
[02:58:59 CEST] <witChdoCtOr> hello
[03:14:32 CEST] <jookiyaya> what is best video codec that existed before x264
[03:14:54 CEST] <kepstin> before h264? probably mpeg4 asp as encoded by xvid or divx
[03:15:12 CEST] <jookiyaya> xvid is horrible, are you sure?
[03:15:22 CEST] <klaxa> what?
[03:15:29 CEST] <klaxa> xvid wasn't that horrible really
[03:15:41 CEST] <jookiyaya> have you not seen xvid encoded videos?
[03:15:49 CEST] <klaxa> i have
[03:15:54 CEST] <c_14> If you give it enough bitrate it's fine
[03:16:05 CEST] <kepstin> it was certainly better than mpeg-2
[03:16:08 CEST] <klaxa> yeah most xvid videos around are targeted at fixed filesize
[03:16:17 CEST] <klaxa> and therefore look shit
[03:16:19 CEST] <jookiyaya> what about wmv9
[03:16:37 CEST] <kepstin> you'll probably see a lot of xvid movie encodes targetting 700mb cds, which will of course look not very good
[03:17:05 CEST] <jookiyaya> why limit to 700mb ?
[03:17:14 CEST] <c_14> Because that's how big a CD is
[03:18:17 CEST] <kepstin> hey, they were originally 650mb, the 700mb ones were the fancy ones ;)
[03:19:25 CEST] <klaxa> if my wikipedia research is not too shabby wmv9 is mpeg4 asp compliant?
[03:19:37 CEST] <jookiyaya> is that mean x264 would look crap too if they limit to 700mb ?
[03:19:56 CEST] <klaxa> less crap but still crap
[03:20:03 CEST] <c_14> Depends on the video resolution, but in most cases yes (though it should look better than mpeg4)
[03:20:14 CEST] <kepstin> jookiyaya: h264 (particularly as encoded by x264) with a standard-definition source could probably do a decent job of a movie in 700mb
[03:20:15 CEST] <c_14> And the length of the video
[03:20:36 CEST] <jookiyaya> let's say 70 min
[03:21:29 CEST] <kepstin> klaxa: my impression was that wmv9 was made with comparable tech, but it had enough differences that ffmpeg's decoder kinda sucked for quite a while :/
[03:21:55 CEST] <klaxa> ah, i see
[03:22:02 CEST] <jookiyaya> wmv9 look better than xvid but has block issues
[03:22:23 CEST] <kepstin> I think VP6 was from around the same era, too?
[03:22:49 CEST] <kepstin> but other than for flash stuff that wasn't really used anywhere.
[03:23:39 CEST] <jookiyaya> i don't see any reason for people to use x264 these days
[03:23:45 CEST] <jookiyaya> x265 is superior
[03:23:55 CEST] <c_14> x265 is hard to encode and hard to decode
[03:24:02 CEST] <c_14> s/x/h/
[03:24:06 CEST] <jookiyaya> c_14 not really
[03:24:10 CEST] <kepstin> keep in mind that most of the video encoding tech improvements aren't fundamental changes; they're just slower to encode and decode
[03:24:13 CEST] <c_14> And the x265 encoder isn't as optimized as the x264 encoder
[03:24:25 CEST] <jookiyaya> c_14 what does that even mean?
[03:24:58 CEST] <c_14> The x264 has a lot of optimizations, including speed optimizations and psychovisual optimizations
[03:25:02 CEST] <c_14> +encoder
[03:25:09 CEST] <kepstin> each video codec generation adds more block sizes, more search types, better entropy encoders, etc. and therefore the encoders and decoders have to do more work.
[03:25:11 CEST] <klaxa> it means a first gen raspberry pi can't play h265 at realtime, but h264
[03:25:11 CEST] <mrelcee> i get pretty good results with x265. though I have a beefy system to throw at it..
[03:25:48 CEST] <c_14> And the hevc decoder (especially in ffmpeg) is missing a lot of optimizations making it even slower than it should be
[03:26:05 CEST] <kepstin> sure, if you're doing non-realtime stuff and have a beefy system, and have *playback hardware* capable of decoding it realtime, no reason not to use h265
[03:26:46 CEST] <kepstin> but e.g. my old amd k6-2 266 can play SD mpeg2 content, it would just keel over and die if someone did an h265 encode of the same thing :/
[03:27:17 CEST] <klaxa> if you want to reach the general masses with your videos, h264 is your choice in 2016
[03:27:56 CEST] <klaxa> i'd even dare to say it is probably more supported than vp9
[03:27:59 CEST] <klaxa> and vp8
[03:28:00 CEST] <kepstin> if you want to also reach an additional minority, vp8 (or *maybe* vp9) in webm will add a bit more :/
[03:28:46 CEST] <mrelcee> but what about ogg?
[03:29:13 CEST] <klaxa> i thought we were talking about video :P
[03:29:19 CEST] <kepstin> the only real ogg video format was theora, vp6 derived. Never really picked up any usage, and it kinda sucked.
[03:29:21 CEST] <jookiyaya> is x264/x265 better than other h264/h265 encoders?
[03:30:05 CEST] <mrelcee> it was sarcasm. :)
[03:30:07 CEST] <kepstin> jookiyaya: x264 is almost universally considered to be the best software h264 encoder for main/high profile content (although e.g. mainconcept's is or was fairly close, in some comparisons)
[03:30:31 CEST] <furq> klaxa: why would you dare to say that when it's definitely true
[03:30:44 CEST] <klaxa> i wasn't sure
[03:30:51 CEST] <klaxa> google is pushing webm, so i don't know
[03:30:56 CEST] <kepstin> h265 encoder.. I don't think the space is mature enough to make any conclusions? I haven't seen any good comparisons.
[03:31:06 CEST] <klaxa> but i guess there aren't any chips to decode vp8 or vp9 for that matter?
[03:31:10 CEST] <klaxa> or are there hardware decoders?
[03:31:37 CEST] <kepstin> there's some hardware decoders for vp8 or vp9; reportedly some arm phone chips have them.
[03:31:53 CEST] <klaxa> ah cool
[03:31:56 CEST] <furq> yeah some android phones have hardware vp9 decode
[03:32:03 CEST] <furq> obviously iOS will never have it though
[03:32:06 CEST] <klaxa> but almost every toaster has a h264 hardware decoder
[03:32:19 CEST] <furq> they'll probably disable it if they end up using an soc that has it
[03:32:26 CEST] <klaxa> the only laptop i own that doesn't have one is 10 years old
[03:32:42 CEST] <kepstin> mrelcee: most "ogg" video files you'll see will probably have xvid-encoded mpeg4 in them :/
[03:32:51 CEST] <furq> also i think some very new intel chips have vp9 decode
[03:32:57 CEST] <mrelcee> kepstin: yep
[03:33:00 CEST] <furq> or maybe they will soon, i forget now
[03:33:25 CEST] <furq> kepstin: do you mean ogm
[03:33:28 CEST] <furq> everyone's favourite format
[03:33:54 CEST] <kepstin> furq: well, half the people still used the ogg extension for them because nobody had any clue what was going on with ogm
[03:34:07 CEST] <kepstin> and yeah, intel has vp9 decode in skylake it looks like
[03:34:09 CEST] <furq> was it actually ogg-based
[03:34:19 CEST] <furq> i thought it was a hack of avi for ages
[03:34:41 CEST] <klaxa> oooh too bad i forgot gmane went down :( http://snackbox.org/~snacky/mn.html the ogg sucks bad had an email why ogg is a bad format
[03:34:42 CEST] <furq> https://en.wikipedia.org/wiki/Ogg#OGM
[03:34:45 CEST] <furq> other way round then
[03:34:53 CEST] <klaxa> i forgot why though i wrote an ogg parser once, it wasn't too bad?
[03:35:01 CEST] <jookiyaya> what is best lossy audio codec right now?
[03:35:10 CEST] <furq> define "best"
[03:35:25 CEST] <jookiyaya> best quality/size
[03:35:28 CEST] <furq> opus
[03:35:36 CEST] <kepstin> jookiyaya: best quality: probably opus, best compatibility while still near best quality: aac
[03:35:59 CEST] <furq> i assume iOS still doesn't support opus
[03:36:01 CEST] <jookiyaya> nobody seems to use opus
[03:36:09 CEST] <klaxa> youtube does
[03:36:13 CEST] <furq> ^
[03:36:17 CEST] <jookiyaya> furq why would OS need to support it? software player has to support
[03:36:23 CEST] <kepstin> of course iOS doesn't support opus, but some individual apps use it (statically linked decoder or whatever)
[03:36:28 CEST] <furq> well yeah
[03:36:40 CEST] <furq> but most people are stupid
[03:36:53 CEST] <c_14> jookiyaya: because most mobile operating systems have system-wide decoder libraries
[03:37:04 CEST] <kepstin> jookiyaya: opus was actually designed as a *realtime* audio/voice codec, and is used in webrtc
[03:37:08 CEST] <c_14> Does android do opus in ogg these days?
[03:37:18 CEST] <kepstin> c_14: as of 5.0 it does, yeah
[03:37:28 CEST] <kepstin> (lollipop)
[03:37:31 CEST] <furq> if it doesn't work in an end-user's iOS safari then it is the developer's fault and they have brought shame on their family
[03:37:47 CEST] <furq> or desktop safari, which also doesn't support it because hooray for apple
[03:38:02 CEST] <jookiyaya> i heard he-aac is best right now
[03:38:12 CEST] <furq> well you've also heard opus is the best right now as well
[03:38:13 CEST] <kepstin> jookiyaya: but the people working on opus overengineered it a bit, and it turned out their realtime/low-latency codec also matched or beat some high latency codecs like aac.
[03:38:20 CEST] <furq> so you should go and test them and find out who's right
[03:40:21 CEST] <kepstin> but yeah, youtube's use of vp9 is kind of weird. Presumably because it's so slow to encode, they only add vp9 encodes for "popular" videos (probably when it hits some view count threshold)
[03:40:29 CEST] <kepstin> but they always do h264 encodes
[03:40:31 CEST] <furq> ?
[03:40:38 CEST] <klaxa> kepstin: really? when i tried to use opus in ogg on android (in an app) it wouldn't play
[03:40:41 CEST] <klaxa> opus in mkv worked fine
[03:40:59 CEST] <furq> i thought all new videos got webm encodes
[03:41:11 CEST] <jookiyaya> can you put opus on mp4 container?
[03:41:17 CEST] <kepstin> furq: yes, but the basic webm encode is vp8 not vp9
[03:41:41 CEST] <kepstin> klaxa: hmm. maybe I got the version wrong
[03:41:42 CEST] Action: kepstin checks
[03:42:11 CEST] <furq> huh
[03:42:13 CEST] <furq> no you're right
[03:42:21 CEST] <furq> i checked with a video i have with 40 views and there's no webm
[03:42:22 CEST] <klaxa> well i'm still subscribed to this issue: https://code.google.com/p/android/issues/detail?id=158490
[03:42:31 CEST] <furq> but i have a bunch with ~500 which have the full set
[03:42:40 CEST] <c_14> jookiyaya: I think they were adding an extension for that
[03:42:48 CEST] <furq> i guess there are a whole lot of videos with <100 views though
[03:42:52 CEST] <jookiyaya> c_14 so no, right now?
[03:43:00 CEST] <kepstin> klaxa: hmm, might have been android 6.0 where they fixed that
[03:43:10 CEST] <kepstin> klaxa: I know my phone can play them using system apis
[03:43:28 CEST] <c_14> jookiyaya: so right now, no
[03:43:44 CEST] <jookiyaya> is there a codec that .mkv does NOT support?
[03:44:17 CEST] <kepstin> jookiyaya: yes, there are many. But mkv indirectly supports a lot of codecs via it's AVI/RIFF compatibility mode
[03:44:19 CEST] <jookiyaya> don't understand why mkv is not standard over mp4
[03:44:27 CEST] <klaxa> i recently found a pixel format it doesn't support
[03:44:34 CEST] <klaxa> or something... uh...
[03:44:35 CEST] <furq> it doesn't support some subtitle formats
[03:44:46 CEST] <klaxa> i forgot what exactly it was, i was doing weird stuff definitely
[03:45:49 CEST] <furq> kepstin: apparently 150 views is the cutoff
[03:46:07 CEST] <furq> at least according to this set of two videos with 151 and 146 views
[03:46:26 CEST] <kepstin> furq: huh. interesting
[03:46:41 CEST] <furq> google are weird
[03:47:03 CEST] <kepstin> they made a big deal of vp9 as a way to save bandwidth (they use lower bitrates than their h264 streams) so they probably only care enough to spend the power on videos where the bandwidth savings are material
[03:47:16 CEST] <jookiyaya> i wonder what youtube would be like if google never bought out youtube
[03:47:31 CEST] <furq> it would be in jai
[03:47:32 CEST] <furq> l
[03:47:32 CEST] <klaxa> probably bought by amazon then
[03:47:47 CEST] <furq> or yeah bought out by another company that can afford/deflect the millions of lawsuits
[03:48:01 CEST] <jookiyaya> i wonder what youtube would be like if nobody bought out youtube
[03:48:07 CEST] <furq> it would be in jail
[03:48:10 CEST] <kepstin> ok, I've confirmed that android 6.0 (M) does support opus in ogg using the system libraries.
[03:48:14 CEST] <jookiyaya> furq really?
[03:48:17 CEST] <furq> thank you for giving me a chance to correct my typo
[03:49:02 CEST] <jookiyaya> furq what about other tube sites not owned by big companies. they are not in jail
[03:49:03 CEST] Action: kepstin did some work helping the "vanilla music" player android app get the opus replaygain stuff right, and checked it there
[03:49:12 CEST] <furq> yeah but nobody uses those sites
[03:49:29 CEST] <jookiyaya> furq yes they do
[03:50:06 CEST] <furq> the only ones i can think of are vimeo and dailymotion
[03:50:21 CEST] <furq> vimeo is exclusively used by short film directors who think they're too good for youtube
[03:50:23 CEST] <kepstin> lets see... other sites that I know of - nicovideo.jp is h264-only (although they also allow swf animations in some cases), i'm pretty sure vimeo is h264 - probably aac audio?
[03:50:25 CEST] <jookiyaya> how can google avoid jail ?
[03:50:42 CEST] <furq> and dailymotion are french and also are owned by vivendi which i assume makes them more difficult to sue
[03:51:00 CEST] <kepstin> jookiyaya: basically? Google makes money with adds, and sends that money to the people who would otherwise put them in jail :)
[03:51:04 CEST] <furq> plus they only still exist as a repository for videos that have been taken off youtube
[03:51:05 CEST] <kepstin> with ads*
[03:51:43 CEST] <jookiyaya> kepstin original owners of youtube could do the same
[03:51:45 CEST] <furq> don't forget viacom were suing youtube for $1B when google bought them
[03:52:04 CEST] <furq> and that case dragged on for seven years
[03:52:10 CEST] <kepstin> jookiyaya: google makes *way* more money from ads than an independent youtube had any chance of doing :)
[03:52:11 CEST] <furq> you need google money to even afford to show up for something like that
[03:52:34 CEST] <furq> and that was just the biggest of the ongoing lawsuits
[03:53:23 CEST] <jookiyaya> what does viacom do?
[03:53:39 CEST] <furq> they made the hit sitcom "roseanne"
[03:53:52 CEST] <kepstin> iirc, viacom mostly sells ads
[03:54:13 CEST] <kepstin> they were annoyed that google was making money from ads instead of them ;)
[03:54:45 CEST] <jookiyaya> how can so many copyrighted video exist in youtube
[03:55:08 CEST] <jookiyaya> if youtube removed all copyrighted videos, nobody would use youtube
[03:55:26 CEST] <furq> most of them have been uploaded by/with permission from the copyright holder now
[03:55:49 CEST] <furq> "with permission from" meaning the copyright holder takes the ad revenue
[03:56:22 CEST] <jookiyaya> furq i see
[03:56:32 CEST] <kepstin> like so: https://www.kepstin.ca/dump/Screenshot%20from%202016-08-23%2021-55-18.png
[03:56:50 CEST] <furq> i have a few that have been claimed but not monetised
[03:57:52 CEST] <furq> oh
[03:58:02 CEST] <kepstin> what's really annoying is when they put region limits on :/
[03:58:03 CEST] <furq> apparently i have a few that have been monetised and blocked
[03:58:17 CEST] Action: kepstin managed to construct a few videos only viewable in 1 or 2 countries.
[04:00:11 CEST] <furq> http://i.imgur.com/cHYViZM.png
[04:00:51 CEST] <furq> an album which was only ever sold in japan is blocked in the usa, mexico, australia and new zealand
[04:00:58 CEST] <furq> how've they worked that out
[04:00:59 CEST] <kepstin> right, I have one video that's "blocked in 248 countries", you can only see it in south korea.
[04:01:46 CEST] <kepstin> the one that's blocked in 153 countries is annoying, because they list the countries it's blocked in rather than the countries where it's still visible.
[04:02:46 CEST] <klaxa> i thought there were only about 170 countries
[04:03:04 CEST] <kepstin> https://www.kepstin.ca/dump/Screenshot%20from%202016-08-23%2022-02-07.png :/
[04:03:15 CEST] <jookiyaya> if google pays copyright holder and everybody is happy. why do videos still get removed from youtube
[04:03:35 CEST] <klaxa> >north korea
[04:03:38 CEST] <klaxa> all the 2 views!
[04:03:54 CEST] <furq> wow you got blocked in the vatican
[04:03:58 CEST] <jookiyaya> klaxa your video has views from northkorea?
[04:03:59 CEST] <kepstin> jookiyaya: because some companies or individuals decide they would rather take down the video than take google's money (admittedly, money from youtube ads tends to be kinda small)
[04:04:37 CEST] <klaxa> jookiyaya: i was commenting on the fact that the video is blocked in north korea and was implying it would get 2 views from said country
[04:04:43 CEST] <jookiyaya> kepstin then i heard youtubers making millions, how is that possible
[04:04:57 CEST] <klaxa> huh? those are probably only a handful
[04:05:16 CEST] <kepstin> jookiyaya: usually they get sponsered from companies outside youtube, and produce ads or sponsered content that they post on youtube
[04:06:13 CEST] <furq> based on my observations of "popular youtubers", they have all sold their soul to satan
[04:06:26 CEST] <jookiyaya> furq what do you mean?
[04:06:35 CEST] <kepstin> same thing, isn't it? :)
[04:07:00 CEST] <furq> in exchange for those video thumbnails where they pull an awful face and next to them it says "WTF OMG LOL??! GRAND THEFT AUTO DENTIST"
[04:07:10 CEST] <furq> and also in exchange for the worst human voice possible
[04:07:34 CEST] <mrelcee> my kids watch a lot of youtube.
[04:08:06 CEST] <mrelcee> gaming stuff.. they've always got somethign streaming, sucking down my precious bandwidth :)
[04:10:22 CEST] <furq> i'll be honest, i'm still annoyed at youtube since they did this
[04:10:27 CEST] <furq> http://i.imgur.com/4W49Z8E.png
[04:10:38 CEST] <furq> since they committed this crime against my humanity
[04:11:15 CEST] <c_14> It's recommended for you, it must be good. This algorithm says so.
[04:11:41 CEST] <furq> hey this guy exclusively watches videos of japanese people playing fighting games
[04:11:44 CEST] <furq> you know what he'd like?
[04:11:44 CEST] <furq> http://i.imgur.com/38rvylU.png
[04:12:42 CEST] <furq> normally a list like this would build to a climax, but "the amazing atheist" is obviously the worst recommendation possible
[04:12:52 CEST] <furq> although at least it wasn't that video of him building to a climax
[04:16:38 CEST] <Spring> drama sells
[04:17:05 CEST] <Spring> youtube is like the lowest form of entertainment though
[04:17:27 CEST] <jookiyaya> can anybody here tell the diffrence between 10 bit and 8bit encoding?
[04:17:44 CEST] <c_14> sure, just use ffprobe
[04:17:55 CEST] <jookiyaya> c_14 you can?
[04:18:38 CEST] <c_14> That was a bad joke based on the fact that you worded your question imprecisely.
[04:18:49 CEST] <c_14> You can use ffprobe to determine if a video is encoded in 8 or 10 bit
[04:19:04 CEST] <jookiyaya> i see, i meant by looking at the picture
[04:19:30 CEST] <kepstin> for display on most screens, it'll be converted back to 8bit anyways
[04:19:36 CEST] <kepstin> my impression was that using the 10bit x264 encoder can lead to mild improvements in efficiency, particularly when using lots of reference frames, since there's less quantization loss
[04:19:46 CEST] <klaxa> but you can probably tell from banding artifacts
[04:19:48 CEST] <kepstin> it may also help with multiple generations of lossy encodes iirc
[04:19:48 CEST] <jookiyaya> kepstin why?
[04:19:49 CEST] <c_14> Depends, I only have an 8bit graphics pipeline. I can notice the difference between low bitrate 8bit vs 10bit encodes in that the 8bit one bands and the 10bit one doesn't
[04:19:56 CEST] <furq> because most displays are 8-bit
[04:20:00 CEST] <furq> or 6-bit
[04:20:33 CEST] <furq> 10-bit displays are really expensive
[04:20:39 CEST] <c_14> But unless you actually have a full 10-bit graphics pipeline you probably won't notice the difference at sufficient bitrates
[04:20:44 CEST] <Spring> don't 10-bit panels require 10-bit GPU support?
[04:20:59 CEST] <klaxa> i would be surprised if not
[04:21:16 CEST] <kepstin> well, i assume most 10bit panels support 8bit input just fine
[04:21:17 CEST] <kepstin> :)
[04:21:22 CEST] <c_14> Your display needs to support it, your gpu needs to output it, your display server needs to support it
[04:21:31 CEST] <c_14> Otherwise you'll dither down to 8bit at some point
[04:21:58 CEST] <furq> that not why people encode to 10-bit though
[04:22:03 CEST] <furq> 's
[04:22:08 CEST] <furq> or not why most people encode to 10-bit
[04:22:17 CEST] <c_14> sure
[04:22:27 CEST] <furq> i know you know that
[04:22:48 CEST] <Spring> they do it to reduce 8-bit artifacts?
[04:22:56 CEST] <furq> they do it because it's more efficient
[04:23:11 CEST] <klaxa> they do it because Daiz said so
[04:23:45 CEST] <klaxa> i think those three are all true
[04:23:54 CEST] <jookiyaya> furq you mean you need special videocard/monitor to view 10 bit video?
[04:24:05 CEST] <furq> 03:21:22 ( c_14) Your display needs to support it, your gpu needs to output it, your display server needs to support it
[04:24:08 CEST] <furq> 03:21:31 ( c_14) Otherwise you'll dither down to 8bit at some point
[04:24:25 CEST] <furq> also should i know what a daiz is
[04:24:39 CEST] <kepstin> furq: well known encoder in the anime fansub scene
[04:24:44 CEST] <furq> oh. an animes man
[04:24:45 CEST] <kepstin> (a person)
[04:25:27 CEST] <jookiyaya> what is "display server" ?
[04:26:08 CEST] <kepstin> jookiyaya: the piece of software that takes all the images of windows and combines them into a single image to show on the screen.
[04:26:30 CEST] <jookiyaya> kepstin so you mean software video player?
[04:27:05 CEST] <kepstin> no, software video players just make a window, it's up to the display server to take that and put it on the screen.
[04:27:07 CEST] <furq> you'd think with how much we've been talking about google lately that it might have dropped a hint
[04:27:56 CEST] <jookiyaya> furq but what if i have 10bit video file on local harddrive
[04:28:12 CEST] <furq> then your family will have good luck for eight years
[04:28:27 CEST] <kepstin> no, 10 years. it's a 10bit video after all.
[04:28:41 CEST] <klaxa> i'm gonna be super lucky forever then
[04:29:30 CEST] <klaxa> jookiyaya: your video player can probably play it, it will dither the 10-bit information down to 8-bit so your display can show it
[04:29:45 CEST] <furq> i have an ffmpeg question, if you can imagine such a thing
[04:29:55 CEST] <furq> is there a non-awful way to rotate the output of drawtext
[04:30:03 CEST] <furq> the best solution i could figure out was transpose,drawtext,transpose
[04:31:19 CEST] <kepstin> furq: that would work fine for 90° rotations, yeah. I imagine if the filter had builtin rotation, that's basically what it would be doing (maybe it could rotate only the text rather than entire image tho...)
[04:31:35 CEST] <c_14> There's also the rotate filter if you want to rotate in radians
[04:31:38 CEST] <furq> i don't really know how wasteful that is but it seems awfully wasteful
[04:31:44 CEST] <c_14> But I don't think the drawtext filter has internal rotation anywhere
[04:31:50 CEST] <furq> it's a 90 degree rotation so that works fine
[04:31:55 CEST] <furq> it just seems wrong
[04:32:22 CEST] <furq> i thought maybe i could draw on nullsrc/color but the text doesn't show up
[04:32:26 CEST] <kepstin> furq: really, you'd want to generate a static image of the rotated text and overlay it (which is presumably what a drawtext with builtin rotation would do internally)
[04:32:46 CEST] <furq> or it shows up at the same alpha as the source, which is obviously not what i want
[04:32:58 CEST] <kepstin> i wouldn't be surprised if drawtext has bad alpha support, yeah :/
[04:33:24 CEST] <klaxa> i guess using ass is not an option?
[04:33:36 CEST] <furq> it's a single text overlay for the entire video
[04:33:48 CEST] <klaxa> well then you can certainly use ass?
[04:33:59 CEST] <furq> probably, but that seems more involved than just transposing twice
[04:34:15 CEST] <klaxa> really? it's just a single event
[04:34:20 CEST] <c_14> It should be faster (assuming the drawtext filter and the subtitles filter/ass filter are equally complex)
[04:34:26 CEST] <c_14> Since you don't have to transpose anything
[04:34:48 CEST] <kepstin> the ass filter should in theory be caching the rendered text rather than re-rendering every frame, so yeah.
[04:34:49 CEST] <c_14> You'll have to write something to generate the ass file though (assuming you want to automate this)
[04:35:01 CEST] <furq> yeah the .ass generation is the involved bit
[04:35:08 CEST] <furq> i'd expect it would be faster
[04:35:26 CEST] <c_14> Well, ass isn't that complicated you can just create the basic outline and swap out the text-line
[04:35:54 CEST] <klaxa> that's what i do
[04:36:36 CEST] <furq> well i already rendered this now but i'll try it if i need it in future
[04:36:45 CEST] <furq> i just figured i might be missing something obvious
[04:47:48 CEST] <Spring> can any values be used for the audio bitrate, eg: 133k, or 287k?
[04:48:04 CEST] <kepstin> Spring: depends on the codec
[04:48:17 CEST] <Spring> what about opus and aac, any idea?
[04:48:20 CEST] <kepstin> Spring: aac or opus, yes
[04:48:29 CEST] <Spring> excellent, thanks
[04:48:42 CEST] <kepstin> Spring: mp3: sort of. lame's vbr mode should allow it, and probably get you something close
[04:49:13 CEST] <furq> will it actually be rejected by any codec
[04:49:26 CEST] <furq> i know ac3 will just ignore it and use the closest acceptable value
[04:53:58 CEST] <kepstin> would have to check lame's cbr mode. it might? probably not tho, i bet it does the same as ac3.
[07:50:08 CEST] <Spring> -report is so damn useful
[07:52:06 CEST] <Spring> is there any way to set the -report path?
[07:52:21 CEST] <Spring> I see file but the docs state that's the name
[07:54:18 CEST] <c_14> There's an environment variable
[07:54:47 CEST] <furq> FFREPORT=/foo/bar works
[07:54:47 CEST] <c_14> Setting the environment variable FFREPORT to any value has the same effect. If the value is a ':'-separated key=value sequence, these options will affect the report; option values must be escaped if they contain special characters or the options delimiter ':' (see the ``Quoting and escaping'' section in the ffmpeg-utils manual).
[07:54:48 CEST] <furq> er
[07:54:52 CEST] <furq> FFREPORT=file=/foo/bar works
[07:56:59 CEST] <Spring> furq, thx for the tip
[08:42:28 CEST] <Spring> is there a way of logging both passes in one log file?
[08:48:10 CEST] <Spring> adding the same name for both passes doesn't seem to work, and adding -report to both passes results with a timestamped name results in two files (expectedly)
[08:52:49 CEST] <relaxed> Spring: on linux?
[08:53:05 CEST] <Spring> relaxed, windows
[08:53:18 CEST] <relaxed> no idea then
[08:53:28 CEST] <Spring> what can Linux do?
[08:53:46 CEST] <Spring> concatenate them?
[08:54:58 CEST] <relaxed> yes, ffmpeg <pass 1> output 2>ffmpeg.log; ffmpeg <pass 2> output 2>>ffmpeg.log
[08:55:25 CEST] <Spring> hmm, I could try concatenating them. Rubber duck problem solving :p
[08:56:30 CEST] <furq> i'm pretty sure > and >> work on windows
[08:56:42 CEST] <furq> you'd need -v debug to get the same output as -report though
[09:05:52 CEST] <Spring> furq, what do you mean with using -v debug?
[09:06:21 CEST] <furq> oh nvm it's -v verbose
[09:06:33 CEST] <furq> -report automatically sets -v verbose
[09:07:31 CEST] <Spring> yeah, the nice thing is it can hide the visual output in the prompt with -loglevel while -report can have a different loglevel of its own
[09:07:50 CEST] <furq> well you won't get any visual output if you're redirecting stderr
[11:06:54 CEST] <MINIMAN10000> I've no idea what I'm doing wrong. Trying to get ffplay to play a stream. I'm using windows. Commands here http://pastebin.com/vz0XkMvx
[11:22:00 CEST] <ozette> How can I verify if ffmpeg will build with zlib enabled and the png codecs, in particular the png encoder. What should my config.log https://paste.fedoraproject.org/413189/47203037/raw/ and config.h https://paste.fedoraproject.org/413190/14720304/raw/ say?
[11:26:03 CEST] <qope> hi there
[11:26:25 CEST] <qope> having a problem transcoding a stream thru ffmpeg+nginx-rtmp
[11:26:31 CEST] <qope> lil' help?
[11:27:40 CEST] <qope> current conf http://pastebin.com/3rENDnNu
[11:28:48 CEST] <MINIMAN10000> I got nothing
[11:28:51 CEST] <MINIMAN10000> its looks alright to me
[11:30:21 CEST] <MINIMAN10000> hmm actually
[11:31:13 CEST] <qope> problem is - i'm not getting my stream transcoded
[11:31:24 CEST] <qope> 0 hls streams (.m3u8)
[11:31:41 CEST] <qope> and yet 1 source stream (rtmp)
[11:31:48 CEST] <MINIMAN10000> found my problem
[11:32:14 CEST] <MINIMAN10000> was streaming to a ip that wasn't mine
[11:32:15 CEST] <qope> :/
[11:32:34 CEST] <qope> what about my problem :(?
[11:32:41 CEST] <MINIMAN10000> wow it threw a ton of errors before starting up the video
[11:32:51 CEST] <MINIMAN10000> and the delay is a lot higher than I want
[11:33:30 CEST] <MINIMAN10000> I've never had to do transcoding so I couldn't tell ya
[11:33:32 CEST] <qope> awww
[11:34:50 CEST] <qope> anyone knows how to help?
[11:36:00 CEST] <furq> does your nginx error log contain anything helpful
[11:37:25 CEST] <qope> well, ffmpeg didn't log anything
[11:37:39 CEST] <qope> yet nginx log contains 404s
[11:51:43 CEST] <MINIMAN10000> ... "-framerate 3" didn't change the framerate
[11:51:58 CEST] <MINIMAN10000> for some reason it seems to just stick to 15
[11:53:37 CEST] <MINIMAN10000> apparently it has to be a starting argument
[11:53:44 CEST] <MINIMAN10000> jeeze.
[11:54:54 CEST] <MINIMAN10000> well increasing it only broke it
[11:55:32 CEST] <MINIMAN10000> "Could not set video options
[11:55:32 CEST] <MINIMAN10000> video=screen-capture-recorder: I/O error" Neat.
[11:56:58 CEST] <DelphiWorld> hi guys
[11:57:10 CEST] <DelphiWorld> i previously installed that crapy intel media sdk
[11:57:26 CEST] <DelphiWorld> my vaapi is trying to use intel own driver from the sdk..., any way to remove it?
[11:57:40 CEST] <DelphiWorld> ffmpeg -vaapi_device /dev/dri/renderD128 -i m1.mp4 -acodec libfdk_aac -profile:a aac_he_v2 -b:a 64k -ar 48k -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -vb 800k -bf 0 -f mp4 m2.mp4
[11:57:44 CEST] <MINIMAN10000> "FrameRate the valid range is 1 to 30." wat
[11:58:54 CEST] <MINIMAN10000> Man
[11:59:17 CEST] <MINIMAN10000> after all this struggling it's still garbage compared to tachyon as far as latency go.
[11:59:18 CEST] <MINIMAN10000> goes
[11:59:33 CEST] <MINIMAN10000> Like I don't know how they built on top of this and made it work to get 200 ms latency lol
[11:59:57 CEST] <MINIMAN10000> because I can't even get the latency locally what they get remotely. not even close
[12:00:33 CEST] <qope> so...noone
[12:00:57 CEST] <MINIMAN10000> I thought man if they can get 200 ms with me streaming to some remote data center and them streaming from that remote data center back imagine how low of latency I can get if I do it locally with ffmpeg.
[12:01:12 CEST] <MINIMAN10000> Well apparently 1/3 times better.
[12:11:48 CEST] <DelphiWorld> dashcloud_: are you a dash streamer? :P
[12:24:07 CEST] <Spring> what does MP4 use as its 'title' metadata? It appears to be different than WebM
[12:57:39 CEST] <bencoh> 47
[12:57:41 CEST] <bencoh> woops
[13:00:01 CEST] <qope> ...guys?
[13:04:26 CEST] <Mavrik> qope, you didn't really provide any useful information for people to help you
[13:04:44 CEST] <Mavrik> 300 lines of configuration isn't something people read for fun :P
[13:04:59 CEST] <Mavrik> What debugging steps did you take until now? What do your logs say? What's your ffmpeg output?
[13:05:04 CEST] <qope> i did provide my config which contains ffmpeg commands used to transcode a stream
[13:06:32 CEST] <qope> ffmpeg debugging did nothing, quite literally
[13:07:28 CEST] <qope> and, as i told above, nginx's log only produces "(2: No such file or directory)" type errors
[13:07:58 CEST] <qope> (obviously because there are no resulting .m3u8 files)
[14:51:05 CEST] <DelphiWorld> hi guys
[14:51:24 CEST] <DelphiWorld> [AVHWDeviceContext @ 0x20c1540] Failed to initialise VAAPI connection: 1 (operation failed).
[14:51:56 CEST] <DelphiWorld> do i need any driver?
[14:52:07 CEST] <DelphiWorld> i installed i965-vaapi-driver but no luck
[14:53:31 CEST] <viric> you need to choose the vaapi device It hink
[14:53:32 CEST] <viric> I think
[14:53:43 CEST] <DelphiWorld> i did chouse
[14:54:06 CEST] <DelphiWorld> viric: ffmpeg -vaapi_device /dev/dri/renderD128 -i udp://@239.100.0.2:1234 -acodec libfdk_aac -profile:a aac_he_v2 -b:a 64k -ar 48k -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -vb 1200k -bf 0 -f rtsp -rtsp_transport tcp rtsp://197.140.2.6/live/almajd03
[14:54:34 CEST] <viric> hm the device is not chosen that way I think. It has to do with the X connection, isn't it?
[14:55:04 CEST] <DelphiWorld> no, you can use it without X11
[14:55:26 CEST] <viric> ah is that without X11?
[14:56:06 CEST] <DelphiWorld> you dont need any X connection with vaapi
[14:56:38 CEST] <DelphiWorld> i think i dont have the right driver
[14:56:47 CEST] <DelphiWorld> i need the ihd driver
[14:57:14 CEST] <DelphiWorld> i installed the i965 but still complaining
[14:57:52 CEST] <viric> vainfo works for you?
[14:58:42 CEST] <DelphiWorld> viric: yep work
[14:59:46 CEST] <DelphiWorld> ffmpeg -vaapi_device /dev/dri/renderD128 -i resonance.mp4 -acodec libfdk_aac -profile:a aac_he_v2 -b:a 64k -ar 48k -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -vb 1200k -bf 0 -f mp4 out.mp4
[14:59:53 CEST] <DelphiWorld> viric, hold on bro, i'm rebooting
[15:03:00 CEST] Action: DelphiWorld is back, viric
[15:03:32 CEST] <BtbN> There is only exactly one driver for intel vaapi.
[15:03:48 CEST] <DelphiWorld> BtbN: yes, am i using the right driver,
[15:04:20 CEST] <DelphiWorld> maybe code conflict in the current FFmpeg snapshot
[15:04:38 CEST] <BtbN> works for me
[15:04:51 CEST] <DelphiWorld> BtbN: what could be my issue so
[15:04:59 CEST] <DelphiWorld> i'm sure mine is vaapi supported
[15:05:11 CEST] <DelphiWorld> I7 with intel QuickSync
[15:05:19 CEST] <BtbN> No idea. Maybe you just selected the wrong device?
[15:05:26 CEST] <BtbN> Do you have more than one card in dev/dri?
[15:05:33 CEST] <DelphiWorld> BtbN: how should i select the correct device so
[15:05:43 CEST] <DelphiWorld> no, i think only one. let me check
[15:05:46 CEST] <BtbN> try them all until it works, check vainfo.
[15:05:56 CEST] <BtbN> if vainfo works, ffmpeg has to work as well.
[15:07:38 CEST] <DelphiWorld> BtbN: that's it: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[15:07:40 CEST] <DelphiWorld> driver
[15:07:46 CEST] <DelphiWorld> but i dont see the device montioned?
[15:08:11 CEST] <BtbN> It should output a lot more, listing all supported codecs and profiles.
[15:08:30 CEST] <DelphiWorld> BtbN: yes it's outputes
[15:08:36 CEST] <DelphiWorld> outputed/
[15:08:59 CEST] <DelphiWorld> BtbN: that's in my /dev/dri: card0 controlD64 renderD128
[15:09:12 CEST] <BtbN> vaapi is fine then
[15:09:50 CEST] <DelphiWorld> so why my latest ffmpeg snapshot dont work... mad...
[15:10:14 CEST] <BtbN> Did it ever work before?
[15:10:45 CEST] <DelphiWorld> for sure
[15:11:02 CEST] <DelphiWorld> it was ubuntu 16.04
[15:11:06 CEST] <DelphiWorld> this is ubuntu 14.04
[15:11:16 CEST] <BtbN> Your kernel might just be too old then.
[15:11:20 CEST] <BtbN> Or your vaapi/driver.
[15:11:37 CEST] <DelphiWorld> should i upgrade kernel?
[15:11:55 CEST] <BtbN> Well, it's Ubuntu, from 2014, ...
[15:12:09 CEST] <DelphiWorld> ... :P
[15:16:12 CEST] <sfan5> DelphiWorld: the ffmpeg command you posted works for me
[15:16:19 CEST] <sfan5> using Linux 4.6.4-1-ARCH on some mobile i5 cpu
[15:16:32 CEST] <sfan5> have you tried upgrading ffmpeg?
[15:23:25 CEST] <jkqxz> Can you paste the whole output of that somewhere (including the libva info lines)? The message indicates that it has a device but the libva initialisation failed somehow.
[15:26:15 CEST] <jkqxz> If vainfo works, that's rather weird.
[15:29:05 CEST] <DelphiWorld> strange
[15:29:14 CEST] <DelphiWorld> jkqxz: what you want me to post?
[15:31:29 CEST] <BtbN> jkqxz, it's Ubuntu 14.04. It has a very ancient libva and driver for it.
[15:31:37 CEST] <BtbN> just post the full vainfo output
[15:36:42 CEST] <jkqxz> And the ffmpeg output from trying to use it.
[15:36:52 CEST] <jkqxz> Ubuntu 14.04 does work, or at least did at some point in the past.
[15:38:05 CEST] <pgorley> worked when i was using it a few months prior
[15:38:13 CEST] <DelphiWorld> will pb... hold on guy's
[15:46:59 CEST] <t4nk289> Hello
[15:47:48 CEST] <qope> :( anyone?
[15:48:20 CEST] <durandal_1707> qope: what is it about?
[15:48:37 CEST] <t4nk289> I have asked a question on user mailing list and not getting answer for that
[15:48:50 CEST] <t4nk289> how can I get qucik resonse from experts?
[15:48:56 CEST] <t4nk289> If anyone can help... Thanks
[15:49:02 CEST] <durandal_1707> t4nk289: ask
[15:49:27 CEST] <VamoMenem> hi guys
[15:49:39 CEST] <qope> durandal_1707 no target .m3u8s for a stream (rtmp->m3u8(low,med,hi) transcoding)
[15:50:06 CEST] <qope> they are literally not being created for some reason
[15:50:27 CEST] <VamoMenem> i was fighting whit h264_nvenc and ssegmenter, i use -g 50 to cut chunks of 2 seconds, but it not compatible whit android devices.
[15:51:10 CEST] <VamoMenem> before to go whit nvenc, i used -force_key_frames expr:gte(t,n_forced*GOP_LEN_IN_SECONDS) but this way is not working whit nvenc/cuda impelmentation
[15:51:13 CEST] <t4nk252> http://libav-users.943685.n4.nabble.com/Libav-user-Not-calling-custom-get-buffer2-function-td4662465.html
[15:51:23 CEST] <t4nk252> I am stuck on this question
[15:51:38 CEST] <t4nk252> please anyone help
[15:52:03 CEST] <t4nk252> reattaching the link
[15:52:05 CEST] <t4nk252> http://libav-users.943685.n4.nabble.com/Libav-user-Not-calling-custom-get-buffer2-function-td4662465.html
[15:53:38 CEST] <ozette> Can anyone tell me how exactly I can have the CONFIG_PNG_ENCODER define in config.h set to 1?, is it possible to change this manually?
[15:53:53 CEST] <durandal_1707> t4nk252: does custom decoder calls get_buffer?
[15:54:22 CEST] <durandal_1707> ozette: you could, and hope it works
[15:54:27 CEST] <c_14> ozette: --enable-encoder=png ?
[15:54:59 CEST] <c_14> You'll need zlib so make sure you have that (that could be the reason it's being disabled)
[15:55:24 CEST] <ozette> c_14: i have --enable-encoder=png, --enable-decoder=png --enable-parser=png --enable-zlib in my config options
[15:55:52 CEST] <c_14> upload the contents of config.log to a pastebin service (or open it yourself and search for png)
[15:56:02 CEST] <durandal_1707> are that your only options?
[15:56:08 CEST] <c_14> and/or zlib
[15:56:19 CEST] <ozette> durandal_1707: what if CONFIG_ZLIB is defined as 0 as well?
[15:56:36 CEST] <durandal_1707> set it to 1
[15:56:36 CEST] <ozette> i posted them a while ago
[15:56:48 CEST] <c_14> ozette: Then your system probably doesn't have zlib headers
[15:57:10 CEST] <ozette> i built a zlib and placed them in the sysroot of the cross-toolchain i'm using
[15:57:25 CEST] <durandal_1707> if compiling doesnot work than its bigger problem
[15:57:48 CEST] <durandal_1707> and what is prefix?
[15:57:59 CEST] <ozette> um
[15:58:13 CEST] <DHE> directory to be used as the base of installation if you use `make install`
[15:58:16 CEST] <ozette> my config.log https://paste.fedoraproject.org/413189/47203037/raw/ and config.h https://paste.fedoraproject.org/413190/14720304/raw/
[15:58:53 CEST] <ozette> there's no prefix
[15:59:13 CEST] <ozette> just a --cross-prefix
[15:59:25 CEST] <c_14> ozette: /usr/local/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.9.3/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: cannot find -lz
[16:00:16 CEST] <bencoh> :)
[16:00:24 CEST] <c_14> is libz.so/a in your ldpath?
[16:01:45 CEST] <wallbroken> [16:36] <klaxa> 32 bit will probably be unsupported earlier than 64 bit (just a guess)
[16:01:53 CEST] <wallbroken> in which sense?
[16:02:41 CEST] <ozette> let me see..
[16:04:10 CEST] <ozette> does it matter where in the sysroot the lib is? i have a sysroot/lib/ and a sysroot/usr/lib
[16:05:03 CEST] <t4nk252> Can anyone look into this lin k http://libav-users.943685.n4.nabble.com/Libav-user-Not-calling-custom-get-buffer2-function-td4662465.html
[16:06:35 CEST] <durandal_1707> t4nk252: I already asked you something
[16:08:17 CEST] <t4nk252> @durandal_1707 : No it doesn't call get_buffer.
[16:08:36 CEST] <t4nk252> @durandal_1707 I don't know how to implement that
[16:08:43 CEST] <qope> @durandal_1707
[16:10:05 CEST] <c_14> ozette: depends, try adding --extra-ldflags="-Isysroot/lib"
[16:10:59 CEST] <bencoh> you meant -L${sysroot}/lib I guess
[16:11:12 CEST] <durandal_1707> t4nk252: see native, in repo, decoders
[16:11:37 CEST] <c_14> bencoh: right, got confused with the one for include dirs
[16:11:39 CEST] <t4nk252> @durandal_1707 : Any suggestions ?
[16:11:50 CEST] <ozette> well
[16:12:17 CEST] <durandal_1707> t4nk252: I told you, see above
[16:13:16 CEST] <t4nk252> durandal_1707: No am asking, native decoders i understand, can you suggest to refer any specific decoder !
[16:13:23 CEST] <ozette> i moved the libz.so to sysroot/usr/lib and now it finds -lz, but the log says: 'File format not recognized': https://paste.fedoraproject.org/413349/20479741/raw/
[16:14:05 CEST] <durandal_1707> t4nk252: bmp decoder
[16:14:07 CEST] <bencoh> is it an arm object/lib?
[16:17:46 CEST] <t4nk289> Ok, I am checking it and let you know
[16:23:04 CEST] <t4nk252> durandal_1707: Ok let me see, thanks BTW.
[16:27:57 CEST] <ozette> this is for arm yes
[16:28:32 CEST] <ozette> but the png and zlib defines in the config.h are still 0
[16:45:10 CEST] <bencoh> ozette: I'd run "file" on it and another (working) lib just to check
[16:52:18 CEST] <ozette> bencoh: interesting, the libz says it's x86-64, 64-bit
[16:52:33 CEST] <ozette> it should be 32-bit arm
[16:53:05 CEST] <bencoh> ;)
[16:53:16 CEST] <ozette> thanks
[16:53:22 CEST] <ozette> but that makes me wonder..
[16:55:21 CEST] <ozette> i built zlib with a line like this: 'CC=toolchain-gcc ./configure prefix=/some/path/build; make'
[16:55:34 CEST] <bencoh> . . .
[16:56:09 CEST] <bencoh> autotools has a standard way of setting a cross toolchain as well
[16:59:16 CEST] <ozette> i never know what config options are available to me
[17:13:19 CEST] <ozette> cool, i think i have the 'right' libz.so now
[17:30:51 CEST] <witChdoCtOr> anyone know how to set the frame rate for an encoder via the AVCodecContext
[17:31:09 CEST] <witChdoCtOr> or av_dict_set
[17:32:48 CEST] <BtbN> you don't.
[17:32:54 CEST] <BtbN> It gets the timestamps on the frames
[17:33:55 CEST] <witChdoCtOr> ok I set pts to the frame count and that got rid of the nag about fixing code
[17:34:16 CEST] <witChdoCtOr> but my fps and bit rates are way out of wack
[17:34:28 CEST] <witChdoCtOr> uv420p, 1024x768 [SAR 1:1 DAR 4:3], 53989966 kb/s, 1016949.15 fps, 1000k tbr, 1000k tbn, 58 tbc (default)
[17:35:22 CEST] <witChdoCtOr> none of the sample code is setting time_stamp
[17:35:27 CEST] <witChdoCtOr> just pts
[17:35:50 CEST] <witChdoCtOr> transcoding.c: frame->pts = av_frame_get_best_effort_timestamp(frame);
[17:36:15 CEST] <BtbN> no idea what you're talking about, but pts is the only timestamp there is for frames.
[17:37:07 CEST] <bencoh> best_effort_timestamp? didn't know we had that now
[17:37:42 CEST] <witChdoCtOr> think it only works with demuxing it returns the pts from the input frame
[17:38:10 CEST] <witChdoCtOr> should I be working on the frame or the encoder?
[17:39:34 CEST] <witChdoCtOr> I added dst_frame->pts = frame_count; before the avcodec_send_frame but it did not help the crazy stats
[17:41:15 CEST] <bencoh> err, you need to set time_base too
[17:41:27 CEST] <wallbroken> klaxa, are you alive?
[17:41:51 CEST] <witChdoCtOr> av_codec_ctx->time_base = (AVRational) { 1, 1000000 }; (void)fps; // }; //* 2;
[17:42:04 CEST] <nonex86> quote
[17:42:05 CEST] <nonex86> * This is the fundamental unit of time (in seconds) in terms
[17:42:06 CEST] <nonex86> * of which frame timestamps are represented. For fixed-fps content,
[17:42:06 CEST] <nonex86> * timebase should be 1/framerate and timestamp increments should be
[17:42:06 CEST] <nonex86> * identically 1.
[17:42:18 CEST] <nonex86> * - encoding: MUST be set by user.
[17:46:44 CEST] <nonex86> also which codec did you use for encoding and which container you mux into?
[17:46:46 CEST] <witChdoCtOr> that is where I started, av_codec_ctx->time_base = (AVRational) { 1, fps }; I got the hard code from ffmpeg -loglevel debug
[17:47:04 CEST] <nonex86> afair mkv timebase is 1/1000
[17:47:05 CEST] <witChdoCtOr> h264_nvenc and mp4
[17:47:11 CEST] <nonex86> for example
[17:47:27 CEST] <witChdoCtOr> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1024x768 [SAR 1:1 DAR 4:3], 770410 kb/s, 15390.78 fps, 15360 tbr, 15360 tbn, 120 tbc (default)
[17:47:36 CEST] <witChdoCtOr> I know those are wrong
[17:48:29 CEST] <nonex86> i easily merge and reencoded several streams to h264 and write it to mkv
[17:48:39 CEST] <witChdoCtOr> Do I need to do a time base for the AVFormatContext
[17:48:41 CEST] <nonex86> for encoder ctx i set 1/30
[17:48:52 CEST] <nonex86> but my framerate were variable
[17:49:00 CEST] <nonex86> and everything was ok
[17:49:11 CEST] <nonex86> muxing to mkv container
[17:49:22 CEST] <nonex86> pts for packets was in 1/1000 timebase
[17:49:52 CEST] <witChdoCtOr> seems like I should be changing the packet ts before I write it to the file since it appears the file is messed up
[17:50:14 CEST] <nonex86> you should provide pts when muxing as far as i remember
[17:50:54 CEST] <viric> I'll try some tests on hyperthreading and x264 encoding...
[17:51:59 CEST] <witChdoCtOr> dst_frame->pts = frame_count; avcodec_send_frame( av_codec_ctx, dst_frame );
[17:53:21 CEST] <witChdoCtOr> i can actually render my output with my decoder but VLC shows 1 frame and stops
[17:54:02 CEST] <witChdoCtOr> btw: Thank you for the help
[17:56:18 CEST] <nonex86> if vlc shows just one frame and then stops
[17:56:33 CEST] <nonex86> this definitly the problem with timestamps :)
[17:57:34 CEST] <viric> furq: I tested HT... http://sprunge.us/VHOj
[17:57:57 CEST] <D`K_C> hi folks, does the input buffer passed to av_parser_parse2 have to be padded?
[18:00:00 CEST] <bencoh> nonex86: I'd expect dts to be relevant when muxing, but...
[18:01:32 CEST] <t4nk252> @durandal_1707: Thanks your suggestion solved my problem
[18:04:57 CEST] <nonex86> well, at version 3.0.0 i used it still possible set dts to AV_NOPTS_VALUE
[18:05:30 CEST] <nonex86> but this functionality is deprecated
[18:05:46 CEST] <nonex86> at least in debug mode ffmpeg warns about that
[18:15:42 CEST] <witChdoCtOr> ffprobe -v error -show_format -show_streams
[18:15:53 CEST] <witChdoCtOr> ffprobe -v error -show_format -show_streams test1024x768.mp4
[18:16:08 CEST] <witChdoCtOr> time_base=1/30000
[18:16:43 CEST] <witChdoCtOr> mine
[18:16:48 CEST] <witChdoCtOr> time_base=1/15360
[18:19:11 CEST] <witChdoCtOr> profile=High 4:4:4 Predictive | profile=High
[18:19:12 CEST] <witChdoCtOr> codec_time_base=1001/60000 | codec_time_base=119/3686400
[18:19:14 CEST] <witChdoCtOr> level=31 | level=32
[18:19:15 CEST] <witChdoCtOr> is_avc=true | is_avc=false
[18:19:17 CEST] <witChdoCtOr> nal_length_size=4 | nal_length_size=0
[18:19:18 CEST] <witChdoCtOr> r_frame_rate=30000/1001 | r_frame_rate=15360/1
[18:19:20 CEST] <witChdoCtOr> avg_frame_rate=30000/1001 | avg_frame_rate=1843200/119
[18:23:39 CEST] <witChdoCtOr> hello?
[18:26:09 CEST] <jrun> is this an ffmpeg bug?
[18:26:14 CEST] <jrun> https://github.com/Flameeyes/unpaper/issues/46
[18:26:46 CEST] <jrun> unpaper uses ffmpeg to process scanned images. pnm file formats exclusively actually
[18:27:31 CEST] <JEEB> the linked ticket seemingly says it was supposedly fixed
[18:27:39 CEST] <JEEB> two months ago by michaelni
[18:29:22 CEST] <jrun> i scanned some pages in two different ways. one, with cropping. two, without cropping.
[18:29:36 CEST] <jrun> this second (no-cropping) image which causes the problem.
[18:30:02 CEST] <jrun> JEEB: i moved ffmpeg to git version on my machine (gentoo), still having the same problem.
[18:31:40 CEST] <mrob> How can I override color range in a ffmpeg filter chain?
[18:32:01 CEST] <mrob> Eg. starting with a limited (MPEG) range input, I want format=yuv420p16,lutyuv=y=val*1.1689319-4787.9452,lutyuv=y=val*0.8554818+4096 to be a null filter (except rounding errors)
[18:32:05 CEST] <JEEB> jrun: current master? if it's the same issue as the one on FFmpeg's trac, then post there again
[18:32:23 CEST] <JEEB> on that issue and say that it happens again, post/link to the sample
[18:32:24 CEST] <mrob> That converts to full (JPEG) range, and then back again
[18:32:45 CEST] <mrob> But it seems ffmpeg clips it to MPEG range between the two calls to lutyuv
[18:33:37 CEST] <furq> mrob: i guess you need colorspace=range=full in there somewhere
[18:33:43 CEST] <furq> er
[18:33:46 CEST] <furq> colorspace=range=jpeg
[18:33:46 CEST] <durandal_1707> mrob: lutyuv clips it
[18:34:08 CEST] <mrob> durandal_1707: Thanks, any way to override?
[18:34:27 CEST] <durandal_1707> no need for lutyuv, use colorspace filter
[18:34:35 CEST] <JEEB> or zscale I guess
[18:34:45 CEST] <JEEB> vf_colorspace is internal and thus simpler I guess
[18:35:57 CEST] <mrob> Basically, I want to apply debanding in anti-gamma-corrected colorspace
[18:36:31 CEST] <mrob> Because if I use gamma correction just as mid-point adjustment (completely ignoring color accuracy), that exaggerates banding in shadows and hides it in highlights
[18:36:56 CEST] <mrob> So I figure if I anti-gamma correct it before debanding, that will do stronger debanding in the shadows
[18:37:56 CEST] <mrob> And at the same time, I want to adjust black point and white point
[18:38:20 CEST] <mrob> So I get the full shadow/midtone/highlight type adjustment from graphics editors
[18:39:01 CEST] <mrob> And this seems simpler with JPEG range colorspace, plus gradfun is only 8 bit so I want all the dynamic range I can get there
[18:40:19 CEST] <JEEB> I think you might be able to do it with zscale and/or vapoursynth (which uses the underlying zimg library that zscale uses as well)
[18:41:59 CEST] <mrob> JEEB: Thanks, I'll check that out
[18:42:19 CEST] <JEEB> I think you might be able to get linear gamma picture from zimg/zscale
[18:42:49 CEST] <JEEB> and then you can apply whatever filter you need (the stuff with vapoursynth can do it with higher bit depths I'm pretty sure), and then you use the same thing to go back to gamma
[18:42:54 CEST] <JEEB> or whatever thing you need
[18:43:34 CEST] <mrob> Or it might be easier to edit lutyuv to remove the clipping, I'll have a look at the source
[18:43:50 CEST] <JEEB> sure
[18:44:20 CEST] <JEEB> the zimg library is surprisingly versatile, and vapoursynth has been going nicely even though it's still niche as hell.
[18:54:02 CEST] <witChdoCtOr> any idea why codec_time_base=119/14400000
[18:59:15 CEST] <jrun> JEEB: unpaper fails on a call to avformat_open_input()
[18:59:49 CEST] <jrun> JEEB: not sure if it's the same issue.
[19:00:01 CEST] <JEEB> see if you can replicate it with ffmpeg cli
[19:00:06 CEST] <JEEB> that'd be the simplest way
[19:00:19 CEST] <JEEB> ffmpeg -i input would be the simplest thing I guess
[19:12:15 CEST] <ozette> my statically linked ffmpeg says: 'error while loading shared libraries: libx264.so.148 .. No such file or directory'
[19:12:33 CEST] <ozette> on the target
[19:12:51 CEST] <DHE> you sure it's statically linked? and that you're launching the right binary?
[19:13:09 CEST] <BtbN> if you don't have static libs for your dependencies, they won't be static.
[19:13:30 CEST] <ozette> DHE: i'm sure it's the right binary
[19:13:39 CEST] <ozette> i tried to ./ffmpeg -codecs | grep png
[19:13:50 CEST] <DHE> you can use `file` on a binary to see if it's dynamic or static
[19:15:24 CEST] <ozette> heh.. it says dynamically linked
[19:15:39 CEST] <ozette> ffmpeg: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, stripped
[19:15:57 CEST] <ozette> it's 14mb
[19:17:02 CEST] <DHE> well then
[19:17:15 CEST] <furq> ozette: --enable-static won't prevent linking to external shared libraries
[19:18:03 CEST] <ozette> the libs in my sysroot/usr/lib are shared
[19:18:07 CEST] <DHE> --enable-static is more for generating libavcodec.a rather than libavcodec.so
[19:18:07 CEST] <ozette> zlib and x264
[19:18:27 CEST] <furq> yeah you need --extra-ldflags="-static" if you want to prevent linking to shared libs
[19:18:30 CEST] <DHE> you're going to want --extra-ldflags=-static but that's a huge can of worms by in a different way
[19:18:41 CEST] <furq> although in this case you probably just want to install the .so on your target machine
[19:18:47 CEST] <ozette> aha
[19:18:56 CEST] <DHE> I have a special build environment just for that
[19:19:04 CEST] <furq> same
[19:19:39 CEST] <ozette> hmm
[19:19:43 CEST] <furq> i should probably fix mine so it doesn't just work for mingw cross compiling
[19:20:06 CEST] <furq> i guess people on less fortunate distros would find it useful
[19:20:51 CEST] <ozette> so all external libs need to be compiled with --extra-ldflags=-static ? what makes it a huge can of worms?
[19:21:37 CEST] <ozette> i can bring over the libs to my target, but i'd like th resulting ffmpeg binary to work out of the box on machines which don't have these libs
[19:21:44 CEST] <DHE> it means you can't use libz.so, you need libz.a. You also need libx264.a, libc.a, libstdc++.a, and all the other things
[19:21:59 CEST] <ozette> i see
[19:22:15 CEST] <DHE> if you've got x11grab installed, you'll need libX11.a, libXcb.a, and so on.
[19:22:25 CEST] <furq> if you want a fully static library then that's the way to do it
[19:22:26 CEST] <DHE> some distros don't even offer such an extensive collection of static libraries
[19:22:34 CEST] <furq> otherwise the linker will assume you want the .so if it's present
[19:23:06 CEST] <DHE> which is why my static build of ffmpeg includes --disable-indevs --disable-xxx quite a bit in the configure scripts
[19:23:09 CEST] <ozette> any reason why --enable-static doesn't warn there's no .a's in my sysroot/usr/lib ?
[19:23:28 CEST] <furq> like DHE said, --enable-static just prevents generation of libav*.so
[19:23:29 CEST] <DHE> because it's for building .a versions of ffmpeg libs, not a static link of the ffmpeg cli tool itself
[19:23:36 CEST] <ozette> o
[19:24:16 CEST] <DHE> a full dynamic version of ffmpeg would be, oh 600k
[19:24:18 CEST] <furq> also uh
[19:24:24 CEST] <furq> 18:20:51 ( ozette) so all external libs need to be compiled with --extra-ldflags=-static ? what makes it a huge can of worms?
[19:24:28 CEST] <furq> no, just ffmpeg
[19:24:51 CEST] <furq> external libs will normally generate a .a
[19:25:05 CEST] <furq> i'm conflicted as to whether that should be "a .a" or "an .a"
[19:25:33 CEST] <ozette> lol
[19:26:15 CEST] <DHE> for pronunciation purposes I say "dot-A" so it's a .a file
[19:26:26 CEST] <furq> yeah that's what i was thinking
[19:26:32 CEST] <furq> i might just stick with "a shared library"
[19:26:36 CEST] <furq> ...
[19:26:39 CEST] <furq> a static library.
[19:26:49 CEST] <furq> this is less complicated than i'm making it
[19:27:07 CEST] <DHE> this whole thing is becoming overcomplicated
[19:27:17 CEST] <furq> anyway
[19:27:25 CEST] <ozette> :p
[19:27:30 CEST] <furq> configure x264 with --enable-static and zlib with --static
[19:27:35 CEST] <DHE> add configure command --extra-ldflags=-static and then complain when it fails to build properly.
[19:27:48 CEST] <furq> then ^
[19:27:51 CEST] <furq> that should work
[19:28:12 CEST] <ozette> haha ok! thanks lads
[19:52:28 CEST] <jrun> JEEB: what is 'ffmpeg -i 002.pbm' supposed to do?
[19:52:53 CEST] <JEEB> just load the input and maybe decode a picture
[19:52:59 CEST] <JEEB> a basic test
[19:53:25 CEST] <JEEB> if your issue is loading the file it should pop up there too
[19:55:17 CEST] <jrun> this is what i get:
[19:55:24 CEST] <jrun> http://bpaste.net/show/b034141487fd
[19:55:44 CEST] <JEEB> well that looks OK
[19:55:56 CEST] <JEEB> ffmpeg -i INPUT -f null -
[19:56:03 CEST] <JEEB> should decode it and output to /dev/null
[19:56:10 CEST] <JEEB> that should then probably finish nicely as well
[19:56:30 CEST] <JEEB> in that case unfortunately the thing seems to work
[19:57:38 CEST] <jrun> Your paste can be seen here: http://bpaste.net/show/8ec5346a2afb
[19:58:13 CEST] <JEEB> alright, so that fails
[19:59:17 CEST] <JEEB> feel free to post that on the bug tracker with the command line you tested it with
[19:59:58 CEST] <jrun> if i'm looking for a similar bug, what should be the keyword? pbm?
[20:02:04 CEST] <JEEB> uhh, you linked to an issue that linked to an FFmpeg trac issue...
[20:02:11 CEST] <JEEB> so *you* should know it :P
[20:04:30 CEST] <jrun> JEEB: any good debug flags to add to your onliner?
[20:04:41 CEST] <jrun> i mean to make the report more comprehensive
[20:04:42 CEST] <JEEB> -v debug is the only way from cli
[20:05:33 CEST] <jrun> http://bpaste.net/show/0f648604d67e
[20:05:43 CEST] <jrun> got more stuff in there, i thought it might help
[20:15:00 CEST] <jrun> could i reopen this:
[20:15:02 CEST] <jrun> https://trac.ffmpeg.org/ticket/5670#modify
[20:16:39 CEST] <jrun> hmm, probably not because the in.pbm file attached is handled fine here
[20:17:57 CEST] <JEEB> jrun: you can just create a new ticket and if it is a duplicate it will be flagged as such
[20:20:41 CEST] <ozette> hmm
[20:22:38 CEST] <ozette> when there's a libx264.a in my sysroot's lib/ and the configure says 'libx264 not found' when i add --extra-ldflags=-static, am i missing some additional option flag?
[20:23:34 CEST] <furq> what does config.log have to say
[20:32:05 CEST] <flyBoi> Any idea why this isn't actually outputting a palette.png file? `ffmpeg -ss 30 -i tmp0/input/trimmedFile.mp4 -y -t 3 -vf palettegen tmp0/input/palette.png`
[20:33:22 CEST] <flyBoi> damnit, nevermind. I'm retrimming an already-trimmed video
[20:33:34 CEST] <flyBoi> Didn't realize it until seeing it in IRC ;-)
[20:35:44 CEST] <ozette> furq: the last couple of lines tell me libx264 is not found, and before that i receive a warning concerning x264.h https://paste.fedoraproject.org/413491/20635991/
[20:36:53 CEST] <DHE> ozette: add --extra-ldflags=-ldl
[20:37:11 CEST] <JEEB> what is your prefix?
[20:37:12 CEST] <DHE> actually, no bad idea for a static link. rebuild libx264 with --disable-opencl
[20:37:30 CEST] <JEEB> because it seems like you're not using pkg-config
[20:37:41 CEST] <ozette> JEEB: that's correct, not using pkg-config
[20:37:43 CEST] <JEEB> PKG_CONFIG_LIBDIR=/your/prefix/lib/pkgconfig
[20:37:47 CEST] <JEEB> this should help
[20:37:52 CEST] <ozette> oh
[20:37:58 CEST] <JEEB> because the -ldl should be in the x264 pc file
[20:37:58 CEST] <ozette> DHE: yea i might rebuild x264
[20:38:14 CEST] <JEEB> LIBDIR overrides pkg-config's full search path
[20:38:24 CEST] <DHE> JEEB: -ldl for a static link is of questionable benefit. better to eliminate the use of libdl
[20:38:24 CEST] <JEEB> while PKG_CONFIG_PATH just appends to it
[20:38:44 CEST] <JEEB> DHE: sure but I'm telling that in general he should be using pkg-config if only possible because it helps :P
[20:39:13 CEST] <JEEB> at least for me it's less of a mess than trying to keep a list of all the cflags/ldflags I need
[20:39:38 CEST] <DHE> ah...
[20:42:59 CEST] <JEEB> many things check for cross-prefix-pkg-config too
[20:43:10 CEST] <JEEB> which usually is a shell script that overrides PKG_CONFIG_LIBDIR
[20:43:14 CEST] <JEEB> and runs your usual pkg-config
[20:46:19 CEST] <witChdoCtOr> $20 for a tutorial and Q&A on time stamps and PTS/DTS
[20:47:07 CEST] <JEEB> presentation vs decoding time stamp
[20:47:21 CEST] <JEEB> presentation has to be >= decoding
[20:47:25 CEST] <witChdoCtOr> enoding?
[20:47:32 CEST] <pgorley> when it should be decoded vs when it should be displayed, i think
[20:47:36 CEST] <JEEB> yes
[20:47:42 CEST] <JEEB> because you can't show something you haven't decoded yet
[20:47:56 CEST] <witChdoCtOr> I found that here http://www.mjbshaw.com/2012/04/seeking-in-ffmpeg-know-your-timestamp.html
[20:48:32 CEST] <witChdoCtOr> eventually I will need to seek in files but right now I am just trying to get through encoding a file
[20:48:55 CEST] <witChdoCtOr> currently I set frame->pts = frame_count;
[20:49:19 CEST] <witChdoCtOr> that got rid of the nag from mux.c about fixing pts
[20:51:57 CEST] <witChdoCtOr> somehow I am not getting time_stamp into the output file
[20:52:10 CEST] <witChdoCtOr> Stream #0:0: Video: h264 (h264_nvenc), yuv420p, 1024x768, q=-1--1, 3000 kb/s, 60 tbr, 60 tbn
[20:52:21 CEST] <witChdoCtOr> at that point is seems good
[20:52:34 CEST] <witChdoCtOr> Stream #0:0: Video: h264 (High), yuv420p, 1024x768 [SAR 1:1 DAR 4:3], 1k fps, 60 tbr, 1k tbn, 120 tbc (default)
[20:52:56 CEST] <witChdoCtOr> then it is broken after I close the file
[20:54:27 CEST] <witChdoCtOr> I am serious about paying for a good lesson
[20:55:58 CEST] <pgorley> hmm, not too sure about this, but shouldn't that be frame->dts = frame_count ?
[20:58:14 CEST] <witChdoCtOr> error: struct AVFrame has no member named dts
[20:58:43 CEST] <kepstin> pgorley: no, you set pts on the frames before sending to the encoder. The encoder might reorder frames, that's where dts comes into play
[20:58:56 CEST] <pgorley> oh... that makes sense
[20:59:17 CEST] <witChdoCtOr> yes m_dst_frame->pts = m_frame_count; avcodec_send_frame( m_av_codec_ctx, m_dst_frame );
[20:59:33 CEST] <witChdoCtOr> that is what I am doing
[21:00:00 CEST] <witChdoCtOr> I got so many brick impressions in my forehead I will try anything
[21:00:08 CEST] <kepstin> witChdoCtOr: what muxer are you using? You might consider running ffprobe -show_frames on your file to see what the timestamps look like.
[21:00:20 CEST] <kepstin> on your output file*
[21:00:48 CEST] <witChdoCtOr> Charles at linux2 1:48pm dec_enc >> ffprobe -v error -select_streams v:0 -show_entries stream=profile,codec_time_base,r_frame_rate,time_base -of default=noprint_wrappers=1 test2.mp4
[21:00:49 CEST] <witChdoCtOr> profile=High 4:4:4 Predictive
[21:00:51 CEST] <witChdoCtOr> codec_time_base=1/120
[21:00:53 CEST] <witChdoCtOr> r_frame_rate=60/1
[21:00:54 CEST] <witChdoCtOr> time_base=1/15360
[21:01:10 CEST] <witChdoCtOr> that was from a file with ffmpeg grab
[21:01:32 CEST] <witChdoCtOr> Charles at linux2 1:57pm dec_enc >> ffprobe -v error -select_streams v:0 -show_entries stream=profile,codec_time_base,r_frame_rate,time_base -of default=noprint_wrappers=1 test.mp4
[21:01:34 CEST] <witChdoCtOr> profile=High
[21:01:35 CEST] <witChdoCtOr> codec_time_base=119/3686400
[21:01:37 CEST] <witChdoCtOr> r_frame_rate=15360/1
[21:01:38 CEST] <witChdoCtOr> time_base=1/15360
[21:01:43 CEST] <witChdoCtOr> my output broken
[21:02:31 CEST] <witChdoCtOr> I changed containers to mkv and VLC will play the file
[21:02:58 CEST] <witChdoCtOr> funny thing is I can actually open it and render with my decoder
[21:08:40 CEST] <kepstin> hmm, those are some weird looking broken timebases :/
[21:08:51 CEST] <witChdoCtOr> lol yea
[21:09:14 CEST] <witChdoCtOr> total GAR-BAAAAAAGE
[21:10:31 CEST] <ozette> adding --extra-ldflags=-ldl still renders the same error 'libx264 not found', and JEEB which pkgconfig did you mean?
[21:10:46 CEST] <witChdoCtOr> pkg-config
[21:11:11 CEST] <witChdoCtOr> $(shell pkg-config --libs libx264)
[21:12:11 CEST] <JEEB> you can use any, the PKG_CONFIG_LIBDIR is the env var you care about
[21:12:25 CEST] <JEEB> which you set to /your/prefix/lib/pkgconfig
[21:12:32 CEST] <DHE> hmm.. I found a broken video that ffmpeg chokes on for video conversion, but mpv plays okay-ish...
[21:13:03 CEST] <ozette> um
[21:13:19 CEST] <witChdoCtOr> mine used PKG_CONFIG_PATH
[21:13:49 CEST] <witChdoCtOr> is he trying to build ffmpeg with libx264 ?
[21:14:11 CEST] <JEEB> PKG_CONFIG_PATH appends
[21:14:15 CEST] <JEEB> PKG_CONFIG_LIBDIR overrides
[21:14:23 CEST] <witChdoCtOr> oh something new cool
[21:14:25 CEST] <JEEB> this is cross-compilation so you generally don't want the system stuff
[21:15:18 CEST] <witChdoCtOr> is he failing compile or runtime?
[21:15:22 CEST] <ozette> not sure i understand, what is /my/prefix/lib/pkgconfig ? x264's? ffmpegs?
[21:15:35 CEST] <JEEB> ozette: you usually have a single prefix you install your cross-compiled libs to
[21:15:40 CEST] <JEEB> that thing
[21:15:58 CEST] <ozette> i didn't provide a prefix
[21:16:05 CEST] <JEEB> --prefix
[21:16:10 CEST] <JEEB> you didn't set that one?
[21:16:12 CEST] <witChdoCtOr> "/my/pefix/" == the place you told libx264 to be
[21:16:15 CEST] <ozette> i never did actually
[21:16:28 CEST] <JEEB> well then it's /usr/local by default for most things with a configure script
[21:16:30 CEST] <witChdoCtOr> i.e. /usr/local is the default a lot of time
[21:16:32 CEST] <JEEB> which is something you don't want
[21:16:43 CEST] <JEEB> anyways, if I recall your comments on #x264
[21:16:54 CEST] <JEEB> --prefix=/home/magissa/Downloads/source/x264/build
[21:17:02 CEST] <JEEB> so you *did* set --prefix somewhere at least :P
[21:17:07 CEST] <witChdoCtOr> lol
[21:17:09 CEST] <witChdoCtOr> once
[21:17:25 CEST] <ozette> that's when i was building x264
[21:17:31 CEST] <ozette> but not when i build ffmpeg
[21:18:08 CEST] <JEEB> well you generally want to set a prefix because you only get the used the directory structure with make install :P
[21:18:08 CEST] <ozette> i'm new with pkg-config, read some guide, but
[21:18:11 CEST] <witChdoCtOr> export PKG_CONFIG_LIBDIR=/home/magissa/Downloads/source/x264/build/lib/pkgconfig
[21:18:31 CEST] <JEEB> or just `PKG_CONFIG_LIBDIR=/home/magissa/Downloads/source/x264/build/lib/pkgconfig ./configure --your-params`
[21:19:03 CEST] <ozette> so i need to override?
[21:19:25 CEST] <JEEB> because by default your pkg-config will be looking at your standard system libraries, so yes...
[21:19:34 CEST] <ozette> aha
[21:19:35 CEST] <JEEB> which you don't want because you have a custom prefix with your cross-compiled stuff
[21:19:55 CEST] <witChdoCtOr> ./configure --extra-cflags=-L/home/magissa/Downloads/source/x264/build/lib
[21:20:01 CEST] <JEEB> no
[21:20:05 CEST] <JEEB> just use pkg-config
[21:20:11 CEST] <JEEB> the pc file should contain that
[21:20:26 CEST] <ozette> i copied the lib files to my toolchain's sysroot
[21:20:29 CEST] <ozette> so..
[21:20:50 CEST] <witChdoCtOr> maybe ln -s would be easier?
[21:20:53 CEST] <kepstin> copied from where?
[21:20:58 CEST] <JEEB> uh-huh, because that's so much simpler to clean than a separate prefix 8)
[21:21:09 CEST] <ozette> from my prefix
[21:21:31 CEST] <JEEB> basically I usually have a single dir I use for a specific architecture/OS for cross-compilation :P
[21:21:39 CEST] <ozette> which was ../x264/build
[21:21:39 CEST] <JEEB> and set that as --prefix for related components
[21:21:56 CEST] <JEEB> anyways, just use pkg-config and it should take care of the ldl issue :P
[21:22:05 CEST] <JEEB> as in, set the PKG_CONFIG_LIBDIR and just have pkg-config installed
[21:22:29 CEST] <witChdoCtOr> pkg-config --list-all | grep 264
[21:22:31 CEST] <JEEB> the libdir being /your/prefix/lib/pkgconfig as I noted a few times already
[21:22:37 CEST] <ozette> i have pkg-config installed and set the PKG_CONFIG_LIBDIR var, but it still gave me the error when i pointed it to the pkgconfig of x264.. so
[21:22:47 CEST] <JEEB> then please post your config.log
[21:22:58 CEST] <JEEB> on a pastebin like thing
[21:22:59 CEST] <JEEB> and link here
[21:23:22 CEST] <witChdoCtOr> check that it is finding the .pc files
[21:23:29 CEST] <witChdoCtOr> pkg-config --list-all | grep 264
[21:23:35 CEST] <JEEB> and yes, that requires the override as well
[21:23:40 CEST] <JEEB> unless you exported the variable
[21:23:50 CEST] <JEEB> also /your/prefix/lib/pkgconfig should contain x264.pc
[21:23:57 CEST] <ozette> not sure what i'm doing wrong. https://paste.fedoraproject.org/413534/66599147/raw/ and input:
[21:24:16 CEST] <ozette> https://paste.fedoraproject.org/413535/72066648/raw/
[21:24:27 CEST] <JEEB> also why are you overriding cc again? if you set cross-prefix that will be used for all tools
[21:24:33 CEST] <JEEB> just as a separate comment
[21:24:47 CEST] <ozette> grepping for 264 displays nothing
[21:25:09 CEST] <JEEB> did you make install x264 :P
[21:25:25 CEST] <JEEB> or did you start manually poking around?
[21:25:43 CEST] <witChdoCtOr> why RTFM much funner to poke around
[21:25:58 CEST] <ozette> im quite sure i installed it, because it ended up in my prefix
[21:26:03 CEST] <witChdoCtOr> -march=armv7-a
[21:26:09 CEST] <witChdoCtOr> cool
[21:26:11 CEST] <ozette> the libs did
[21:26:17 CEST] <JEEB> with the libraries? I remember you first compiled without the libs enabled
[21:26:23 CEST] <ozette> true
[21:27:08 CEST] <ozette> but thanks to your help, i managed to build x264 and the resulting lib looks ok
[21:27:15 CEST] <JEEB> after that you should have lib/pkgconfig/x264.pc
[21:27:18 CEST] <JEEB> in the prefix you set
[21:27:23 CEST] <ozette> yes, that i have
[21:27:32 CEST] <ozette> um
[21:27:43 CEST] <JEEB> ok, then if you set PKG_CONFIG_LIBDIR correctly you should be able to pkg-config --list-all
[21:27:47 CEST] <JEEB> and see it listed
[21:27:55 CEST] <ozette> yea it's there
[21:27:59 CEST] <witChdoCtOr> did you enable opencl ?
[21:28:11 CEST] <ozette> wait
[21:28:12 CEST] <JEEB> it's enabled by default in x264 if found
[21:28:18 CEST] <witChdoCtOr> OPS /usr/local/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi/sysroot/usr/lib/libx264.a(opencl.o): In function `x264_opencl_load_library':
[21:28:27 CEST] <JEEB> ozette: ok now you can set the PKG_CONFIG_LIBDIR and configure FFmpeg
[21:28:47 CEST] <JEEB> witChdoCtOr: it's because it's trying to find libx264 without pkg-config so it doesn't know the requirement of ldl
[21:29:02 CEST] <JEEB> pkg-config would tell that it has to link against ldl as well
[21:29:06 CEST] <JEEB> as in, the pc file
[21:29:37 CEST] <JEEB> the "hurr durr I'm a renegade and I'm not going to use pkg-config" way has no way of knowing it is required
[21:29:40 CEST] <JEEB> and thus the check fails
[21:30:05 CEST] <ozette> even when i set PKG_CONFIG_LIBDIR=/home/magissa/Downloads/source/x264/build/lib/pkgconfig .. or PKG_CONFIG_LIBDIR=/home/magissa/Downloads/source/x264/build/lib/pkgconfig/x264.pc
[21:30:16 CEST] <ozette> i can't pkg-config --list-all | grep x264
[21:30:21 CEST] <ozette> well i can, but it doesn't show anything
[21:30:30 CEST] <JEEB> but it shows up under pkg-config --list-all itself?
[21:30:39 CEST] <JEEB> if you set the ..LIBDIR correctly
[21:30:44 CEST] <witChdoCtOr> means pkg-config did not find the x264.pc file
[21:31:00 CEST] <kepstin> you need to set the env variable PKG_CONFIG_PATH not PKG_CONFIG_LIBDIR
[21:31:08 CEST] <JEEB> kepstin: LIBDIR overrides the full search path
[21:31:12 CEST] <JEEB> PATH appends
[21:31:18 CEST] <JEEB> LIBDIR is required for cross-compilation
[21:31:22 CEST] <ozette> no https://paste.fedoraproject.org/413542/20670731/raw/
[21:31:23 CEST] <kepstin> oh, huh? didn't realize that
[21:31:30 CEST] <witChdoCtOr> ozette what doe echo $SHELL show?
[21:31:32 CEST] Action: kepstin re-reads the pkg-config man page
[21:31:54 CEST] <witChdoCtOr> i didn't know either and I love pkg-config
[21:31:58 CEST] <ozette> witChdoCtOr: /bin/bash
[21:32:06 CEST] <kepstin> huh, you're right. I thought that var named seemed funny but I just don't cross-compile much :)
[21:32:18 CEST] <JEEB> yes, they're pretty different in name
[21:32:26 CEST] <witChdoCtOr> export PKG_CONFIG_LIBDIR=/home/magissa/Downloads/source/x264/build/lib/pkgconfig
[21:32:32 CEST] <witChdoCtOr> do that first
[21:32:41 CEST] <witChdoCtOr> in the same shell
[21:32:50 CEST] <ozette> ah
[21:32:50 CEST] <witChdoCtOr> then configure
[21:32:53 CEST] <witChdoCtOr> then build
[21:32:53 CEST] <JEEB> also there's PKG_CONFIG_SYSROOT which I generally just leave undefined because the one time I tried using it, it failed
[21:33:24 CEST] <JEEB> (and most of my cross-compilation toolchains had the sysroot in a place that was available to the tools by default)
[21:35:47 CEST] <furq> i bet you wish you'd just installed debian now
[21:36:56 CEST] <JEEB> I don't think the distro selection has much to do with cross-compilation stuff
[21:37:12 CEST] <JEEB> since most distros do give you the toolchain and maybe cross-prefix-pkg-config
[21:37:25 CEST] <JEEB> and then you still have the PKG_CONFIG_PATH/LIBDIR overriding
[21:37:41 CEST] <ozette> haha
[21:37:53 CEST] <ozette> i am thinking about dropping fedora for months now and go to debian
[21:38:05 CEST] <JEEB> dunno, I use both
[21:38:11 CEST] <furq> debian multiarch deals with all of this, including pkg-config
[21:38:29 CEST] <JEEB> that's not debian specific
[21:38:34 CEST] <JEEB> fedora has that just fine too
[21:38:41 CEST] <JEEB> the thing is that you often can't use the pre-packaged libs
[21:38:41 CEST] <witChdoCtOr> so does fedora/centos has nothing to do with distro
[21:38:44 CEST] <ozette> witChdoCtOr: JEEB thanks by the way, i didn't 'export' PKG_CONFIG_LIBDIR, but rebuilding x264 now just to be sure
[21:39:11 CEST] <JEEB> for example in my case the toolchain comes from GOOG anyways
[21:39:22 CEST] <JEEB> since I mostly cross-compile for android
[21:39:37 CEST] <furq> this is just a generic armv7 build though
[21:39:38 CEST] <witChdoCtOr> so you will be the guy I come looking for when I port to pine64
[21:40:02 CEST] <JEEB> and then I install the mingw-w64 cross compiler from fedora's repos and still have to build stuff because I wanted static libs
[21:40:27 CEST] <JEEB> so while I do have mingw-w64 libraries actually available in the repos, I can't really use much more than stdlib
[21:40:32 CEST] <JEEB> (´4@)
[21:40:54 CEST] <ozette> wow
[21:41:00 CEST] <JEEB> of course, if you're just building for that same linux distro on <arch> then you can just use the packaged multiarch packages
[21:41:11 CEST] <furq> i was going to say "wow i didn't know fedora packaged mingw libraries" but it's nice to know they've made them useless
[21:41:18 CEST] <witChdoCtOr> my offer to pay for a lesson still stands
[21:41:18 CEST] <ozette> x264 still not found: https://paste.fedoraproject.org/413546/47206734/raw/
[21:41:22 CEST] <furq> i knew i could trust them to fuck up the packaging somehow
[21:41:43 CEST] <JEEB> ozette: config.log
[21:41:45 CEST] <JEEB> as usual
[21:41:59 CEST] <ozette> did a make clean, rebuilt x264 with --disable-opencl, re-exported PKG_CONFIG_LIBDIR
[21:42:13 CEST] <JEEB> furq: well shared libs are a completely valid thing, it's just that in some cases you don't want that
[21:42:24 CEST] <furq> well you almost certainly don't want that for mingw
[21:42:25 CEST] <JEEB> also I didn't check if the packages contained static .as
[21:42:35 CEST] <JEEB> dunno, in many cases I'm OK with DLLs
[21:42:50 CEST] <JEEB> I have some specific cases where I want a stand-alone EXE
[21:43:03 CEST] <witChdoCtOr> pkg-config --list-all | grep 264
[21:43:29 CEST] <ozette> i don't think much/anything has changed: JEEB https://paste.fedoraproject.org/413553/47206778/
[21:44:03 CEST] <ozette> witChdoCtOr:
[21:44:19 CEST] <ozette> [magissa at localhost ffmpeg-3.1.2]$ pkg-config --list-all
[21:44:21 CEST] <JEEB> ozette: clean up the x264 crap you installed outside your prefix :P
[21:44:21 CEST] <ozette> x264 x264 - H.264 (MPEG4 AVC) encoder library
[21:45:08 CEST] <JEEB> because it's picking the stuff from your /usr/local/cross-prefix/ dir
[21:45:19 CEST] <ozette> JEEB: oh?
[21:45:34 CEST] <JEEB> /usr/local/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi/sysroot/usr/lib/libx264.a(opencl.o):opencl.c:(.text+0x120): more undefined references to `dlsym' follow
[21:46:08 CEST] <ozette> so i should remove the x264 libs from my toolchain sysroot?
[21:46:23 CEST] <ozette> how's it trying to pick that
[21:46:37 CEST] <JEEB> because that is in your standard linker search path?
[21:46:45 CEST] <JEEB> -_--
[21:46:46 CEST] <ozette> hm yea
[21:46:54 CEST] <witChdoCtOr> --prefix=/home/magissa/Downloads/source/
[21:47:19 CEST] <ozette> i was hoping this pkg_config_libdir override thing got it covered
[21:47:34 CEST] <JEEB> well that just adds things to default search paths for compiler/linker
[21:47:45 CEST] <JEEB> so if you did something like you did then herp derp have fun
[21:49:14 CEST] <witChdoCtOr> you should probably build x264 and ffmpeg with the same prefix
[21:49:33 CEST] <witChdoCtOr> it would make sorting it out easier
[21:49:48 CEST] <JEEB> well that will affect things after ffmpeg gets built
[21:50:01 CEST] <witChdoCtOr> where is your x264 config?
[21:50:11 CEST] <witChdoCtOr> how so Jeeb
[21:50:37 CEST] <JEEB> because if you only need x264 for FFmpeg then it really doesn't matter that much if you're not trying to use the FFmpeg libraries for something
[21:50:58 CEST] <JEEB> of course if you have more than one dep then yes, definitely have a single prefix you install crapola into
[21:51:22 CEST] <JEEB> (like when I build mpv I usually have a armv7_prefix somewhere and I se --prefix for everything there
[21:51:45 CEST] <witChdoCtOr> ok you lost me but I would like to hear more
[21:52:23 CEST] <witChdoCtOr> I thought we was trying to build x264 and ffmpeg for armV7
[21:52:41 CEST] <ozette> yes
[21:53:04 CEST] <JEEB> yes, but thus FFmpeg only has a single dep and thus it really doesn't matter how he sets his prefix since it's not going to be used for FFmpeg. if he has something depending on FFmpeg then most definitely you will want a single prefix
[21:53:19 CEST] <JEEB> or if you start adding deps for FFmpeg (other libs etc)
[21:53:49 CEST] <JEEB> tl;dr if you just have a single dep, do whatever you want. but as soon as it gets to >1 then you better have a single prefix
[21:53:55 CEST] <ozette> what's this prefix matter?
[21:54:08 CEST] <JEEB> it's where your compiled stuff gets installed
[21:54:23 CEST] <witChdoCtOr> that is the path that binary files go to when you do make install
[21:54:49 CEST] <JEEB> if you have an app that depends on freetype2, libass, FFmpeg then you usually want to install them to a single --prefix so you don't have to put a list of directories into PKG_CONFIG_LIBDIR
[21:54:54 CEST] <ozette> yea.. so what i've been doing all this time is
[21:55:09 CEST] <ozette> mkdir build, set my prefix to build/
[21:55:17 CEST] <ozette> and move its contents to my toolchain's sysroot
[21:55:22 CEST] <JEEB> yeah, nope
[21:55:35 CEST] <witChdoCtOr> That was what I was saying, use the same prefix for everything you build for each arch
[21:55:39 CEST] <JEEB> I mean, that will work as long as it will work as you just saw :P
[21:56:12 CEST] <JEEB> and to be honest, if you want to dispense stuff all over your cross compiler's sysroot - feel free, just that you use that as your prefix
[21:56:16 CEST] <mrob> I removed the color levels clipping from lutyuv and now I have debanding working in anti-gamma-corrected colorspace
[21:56:20 CEST] <witChdoCtOr> prefile=/path/arm7/
[21:56:28 CEST] <ozette> lol.. but i honestly don't know why it can't find libx264
[21:56:29 CEST] <mrob> I am now thinking of improving gradfun to support higher bit depths
[21:56:40 CEST] <JEEB> ozette: anyways remove those x264 things from the sysroot and then post your config.log again
[21:56:41 CEST] <witChdoCtOr> prefix=/path/arm8/
[21:56:47 CEST] <JEEB> and make sure you are setting your PKG_CONFIG_LIBDIR correctly
[21:56:48 CEST] <JEEB> kthx
[21:56:49 CEST] <ozette> JEEB: okay
[21:56:54 CEST] <witChdoCtOr> prefix//path/x86_64/
[21:57:28 CEST] <witChdoCtOr> is there an alternative?
[22:00:00 CEST] <ozette> JEEB: well it seems to look somewhat different now
[22:00:08 CEST] <ozette> https://paste.fedoraproject.org/413561/47206875/
[22:00:54 CEST] <JEEB> then it probably doesn't find it with pkg-config for whatever reason
[22:01:00 CEST] <JEEB> echo $PKG_CONFIG_LIBDIR
[22:01:31 CEST] <JEEB> and then pkg-config --cflags x264
[22:01:53 CEST] <JEEB> it should give you the cflags for your prefix
[22:02:14 CEST] <ozette> [magissa at localhost ffmpeg-3.1.2]$ echo $PKG_CONFIG_LIBDIR
[22:02:16 CEST] <ozette> /home/magissa/Downloads/source/x264/build/lib/pkgconfig
[22:02:38 CEST] <ozette> [magissa at localhost ffmpeg-3.1.2]$ pkg-config --cflags x264
[22:02:40 CEST] <ozette> -I/home/magissa/Downloads/source/x264/build/include
[22:02:52 CEST] <JEEB> ok, so it works for you locally
[22:02:58 CEST] <ozette> yea
[22:04:08 CEST] <ozette> the build dir of x264 contains a(n) .a
[22:04:17 CEST] <JEEB> so in prefix/lib?
[22:04:36 CEST] <ozette> yea and for some reason also in prefix/
[22:04:44 CEST] <JEEB> that shouldn't affect it
[22:04:49 CEST] <mrob> Results are not as good as I hoped with only 8bit gradfun
[22:04:58 CEST] <ozette> ok great
[22:05:01 CEST] <JEEB> you can also try out --libs with pkg-config
[22:05:13 CEST] <JEEB> that should give it the flags to be able to link against it
[22:05:26 CEST] <ozette> [magissa at localhost ffmpeg-3.1.2]$ pkg-config --libs x264
[22:05:28 CEST] <ozette> -L/home/magissa/Downloads/source/x264/build/lib -lx264 -lpthread -lm
[22:06:15 CEST] <shincodex> uh
[22:06:29 CEST] <JEEB> the only thing in the config.log I last posted that I see using "build/lib" is PKG_CONFIG_LIBDIR
[22:06:35 CEST] <JEEB> so something is not correct there
[22:06:36 CEST] <shincodex> AVERROR_EOF on camera stream how could i reget a image from stream
[22:06:43 CEST] <shincodex> or reset the AVERROR_EOF
[22:06:57 CEST] <shincodex> i tried av_free_packet init_packet
[22:07:12 CEST] <shincodex> av_seek_frame
[22:07:24 CEST] <shincodex> and then a av_read_frame but fail
[22:07:44 CEST] <shincodex> i know i can completely close/open to get a new frame but thats a hog
[22:07:49 CEST] <JEEB> ozette: for whatever reason the configure script is falling back to manually finding the thing :P and since you still seeem to have the headers there in your goddamn sysroot it will not fail before it starts looking for the libraries
[22:08:09 CEST] <JEEB> ozette: this is why you generally keep your sysroot clean of whatever custom crap you built
[22:08:18 CEST] <ozette> haha true.. i did not remove the headers
[22:08:44 CEST] <JEEB> wait
[22:08:50 CEST] <ozette> i didn't know, back when i was stuck on zlib someone told me if my libs were in sysroot
[22:08:51 CEST] <JEEB> why the fuck is your pkg-config "false"
[22:08:58 CEST] <JEEB> false --exists --print-errors x264
[22:08:59 CEST] <ozette> false?
[22:09:11 CEST] <shincodex> i deleted that line in my configure script
[22:09:14 CEST] <shincodex> ah freedom
[22:09:35 CEST] <JEEB> ok, whom do I whack on the head for this
[22:09:45 CEST] <witChdoCtOr> yea I remeber something about deleting that line
[22:10:06 CEST] <witChdoCtOr> you ?
[22:10:09 CEST] <JEEB> this used to work
[22:10:13 CEST] <ozette> not sure what's going on
[22:10:17 CEST] <JEEB> why on earth is it defaulting to "false"
[22:10:20 CEST] <JEEB> when pkg-config exists
[22:10:30 CEST] <JEEB> --pkg-config=pkg-config <- ozette add this to your configure line
[22:10:37 CEST] <JEEB> that's the default but still
[22:10:41 CEST] <ozette> JEEB: alright
[22:10:43 CEST] <JEEB> what the fucking flying fuck
[22:10:49 CEST] <JEEB> it's git blame time
[22:11:05 CEST] <shincodex> very upset
[22:11:23 CEST] <shincodex> its just a package configure
[22:11:45 CEST] <ozette> lol no more libx264 not found
[22:12:03 CEST] <ozette> yay i can finally make again!!!!
[22:12:05 CEST] <JEEB> yeah, it seems like if it can't find cross-prefix-pkg-config it will just think that you don't want one at all
[22:12:10 CEST] <JEEB> so you have to override it
[22:12:19 CEST] <JEEB> and tell configure you want to use no-prefix pkg-config
[22:12:36 CEST] <JEEB> so that's probably why it worked for me (I had cross-prefix-pkg-config for my cross-prefix)
[22:12:56 CEST] <JEEB> I do kind of understand why it does that but if you're overriding PKG_CONFIG_LIBDIR...
[22:13:13 CEST] <JEEB> (because you don't want your system libraries popping up in your cross-compile)
[22:13:44 CEST] <ozette> mhm
[22:14:03 CEST] <shincodex> does anyone know about camera streams and how they use mjpeg for one frame decode then just end
[22:14:19 CEST] <shincodex> vlc refreshed the player over and over again to make me get new ones
[22:14:29 CEST] <shincodex> which to me sounds like avformat_close avformat_open
[22:14:29 CEST] <TD-Linux> you mean like a webm?
[22:14:33 CEST] <TD-Linux> err webcam
[22:14:51 CEST] <shincodex> hmmm i have a camera if i hit it with a browser
[22:14:57 CEST] <shincodex> it will give me a jpeg and thats it of what it sees
[22:15:02 CEST] <shincodex> if you f5 new frame
[22:15:07 CEST] <shincodex> infact I dont even think you need ffmpeg
[22:15:16 CEST] <shincodex> curl get and uh libjpeg if you like
[22:15:21 CEST] <TD-Linux> oh okay. some cameras automatically refresh by using a multipart content type
[22:15:31 CEST] <shincodex> its not
[22:15:44 CEST] <shincodex> i get one frame then avjunk says AVERROR_EOF
[22:15:53 CEST] <shincodex> and im trying to detect that and do something based off of it
[22:16:03 CEST] <JEEB> that's because you're not getting a continuous stream
[22:16:07 CEST] <shincodex> and im doing detection just fine but refreshing the stream...
[22:16:11 CEST] <shincodex> is what im trying to figure out
[22:16:14 CEST] <JEEB> but you get a single thing, that's it. then you need to re-load it :P
[22:16:20 CEST] <shincodex> yeah
[22:16:28 CEST] <JEEB> basically what you REALLY want is a camera that gives you a continuous stream
[22:16:34 CEST] <shincodex> well i have a backup solution Stream::Close Stream::Open
[22:16:35 CEST] <shincodex> lol
[22:16:37 CEST] <JEEB> and if you can't have that, then you have to handle it yourself
[22:16:40 CEST] <JEEB> yes
[22:16:56 CEST] <shincodex> i know
[22:17:01 CEST] <JEEB> that's what you need to do because your darn stream only contains a single picture and you need to do a full new request for another
[22:17:03 CEST] <shincodex> this is really stupid but for some reason
[22:17:06 CEST] <shincodex> somebody wants this junk
[22:17:15 CEST] <shincodex> and i say go get a real stream and a real camera lol
[22:17:29 CEST] <shincodex> you say full request like...
[22:17:46 CEST] <JEEB> new avformat request basically so what you say about close/open probably is close to that :P
[22:18:12 CEST] <shincodex> find input format
[22:18:18 CEST] <shincodex> some dictionary options
[22:18:25 CEST] <shincodex> avformat_open_input
[22:18:38 CEST] <shincodex> avformat_find_Stream_info for vidstream shite
[22:18:44 CEST] <shincodex> ..decoder
[22:18:46 CEST] <shincodex> context
[22:18:48 CEST] <shincodex> this is crap
[22:19:06 CEST] <JEEB> well crap on all sides so feel free to hate everything
[22:19:14 CEST] <JEEB> it's not a continuous stream so what the fuck are you expecting
[22:19:20 CEST] <JEEB> you're getting a EOF from the server on the camera anyways
[22:19:41 CEST] <shincodex> reset on eof logic
[22:19:47 CEST] <shincodex> but somebody else wrote it
[22:19:58 CEST] <shincodex> :D
[22:21:24 CEST] <shincodex> heh
[22:21:26 CEST] <shincodex> i think i tricked it
[22:21:37 CEST] <shincodex> it didnt segfault.... yet
[22:25:31 CEST] <witChdoCtOr> should I be screwing with packets pts/dts or is something broken between my encoder and output
[22:25:45 CEST] <witChdoCtOr> pts = 00 dts = 0
[22:25:52 CEST] <witChdoCtOr> pts = 1717 dts = 17
[22:26:00 CEST] <witChdoCtOr> pts = 3333 dts = 33
[22:26:16 CEST] <witChdoCtOr> I know packets are more than frames but that just seems wrong
[22:27:43 CEST] <shincodex> Unknown option "".
[22:28:19 CEST] <witChdoCtOr> if i probe the header is looks file
[22:28:22 CEST] <witChdoCtOr> fine
[22:28:32 CEST] <witChdoCtOr> once I write packets to it, its wacked
[22:31:34 CEST] <shincodex> not sure where i erased the space from the configure but
[22:32:16 CEST] <shincodex> thinking before die_unknown shite
[22:32:24 CEST] <shincodex> trim string compare
[22:36:24 CEST] <shincodex> if someone needs help msvc build cli i just got finished with a managed c++ to ffmpeg misery fest
[22:36:54 CEST] <ozette> sweet, the ffmpeg and ffprobe run on my target and the finally have a png encoder (DEV..S :) )
[22:37:17 CEST] <ozette> thnaks for the help
[22:37:21 CEST] <VamoMenem> congrats (muscle)
[22:37:21 CEST] <JEEB> np
[22:37:44 CEST] <witChdoCtOr> cool
[22:37:45 CEST] <ozette> :)
[22:49:14 CEST] <witChdoCtOr> time scale anyone?
[22:51:20 CEST] <trudev> I'm considering using ffmpeg for a android app. We need to add music to a video, but we also need to specify when the song starts (ex: start the song at 10 seconds relative to song). Is this possible with ffmpeg?
[22:51:45 CEST] <witChdoCtOr> if the time scale in the media content is correct
[22:51:51 CEST] <witChdoCtOr> av_seek
[22:53:02 CEST] <trudev> witChdoCtOr: Are you talking to me? What do you mean by time scale?
[22:53:50 CEST] <witChdoCtOr> yea was talking to you
[22:54:06 CEST] <witChdoCtOr> time scale ~= time stamps in the media container
[22:54:56 CEST] <witChdoCtOr> in video terms frame rate is time scale FPS/1 the time between frames
[22:56:09 CEST] <witChdoCtOr> so if you want to skip 10 seconds in, the container has to have correct timescale for the data, to determine how much data to skip for 10 seconds but that will change depending on how the media was encoded
[22:58:28 CEST] <trudev> Thanks for explaining. This is still way above my head unfortunately
[22:59:39 CEST] <witChdoCtOr> ok HD vs standard def
[23:00:09 CEST] <trudev> I just need to mix an mp3 with an mp4 but, the mp3 should begin at say 20 seconds. So at the first second of the video, you should hear audio from the 20 second mark
[23:00:47 CEST] <witChdoCtOr> yes, you can do that with ffmpeg
[23:01:30 CEST] <trudev> Perfect! Do you know what that's called so I can read up on it?
[23:01:56 CEST] <furq> if you're reencoding the audio then -af adelay
[23:02:01 CEST] <furq> if not then i think -itsoffset will do it
[23:02:10 CEST] <furq> assuming you're using the cli tool
[23:02:38 CEST] <trudev> well yeah, I'm going to use a lib that will exposes the CLI to android
[23:02:43 CEST] <witChdoCtOr> i was thinking of ofset
[23:02:56 CEST] <witChdoCtOr> offset
[23:02:57 CEST] <trudev> like the ffmpeg binary included in the app
[23:03:09 CEST] <witChdoCtOr> https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[23:03:41 CEST] <furq> ?
[23:05:27 CEST] <witChdoCtOr> adelay=1500|0|500
[23:06:03 CEST] <witChdoCtOr> may be an easier way but I am not an audio guy
[23:08:31 CEST] <trudev> Thanks guys, I appreciate the help
[23:11:03 CEST] <VamoMenem> yes adelay is best than -itsoffset because itsoffets work arround timestamps, adelay works whit samples
[23:11:29 CEST] <VamoMenem> with
[23:11:50 CEST] <furq> adelay only works if you reencode though
[23:12:13 CEST] <VamoMenem> yes, i used adelay to sync a mosaic
[23:12:14 CEST] <furq> but yeah itsoffset is finicky as fuck in my experience
[23:14:00 CEST] <VamoMenem> when you cannot know timestamps, for example when youre maping and appliyng complex filters
[00:00:00 CEST] --- Thu Aug 25 2016
More information about the Ffmpeg-devel-irc
mailing list