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

[burek]

[00:01] <thinktink> :(
[00:07] <Datalink> http://illogicallabs.com/paste/00000008.txt I managed to get to the point where the error is no longer IO but is an auth issue... anyone here familiar with Akama's streaming server??
[00:07] <Datalink> they're using Flash Media Server with some specific auth I think
[01:04] <luc4> Anyone here experiencing interruptions on audio transcoded to ac3?
[01:29] <shoop_da_whoop>  I'm having an issue transcoding an mpegts created with mythtv. The first keyframe is missing from the output file. However, the frame is present in both vlc, and a transcode created via vlc. I'm assuming that the problem lies in the video codec parameters. Here's a pastebin with the command line and ffmpeg output. http://pastebin.com/T9KTrwQw 
[01:29] <shoop_da_whoop> VLC decodes and plays the file properly. http://pastebin.com/RDDeqYin
[01:29] <jure> you asked that question a couple of hours ago
[01:30] <jure> and were gone after 15 mins
[01:57] <shoop_da_whoop> jure: my laptop had died and my irc client lost the connection. do u have any ideas about my problem?
[01:59] <jure> 1. you're not technically transcoding the fil e, you're merely remuxing it
[01:59] <jure> 2. you are ostensibly remuxing to matroska (.mkv), yet your output is named "output.mp4".
[02:00] <jure> which means your output does not correspond to your input command line, which means there's something you're not telling us
[02:03] <jure> ^ shoop_da_whoop
[02:14] <shoop_da_whoop> jure: The mp4 was another remux test with the exact same parameters. Here's the correction. http://pastebin.com/fEFYusFX
[02:21] <jure> I think it's a bug in ffmpeg's muxer.
[02:22] <jure> (de)muxer
[02:33] <jure> try -c:a ac3 instead of -acodec copy
[02:39] <jure> ffmpeg -i input.mpg -r 29.97 -s 720x480 -c:v copy -c:a ac3 output.mkv
[02:40] <jure> ^ shoop_da_whoop
[02:53] <shoop_da_whoop> jure: No dice, the first frame is still missing and there is an a/v sync issue. Also, VLC reports the input frame rate as 59.94, while ffmpeg reports 29.97 fps. I've also tried ffmpeg -r 59.94 -i input.mpg -r 29.97 -s 720x480 -c:v copy -c:a ac3 output.mkv
[02:54] <shoop_da_whoop> But to no avail.
[02:54] <shoop_da_whoop> jure: Should I send you a sample of the file?
[02:59] <JustAnotherUser> Is there a way to increase the bitrate on a stream captured from a webcam?
[03:00] <JustAnotherUser> This is what I am using. And I don't know where it sets quality in it: ffmpeg -y -f dshow -s 640x480 -r 60 -rtbufsize 3000k -i video="PS3Eye Camera" out.mp4
[10:06] <Keshl> How do I rescale videos, oÉo? -s 1280x720 doesn't like me.
[10:06] <Keshl> Neither does -s 1280:720
[10:09] <Keshl> Oh, got it. Typo. Was doing -mov_flags rather than -movflags before. <É< Nevermind. -s 1280x720 works fine.
[10:09] <sco__> i am streaming an MJPEG video from an rtp source to an rtmp server, here is the paste of the code and the Output http://pastebin.com/SSmRApze
[10:15] <sco__> I tried to also stream from and older version of ffmpeg. here is the paste of the command and the output http://pastebin.com/ayh1Yq8c. what do I need to do?
[14:17] <Mattias> I'm trying to get rotation data from quicktime, I'm using php with getID3() to get all data from a video. QuickTime can automatically rotate the video no matter how you record the video (upside down or whatever). I can't find a single variable which would have that data. Has anyone successfully gotten the rotation from a mov file before? I need it so I can rotate the video correctly when converting. Unle
[14:17] <Mattias> ss ffmpeg can somehow figure that out automatically?
[14:22] <braincracker> ffmpeg knows php ?
[14:33] <Mattias> braincracker, well, if ffmpeg itself knows how to get rotation data then correctly rotate it, I'll use that
[14:38] <Mattias> braincracker, found http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/mov.c;h=133dd89509384a7b70e22153619580fc9489c70c;hp=06b2f87b0db06ecd2db5850b0159dd4faede6ef3;hb=62d2a75b024bf72e6f3648e33c5bb5baf9018358;hpb=6813450209bab97c30e8b25a018cdc4c936b224a :)
[17:36] <Fieldy> i'm using the following command in 1.2.2. when I play the video with vlc, it appears to play twice as fast as was recorded. trying to figure out what I'm doing wrong:
[17:36] <Fieldy> ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 25 -s 1920x1050 -i :0.0+0,30 -acodec pcm_s16le -vcodec libx264 -threads auto -preset:v ultrafast -qp 24 -sc_threshold -1 /tmp/video.mkv
[17:38] <jure> -r 10
[17:38] <Fieldy> ok, gonna look at the docs to see what -r does
[17:39] <mittens> whats with "ultrafast" ?
[17:39] <jure> so you're using stuff you don't understand? good going
[17:39] <Fieldy> honestly i don't even know, it's such a mashup of commands (trying to capture a video of a game fullscreen)
[17:39] <Fieldy> many suggestions from many people
[17:39] <jure> it's like firing a gun you've never held in your hands before
[17:39] <Fieldy> i did just say i was going to read. no need to be a cock.
[17:40] <Fieldy> i'll back up, my goal is to capture a good quality video of a game I'm playing. i've no problem with starting over
[17:44] <Fieldy> ah okay i see now, during recording it's saying fps=14, so the player is probably trying at about 24, hence apparent speed doubling
[17:46] <jure> 1920x1050 :snicker:
[17:46] <Fieldy> you are unhelpful and only offer insults
[17:47] <Fieldy> but yes, i don't want my menu bar etc captured. hence that and the shift
[17:48] <Fieldy> read up on -r which is supposed to set framrate. set the one in the command to 24 and added another -r 24 as seen in the man page just before the output file name. still records at 14 fps. removed the first -r 24 leaving the second one, same thing.
[17:49] <cbsrobot> Fieldy: what happens if you omit both -r 24 ?
[17:49] <jure> your PC. not good enough.
[17:50] <cbsrobot> Fieldy: and here's also some info: http://trac.ffmpeg.org/wiki/How%20to%20grab%20the%20desktop%20%28screen%29%20with%20FFmpeg
[17:50] <jure> oh, I think he's read that
[17:50] <jure> his command is almost a carbon copy of the one there
[17:51] <Fieldy> cbsrobot: i'll try that and I'll read, just a moment, thank you for the response
[17:51] <cbsrobot> Fieldy: and btw:
[17:51] <Fieldy> can do
[17:52] <Fieldy> good url. i believe that's where I started, and kept tacking on stuff until it became the monster it is now. without any -r, it's recording at 14fps. i'm going to restart my command based on that page
[17:59] <Fieldy> cbsrobot: based on that I came up with another command, though i get errors: http://pastie.org/pastes/8239354/text
[18:07] <jure> [flv @ 0xa66720] FLV does not support sample rate 48000, choose from (44100, 22050, 11025)
[18:07] <jure> gee, I wonder what was wrong with -r 10 ...
[18:12] <cbsrobot> well set -ar 44100
[18:14] <Fieldy> thanks
[19:57] <guest1234> are there any options to ffmpeg to get information  (bitrate, duration, format) about an input file  in structured way (like -f ffmetadata) or do I have to parse that information from stderr?
[20:00] <sacarasc> guest1234: You could use a programme such as mediainfo to do this. (It's available on Windows, *nix and OS X, in CLI and GUI forms.)
[20:02] <guest1234> actually, it seems that ffprobe does exactly what I want
[20:02] <guest1234> just found that
[20:02] <guest1234> thanks for the suggestion though!
[22:11] <luc4> Hi! Anyone who recently transcoded from aac to ac3?
[22:56] <jure> why, are there issues?
[23:06] <luc4> jure: yes, I transcoded a video as I commonly do, but it seems that for some reason the result has audio interruptions.
[23:08] <luc4> jure: I'm not able to understand whether this is related to the player or ffmpeg...
[23:08] <sacarasc> Try a different player!¬
[23:09] <luc4> sacarasc: yes, that is the problem. The player I'm using is vlc. The only other player I have is quicktime, but it never plays the audio of the video produced by ffmpeg for some reason. What other player should I use?
[23:09] <jure> vlc works remarkably well with bad content
[23:10] <jure> so your ffmpeg-produced output must be really bad
[23:10] <jure> question: why transcode aac to ac3?
[23:11] <luc4> jure: yes, vlc should not be the issue. This is the output: http://paste.kde.org/pbeb5c7e2/. I see nothing strange.
[23:12] <luc4> jure: it confuses me that I experience the issue with mp4 and mpv, but not with mkv...
[23:12] <luc4> *mpv = mov sorry
[23:13] <jure> probably because ffmpeg muxes ac3 badly with mp4
[23:13] <luc4> jure: why not? ac3 is more compatible with many players.
[23:13] <luc4> jure: should I report this as a bug then?
[23:14] <jure> no.
[23:14] <luc4> jure: I have to say I frequently do this conversion and I never experienced this.
[23:14] <jure> you are unnecessarily introducing loss by transcoding audio
[23:14] <jure> why not use -c:a copy
[23:15] <luc4> jure: as I said, it seems to me ac3 is more portable. Especially to desk players.
[23:16] <luc4> jure: anyway, is this the expected behavior? Interruptions?
[23:16] <jure> no, but it could be due to bad container format / bad timecodes
[23:16] <jure> I'm not sure a 16kHz sample rate is even officially supported by AC3
[23:17] <jure> you could also play around with vsync
[23:19] <jure> try -ar 32000
[23:19] <jure> so: ffmpeg -i input.mp4 -c:v libx264 -preset veryslow -crf 22 -c:a ac3 -ar 32000 -threads 4 output.mp4
[23:20] <jure> ^ luc4
[23:20] <luc4> jure: it is not a problem for me, I could also transcode to mkv or avoid audio transcoding. Just wanted to know if it is a good idea to report to contribute to ffmpeg or not...
[23:20] <jure> it's not ffmpeg's fault when people flaunt standards
[23:21] <luc4> jure: exactly, I didn't know that. If this is not the case I won't pollute with a wrong report.
[23:21] <jure> right
[23:21] <luc4> that's why I aked here first
[23:21] <jure> but try anyway with -ar 32000, see if it works
[23:33] <luc4> jure: it works perfectly
[23:33] <luc4> jure: thanks
[23:34] <luc4> jure: wouldn't it be good to log a warning in such cases?
[23:35] <jure> np, luc4. and indeed, it would be. personally, I'd even make it error out in case the rate doesn't match the standard.
[23:36] <luc4> jure: can I report this as a "wish" or similar?
[23:37] <mark4o> luc4: original AC-3 supported only 32k, 44.1k, and 48k but I think lower sample rates were added in a later revision
[23:37] <mark4o> but many players do not support those
[23:39] <luc4> mark4o: interesting, I was reading the wikipedia article on ac3 but I can only see the max frequency. Anyway, as I suppose vlc is still using ffmpeg, in either cases there might be some possible improvements?
[23:39] <mark4o> does the file play using ffplay?
[23:42] <mark4o> I am able to play ac3 with 16k sample rate in ffplay and in vlc
[23:42] <luc4> let me check
[23:42] <mark4o> maybe you have an old version
[23:42] <luc4> of what?
[23:43] <mark4o> vlc
[23:43] <luc4> 2.0.7 for mac os
[23:43] <luc4> should be the latest
[23:44] <mark4o> 2.0.7 for mac os x works for me
[23:44] <luc4> and I've just built ffmpeg with its dependencies from the git
[23:44] <luc4> I didn't even think of ffplay :-) just a second and I'll try to play it
[23:46] <luc4> ffplay plays it perfectly
[23:47] <luc4> So only related to vlc. It means my suspect was correct and I'm in the wrong place possibly :-) sorry
[23:48] <luc4> thank you guys
[23:48] <mark4o> maybe vlc 2.0.8 works
[23:49] <luc4> maybe not stable yet?
[23:49] <mark4o> 2.0.8 was released a few weeks ago
[23:49] <luc4> checking for updates on mac reports 2.0.7 to be the latest...
[23:51] <luc4> but it seems it is actually not...
[00:00] --- Fri Aug 16 2013