Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
July 2014
- 1 participants
- 62 discussions
[00:01] <BBB> kierank: yeah it sounds like they mean they change some types from uint8_t to uint16_t, that doent mean 16bits in terms of hw will require all 16 bits
[00:01] <BBB> kierank: it just means a marketing dude rather than a tech dude
[00:01] <BBB> but what do I know, I dont work there
[00:01] <kierank> heh
[00:02] <BBB> Daemon404: also, if you have stuff youd rather have me work on, feel free to suggest it, Im open to different stuff
[01:20] <J_Darnley> Does git allow you to define global hooks like its global settings?
[01:22] <J_Darnley> I guess not. There's only a file .gitconfig in ~
[04:34] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:418e5768c68b: swresample/resample_template: move division out of loop for float/double swri_resample_linear()
[05:21] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:ca384d708b74: avformat/rtsp: use av_malloc_array()
[05:21] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:f054d1e7aedb: avformat/hdsenc: Use av_mallocz_array()
[10:06] <Varuh> hi guys. tell me please, can the Windows Media player correctly switch SPS PPS ? I've made mp4/h264 file from several pieces.
[10:46] <anshul> Varuh, wrong maililing list ask it at #ffmpeg if its related using ffmpeg
[10:57] <Varuh> anshul, I want improve mp4 multiplexer (movenc.c) to make WMP compatible mp4 files.
[11:23] <anshul> varuh, Sorry for previous one
[11:26] <anshul> Varuh ,I am not sure but have heard that wmp does not have any codec of his own , it use some external codecs.
[11:27] <anshul> If Wmp is using some xyz encoder for h264 then look at xyz encoder spec, it might be helpful to get in that direction
[11:33] <anshul> Varuh, http://www.mediacodec.org/ from here, i got to know that wmp use ffdshow, it look like opensource and may ur solution lies here
[11:35] <Varuh> I have not ffdshow. WMP uses Microsoft DTV-DVD Video decoder. (native ms decoder)
[11:36] <Varuh> the question is how to satisfy
[11:36] <Varuh> it
[11:38] <Varuh> sometimes it eats new SPSPPS from stream sometimes not.)
[11:38] <av500> sometimes its hungry
[11:39] <Varuh> :)
[11:57] <anshul> Is there any difference between pps/sps when it accept
[12:08] <Varuh> everything is much more strange.
[12:08] <Varuh> I have 2 files. the first contain only video stream, second contain video and audio.
[12:08] <Varuh> video stream was created from 2 files with same resolution and different FPS and SPSPPS.
[12:08] <Varuh> so WMP switches SPSPPS on v+a file and can't do it when video only.
[12:08] <Varuh> video bitstream and timestamps on this files are the same.
[12:24] <anshul> Varuh,It look like issue is at muxing level not encoding level
[12:27] <anshul> It may be variable fps issue did you try after converting the fps of both video to common value.
[12:46] <Varuh> you're right, anshul. fps alignment fixes it. thank you)
[13:51] <plepere> BBB : is there some strange voodoo magic to benefit from AVX2 speed-ups ?
[13:51] <plepere> because I'm not getting any. :/
[13:56] <BBB> lol
[13:56] <BBB> I dont have a test machine, so I dont know
[13:58] <nevcairiel> Aren't you using Intel's emulation thing? Maybe that's just not suited for benchmarking
[13:58] <plepere> ubitux gave me access to a AVX2 laptop
[13:58] <plepere> through SSH
[13:58] <nevcairiel> Ah
[13:59] <plepere> the times weren't changing, so I did a valgrind and the cycles are just too similar
[13:59] <plepere> less than 1% difference, but in favor of SSE2
[14:00] <nevcairiel> Did you confirm that it's really calling the new code?
[14:00] <BBB> valgrind?
[14:00] <plepere> I get errors when I put bugs in it. :p
[14:00] <BBB> wait
[14:00] <BBB> what?
[14:01] <BBB> you have to cycle-count
[14:01] <BBB> START_TIMER/STOP_TIMER
[14:01] <BBB> dont use valgrind or time, thats insane
[14:01] <plepere> valgrind --tool=callgrind
[14:01] <BBB> use START_TIMER/STOP_TIMER
[14:01] <plepere> gives cycle count
[14:01] <BBB> again, use START_TIMER/STOP_TIMER
[14:01] <plepere> ok ok
[14:01] <plepere> I'll try that
[14:01] <BBB> you really want to learn to use the tools that others use
[14:01] <BBB> if 100 people use one tool and you use another
[14:01] <BBB> youre probably wrong
[14:02] <BBB> even if youre not, its better to conform to majority rule in this case
[14:02] <plepere> ok, I'll do a timer test.
[14:02] <BBB> thanks
[14:02] <BBB> now, as for why does avx2 not give speedups: need to see code (old sse2/whatever code and new avx2 code)
[14:02] <BBB> you should get speedups from 3-op instructions on things like idct, and double registe width as long as you dont cross lanes
[14:03] <BBB> (plus sse2 was slow on core duo also, slower than mmx2)
[14:03] <nevcairiel> That lane thing is so lame
[14:03] <BBB> yay intel
[14:06] <plepere> the worst thing for me with AVX2 is the unpacks and packs that are done on 128b registers, not 256b. :/
[14:14] <plepere> http://pastebin.com/zPSYM8G5
[14:15] <plepere> it's for epel_hv on 16x16
[14:19] <plepere> nothing significan
[14:19] <plepere> t
[14:19] <BBB> code? (specifically, disassembly; not source)
[14:26] <plepere> BBB : http://pastebin.com/r5HqWC3h
[14:27] <plepere> good luck.
[14:27] <plepere> the sse2 version is in hevc_mc.asm
[15:37] <cone-445> ffmpeg.git 03Clément BSsch 07master:ec94c52e9724: doc: remove trailing ':' at the end of sections
[16:01] <Daemon404> shitty thing of the day: i can't apply a cmyk profile to a cmyk jpeg decoded with libavcodec because it converts to rgb
[16:02] <Daemon404> god i hate image format crap.
[18:10] <cone-445> ffmpeg.git 03John Stebbins 07master:253d0be6a1ec: pgssubdec: handle more complex PGS scenarios
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:376f353e3d76: avcodec/pgssubdec: rename PICTURE_SEGMENT
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:ca7f2a737256: avcodec/pgssubdec: do not fail when part of the packet is faulty unless AV_EF_EXPLODE is set
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:4701f7676ce9: avcodec/pgssubdec: split out flush_cache()
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:5c019ec91d94: avcodec/pgssubdec: Pass AVSubtitleRect to decode_rle()
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:fc7da418ff5d: avcodec/pgssubdec: better error codes
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:066a4819cc1b: avcodec/pgssubdec: Bail out of decode_rle() if error and AV_EF_EXPLODE is set
[18:11] <cone-445> ffmpeg.git 03John Stebbins 07master:0c911c8fbc87: avcodec/pgssubdec: fix end display time
[18:11] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:ae9a73de2a2f: Merge commit '253d0be6a1ecc343d29ff8e1df0ddf961ab9c772'
[18:26] <ubitux> fun, i made dctdnoiz free of the avcodec dep, but it's now almost twice as slow (yeah that's possible...), but the funny thing is that going from 16x16 to 8x8 is like more than 7 times faster
[18:27] <nevcairiel> so its now 3.5 times faster?
[18:29] <J_Darnley> Cripes! What will I replace GetTickCount() with?
[18:29] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:89bcb77726e2: avcodec/pgssubdec: Check input buffer size in parse_presentation_segment()
[18:29] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:e429d6c1971d: avcodec/pgssubdec: remove unused variables
[18:30] <ubitux> nevcairiel: yeah about that
[18:32] <nevcairiel> J_Darnley: there is plenty timing functions, most non-portable, any particular environment you're targetting? :p
[18:33] <J_Darnley> I don't want to replace it with another real time function
[18:34] <J_Darnley> I will replace it with something like a timestamp
[18:39] <J_Darnley> Now... Do I plan ahead and use a 64-bit integers or stick with 32? I guess I will stick with 32 and add 64 to the list of future improvements.
[20:09] <cone-445> ffmpeg.git 03Lukasz Marek 07master:e5c806fd676f: lavd/xv: handle delete window message
[20:41] <iive> ubitux: what codec have 16x16 dct?
[20:46] <cone-445> ffmpeg.git 03Ronald S. Bultje 07master:847bb638c098: swr: convert resample_common/linear_int16_mmx2/sse2 to yasm.
[20:48] <ubitux> iive: vp9? probably hevc too
[20:49] <iive> i know hevc doesn't have asm accelerated dct, so it can't be fast(er)
[20:55] <iive> ubitux: btw, is dctdnoiz works in a way similar to spp, how do they compare in speed?
[21:00] <jamrial> fate is very red right now
[21:11] <Daemon404> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
[21:11] <Daemon404> nice
[21:13] <jamrial> there are like 20 slots failing with libavdevice/xv.c
[21:15] <Daemon404> yeah i saw
[21:15] <Daemon404> theyre all prerelease 4.9 though
[21:15] <Daemon404> and 4.9.0 is known to miscompile ffmpeg
[21:15] <Daemon404> so i am suspicious of gcc
[21:15] <jamrial> the file is missing a {
[21:15] <Daemon404> ah
[21:16] <Daemon404> just a coincidence i saw a slew of 4.9s then
[21:16] <jamrial> yeah, it's just that the rest didn't get to run again just yet
[21:16] <jamrial> the commit that introduced this is recent. less than two hours old
[21:33] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:9efa7f82ce4a: avdevice/xv: fix missing {
[22:31] <ubitux> for a 8-len dct, do we do better than 11 mult and 29 add nowadays?
[22:32] <ubitux> (just wondering if i should look into this: http://www3.matapp.unimib.it/corsi-2007-2008/matematica/istituzioni-di-anal… or if there is a better reference/strategy i should consider)
[22:41] <cone-445> ffmpeg.git 03Muhammad Faiz 07master:46563af79c65: avfilter/showcqt: adding freetype support
[22:47] <michaelni> ubitux, AAN does it in fewer multiplies, also if you dont limit yourself to doing all row transforms and then all column transforns seperately than 8x8 dct can be done with even fewer multiplies IIRC
[22:47] <michaelni> ubitux, see libavcodec/faandct.c
[22:48] <ubitux> isn't aan more approximative than the others?
[22:48] <michaelni> no
[22:48] <michaelni> its exact with real numbers
[22:48] <ubitux> ah, ok
[22:48] <michaelni> or floats more or less
[22:48] <michaelni> with integers it might be less accurate
[22:49] <ubitux> i'm looking for an integer version
[22:51] <michaelni> for 8x8 ?
[22:51] <michaelni> for that using the existing code would make most sense i guess
[22:52] <michaelni> as its optimized
[22:53] <ubitux> i'm actually somehow trying to understand the reasoning behind this common butterfly algorithm
[22:53] <ubitux> so i can apply it to a 16x16
[22:55] <ubitux> ...but strangely i don't see that much documentation on AAN or the other various variants
[22:58] <michaelni> dunno about how it was derived but the 2 obvious pathes i could imagine are to start with a DCT implemented via a FFT or to directly factorize the matrix use din the vector maxtrix multiply that represents the (i)dct
[00:00] --- Tue Jul 1 2014
1
0
[00:28] <josePhoenix> hi all
[02:27] <yawnzi> Hello. I get nothing but immediate segmentation faults when trying to convert files to webm with ffmpeg. libvpx version: 1.3.0 ffmpeg version: 1.0.8
[02:27] <yawnzi> Can anyone shed some light on this?
[05:58] <md_5-> hi
[05:58] <md_5-> I have a series of pngs I neeed to convert to a video, however whatever I do the fps is 25
[05:58] <md_5-> avconv -r 24 -i reconstructed/%d.png -r 24 out.mp4
[06:00] <md_5-> lemme install ffmpeg proper and try
[06:03] <md_5-> aha works with avi+ffmpeg proper
[09:49] <ILEoo> hi, should ffmpeg handle dvb subtitle overlay even if subtitles appear only around middle of ts file?
[10:16] <Mavrik> it probably should
[10:16] <Mavrik> but I doubt it does :)
[10:45] <ILEoo> yep, noticed that too that you can't tell ffmpeg to do overlay if subtitle track isn't present at the beginning
[14:28] <zap0> i have some AVI that i want to convert to MP4 is there a simple just-do-it command line arguments.. i'm not terrible fussed about quality
[14:29] <sfan5> ffmpeg -i input.avi -c copy output.mp4
[14:29] <sfan5> that command will just copy the data from the .avi, no changes to quality
[14:30] <zap0> very much appreciated. thank you.
[14:32] <zap0> is there a -j 8 (use 8 threads) type of thing? that can utiltse more cores to do the work faster?
[14:33] <zap0> -threads 8
[14:33] <zap0> nevermind.
[14:34] <zap0> anyone care to comment on how safe using -threads is ?
[14:34] <sacarasc> Pretty safe, but it won't do anything in the command sfan5 told you.
[14:34] <sacarasc> Because that's just remuxing.
[14:41] <zap0> ok
[14:42] <zap0> does remuxing spend 99% of it's time in disk I/O anyway? so -threads is likely of little value?
[14:45] <sfan5> yes, remuxing is mostly I/O
[14:50] <Mavrik> muxing isn't multithreaded anyway
[15:05] <zap0> ah
[16:00] <chris_> hi all. I am trying to play an RTP stream using ffplay. the stream is an h264 elementary stream for which I have an sdp file locally on my pc. I try with: ffplay stream.sdp - but it just gives me "Invalid data found when processing input" - the same stream/file works with vlc, but I want to build an encoding pipeline with ffmpeg
[16:08] <sfan5> try passing the rtp URL instead of the sdp file
[16:08] <c_14> Or maybe try ffplay rtp://stream.sdp
[16:09] <c_14> Or try forcing the format to rtp so ffmpeg knows what it's dealing with.
[16:09] <chris_> okay thanks, I will try that
[17:05] <Filarius> Hello, I wonder if I can use FFmpeg to fix record of rtmp what done by Livestreamer. Often there is error with video codec or just with header, donno. It looks like video stream just have no info about codec. I found in some kind I can fix it with Avidemux (Windows), but this tool not so friendly to fix files each time.
[17:11] <c_14> Try remuxing the file and see what happens?
[17:22] <Filarius_2> just coping streams not working or I do it in wrone way
[17:26] <Filarius_2> http://pastebin.com/KMEaBSY4
[17:27] <Filarius_2> where I can upload sample with video, if you need it
[17:35] <c_14> Try forcing the video codec, ffmpeg -c:v h264 -i 1.ts -codec copy 1.mkv Not sure if that works, but it's worth a shot.
[17:53] <Filarius_2> not working http://pastebin.com/3ycMNt1z
[17:57] <c_14> What resolution is the video?
[17:57] <c_14> try ffmpeg -c:v h264 -s widthxheight -i 1.ts -codec copy 1.mkv
[17:59] <Filarius_2> "Option video_size not found"
[18:01] <Filarius_2> maybe it`s something about mapping ?
[18:01] <c_14> you can try adding -map 0
[18:02] <c_14> I'm just trying to forcibly override the FFmpeg internal codec settings detection.
[18:03] <Filarius_2> http://pastebin.com/TDEVbDf1
[18:04] <Filarius_2> error
[18:04] <c_14> Try adding the -s widthxheight as an output option with that command.
[18:04] <c_14> I'm gonna go dig through some source code.
[18:05] <Filarius_2> oh, forgot add while looking at memory or sended commands
[18:08] <Filarius_2> nop http://pastebin.com/ybebU5FR
[18:08] <Filarius_2> maybe I can give you example file ?
[18:08] <c_14> sure
[18:09] <Filarius_2> what place would you like me to upload ?
[18:09] <Filarius_2> sorry my english
[18:10] <c_14> Anywhere I can download without having to pay or click ads or stuff.
[18:10] <Filarius_2> heh
[18:12] <Fjorgynn> download what?
[18:13] <c_14> sample video
[18:13] <Filarius_2> https://docs.google.com/file/d/0B4aKhSJbPIe-ckFydmlQdzIxcnM
[18:13] <Fjorgynn> google docs ftw
[18:14] <c_14> Oh, well increasing analyzeduration and probesize to 1G makes ffprobe detect the settings.
[18:15] <Filarius_2> It is not TS file, just how Livestreamer save it
[18:17] <c_14> So this command mostly fixed the file for me: `ffmpeg -analyzeduration 1G -probesize 1G -i 1.ts -codec copy 1.mkv'
[18:17] <c_14> The only thing it doesn't set is the pixel format which isn't _that_ important. The file plays anyway.
[18:19] <Filarius_2> Fjorgynn, sorry, google docs was closest place for me :)
[18:20] <Filarius_2> yey *dancing*
[18:32] <Filarius_2> tested on 3 files, look okay
[18:44] <neosisani> how much sense does it make to start encoding stuff to h265 or some other codec of that generation? Also, is there some good article which compares H265 to H264 in maybe 20 pages or so?
[18:45] <JEEB> do you want a comparison of the format, or current implementations?
[18:45] <JEEB> because those two are pretty different result-wise
[18:46] <neosisani> JEEB if you could summarise differences between format and implementation in two sentences, then format comparison would be prefered
[18:47] <JEEB> HEVC is quite a bit better as a format, but thanks to it being out only for a year+ now, and thanks to the AVC encoders (*cough* x264 *cough*) just being /that/ good, while their development has been faster than with AVC ten years ago, they're still not really having an edge over good AVC encoders
[18:47] <neosisani> i'm interested in format just to keep my knowledge up-to-date and as far as practical considerations are considered, simple: "go for it" or "don
[18:47] <neosisani> i'm interested in format just to keep my knowledge up-to-date and as far as practical considerations are considered, simple: "go for it" or "don't cause it is slow / unstable / no hardware or software support is enough"
[18:48] <sfan5> neosisani: H265 only needs half the bitrate of H264 for the same quality, but be prepared to wait. x265 is not very fast
[18:48] <JEEB> oh boy
[18:48] <neosisani> cool, thanks
[18:48] <sfan5> this might be helpful: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_prep…
[18:48] <JEEB> the numbers with PSNR during HEVC development was ~35% overall (I might find you the actual research papers later)
[18:49] <JEEB> and "probably better when encoders do psyopts", which is where the ~50% number comes from
[18:49] <JEEB> (and a lot of bullshit marketing)
[18:49] <JEEB> anyways, x265 is not developed by the same people as x264, and is based on the reference encoder HM, with random parts being taken from x264 by the indian/chinese cheap labour development teams
[18:50] <sfan5> >by the indian/chinese cheap labour development team
[18:50] <sfan5> [citation needed]
[18:50] <JEEB> uhh
[18:50] <JEEB> you can just look at x265-devel and friends
[18:50] <JEEB> and I've met the single guy from the US
[18:50] <JEEB> at last year's VDD
[18:50] <JEEB> he manages the indian and chinese developer teams
[18:51] <JEEB> some of the guys have finally kind of grasped video coding, I guess
[18:51] <JEEB> but it's still kind of herp and derp at times
[18:51] <JEEB> (unrelated to any country or nationalities, just looking at the patches/commits)
[18:51] <sfan5> https://bitbucket.org/multicoreware/x265/commits/b9bc64443ee4bcfc38c39156c2…
[18:51] <sfan5> # User Satoshi Nakagawa <nakagawa424(a)oki.com>
[18:51] <JEEB> yes, that seems to be the only outsider developer
[18:51] <sfan5> sounds more like japanese
[18:51] <JEEB> not paid by MCW
[18:52] <sfan5> there is also this other HEVC encoder: https://github.com/ultravideo/kvazaar
[18:52] <JEEB> yes, I've poked its code some time ago
[18:52] <JEEB> not that far overall, though
[18:53] <JEEB> x265, while being developed in a derpy way, is currently the least bad alternative (including the proprietary stuff) for HEVC
[18:53] <JEEB> there's also f265 and cclxv
[18:53] <JEEB> aforementioned being yet another company encoder being open sourced (and it actually has some nice documentation), and the latter being just a research/hobby kind of thing
[18:55] <JEEB> anyways, in my latest tests with x265, it's finally kind of getting an edge over x264, but I'd really need to do more tests to say anything for sure. At least it looks better in comparison than in February
[18:55] <sfan5> but it's still slow
[18:55] <JEEB> february had it win when both looked like crap (~415kbps for 720p24), but as soon as you went somewhat upwards x264's psyopts worked way too well
[18:55] <JEEB> of course, although it's way faster than HM :P
[18:56] <neosisani> what is psyopts?
[18:56] <JEEB> psychovisual optimizations
[18:56] <JEEB> in other words, optimization for the eye (more or less), rather than for a metric
[18:57] <neosisani> like mp3 filter banks?
[18:58] <JEEB> anyways, my personal opinion is that I wouldn't use HEVC for anything just yet that I would distribute. I test it around and see if it's finally viable every now and then, but until I'm fully convinced I'm not going to be using it too much
[18:58] <JEEB> that said, at least we're getting useful things quicker than with AVC (albeit some people started using Nero's AVC encoder in like '04, year after the spec came out), so it shouldn't take too long
[18:59] <neosisani> and does hevc get huge benefits from some special hardware support?
[18:59] <neosisani> well not does, but will it eventually?
[18:59] <JEEB> you mean decoding?
[19:00] <neosisani> yes
[19:00] <JEEB> ASICs supporting HEVC are already going out on the market, so I would say that's getting better by the day
[19:00] <sfan5> most devices don't have HEVC HW decoding
[19:00] <neosisani> well not asics but intel / cuda / opencl?
[19:00] <JEEB> uhh
[19:00] <JEEB> that's never worked
[19:01] <JEEB> video decoding is not a job for a GPU
[19:01] <sfan5> intel: libva does not even support hevc; others: see ^
[19:01] <JEEB> which is why everyone puts a specific ASIC there
[19:01] <neosisani> even intel?
[19:01] <JEEB> sfan5, that is an API for ASICs
[19:01] <JEEB> also Intel IIRC already started adding the APIs to its Windows media stuff
[19:01] <sfan5> vaapi is for ASICs?
[19:01] <JEEB> yes
[19:02] <JEEB> all the decoding is done by ASICs
[19:02] <JEEB> if there's rendering/deint that is possibly done with the gPU
[19:02] <JEEB> but the decoding part is done with ASICs
[19:02] <sfan5> ..
[19:03] <sfan5> but the video decode ASICs are inside of the CPU
[19:03] <JEEB> CPU or GPU or whatever, depends on the maker
[19:03] <JEEB> the main point is that nothing right now is decoding video on !ASIC
[19:03] <JEEB> it's just not feasible nor power-friendly
[19:04] <JEEB> GPUs are good for picture stuff, and certain types of highly threadable things that don't have dependencies
[19:04] <JEEB> video decoding is not such a process
[19:06] <JEEB> ok, fine. If you really want to nitpick on the line that says nothing right now is decoding video on !ASIC, then you can. There's supposedly some hardware that does it on an FPGA, but the chances you are going to see such hardware around you are pretty slim. I haven't seen such, either, but some of the high-pricey STBs for 2160p 10bit HEVC broadcasts supposedly have them.
[19:07] <neosisani> GPUs are doubtful for pics decoding since you spend lots of time sending pic to gpu and back
[19:07] <JEEB> well, even if you make that less of a problem, it's just not a problem that you can use the GPU efficiently or
[19:07] <JEEB> *for
[19:07] <JEEB> neosisani, http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Overview.pdf
[19:07] <JEEB> this is a good overview of HEVC btw
[19:08] <JEEB> also this thread @ http://forum.doom9.org/showthread.php?t=167081
[19:09] <neosisani> cool, thanks, i'll read this
[19:11] <neosisani> i think i'm getting blind. ffmpeg converted dvd to h264 and reduced size 10x and I can't spot differences
[19:12] <JEEB> it depends on the material and on the settings you used how much rate it needs to look good
[19:12] <JEEB> not to mention that it depends on your eyes, too
[19:12] <JEEB> and how you watch the content, of course
[19:13] <neosisani> well it is big shot of moving girl. Though i guess all colors that are mostly grayish and fixed background helps.
[19:13] <JEEB> for example, if you are ripping a DVD so that it will then be watched full screen on a 1080p screen of a relatively normal size, that will probably show the artifacts easier than a screen of your mobile phone
[19:14] <neosisani> that too, but it isn't issue here since i'm testing on 24' screen
[19:21] <neosisani> JEEB have you ever tested for fun what happens if you take 3 gig dvd, then transocde to 2 gig divx then transcode to 1 gig h264 then transcode to half gig h265 and then compare that to direct transcoding to h265?
[19:21] <JEEB> why the fuck would you even do that :P
[19:21] <JEEB> generational loss, ho
[19:22] <neosisani> JEEB so that i don't have to keep all dvds just so i could transcode them to something really small in 2050
[19:22] <JEEB> well, if you are going to do that then that's the only thing you can do :P
[19:23] <JEEB> you re-encode the stuff now, and you pretty much are going to have be content with that
[19:30] <kingsob> I have a video created on an iphone, which is inverted... I see the metadata contains "rotate : -0".. but it also has a SAR -1:1 DAR -40:71.. any time I try to encode the video, I get [buffer @ 0x33fdda0] Value -1.000000 for parameter 'pixel_aspect' out of range [0 - 1.79769e+308] [buffer @ 0x33fdda0] Error setting option pixel_aspect to value -1/1.
[19:32] <kingsob> full output is at --> http://pastie.org/9341077
[19:45] <c_14> try adding -vf setsar=1
[19:59] <kingsob> same thing :( http://pastie.org/9341149
[20:00] <kingsob> I have tried removeing the -ve rotation using -codec copy -metadata:s:v:0 rotate=90 which works, but when I try to encode the resuling video, I gte the same error
[20:04] <c_14> try ffmpeg -sar 1 -i file [..]
[20:18] <kingsob> same thing
[20:19] <kingsob> I found using ffmpeg -i ... -c copy -aspect 40:71
[20:19] <SolPenguinz0> Hey all. Anyone here familiar with simplescreenrecorder?
[20:19] <kingsob> produces a valid file I can use
[20:19] <kingsob> it adds an extra step, but its really fast, so I think I can live with this
[22:24] <Rin_Tohsaka> Is it normal to experience around a 3x performance improvement with ffvp9 decoding just due to the presence of SSSE3?
[22:24] <sfan5> are you complaining about ffmpeg being too quick?
[22:26] <Rin_Tohsaka> It'd be more accurate to say that I'm complaining about the performance on my non-SSSE3 AMD CPU
[22:26] <Rin_Tohsaka> but I wasn't meaning it as a complaint anyway
[22:26] <sacarasc> Which CPUs are you comparing?
[22:27] <Rin_Tohsaka> 2.5GHz Brisbane G2 and a 2GHz Merom
[22:27] <Rin_Tohsaka> Brisbane = 65nm Athlon 64 x2
[22:27] <Rin_Tohsaka> Merom = 65nm mobile Core 2
[22:27] <Rin_Tohsaka> *Core 2 Duo
[22:29] <Rin_Tohsaka> my mobo can take up to a Thuban Phenom II x6, but that doesn't even have SSSE3, so I've been hesitant to upgrade the CPU
[22:30] <Rin_Tohsaka> especially since it's a media-focused PC, so low-power and heat is optimal
[22:32] <Rin_Tohsaka> in other words, a Phenom II could probably brute force performance via it's multiple cores, but that's no good if it transforms into Bulldozer in the process
[22:34] <Rin_Tohsaka> oh wait, it's a Merom-2M
[22:35] <Rin_Tohsaka> specifically a T5800
[23:39] <Peter_Occ> I am capturing images to a directory and I want to make videos from the images. The images have sequence numbers and ffmpeg is able to make the videos, However I need to make the video start from a certain time. Is there a simple way to associate the starting
[23:39] <Peter_Occ> sequence number with an exact time?
[00:00] --- Tue Jul 1 2014
1
0