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

[burek]

[01:52] <luc4> Hello! I re-encoded a mpeg2 video to h265 but what I get is a larger video. Why can this happen?
[01:52] <c_14> Magic.
[01:52] <c_14> Otherwise known as your bitrate is too high.
[01:53] <luc4> c_14: checked that. Bitrate was 10Mbit, now it is 6Mbit.
[01:53] <luc4> Should I set it to a lower value?
[01:53] <c_14> Audio tracks?
[01:53] <c_14> What's your command?
[01:54] <luc4> Yes, it was mp2. I transcoded to ac3.
[01:54] <PovAddict> same bitrate?
[01:56] <luc4> yes
[01:56] <luc4> I mean, the audio track has the same bitrate as the original one.
[01:56] <luc4> ffmpeg -i HPIM0758.MPG -vcodec libx265 -preset veryslow -x265-params crf=18 -acodec ac3 HPIM0758.mkv
[01:57] <luc4> This is the command I used.
[02:01] <c_14> Maybe the bitrate calculation isn't working, try encoding vbv ?
[02:02] <luc4> c_14: vbv?
[02:02] <c_14> variable-bitrate video
[02:02] <c_14> ie -b:v
[02:06] <luc4> c_14: you mean I should add -vbr to something like 3?
[02:07] <c_14> Nah, just try switching from cbr to setting a target bitrate.
[02:07] <c_14> Bitrate calculations have always been rather fishy.
[02:07] <c_14> If you pick a bitrate manually, you can ensure that it'll be smaller.
[02:07] <luc4> c_14: ah, so you mean the resulting file should be cbr correct?
[02:08] <PovAddict> huh, was he using cbr?
[02:08] <c_14> eh s/cbr/crf
[02:08] <c_14> For my earlier one.
[02:09] <PovAddict> is there anything like crf for mpeg2 video?
[02:09] <c_14> luc4: that is what I'd probably try, yes
[02:09] <luc4> c_14: trying that already. Ill see the result. Thanks then!
[02:11] <luc4> What bitrate should I use. From what I read half or two third of the origin may be appropriate. Correct?
[02:12] <PovAddict> you want the same quality as the original?
[02:12] <luc4> If possible yes, more or less.
[02:12] <PovAddict> or do you have a target file size?
[02:12] <luc4> No target file size.
[02:14] <luc4> The idea is just that transcoding those old files to h265 I may gain a little in size for the same quality.
[02:14] <c_14> I'd probably start around 2/3 to 1/2, play around with it.
[02:14] <luc4> c_14: ok, thanks!
[02:20] <PovAddict> I transcoded a pile of videos to h264 and deleted the originals already :(
[02:20] <PovAddict> well, the real-originals are 8mm video tape, but I'm *not* going back to those again :)
[02:51] <PovAddict> man, making a dvd menu is such a pain in the ass
[07:17] <evilwombat> Hello. I own a popular consumer video camera which produces MP4 files that are otherwise valid, but cause mplayer (well, actually, libavformat.so) to spew warnings of "Non-increasing DTS in stream blah-blahlbhah" for several minutes before playback actually begins.
[07:18] <evilwombat> The warnings themselves are not that big a deal, but the associated delay in playback is rather annoying. Attempting to play a 5-minute clip results in a delay of several minutes while these warnings are spewed. Piping them to /dev/null doesn't help with the delay, either.
[07:19] <evilwombat> What can I do here? Should I report a bug someplace, along with sample video? Or is there a flag that can suppress this check for monotonically-increasing time values?
[11:39] <luc4> Hello! I have a few mpeg video files, which contain mpeg2 video and mp2 audio streams. I thought I may get better compression by using h265 but after transcoding I get a file size which is larger or equal to the original. Original bitrate is 10Mbit/s while h265 bitrate is 6Mbit/s. Any idea why compression is not higher?
[11:41] <Mavrik> well, that's because you set the desired bitrate to be 6Mbit/s.
[11:46] <luc4> Mavrik: should I set it lower?
[11:46] <luc4> Mavrik: to get a more or less identical quality I mean.
[11:50] <edoardo> hi!
[11:51] <edoardo> i'm trying to stream a concert in a theatre to a near bar
[11:51] <edoardo> i'm using ffmpeg as a client to connect to a mplayer istance listening for connections and it works allright
[11:51] <edoardo> however, the quality is awful and uses a lot of bandwidth
[11:51] <edoardo> ffmpeg -i web.mp4 -f mpegts tcp://192.168.1.23:2000
[11:52] <edoardo> is it possible to use h264 or libvpx to lower the bitrate? in 1080p the stream is unwatchable and it uses 4mbit of bandwidth
[12:06] <ChocolateArmpits> edoardo: h264 will be a better choice in this case. You can try changing the profile to High, increase gop, setting the preset setting to "slower". For relatively static content at 1080p I would expect 2mbps to be a good starting point. If however there is a lot of motion, scene change happening more bandwith will be required anyways
[12:07] <edoardo> ChocolateArmpits: but how do i stream in h264?
[12:07] <edoardo> -f h264 doesn't work
[12:07] <edoardo> neither libx264
[12:08] <ChocolateArmpits> "-f" defines wrapper format
[12:08] <ChocolateArmpits> h264 is a codec format
[12:08] <ChocolateArmpits> x264 is an encoder
[12:08] <edoardo> oh!
[12:08] <edoardo> so i need -f:v?
[12:08] <ChocolateArmpits> to define the encoder you use "-vcodec" for video codec
[12:08] <edoardo> or -v:f, can't remember
[12:08] <ChocolateArmpits> "-acodec" for audio codec
[12:09] <edoardo> perfect, what about libx264 vs libvpx? what's better?
[12:09] <ChocolateArmpits> If you want to check available codecs and wrapper formats use "ffmpeg -encoders" and "ffmpeg -formats" respectively
[12:09] <ChocolateArmpits> x264 by a huge margin, unless you're using a less system intensive baseline profile
[12:10] <edoardo> i'll use x264 then
[12:10] <edoardo> aac for audio?
[12:10] <edoardo> i always use that for uploading to youtube, but i don't know if it's suitable for a stream
[12:10] <ChocolateArmpits> Again, AAC is a codec standard, to encode in that standard you have multiple encoders with different names
[12:12] <ChocolateArmpits> For example Zeranoe build of Ffmpeg contains two aac encoders. "AAC" and "Libvo_aacenc"
[12:12] <ChocolateArmpits> If I believe right "AAC" requires experimental tags, so "Libvo_aacenc" will probably be more suited for this
[12:14] <ChocolateArmpits> Your command line should probably look like this "ffmpeg -i $input -vcodec libx264 -profile:v high -preset slower -b:v 2500k -g 100 -acodec libvo_aacenc -b:a 384k -f mpegts $output"
[12:18] <edoardo> ChocolateArmpits: why -preset slower?
[12:19] <edoardo> nevermind, it works perfectly
[12:19] <ChocolateArmpits> edoardo: http://mewiki.project357.com/wiki/X264_Settings#preset
[12:21] <ChocolateArmpits> Compared to medium, the default one, compression efficiency should increase by about 15%
[12:21] <edoardo> perfect
[12:21] <edoardo> if the pc handles it, i'll use that one
[12:21] <ChocolateArmpits> However if your system can't handle it try changing it to a faster one
[12:21] <edoardo> what's -g 100?
[12:21] <ChocolateArmpits> GoP size
[12:21] <ChocolateArmpits> Group of Pictures
[12:22] <ChocolateArmpits> http://en.wikipedia.org/wiki/Group_of_pictures
[12:22] <edoardo> oh, the full image thing
[12:22] <edoardo> each 100 images one if full, the other are based on the full one
[12:22] <ChocolateArmpits> Sorta
[12:22] <ChocolateArmpits> There are different frame types so they act differently
[12:23] <ChocolateArmpits> Usually you should set the gop to 2 seconds when streaming, that is your framerate multiplied by 2
[12:24] <ChocolateArmpits> If your framerate is at 25 fps then setting gop to 50 would be appropriate from streaming standpoint
[12:24] <edoardo> 30fps here
[12:24] <ChocolateArmpits> However if you want to conserve bandwith increasing it past that is a good solution but only if you have a stable connection at both sides
[12:24] <edoardo> the connection is like this: pc -> router -> pc
[12:25] <edoardo> so it should be fairly stable
[12:27] <ChocolateArmpits> edoardo: any more questions?
[12:27] <edoardo> no :)
[12:27] <edoardo> streaming right now a 1080p video and the computer that's struggling is the receiver
[12:28] <edoardo> -f scale=1024:-1 solved everything :)
[12:28] <edoardo> also, with a bitrate of 2m the image quality is very high with no visual artifacts whatsoever
[12:30] <ChocolateArmpits> "-f scale "? ??
[12:30] <ChocolateArmpits> Are you sure it's not -vf scale /
[12:30] <ChocolateArmpits> ?
[12:30] <edoardo> yes, my bad
[12:30] <edoardo> it was a typo
[12:31] <edoardo> so the final command is
[12:31] <edoardo> ffmpeg -re -i test.mp4 -vcodec libx264 -profile:v high -preset veryfast -b:v 2000k -g 100 -acodec libvo_aacenc -vf scale=1280:-1 -b:a 128k -f mpegts tcp://192.168.1.23:2000
[12:31] <edoardo> i get a delay of 6 secs, so that's fairly good
[12:32] <ChocolateArmpits> If it's a concert I would increase audio bitrate
[12:32] <edoardo> isn't aac very efficient?
[12:32] <edoardo> also, is the -b:a total or per channel?
[12:34] <ChocolateArmpits> Total, there's no such thing as "per channel", "per track" maybe
[12:34] <edoardo> isn't a stereo stream a two channel stream?
[12:35] <ChocolateArmpits> A track is composed of either two channels or a one mono channel
[12:35] <ChocolateArmpits> In terms of formats it's one essence stream
[12:36] <ChocolateArmpits> If you have multiple stereo tracks you have multiple audio essence streams
[12:36] <ChocolateArmpits> Depending on the format each essence stream can have different settings, length, channel count, bitrate or even encoding
[12:37] <edoardo> so, you can have multiple "tracks" each composed of one or more channels?
[12:37] <edoardo> and these tracks can have different codecs, bitrates....
[12:37] <ChocolateArmpits> Or more depending on channel system, say 4.1 can have 5 channels in one track
[12:38] <edoardo> cool
[12:38] <ChocolateArmpits> Depending on the format the same 4.1 system can be separated into 5 mono tracks
[12:39] <ChocolateArmpits> It's can get pretty messy and I'm not really that familiar with this yet
[12:39] <ChocolateArmpits> it*
[12:39] <ChocolateArmpits> As for the audio bitrate I would increase it more
[12:39] <edoardo> yes, i'm testing right now and i can hear some losses
[12:39] <ChocolateArmpits> Compared to how much you're using for video alone, trying to conserve on audio is not the best idea
[12:39] <edoardo> i'm trying to transmit with opus
[12:40] <edoardo> ...and it doesn't work :)
[12:40] <edoardo> i'll stick to aac then
[12:41] <ChocolateArmpits> There is a patch to libav for opus support in mpegts. It should probably get into ffmpeg sometime in the future
[12:42] <ChocolateArmpits> Mpegts standard was also updated for opus support https://twitter.com/obencoder/status/482548498467155968
[12:42] <edoardo> yeah!
[12:43] <edoardo> i would really like to use opus to stream, i can get amazing results with only 128k of bitrate
[12:54] <luc4> Hello! Im transcoding to h265 and I see this output: x265 [info]: Main profile, Level-3 (Main tier). Can I use a higher level to improve compression?
[12:54] <edoardo> luc4: -profile:v high maybe?
[12:57] <luc4> edoardo: will that provide better compression?
[12:58] <edoardo> luc4: yes
[12:58] <edoardo> brb/afk
[12:59] <luc4> edoardo: Ill try that, thanks.
[13:13] <JEEB> edoardo, there is no high profile in HEVC
[13:16] <JEEB> (also setting the profile higher than the encoder sets in libx264 does not lead to better compression either)
[13:16] <ChocolateArmpits> Does Ffmpeg use any type of dithering when changing pixel format (for example from 16bpp to 8bpp) ?
[13:20] <luc4> JEEB: I thought so. But I dont clearly understand how it is possible that transcoding mpeg2 to h265 results in a larger file& Probably because of bitrate, but I set 6000k from 10000k and yet the file is not smaller...
[13:24] <JEEB> well, multiple possibilities there: 1) you miscalculated the overall bit rate of the original file 2) libx265 fails with ABR encoding (it's a very volatile project)
[13:24] <JEEB> personally I would not use any HEVC encoder yet for real use cases, except if you are aiming for very, very low bit rate
[13:27] <JEEB> because that's the only use case where in my testing libx265 can "beat" libx264. In which case the picture from both will suck, but HEVC sucks a bit less.
[13:28] <JEEB> of course, this is with preset placebo and all those bells and jingles
[13:28] <JEEB> so not exactly quick
[13:29] <JEEB> as soon as you start wanting good compression on a nice picture quality level, libx265 is still not good enough with psychovisual optimizations
[13:30] <luc4> JEEB: I see, but the same happened to me with h264.
[13:30] <luc4> JEEB: Ill try with this sample and see the result.
[13:31] <luc4> JEEB: thanks for the information.
[13:31] <JEEB> sounds like you are just missetting or misusing something. Feel free to pastebin your full command line and terminal output of that command line and link it here
[13:32] <JEEB> because libx264 is by now rather stable and it does exactly what you set
[13:34] <luc4> JEEB: this is what Im testing now: http://paste.kde.org/pyb0pvwdr
[13:34] <luc4> JEEB: but I previously tried not setting -b:v at all and setting to 6000.
[13:35] <JEEB> not setting it at all is a default that is different for every encoder
[13:35] <luc4> JEEB: by setting 6000k I got a file which was nearly as large as the original.
[13:35] <JEEB> x264 had it at crf 23
[13:36] <JEEB> luc4, using bit rate based encoding, esp. with a single pass is probably rather broken in libx265 :P at least I definitely wouldn't be surprised if it was
[13:36] <luc4> JEEB: in the h264 guide I real crf 18 should be almost no quality loss.
[13:36] <JEEB> that is not a definitive value
[13:36] <luc4> JEEB: ah I see.
[13:36] <JEEB> you start from 23 and go up if it looks good already, and down if it looks bad
[13:36] <JEEB> and thus you see which value is the highest still looking good for you for that kind of content
[13:36] <JEEB> that is the idea of CRF
[13:37] <luc4> JEEB: ok then. But should I keep -b:v or crf takes that into account?
[13:37] <JEEB> they are incompatible settings, you can't set an average bit rate and a rate factor at the same time
[13:38] <JEEB> also, the range of CRF values is completely different with libx265, so if you're going to be using that, you'll probably have to find the initial value from around 28 or so ? Not sure
[13:41] <JEEB> anyways, I recommend going for x264 in general for this kind of usage
[13:41] <JEEB> x265 is just too volatile for my use
[13:41] <JEEB> not to mention that in all of my tests as soon as you leave the "very low bit rate" scenario
[13:41] <JEEB> x265 is the one starting to lose :P
[13:42] <JEEB> maybe in the future x265 is going to be better, but not now
[13:42] <luc4> JEEB: sure, Ill stay with h264. I was just starting to test h265 as Im reading a lot about it and I was anxious to give it a try.
[13:42] <JEEB> yeah, HEVC as a standard is nice
[13:43] <JEEB> too bad it'll take time for the implementations to become good :)
[13:43] <JEEB> or well, let's just say that libx264 being so good doesn't make them look good even if they were kind of alright now
[13:43] <JEEB> because they'd still have to beat libx264, which is kind of awesomesauce as far as an implementation goes
[13:43] <luc4> JEEB: but happened to me something similar with h264. mp2 video resulted smaller in size than h264 after transcoding. So I thought it was me again doing something wrong.
[13:44] <JEEB> yes, with x264 that option is a bigger one
[13:44] <JEEB> so you most probably miscalculated the original file's average bit rate and set the rate control to a too big of a value
[13:44] <luc4> JEEB: ah possible, as I understand ffprobe does not always compute the bitrate correctly.
[13:45] <JEEB> personally I haven't used bit rate based encoding in quite a while, and if one is to use such it's much better to do it wish -pass 1 and -pass 2
[13:45] <JEEB> *with
[13:45] <JEEB> single pass ABR is only for streaming scenarios, and even there I'd rather use CRF ;)
[13:46] <JEEB> (with VBV limitations)
[13:46] <rcombs> CRF :D
[13:46] <luc4> JEEB: so I should go with crf and also -pass 2?
[13:46] <JEEB> no, CRF is single pass only
[13:46] <luc4> ah ok
[13:46] <JEEB> so you don't need to set any -pass there
[13:46] <JEEB> you only set -pass 1 with the first pass and -pass 2 with the second when using bit rate based ABR
[13:46] <JEEB> (and yes, you have to run ffmpeg twice)
[13:47] <luc4> Ill try with crf then and see what I get. Thanks for the info!
[13:47] <JEEB> well, as I said
[13:47] <JEEB> crf is something you will have to tweak yourself
[13:48] <JEEB> <JEEB> you start from 23 and go up if it looks good already, and down if it looks bad
[13:48] <JEEB> <JEEB> and thus you see which value is the highest still looking good for you for that kind of content
[13:48] <JEEB> <JEEB> that is the idea of CRF
[13:48] <JEEB> and thus you will find the exact compression rate you can get with those compression settings to gain the quality level you want
[13:48] <JEEB> and then you can use the CRF value with similar content
[13:49] <JEEB> if you go for completely different content (resolution, frame rate etc.), then you might have to tweak the value somewhat
[13:49] <JEEB> for example for higher resolution content you generally don't zoom it in as much when watching so you can use a higher crf value, and so forth
[13:51] <rcombs> and if your audience is OCD you say "fuck it", set -crf 15, and end up with huge files
[17:06] <BlackDream> I have created an application that takes the output of ffmpeg (mpegts/flv or any other output) and streaming it to a port, then the clients can connect to it
[17:06] <BlackDream> The command is as follows
[17:07] <BlackDream> ffmpeg -i "stream_link" -codec copy -f mpegts - | server -p 20000
[17:07] <BlackDream> It works fine, however, i'm unable to create duplicate outputs using this
[17:07] <BlackDream> For example if i want to duplicate flv and mpegts how i will do it :/
[17:08] <BlackDream> I saw that: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#no1 however this comes to pipes and it's a bit hard its not the same
[17:14] <sacarasc> BlackDream: How about using a named pipe and using server with that instead... Something like mkfifo cheese.ts && ffmpeg -i "stream_link" -codec copy -f mpegts cheese.ts -f copy keeping.ts -f copy keeping.flv & server -p 20000
[17:15] <sacarasc> mkfifo cheese.ts && ffmpeg -i "stream_link" -codec copy -f mpegts cheese.ts -f copy keeping.ts -f copy keeping.flv & server -p 20000 cheese.ts
[17:15] <sacarasc> That, even.
[17:19] <BlackDream> wait to investigate it :P
[17:33] <kaotiko> hi
[17:58] <binni> How do I convert a video using the libx264 codec but NOT touch the audio, keep it as it is?
[17:59] <binni> I have: avconv -i video1.mp4 -vcodec libx264 -b:v 3000k -maxrate 3000k -bufsize 3000k video1-quality.mp4
[17:59] <binni> but it decides to convert the audio aswell
[17:59] <binni> Stream #0:1 -> #0:1 (aac (native) -> aac (libvo_aacenc))
[18:00] <foonix> -c:a copy
[18:01] <binni> foonix, thank you!
[18:13] <zenny> Hi, was reading this: "https://trac.ffmpeg.org/wiki/How to concatenate (join%2C merge) media". But my situation is a bit different than what the script at the bottom of the page describes. I need to add a video (including audio) each in the beginning and end of a certain video. What should be the tweak to achieve? Thanks!
[18:14] <c_14> just use the concat demuxer?
[18:14] <c_14> file video1\nfile video2\nfile video3
[18:19] <zenny> c_14: Thanks!
[19:49] <pappi> hello. i'm trying to force the use of --hwaccel vdpau in ffmpeg. any tips on how to deal with this?
[19:56] <BtbN> Pass --hwaccel vdpau on the command line.
[20:42] <antranigv> Greetings, I'd like to convert an .webm video to .ogg audio, any CLI help ? thanks in advance!
[20:44] <JEEB> webm files tend to have either opus or vorbis audio, and both in theory should go into the ogg container, I guess?
[20:44] <JEEB> so ffmpeg -i welp.webm -map 0:a -c copy out.ogg
[20:44] <JEEB> try this
[20:45] <JEEB> -map 0:a selects the audio track(s) from the input
[20:45] <JEEB> -c copy sets "codec" to copy, which copies the input track
[20:45] <JEEB> out.ogg creates an ogg file
[20:46] <antranigv> JEEB it worked! thanks ! I was looking for this for 2-3 hours :D
[21:58] <ChocolateArmpits> Is there a way to check if a source is true 10 bit and not 8bit resampled to 10bits ?
[21:59] <JEEB> no
[22:00] <JEEB> because a "true 10bit source" might not be using the full range of values (as in, have similar steps to 8bit content), and 8bit content could be debanded after being bit shifted to 10bit range of values (in which case there would be steps using 10bit steps to all of their potential)
[22:03] <ChocolateArmpits> JEEB: but it would be extremely unlikey for real life shot material to have 8bit stepping matching if it was downsampled from whatever the sensor captured down to 10 bits ?
[22:03] <ChocolateArmpits> Unless shooting artifical charts
[22:05] <JEEB> if specific to real life material straight out of a camera, then I guess. But I still wouldn't be able to trust the thing based upon a single picture, you'd have to push through a whole clip and have a heuristic based on it
[22:06] <ChocolateArmpits> So I guess only a gradient chart could be used for truthful testing ?
[23:44] <kevmitch> what's the difference between bbox and cropdetect filters?
[23:58] <kevmitch> and what exactly does dejudder do? I thought pullup restored the original film frames. Is that not the case?
[00:00] --- Mon Oct 20 2014