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

[burek]

[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_preprint.pdf
[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/b9bc64443ee4bcfc38c39156c219a4cf3e5831da/raw/
[18:51] <sfan5> # User Satoshi Nakagawa <nakagawa424 at 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