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

burek burek021 at gmail.com
Sun Dec 28 02:05:01 CET 2014


[00:53] <c_14> v4l2 should be able to tell you, ffprobe should also tell you whatever it picks
[01:49] <fahadash> hello
[01:49] <fahadash> any ffmpeg folk online ?
[02:16] <squeegily> Hey guys. I have an old Acer Aspire laptop I'd like to try to watch anime on. This thing is too slow to play the videos as-is (720p H.264). Any tips for re-encoding?
[02:17] <squeegily> It's OK if it takes up to an hour or two to re-encode, and files up to 1GB per 20 minutes are fine
[02:17] <squeegily> So what can I do to make it look as good as possible
[02:19] <squeegily> I know that the 4 factors in (re)encoding video are finished file size, encoding time, video quality, and decoding ease, and that for the most part those factors can be improved at the cost of each other
[02:19] <squeegily> Speaking generally
[02:28] <squeegily> The only hard limit I have is that a 1.33GHz Atom processor needs to be able to decode it at watching speed. We have as much ENcoding time as we need, and the hard drive space is also pretty much immaterial. So how can I get the least damage to the video with this?
[02:41] <debianuser> squeegily: You can try reencoding it into divx/xvid or other mpeg4 format that is easy to decode (basically `ffmpeg -i file.mkv recoded.avi` would do that with default encoding settings). Do a few experiments, to make sure you like the quality. Check https://trac.ffmpeg.org/wiki/Encode/MPEG-4 to see some quality options (-qscale:v).
[02:42] <squeegily> debianuser: Thanks.
[02:42] <debianuser> squeegily: Another option: configure mplayer on your laptop locally with --extra-cflags="-O3 -march=native" and build it. It should have enough performance to decode 720p h264 in software :)
[02:44] <squeegily> The GPU is a gma500
[02:45] <squeegily> It's supposed to have H.264 acceleration on Linux.. but I have my doubts
[02:45] <squeegily> So DivX is relatively easy to decode?
[02:46] <squeegily> Hehe "the most common usage of Xvid video is currently for older hardware devices. See the H.264 and AAC encoding guides if you are using modern devices. "
[02:46] <squeegily> This sounds perfect ^0^
[02:48] <shevy> guys I have a hypothetical question
[02:48] <shevy> say I have an .avi file - which should have video, and audio. now I wish to add another audio to said video
[02:49] <shevy> do I first have to demultiplex so that I get the raw video, and then add the new audio - or can I directly just add the new audio to that .avi file, and it would replace the existing audio part?
[02:49] <shevy> (I want only one audio track in total btw)
[02:51] <debianuser> squeegily: Actually gma500 supports h264 decoding. I don't remember supported profile, but I did that a few years ago. :) You need a special proprietary "psb" driver (https://wiki.ubuntu.com/PoulsboObsoleteDrivers) specific version ranges of xorg and kernel, and a patched mplayer with vaapi support (I *guess* those are in centos6). But if you manage to match them all - it works.
[02:54] <debianuser> shevy: You can replace the audio track. Something like that: `ffmpeg -i infile.avi -i infile.mp3 -map 0:v -map 1 -c copy outfile.avi` Check -map option: https://trac.ffmpeg.org/wiki/How%20to%20use%20-map%20option
[02:56] <debianuser> squeegily: Ah, debian squeezy may work too. :)
[02:56] <debianuser> *squeeze
[03:00] <squeegily> debianuser: The audio I don't worry about.. I'm actually running "ffmpeg -i ../Joshiraku/[gg]_Joshiraku_-_02v2_[01AC8A77].mkv -c:v libxvid -c:a copy -c:s copy 2.mkv" and we'll see what happens
[03:00] <shevy> hmm
[03:00] <shevy> debianuser ok so in other words, I don't need the additional step of demultiplexing there - I can simply just add the new audio track, right?
[03:01] <squeegily> shevy: I don't think ffmpeg can modify a file in-place
[03:01] <shevy> yeah the old file will be retained I guess
[03:02] <squeegily> shevy: You'll be saved the trouble of re-encoding if you map things correctly (it'll list itself as running at thousands of frames per second since it's literally just copying the streams)
[03:02] <debianuser> shevy: Yes, you can either add one more track or replace existing track in one ffmpeg run, depending on what tracks you select to be copied with -map option.
[03:02] <shevy> debianuser ok cool, thanks man
[03:02] <debianuser> you're welcome. :)
[03:02] <squeegily> debianuser: Wait.. ffmpeg  can modify files in-place?
[03:03] <debianuser> squeegily: Not in place, it would still create a new file. You just can do it in one run
[03:03] <squeegily> debianuser: ffmpeg -i audio -i video output && mv output video
[03:03] <squeegily> You mean like that?
[03:04] <debianuser> squeegily: I mean you don't have to extract video track with first command ("demultiplex") and then combine it with audio track with second command - you can do both in one run.
[03:04] <squeegily> debianuser: Ohh I think I see
[03:04] <squeegily> What's the point of that?
[03:04] <debianuser> of what? ;)
[03:05] <squeegily> Oh wait I thought you meant something else
[03:05] <shevy> squeegily ah I am in the process of building up piped instructions
[03:05] <shevy> squeegily one part goes like this currently:
[03:05] <squeegily> shevy: Yeah the only places you'll need piping with ffmpeg these days is the one corner case involving subtitle conversion
[03:05] <shevy>   assign TheShining.avi | remove audio | add audio bla.mp3
[03:06] <shevy> and when I saw it I was wondering whether I had to really remove the audio
[03:06] <squeegily> shevy: Ohh.. yeah you can do that in one command
[03:06] <shevy> :)
[03:07] <squeegily> I really like MKV as an output format because I can mix Vorpis video and M4A audio without reencoding
[03:07] <squeegily> Or any other mismatches
[03:07] <squeegily> Just  remember that remuxing is awesome
[03:07] <squeegily> Saves CPU and completely lossless
[03:08] <squeegily> I just discovered it recently
[03:08] <squeegily> Blew my mind
[03:08] <shevy> .mkv sounds like a improvement over .avi
[03:09] <squeegily> shevy: The only case where MKVs aren't absolutely suitable is if the video is going to be played on a PS3
[03:09] <squeegily> MKVs are the best thing ever.. It's literally the perfect container format
[03:10] <squeegily> It can accept any number of video, audio, or subtitle tracks, and since it's completely modular, it's forward-compatible so whatever gets invented in the future will still work with it
[03:12] <squeegily> I use them for YouTube rips so I can have the easier to decode, smaller file Webm video with the better quality m4a audio
[03:12] <shevy> hmm
[03:12] <shevy> with YouTube rips, you actually mean you first have to download the video (which I assume will often be a .mp4 file) and the re-encode it into a .mkv file?
[03:13] <shevy> *and then re-encode
[03:13] <squeegily> No.. I download the video-only Webm and the m4a audio and then remux them into an MKV
[03:14] <squeegily> it takes like a second and is literally 100% lossless since nothing gets reencoded
[03:14] <shevy> it's been some years since I last looked into .mkv; back then it did not seem to be as polished, or simply as widespread. like initially I found mostly just .avi and .mpeg files, then .flv and lately very often .mp4 (which I assume usually has h264)
[03:14] <shevy> hmm
[03:14] <shevy> how can you download the video only webm?
[03:14] <squeegily> Check out youtube-d
[03:14] <squeegily> youtube-dl;
[03:14] <shevy> aaaah ok
[03:15] <shevy> I know that, commandline thingy in python right?
[03:15] <squeegily> Try out youtube-dl -F and you'll understand why it's the best
[03:15] <squeegily> Yeah exactly
[03:15] <squeegily> That's how I remember it too
[03:15] <shevy> hmm
[03:15] <shevy> but you will get a single file by default right?
[03:15] <shevy> so I assume you use ffmpeg to split the file?
[03:15] <squeegily> Yes, by default it downloads the MP4 format
[03:15] <shevy> ok I understand finally!
[03:16] <squeegily> Try it out with the -F flag and it will list all the backend ways YouTube lets you download the video in
[03:16] <squeegily> It has an option to automatically use ffmpeg to download and merge two different formats
[03:17] <squeegily> I used the flags --prefer-ffmpeg -f 271+172 -o '%(title)s.mkv' when downloading RWBY
[03:18] <squeegily> I have no idea why --prefer-ffmpeg isn't the default since avconv is really lamee
[03:18] <shevy> oh?
[03:18] <squeegily> But yeah if you just run it on a URL with no flags it will download from YouTube a ready-to-watch MP4 without any further ado
[03:18] <shevy> you mean I can choose which format youtube will give me the file in?
[03:18] <squeegily> Yes, YouTube has several formats available
[03:19] <shevy> cool. I always thought there was just one (the default I use with youtubedl heheheheh)
[03:19] <squeegily> Usually it's an MP4 (video+sound), a lower-quality webm (video+sound) and then a TON of quality options in webm or mp4 (these are video only) and some audio options (I think they're all m4a except 1 webm)
[03:20] <squeegily> So I prefer the webm that's the same quality as the default MP4 muxed with the best quality m4a audio
[03:20] <squeegily> For some reason it seems 1080p video (scaled up?) is available for every video
[03:21] <squeegily> But anyway, after discovering -F it's pretty cool
[03:21] <shevy> for the most part I am interested mostly in audio
[03:21] <squeegily> shevy: You can download the raw audio for e.g., a song which is nice
[03:21] <squeegily> Just a plain .m4a file
[03:22] <shevy> ah
[03:22] <squeegily> I wonder if m4a and mp3 match up like WAV and CDA
[03:22] <shevy> so I could use youtube-dl just to grab the audio directly?
[03:22] <squeegily> Exactly
[03:22] <squeegily> Run it with the -F flag
[03:22] <shevy> my current workflow was like this: get the file through youtube-dl, use ffmpeg to extract the audio through a script :)
[03:22] <squeegily> Wow
[03:22] <squeegily> What's up with pekman
[03:23] <squeegily> He keeps connecting and disconnecting
[03:23] <squeegily> Maybe his wifi is flaky
[03:25] <squeegily> Is it -scale=height:width?
[03:41] Action: debianuser actually came here to ask a question too :)
[03:41] <debianuser> I have 3d half-side-by-side 1280x720 video, how can I reencode it to a single side video? "-vf stereo3d=sbs2l:ml" is not enough, I get just the left half which is displayed as 640x720, while I want to see it as 1280x720. I don't want to actually scale it (that's a last resort), just wanted set some tag to have it scaled by the device playing the file. Is there some option I miss?
[03:43] <squeegily> Whoa
[03:43] <squeegily> I think you're the senior user here
[03:43] <squeegily> You may not get any help from that unless we get the maker of ffmpeg here
[03:44] <debianuser> We have them here. :) They just don't always read this channel. But I can wait.
[03:45] <debianuser> This is a rather active channel, there're IRC channels where I had to wait for a few days before someone who knows the answer would actually come and read my question.
[03:46] <squeegily> Do you have any idea why this is giving an error: ?
[03:46] <squeegily> ffmpeg -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -vf scale=-1:480 -c:v libxvid -vtag xvid -q:v 24 -c:a copy 2.mkv
[03:46] <squeegily> It's the usual "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height"
[03:47] <squeegily> I tried removing the quality option incase it was conflicting with the scale option
[03:47] <squeegily> But it looks like the scale option is not working
[03:47] <debianuser> Try dropping options one by one until you find the one that causes the error. :)
[03:47] <squeegily> It's the scale one
[03:47] <squeegily> The command worked until I added that in
[03:48] <squeegily> I add things one by one for the very reason of diagnosis when one fails
[03:48] <squeegily> The syntax is correct..
[03:48] <debianuser> Try different value then, e.g. 5 instead of 24
[03:49] <squeegily> The quality is fine.. other values of it still cause crashing
[03:49] <squeegily> But it works without the scale filter
[03:49] <squeegily> So the scale filter's crashing it
[03:49] <squeegily> Even if I use the scale without the quality it still crashes
[03:51] <squeegily> But 24 quality is barely tolerable to watch and still isn't easy-to-decode enough
[03:51] <squeegily> I'm going to try 24 quality and 480p so maybe it'll play properly
[03:52] <squeegily> Okay I just ran this and it still failed:
[03:52] <squeegily> ffmpeg -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -vf scale=-1:480 2.mkv
[03:52] <debianuser> Replace -1 with actual number
[03:53] <squeegily> Ah it works
[03:53] <squeegily> Now I just need to calculate 1280/720=x/480
[03:54] <debianuser> 854 :)
[03:54] <squeegily> Thanks
[03:54] <debianuser> But since you're encoding to xvid you don't have to scale, unless the screen of your laptop is 480p ;)
[03:55] <squeegily> The laptop is 1366x768
[03:56] <squeegily> But it can't handle 1280x720 H.264 decoding
[03:56] <squeegily> It's spamming [libxvid @ 0x9b32a40] Invalid pixel aspect ratio 1280/1281, limit is 255/255 reducing
[03:56] <squeegily> So I can't see the progress
[03:56] <squeegily> But I think it's working
[03:57] <squeegily> Trying 853 or 855 make it crash outright
[03:57] <squeegily> made
[03:58] <squeegily> debianuser: I'm scaling since even with xvid killed all the way down to 24 quality (31 is worst) it STILL lags too much to be worth watching
[03:59] <debianuser> squeegily: What about a simple: ffmpeg -t 60 -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv 2.avi
[03:59] <debianuser> (-t 60 is to limit it to first 60 seconds, enough for the test and much faster than encoding entire file)
[04:11] <debianuser> squeegily: Because when even xvid "lags too much" the problem is probably not in your cpu, but in your video output. If you have mplayer there run `mplayer -benchmark -lavdopts threads=2 -vo null -ac null -endpos 120 \[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv` and copy its output to some pastebin, let's see how fast it's decoded.
[04:37] <Dr_Radium> should i use PSNR or sSIM when encoding using x265 ?
[05:36] <squeegily> debianuser: Yeah I usually run it for about 45 seconds worth of film, then ^Z to pause it, then I take a look at it and see if it will work
[05:37] <squeegily> I've tried mplayer with multithreading and even frame dropping and I get about the same results
[05:46] <Zeranoe> Trying to extract subtitles (PGS) to .sup to do a ORC on them. Keep getting "Unable to find a suitable output format...". Output: http://paste.ubuntu.com/9628132/ command: ffmpeg -i "C:\input.m2ts" -an -vn -map 0:3 -c:s copy "C:\output.sup"
[05:48] <squeegily>  Lol on the video 480p quality 24 mplayer 4 threads frambuffer it prints out a huge warning in all caps "YOUR COMPUTER IS TOO SLOW TO PLAY THIS"
[05:49] <squeegily> And it proceeds to lag
[05:50] <squeegily> Wait.. does MPlayer pre-decode the video like buffering it?
[05:51] <squeegily> Because I have always thought that such a thing would be amazing - just pause a video, let it buffer, and then you're ready to playe
[05:51] <squeegily> holy crap where has this been all my LIFE
[05:51] <squeegily> MPlayer has earned a special spot in my heart
[05:56] <Dr_Radium> is x265 much better than x264 ?
[05:58] <Zeranoe> Dr_Radium: In what category?
[05:58] <Dr_Radium> encoder category
[05:59] <Zeranoe> Dr_Radium: Yes, but encoding speed, compression ratio, compatibility... etc
[05:59] <Dr_Radium> compression ratio
[05:59] <Zeranoe> Dr_Radium: It's marginally better
[06:00] <Zeranoe> Dr_Radium: I would not recommend it for anything yet
[06:00] <Dr_Radium> zeranoe why not
[06:01] <Zeranoe> Dr_Radium: encoder speed is horrid. Compression is good, but not substantially better. Very beta source right now
[06:01] <Zeranoe> Dr_Radium: It's more of a proof of concept right now IMO
[06:07] <Zeranoe> Looks like I stumbled on a known bug... https://trac.ffmpeg.org/ticket/2208
[06:12] <squeegily> I managed to get my anime somewhat working with this command, thanks to you all!
[06:12] <squeegily> sudo mplayer -lavdopts threads=4 -vo fbdev2 ~/Videos/Anime/Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -frames 4096 -fs -pp 0
[06:12] <squeegily> It can't handle scenes with too much motion, but at least it works!
[06:14] <Zeranoe> squeegily: no idea what you're doing, but why sudo?
[06:14] <squeegily> Zeranoe: Just to make sure the framebuffer would work
[06:14] <squeegily> It's the 'video' group on Ubuntu?
[06:15] <squeegily> The console is 1366x768 but the video is 1280x720.. mplayer seems to ignore the -fs flag.....
[06:38] <Dr_Radium> what is best aac encoder
[07:14] <Zeranoe> Dr_Radium: FDK-AAC
[07:14] <Dr_Radium> is that better than apple or nero one?
[07:14] <Dr_Radium> or google one
[07:14] <Zeranoe> Dr_Radium: Yes
[07:14] <Zeranoe> Dr_Radium: Is is the "Google one"
[07:15] <Dr_Radium> fdk = frauhofer
[07:15] <Zeranoe> Dr_Radium: Yes, but it's also the library that is included with the android SDK
[07:15] <Zeranoe> if that's what you meant by "google one"
[07:18] <Dr_Radium> no, there is google one
[07:18] <Kei_N> he probably means the vo one
[07:18] <Dr_Radium> there is lib vo
[07:20] <Zeranoe> Dr_Radium: Well yes, it's better than vo
[07:20] <Dr_Radium> what about compared to nero and apple
[07:20] <Zeranoe> Dr_Radium: See https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
[07:21] <Dr_Radium> nero and apple is not listed there
[07:22] <Zeranoe> Dr_Radium: It's better that both, but feel free to run your own tests and find out for yourself
[07:23] <Dr_Radium> what is "opus" never heard of that one
[07:23] <Zeranoe> Dr_Radium: It's not AAC
[07:23] <Dr_Radium> then what is it
[07:25] <Zeranoe> Dr_Radium: I believe it is a variant of ogg, but it specializes in lot latency and bitrate
[07:25] <Dr_Radium> is it bette than vorbis?
[07:26] <Zeranoe> Dr_Radium: Did you read the wiki page?
[07:26] <Dr_Radium> libopus > libfdk_aac = libvorbis > libmp3lame >= libfaac >= eac3/ac3 > aac > libtwolame > vorbis > mp2 > wmav2/wmav1 > libvo_aacenc
[07:26] <Zeranoe> So what does that tell you?
[07:27] <Dr_Radium> google-aac is worst?
[07:27] <Dr_Radium> why is eac3/ac3  ranked so low?
[07:28] <Zeranoe> Dr_Radium: Because at the same bitrate as fdk-aac ac3 and such are worse
[07:28] <Dr_Radium> i see
[07:28] <Dr_Radium> is libfdk-aac new? because i didn't see this before until very recently
[07:29] <Zeranoe> Relatively, probably within the last year
[07:30] <Dr_Radium> why did it took so long
[07:30] <Zeranoe> Dr_Radium: I don't understand the question, AAC has been around for a while
[07:31] <Dr_Radium> zeranoe exactly
[07:31] <Dr_Radium> my point
[07:31] <Zeranoe> ? There have been plenty of other open source AAC encoders
[07:32] <Dr_Radium> what took so long to release fdk one?
[07:33] <Zeranoe> Sorry, but these questions are not worth loosing sleep. I'm heading to bed
[10:45] <t4nk793> How do I split a video into smaller clips? I have this so far: http://pastebin.com/F6MWchYt How does that look in a "for" loop in Microsoft DOS?
[10:48] <Mavrik> t4nk793, first, you have to add -codec copy if you don't want to ruin your quality
[10:48] <Mavrik> second, I have no idea how that looks like in batch script :P
[13:00] <t4nk793> How to escape quotations marks and get back in?
[13:16] <t4nk793> How do I use a wildcard for file input?
[14:33] <debianuser> t4nk793: Don't know about wildcards, I used bash scripts for it, e.g. `ffmpeg $(ls *.mp4 | sed 's/^/-i /') ...` It's not too important, because you have to manually configure mapping for each file usually anyway.
[14:34] <debianuser> By the way, I have 3d half-side-by-side 1280x720 video, how can I reencode it to a single side video? "-vf stereo3d=sbs2l:ml" is not enough, I get just the left half which is displayed as 640x720, while I want to see it as 1280x720. I don't want to actually scale it (that's a last resort), just wanted set some tag to have it scaled by the device playing the file. Is there some option I miss?
[14:54] <rhagu> hi I am checking a lot of mkvs for missing parts or corruptions. This is the command I use: "ffmpeg  -v error -i "$X" -map 0:v -map 0:a -threads 3 -f null -"   and this is a sample of the outputs I get: http://pastebin.com/cwcfTNKX  I am actually looking for files missing parts of the video information due to a corruption in the underlying filesystem, the errors in the pastebin do not seem to be caused by something like this, do they? What do
[15:03] <debianuser> It looks like an error in encoded data, but it's hard to tell if it's caused by the filesystem or it was there from the beginning. (I'm not familiar with those encoding format, can't tell what they mean)
[15:04] <c_14> ye, what I'd probably do is just check for ffmpeg's exit code
[15:05] <c_14> If you know how long the file is supposed to be, you can also check things like the length etc
[15:07] <debianuser> rhagu: If you're checking some downloaded files - you can check for files itself. E.g. there're integrity checksums in torrent file. Or you can do it the other way and just watch the files (especially during those "error" moments). Who cares it's corrupted if it plays fine. :)
[15:15] <rhagu> no torrents, so there is no checksum file
[15:16] <rhagu> it is too many files to watch them to find the errors
[15:19] <c_14> rhagu: what kind of corruption are we talking about here? bit-failures or more like head-crash?
[15:31] <rhagu> c_14 xfs filesystem on zfs volume, the zfs volume was shrunk from 8TB to 6TB and 2 TB of data were lost, then it was set back to 8TB and xfs repaired, so the filesystem does not "see" the missing 2TB, but they are not there anymore, but 6TB of mkv data are still good, some files may not be  affected at all, others partly and some may be gone for good
[15:33] <iive> i don't think you can shrink xfs... at least not with the xfs tools.
[15:37] <rhagu> iive you cannot i shrinked the block device xfs was on, which was the reason I lost 2 TB of data
[15:39] <iive> was it lvm?
[15:40] <rhagu> iive not really, it was a zvol of zfs, I checked if the data can be rescued but the people over at #zfsonlinux told me it can not, so I am trying to figure out which files are still "good" and which need to be replaced
[15:41] <iive> never heard of it, so zfs provides volumens/partitions that could be formatted with another filesystems?
[15:44] <c_14> rhagu: I'd probably just check the fatal loglevel
[15:44] <debianuser> rhagu: How are you going to replace them? Do you have a backup somewhere? I mean maybe you can just compare against that backup?
[15:46] <rhagu> iives yes, they are called zvols and behave like block devices
[15:46] <rhagu> c_14 is there a summary that shows the differences between fatal and error?
[15:47] <rhagu> debianuser they are on blu rays and I would need to reread every one of them
[15:47] <c_14> http://ffmpeg.org/ffmpeg.html
[15:47] <c_14> under loglevel
[15:48] <rhagu> c_14 thanks I will have a look
[15:50] <rhagu> "cannot continue after" seems fine, I will run it with this setting and see, what turns up, may take some time though :-D
[16:15] Action: debianuser still looks for a way to make decoding device show a 640x720 video (got with ffmpeg from 1280x720 video by "-vf stereo3d=sbs2l:ml") as a 1280x720... Shouldn't "stereo3d" filter do that on its own?
[16:34] <c_14> debianuser: it probably should... (at least if my understanding is correct)
[16:38] <JEEBsv> you probably have to actually signal somehow to the device what the content is
[16:39] <JEEBsv> at least x264 has related settings to that
[16:39] <JEEBsv> http://up-cat.net/p/15a661e5
[16:39] <JEEBsv> that's for the x264 command line encoder, you probably will have to use -x264opts or so to set the API-wise setting
[16:40] <JEEBsv> and of course, there is no way to know if the player you'll play your content with will support that specific way of signaling :P
[16:41] <JEEBsv> also if it's the other way (part of side-by-side being encoded), then you will have to make sure the SAR is correct
[16:50] <debianuser> JEEBsv: No, it's the other way around. :) I have a 3d half-side-by-side 1280x720 video and trying to encode it as usual 2d video to play on a regular 2d player. The problem is that after doing "-vf stereo3d=sbs2l:ml" I get a 640x720 video, which looks narrow...
[16:51] <JEEBsv> yes, should then use setsar filter to set a 2:1 SAR
[16:51] <JEEBsv> because the samples should be two times as wide as they are high
[16:52] <debianuser> Trying, thanks! Looking into the docs...
[16:52] <vivan> are planar 10-bit formats (yuv420p10le, yuv422p10le, yuv444p10le) padded to 16 bits (and essentially the same as 16-bit formats)?
[16:53] <JEEBsv> basically they use the 10 least significant bits out of the 16
[16:54] <vivan> thanks
[17:10] <debianuser> Tried "-vf stereo3d=sbs2l:ml,setsar=2/1" - worked for mplayer, but not for targetted hardware player. I guess it does not support non-square pixels... Unless there's some other option that I forgot to set.
[17:12] <JEEBsv> yeh, hw shit can fail in various ways although usually the ways that ffmpeg sets should work in most things
[17:12] <JEEBsv> my condolences if your shit is not one of those
[17:13] <JEEBsv> I guess you can just use the scale filter to scale to 2x the width
[17:13] <JEEBsv> (this is usually the less preferred way to do it because you're creating unnecessary data
[17:18] <MaximLevitsky> I implemented simple encoder using ffmpeg, but resulting mp4 files don't play well in some players, including totem, OSX quicktime,windows media player
[17:18] <MaximLevitsky> Could you take a look, at what I do wrong?
[17:18] <MaximLevitsky> https://github.com/maximlevitsky/animations-editor-bdmorph/blob/master/utils/ffmpeg_encoder.cpp
[19:09] <t4nk910> hi guys
[19:11] <t4nk910> is there any known issue for mp4 video to go black (something like 85% opacity) for a few seconds in chrome/ff and then get back to normal?
[19:11] <pzich> at a particular time? or periodically?
[19:11] <t4nk910> periodically
[19:12] <t4nk910> and not always..
[19:12] <debianuser> MaximLevitsky: Check compatibility section of https://trac.ffmpeg.org/wiki/Encode/H.264
[19:12] <pzich> not always meaning not for every video, or for different playbacks of the same video?
[19:12] <t4nk910> for example for me the video loads ok, but for my friends sometimes they get this issue
[19:12] <pzich> ah, hmm
[19:13] <pzich> and this is Chrome and FF, not Chrome vs FF?
[19:13] <t4nk910> yes, chrome and ff
[19:13] <t4nk910> they experienced the issue in these 2 browsers..
[19:16] <t4nk910> pzich: yes, for different playbacks of the same video
[19:23] <AlexRussia> hey
[19:23] <AlexRussia> if i have cue file with metadata and flac with tracks, can i split flac by metadate in cue?
[19:23] <AlexRussia> metadata*
[19:26] <pzich> well, googling "ffmpeg cue file" brings up this: https://bbs.archlinux.org/viewtopic.php?pid=702289
[19:26] <pzich> looks like maybe not with ffmpeg, but shntool can?
[19:28] <AlexRussia> pzich: yep, looks like shntool is what i need
[19:29] <AlexRussia> pzich: i just prefer live people than search machine :)
[19:29] <AlexRussia> pzich: i thought, isn't complicated question xD
[19:29] <pzich> we prefer search machine first, then machines are doing the work instead of other people :)
[19:30] Action: c_14 doesn't mind if you ask dead people first
[19:30] <AlexRussia> pzich: just i can reask ppl about misunderstanding parts, with static text i can't do it :P
[19:31] <AlexRussia> c_14: xD
[19:32] <AlexRussia> re-ask*
[20:07] <shevy> got a question
[20:07] <shevy> when I chop off the first 5 minutes of an .avi file, I must re-encode the full movie, and hence will lose quality?
[20:10] <JEEBsv> in theory if you can do it properly with that format, you could encode the required GOPs
[20:11] <JEEBsv> and stitch them to the rest of the GOPs
[20:11] <JEEBsv> but
[20:11] <JEEBsv> 1) not automagically supported in ffmpeg 2) not sure if even applicable with your formats
[20:14] <debianuser> shevy: Actually I *think* it should work: ffmpeg -ss 300 -i fullfile.avi -map 0 -c copy chopfile.avi
[20:15] <debianuser> (at least a similar idea worked in mencoder a few years ago, so why shouldn't it work in ffmpeg...)
[20:17] <shevy> ah ok
[20:19] <JEEBsv> yeah, if you can cut right on the GOP and that's OK then that should work
[20:20] <JEEBsv> but as soon as as the GOP points are not on that very point you start getting a difference
[20:21] <mnewton> Hey guys, codec question. I have a file that has the following codec information. What's codec should I use that will be optimized for the web (that is fast - about 1 min per 100mb) Video: h264 (avc1 / 0x31637661), yuv420p, 640x480 [SAR 39:40 DAR 13:10], q=2-31, 135 kb/s, 10 fps, 10240 tbn, 10 tbc (default) Audio: aac (mp4a / 0x6134706D), 22050 Hz, mono, 32 kb/s (default)
[20:22] <mnewton> What would the ffmpeg command look like. Sorry I dont have much idea about codes or ffmpegs - i just want to make some lecture videos avilable on s3 for streaming and the file size if huge even though it is low quality
[20:30] <iive> mnewton: hum? the line you pasted shows that the video bitrate is 135kb/s, so that's about 8MB for 1 minute
[20:31] <mnewton> iive, okay - i meant that processing 100mb should take about 1 min when converting
[20:31] <mnewton> Is 8MB for 1 min decent for web?
[20:32] <iive> 1mbps (mega bits per second) is usually good quality for SDTV (720x576x25)
[20:32] <iive> you can probably go lower, since you have smaller resolution and framerate.
[20:32] <mnewton> okay
[20:33] <mnewton> what should I try?
[20:33] <mnewton> it is a .m4v file
[20:33] <iive> avc (advanced video coding) is also know as H264. it is quite good and widely supported codec.
[20:34] <iive> ffmpeg uses libx264 for encoding in this format. imho that's the best encoder that there is.
[20:34] <mnewton> isn't it already in it? Video: h264 (avc1 / 0x31637661)
[20:35] <brontosaurusrex> mnewton: not by default, thats probably a container
[20:36] <brontosaurusrex> or rather "format"
[20:36] <mnewton> okay - so how do I convert it?
[20:37] <iive> ffmpeg -i <input_file> -c copy -c:v libx264 -crf 24 -preset fast <output>.mp4
[20:40] <iive> hum....
[20:40] <iive> kb/s is kbps
[20:41] <iive> sorry for the confusion.
[20:41] <iive> the video is 135kbps, not 1000kbps, it is already insanely low.
[20:42] <iive> same for the audio. 128kbps is plenty for 44kHz stereo, you have 22kHz mono, that is 32kbps.
[20:42] <iive> I don't think you can get lower than these
[20:44] <mnewton> ok
[20:49] <mnewton> how do i get it from a m4v container to a mp4 container
[20:51] <brontosaurusrex> mnewton: thats the same thing, just rename
[21:16] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler"
[21:19] <Fjorgynn> let there be cake
[23:17] <lm_> Hi. I need of help
[23:18] <lm_> Hello!
[23:18] <c_14> Don't we all.
[23:19] <lm_> How enable suport to libmp3lame in ffmpeg?
[23:19] <c_14> --enable-libmp3lame
[23:19] <c_14> probably
[23:19] <lm_> not work
[23:20] <c_14> error?
[23:20] <lm_> ERROR: libmp3lame >= 3.98.3 not found
[23:20] <c_14> Is it installed?
[23:21] <lm_> Yes. I have LAME 64bits version 3.99.5
[23:21] <c_14> distro?
[23:22] <lm_> linux mint 17.1 64 bit
[23:25] <c_14> Did you install the -dev version?
[23:25] <lm_> not
[23:25] <c_14> install it and try again
[23:26] <lm_> OK.
[23:32] <lm_> Has worked
[23:32] <lm_> Thank's
[00:00] --- Sun Dec 28 2014


More information about the Ffmpeg-devel-irc mailing list