Closed pengqiuyuan closed 8 years ago
What if you split up the inputs, like -f dshow -i video=... -f dshow -i audio=... ?
On Mon, Mar 10, 2014 at 8:26 PM, pengqiuyuan notifications@github.comwrote:
Hello, desktop capture, video is very good, audio will frame dropped!
ffmpeg -f dshow -i video="screen-capture-recorder":audio="virtual-audio-capturer" -vf scale=-1:480 -vcodec libx264 -r 60.97 -acodec libvo_aacenc -vbr 3 -ac 2 -ar 44100 -ab 1900 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f flv "rtmp://192.168.1.50/hls/test"
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37 .
Alone video = screen-capture-recorder, there will be real-time buffer 275% full! Frame dropped!
ffmpeg -f dshow -i video=screen-capture-recorder -vcodec libx264 -vf scale=1366:768 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f flv "rtmp://192.168.1.50/hls/test"
ffmpeg -f dshow -i video=screen-capture-recorder -vcodec libx264 -f flv "rtmp: //192.168.1.50/hls/test" ffmpeg version N-61269-g9a05e8a Copyright (c) 2000-2014 the FFmpeg developers built on Mar 10 2014 22:06:58 with gcc 4.8.2 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp eex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aa cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavp ack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable -zlib libavutil 52. 66.101 / 52. 66.101 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 34.100 / 55. 34.100 libavdevice 55. 11.100 / 55. 11.100 libavfilter 4. 3.100 / 4. 3.100 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, dshow, from 'video=screen-capture-recorder': Duration: N/A, start: 344753.504000, bitrate: N/A Stream #0:0: Video: rawvideo, bgr0, 1366x768, 30 tbr, 10000k tbn, 30 tbc [dshow @ 0000000002a57a40] real-time buffer 275% full! frame dropped! Last message repeated 22 times
Use only audio = virtual-audio-capturer, good ffmpeg -f dshow -i audio=virtual-audio-capturer -acodec libvo_aacenc -f flv "rtmp://192.168.1.50/hls/test"
What if you split up the inputs, like -f dshow -i video=... -f dshow -i audio=... ?
ffmpeg -f dshow -i video=screen-capture-recorder -f dshow -i audio=virtual-audio-capturer -vf scale=1280:720 -vcodec libx264 -acodec libvo_aacenc -f flv "rtmp://192.168.1.50/hls/test"
Thank you very much, now I can Occasional real-time buffer 275% full! Frame dropped!, The sound will frame dropped!
ffmpeg -f dshow -i video=screen-capture-recorder -f dshow -i audio=virtual-audio-capturer -vf scale=1280:720 -vcodec libx264 -r 60.97 -acodec libvo_aacenc -ac 2 -ar 44100 -ab 128 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f flv "rtmp://192.168.1.50/hls/test"
OK with latest zeranoe ffmpeg and combined -i video=X:audio=X does it still drop audio packets?
On Tue, Mar 11, 2014 at 9:35 PM, pengqiuyuan notifications@github.comwrote:
Thank you very much, now I can Occasional real-time buffer 275% full! Frame dropped!, The sound will frame dropped!
ffmpeg -f dshow -i video=screen-capture-recorder -f dshow -i audio=virtual-audio-capturer -vf scale=1280:720 -vcodec libx264 -r 60.97 -acodec libvo_aacenc -ac 2 -ar 44100 -ab 128 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f flv "rtmp://192.168.1.50/hls/test"
[image: image]https://f.cloud.github.com/assets/4953205/2393608/435f2878-a997-11e3-974e-0be93e0740c6.png
[image: image]https://f.cloud.github.com/assets/4953205/2393609/4d38c6ce-a997-11e3-9a7c-d9955cc00a65.png
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-37372531 .
@rdp I got the exact same issue. Running i7 4 cores (8 with virtual) 2.6Ghz and 16 GB DDR3 ram and a descent graphic card.
C:\ffmpeg\ffmpeg_64_static\bin\ffmpeg -r 25 -rtbufsize 2100M -f dshow -i video="screen-capture-recorder" -r 25 -f dshow -i audio="Microphone Array (IDT High Defi" -f dshow -i audio="Rec. Playback (IDT High Definit" -pix_fmt yuv420p -s hd720 -vcodec libx264 -preset ultrafast -b:v 2400k -maxrate 2400k -bufsize 600k -threads 0 -tune zerolatency -f flv "rtmp://live.twitch.tv/app/live_*****_******"
I get:
[dshow @ 00000000003bd8e0] real-time buffer[Microphone Array (IDT High Defi] too full (95% of size: 3041280)! frame dropped!
[dshow @ 00000000029f1860] real-time buffer[Rec. Playback (IDT High Definit] too full (101% of size: 3041280)! frame dropped!
[dshow @ 00000000003be900] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped!
Last message repeated 1 times
[flv @ 0000000012089c60] Failed to update header with correct duration.
[flv @ 0000000012089c60] Failed to update header with correct filesize.
frame= 140 fps=3.7 q=1.0 Lsize= 1363kB time=00:00:05.99 bitrate=1863.3kbits/s
video:1262kB audio:94kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.566206%
[libx264 @ 000000001208a540] frame I:1 Avg QP:29.73 size: 50851
[libx264 @ 000000001208a540] frame P:139 Avg QP: 5.73 size: 8923
[libx264 @ 000000001208a540] mb I I16..4: 100.0% 0.0% 0.0%
[libx264 @ 000000001208a540] mb P I16..4: 0.9% 0.0% 0.0% P16..4: 14.3% 0.0% 0.0% 0.0% 0.0% skip:84.8%
[libx264 @ 000000001208a540] coded y,uvDC,uvAC intra: 27.2% 13.9% 11.6% inter: 6.3% 3.9% 3.5%
[libx264 @ 000000001208a540] i16 v,h,dc,p: 50% 42% 7% 1%
[libx264 @ 000000001208a540] i8c dc,h,v,p: 74% 19% 6% 0%
[libx264 @ 000000001208a540] kb/s:1844.55
Now the message gets repeated anything from 1 to 20 times per second. I've tried everything and i got it down from the absolute worst of 200 per second.
It only happens when i stream to a rtmp:// stream such as twitch.tv, streaming down locally works like a charm.. Got the latest git static 64bit build of ffmpeg and the latest (yesterday) build of screen-capture-recorder :)
Edit: Most settings for screen-capture-recorder is a bit diffuse to me, but the basics are 1920x1080 running 25fps with exluding transparent windows but recording the mouse.
Interesting, I presume cpu is basically "maxed out"? though ffmpeg does sometimes delay sending things...
The good news is that we can see now that, yep, we can now tell that it is indeed dropping audio packets :)
1 thing to try: add a -rtbufsize before your audio inputs
another thing to try (assuming cpu is an issue): lower the frame rate from 25. -r 25
There may be another problem at play here, as well...that on windows ffmpeg doesn't buffer rtmp stuffs on their way out...hmm...we'll explore that one later :)
On Wed, Apr 2, 2014 at 3:50 AM, Anton Hvornum notifications@github.comwrote:
@rdp https://github.com/rdp I got the exact same issue. Running i7 4 cores (8 with virtual) 2.6Ghz and 16 GB DDR3 ram and a descent graphic card.
C:\ffmpeg\ffmpeg_64_static\bin\ffmpeg -r 25 -rtbufsize 2100M -f dshow -i video="screen-capture-recorder" -r 25 -f dshow -i audio="Microphone Array (IDT High Defi" -f dshow -i audio="Rec. Playback (IDT High Definit" -pixfmt yuv420p -s hd720 -vcodec libx264 -preset ultrafast -b:v 2400k -maxrate 2400k -bufsize 600k -threads 0 -tune zerolatency -f flv "rtmp:// live.twitch.tv/app/live**___***"
I get:
[dshow @ 00000000003bd8e0] real-time buffer[Microphone Array (IDT High Defi] too full (95% of size: 3041280)! frame dropped! [dshow @ 00000000029f1860] real-time buffer[Rec. Playback (IDT High Definit] too full (101% of size: 3041280)! frame dropped! [dshow @ 00000000003be900] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped! Last message repeated 1 times [flv @ 0000000012089c60] Failed to update header with correct duration. [flv @ 0000000012089c60] Failed to update header with correct filesize. frame= 140 fps=3.7 q=1.0 Lsize= 1363kB time=00:00:05.99 bitrate=1863.3kbits/s video:1262kB audio:94kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.566206% [libx264 @ 000000001208a540] frame I:1 Avg QP:29.73 size: 50851 [libx264 @ 000000001208a540] frame P:139 Avg QP: 5.73 size: 8923 [libx264 @ 000000001208a540] mb I I16..4: 100.0% 0.0% 0.0% [libx264 @ 000000001208a540] mb P I16..4: 0.9% 0.0% 0.0% P16..4: 14.3% 0.0% 0.0% 0.0% 0.0% skip:84.8% [libx264 @ 000000001208a540] coded y,uvDC,uvAC intra: 27.2% 13.9% 11.6% inter: 6.3% 3.9% 3.5% [libx264 @ 000000001208a540] i16 v,h,dc,p: 50% 42% 7% 1% [libx264 @ 000000001208a540] i8c dc,h,v,p: 74% 19% 6% 0% [libx264 @ 000000001208a540] kb/s:1844.55
Now the message gets repeated anything from 1 to 20 times per second. I've tried everything and i got it down from the absolute worst of 200 per second.
It only happens when i stream to a rtmp:// stream such as twitch.tv, streaming down locally works like a charm.. Got the latest git static 64bit build of ffmpeg and the latest (yesterday) build of screen-capture-recorder :)
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-39310587 .
CPU is at @2% on a isolated core and ~1% on the other ffmpeg process. It's on 5% if i run everything in one process and once every 2 minutes it spikes to 20%, but even on the low ammount of CPU usage it says (using -r 20 and -rtbufsize on all input sources):
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped!
Last message repeated 124 times
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (99% of size: 2100000000)! frame dropped!
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (98% of size: 2100000000)! frame dropped!
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (99% of size: 2100000000)! frame dropped!
Last message repeated 2 times
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped!
Last message repeated 119 times
It's ok to see the
real-time buffer[screen-capture-recorder]
messages since that just means that it's dropping video frames (suspected network can't keep up).
It's the dropping audio, do they still occur?
On Wed, Apr 2, 2014 at 1:38 PM, Anton Hvornum notifications@github.comwrote:
CPU is at @2 https://github.com/2% on a isolated core and ~1% on the other ffmpeg process. It's on 5% if i run everything in one process and once every 2 minutes it spikes to 20%, but even on the low ammount of CPU usage it says:
[dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped! Last message repeated 124 times [dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (99% of size: 2100000000)! frame dropped! [dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (98% of size: 2100000000)! frame dropped! [dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (99% of size: 2100000000)! frame dropped! Last message repeated 2 times [dshow @ 000000000036ec20] real-time buffer[screen-capture-recorder] too full (100% of size: 2100000000)! frame dropped! Last message repeated 119 times
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-39374006 .
Problem is that i see the message to often. It literally makes the video not render on the other end because i'm dropping so many frames.
Audio suffers the same fate, altho when it's working the sound works as well, they sorta go hand in hand. I solved some of the problems by using TCPRelay and piped the encoded stream into a secondary ffmpeg instance which relayed to TCPRelay and i got the video to render at least for a bit.
Then av_interleaved_write_frame(): Invalid argument occured, so now i'm stuck with two problems.. One being that the buffer gets full occationally and the other that the stream breaks because of the interleaved issue...
man that is weird, does ffsplit work? I wonder if compiling an ffmpeg without "--enable-librtmp" would have different results...
On Wed, Apr 2, 2014 at 4:16 PM, Anton Hvornum notifications@github.comwrote:
Problem is that i see the message to often. It literally makes the video not render on the other end because i'm dropping so many frames.
Audio suffers the same fate, altho when it's working the sound works as well, they sorta go hand in hand. I solved some of the problems by using TCPRelay and piped the encoded stream into a secondary ffmpeg instance which relayed to TCPRelay and i got the video to render at least for a bit.
Then av_interleaved_write_frame(): Invalid argumenthttp://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1905&p=6528#p6528occured, so now i'm stuck with two problems.. One being that the buffer gets full occationally and the other that the stream breaks because of the interleaved issue...
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-39390935 .
@rdp Like a clockwork, FFsplit does everything i intended to do with ffmpeg via the command-line. Makes me wonder if i should give up and just use ffsplit :P
are they using a different command line than you? What if you use your commandline and their ffmpeg.exe [I assume they bundle one]?
On Thu, Apr 3, 2014 at 1:36 AM, Anton Hvornum notifications@github.comwrote:
@rdp https://github.com/rdp Like a clockwork, FFsplit does everything i intended to do with ffmpeg via the command-line. Makes me wonder if i should give up and just use ffsplit :P
Reply to this email directly or view it on GitHubhttps://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-39420991 .
(as a note, IIRC ffsplit drops packets all the time, as well, they just use -loglevel panic so that you never see the drop messages, so that in itself may not be the issue)
FFsplit use this for streaming:
ffmpeg.exe" -y -f dshow -f dshow -i video="FFsource" -f dshow -i audio="FFsplit Playback Mixer" -vcodec libx264 -preset veryfast -g 60 -maxrate 2000k -bufsize 2000k -b:v 2000k -x264opts fullrange=on:colorprim=bt709:transfer=bt709:colormatrix=bt709:nal-hrd=cbr -pix_fmt yuv420p -acodec libvo_aacenc -ab 128k -ac 2 -ar 44100 -r 30 -f mpegts \\.\pipe\midpipeIN
fmpeg.exe" -analyzeduration 500000 -y -f mpegts -i \\.\pipe\midpipeOUT -vcodec copy -acodec libvo_aacenc -ab 128k -ac 2 -ar 44100 -flags +bitexact -metadata encoder="FFsplit 0.7.0.23" -f flv "rtmp://127.0.0.1:4759/app/live_50837324_SypWjj7g2x5Lezd5PbCSPG7HtjTlz4 flashver=FMLE/3.0\20(compatible;\20FMSc\201.0)"
dont know why there is 2x audio compression.. but
for problems in first post try use -re
im using this:
"ffmpeg -loglevel warning -re -rtbufsize 1500M -f dshow -i video="UScreenCapture" -f dshow -i audio="virtual-audio-capturer" -c:v libx264 -force_key_frames expr:gte(t,n_forced*2) -b:v 1000k -minrate 1000k -maxrate 1000k -bufsize:v 1000k -preset:v veryfast -pix_fmt yuv420p -tune film -c:a libmp3lame -q:a 2 -ar 44100 -ac 2 -f flv "rtmp://localhost:1935/app/live_27039710_6ONjNDTVXQ5NTYKUINo"
and is ok,
and dont use AAC from official FFMpeg build, mp3 is better at every bitrate
rdp will you add duplicate dekstop
for screen capture on windows 8? Its much faster than blt, no need to kill dwm.exe there http://msdn.microsoft.com/en-us/library/windows/desktop/hh404487%28v=vs.85%29.aspx
you shouldnt' have to use "-re" does it make a difference? typically that should only be used for streaming, say, a file, at wall clock time, not with live input sources...FWIW :)
On Fri, Jul 18, 2014 at 11:31 AM, mca64 notifications@github.com wrote:
FFsplit use this for streaming:
fmpeg.exe" -analyzeduration 500000 -y -f mpegts -i .\pipe\midpipeOUT -vcodec copy -acodec libvo_aacenc -ab 128k -ac 2 -ar 44100 -flags +bitexact -metadata encoder="FFsplit 0.7.0.23" -f flv "rtmp:// 127.0.0.1:4759/app/live_50837324_SypWjj7g2x5Lezd5PbCSPG7HtjTlz4 flashver=FMLE/3.0\20(compatible;\20FMSc\201.0)"
for problems in first psot try use -re im using this: "ffmpeg -loglevel warning -re -rtbufsize 1500M -f dshow -i video="UScreenCapture" -f dshow -i audio="virtual-audio-capturer" -c:v libx264 -force_key_frames expr:gte(t,n_forced*2) -b:v 1000k -minrate 1000k -maxrate 1000k -bufsize:v 1000k -preset:v veryfast -pix_fmt yuv420p -tune film -c:a libmp3lame -q:a 2 -ar 44100 -ac 2 -f flv "rtmp://localhost:1935/app/live_27039710_6ONjNDTVXQ5NTYKUINo"
and is ok,
— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-49457972 .
Did you try to increase the following registry values?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultReceiveWindow"=dword:00010000
"DefaultSendWindow"=dword:00010000
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&start=60#p5527
I found the same issue in this command line-:
ffmpeg -f dshow -i video="screen-capture-recorder" -vcodec libx264 -tune zerolatency -b:v 900k -f mpegts http://localhost:8090
error
> Stream #0:0: Video: rawvideo, bgr0, 1920x1080, 30 fps, 30 tbr, 10000k tbn, 10000k tbc
> [dshow @ 000000000249a8a0] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped!
> Last message repeated 284 times
> http://localhost:8090: Unknown error
> [dshow @ 000000000249a8a0] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped!
This is not an error it just implies you're not able to encode at realtime so it drops some incoming packets.
On Fri, Jun 23, 2017 at 11:15 AM, Palak92 notifications@github.com wrote:
I found the same issue in this command line-: ffmpeg -f dshow -i video="screen-capture-recorder" -vcodec libx264 -tune zerolatency -b:v 900k -f mpegts http://localhost:8090
error
Stream #0:0: Video: rawvideo, bgr0, 1920x1080, 30 fps, 30 tbr, 10000k tbn, 10000k tbc [dshow @ 000000000249a8a0] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped! Last message repeated 284 times http://localhost:8090: Unknown error [dshow @ 000000000249a8a0] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-310723135, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0JosxYnvj395yzRzCMnpQxElgB_Bks5sG_KygaJpZM4Boewv .
Can you please guide me what kind of encoding I should use in real-time to stream video?
I attempted to put some better examples here: https://trac.ffmpeg.org/wiki/StreamingGuide
On Fri, Jun 23, 2017 at 1:30 PM, Palak92 notifications@github.com wrote:
Can you please guide me what kind of encoding I should use in real-time to stream video?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-310753751, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0AG-Vuuc4EV-o6_oVw3llDgwjERjks5sHBJfgaJpZM4Boewv .
I have read them. But no success.
like I tried
$ ffmpeg -y -loglevel warning -f dshow -i video="screen-capture-recorder" -vf crop=690:388:136:0 -r 30 -s 962x388 -threads 2 -vcodec libx264 -vpre baseline -vpre my_ffpreset -f flv rtmp:///live/myStream.sdp
but It saidFile for preset 'baseline' not found
Then I tried streaming a video by http using-:
ffmpeg -f mp4 --video_size 320x240 -r 25 -i screen-capture.mp4 http://localhost:8090/feed1.mp4
But it gave errorUnrecognized option '-video_size'. Error splitting the argument list: Option not found
Even tried this example using http:
ffmpeg -f dshow -i video="screen-capture-recorder" -preset ultrafast -vcodec libx264 -tune zerolatency -b:v 900k -f mpegts http://localhost:8090
it says:
[dshow @ 000000000257a980] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped!
Read through that link carefully. Once you have tried everything on it, let me know...
On Fri, Jun 23, 2017 at 2:09 PM, Palak92 notifications@github.com wrote:
I read them.. But no success.
-
like I tried $ ffmpeg -y -loglevel warning -f dshow -i video="screen-capture-recorder" -vf crop=690:388:136:0 -r 30 -s 962x388 -threads 2 -vcodec libx264 -vpre baseline -vpre my_ffpreset -f flv rtmp:///live/myStream.sdp but It said File for preset 'baseline' not found
- Then I tried streaming a video by http using-: ffmpeg -f mp4 --video_size 320x240 -r 25 -i screen-capture.mp4 http://localhost:8090/feed1.mp4 http://localhost:8090/feed1.mp4 But it gave error
Unrecognized option '-video_size'. Error splitting the argument list: Option not found
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-310761334, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0NrYFLwDP3kAaBCAY886uV8kX8ASks5sHBt_gaJpZM4Boewv .
Hi, I went through the examples thoroughly. I am getting "unknown" error.
command line:ffmpeg -re -i out3.mp4 -c copy -f mpegts http://localhost:8080
error:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'out3.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.73.100
Duration: 00:02:17.40, start: 0.000000, bitrate: 547 kb/s
Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv444p, 1920x1080, 546 kb/s, 10 fps, 10 tbr, 10240 tbn, 20 tbc (default)
Metadata:
handler_name : VideoHandler
http://localhost:8080: Unknown error
The normal documentation may be helpful: https://ffmpeg.org/ffmpeg.html Basically the last thing listed is where it is "sending to" and you don't have a receiving server to receive it there. GL.
On Mon, Jun 26, 2017 at 9:06 AM, Palak92 notifications@github.com wrote:
Hi, I went through the examples thoroughly. I am getting "unknown" error. command line:ffmpeg -re -i out3.mp4 -c copy -f mpegts http://localhost:8080 error: ``` Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'out3.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf57.73.100 Duration: 00:02:17.40, start: 0.000000, bitrate: 547 kb/s Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv444p, 1920x1080, 546 kb/s, 10 fps, 10 tbr, 10240 tbn, 20 tbc (default) Metadata: handler_name : VideoHandler http://localhost:8080: Unknown error
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-311087226, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0LPLWcwH1DS30VRFUTn41ZF5i9hRks5sH8jigaJpZM4Boewv .
I am sending it to http://localhost:8080
which is valid server. Why ffmpeg is not supporting it?
running with -loglevel debug might be helpful. Unfortunately I'm not much help, maybe try on the ffmpeg-user mailing list, good luck!
On Mon, Jun 26, 2017 at 1:11 PM, Palak92 notifications@github.com wrote:
I am sending it to http://localhost:8080 which is valid server. Why ffmpeg is not supporting it?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/37#issuecomment-311153933, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0CKpTJlAf2Ehm4CrTbRxucBvwAU0ks5sIAJQgaJpZM4Boewv .
I will look into that. Thank you for your time
Hello, desktop capture, video is very good, audio will frame dropped!
ffmpeg -f dshow -i video="screen-capture-recorder":audio="virtual-audio-capturer" -vf scale=-1:480 -vcodec libx264 -r 60.97 -acodec libvo_aacenc -vbr 3 -ac 2 -ar 44100 -ab 1900 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f flv "rtmp://192.168.1.50/hls/test"