Re: [FFmpeg-user] kmsgrab on Intel 8th generation aka h/w accelerated screen capture

[Kai Hendry]

Thanks for the sudo setcap cap_sys_admin+ep /path/to/ffmpeg tip. It
indeed works.

https://github.com/kaihendry/recordmydesktop2.0/commits/kms

Unfortunately kmsgrab seems to lag for me:
https://s.natalian.org/2018-06-26/1529976937.mp4

And sometimes is unreliable:
https://s.natalian.org/2018-06-26/moov-atom-not-found.log (leaving me
with an unplayable file)

I guess screen capture to mp4 is just too risky.

The most reliable method for screen capturing on Archlinux for me is:
1) https://github.com/kaihendry/recordmydesktop2.0/blob/nodrop/x11capture to mkv
2) https://github.com/kaihendry/recordmydesktop2.0/blob/nodrop/htmlvideo
to get that mkv to mp4

Really was hoping to get it to one step and leverage my 8th gen Intel
gizmos. Sigh.

Or is there some other format that is safe to record to that FCPX will
be able to grok even if abruptly terminated?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] x11grab segfault when display is closed

[Carl Eugen Hoyos]

2018-06-22 17:03 GMT+02:00, Matt Garman :

> # ./ffmpeg -an -f x11grab -framerate 10 -video_size 1280x1024 -i :13
> /tmp/cap.mp4
>
> If I stop ffmpeg before that display is closed, I get a nice video, exactly
> as expected.
>
> However, if ffmpeg is still running when the display (:13 in the above
> command) is closed, ffmpeg segfaults.

Please provide backtrace, disassembly and register dump to
allow us to debug the issue you see.

Thank you, Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] kmsgrab on Intel 8th generation aka h/w accelerated screen capture

[Mark Thompson]

On 25/06/18 10:42, Moritz Barsnick wrote:
> On Mon, Jun 25, 2018 at 09:10:29 +0800, Kai Hendry wrote:
>> However since kmsgrab requires CAP_SYS_ADMIN as it points out to its
>> friendly documentation
>> https://www.ffmpeg.org/ffmpeg-devices.html#kmsgrab I believe I need to
>> run it with `sudo`.
> 
> Actually, the documentation says: "If you don’t understand what all of
> that means, you probably don’t want this." ;-)
> 
> My understanding (<- that's a disclaimer ;-)):
> 
> CAP_SYS_ADMIN is a Linux capability. Such a capability is something you
> (or the system administrator) grants a program. In effect, this
> particular capability is somewhat like root permissions, but sudo just
> won't suffice anymore, a program *must* have this capability in order
> to access DRM (which kmsgrab uses). I consider this unfortunate, that a
> program has to be granted general CAP_SYS_ADMIN, but *sigh*.

The test you need to pass for kmsgrab to work is here: 
.

When capturing inside X, the X server is already the DRM master (which has the 
Highlander nature) and therefore you need to have CAP_SYS_ADMIN instead to pass 
the test.  (It isn't needed in all cases - for example, you can capture the 
text console and some framebuffer programs without CAP_SYS_ADMIN because they 
do not take DRM master.)  The root user always has CAP_SYS_ADMIN, so sudo is 
always sufficient to allow kmsgrab to work.

For the pulse side of this, I believe the problem is that the pulseaudio daemon 
enforces that you can't record output owned by a different user.  Recording 
under sudo therefore doesn't work, because root is not the same user as you.  
You might be able to overcome this with some configuration setting for 
pulseaudio, but I'm not sure exactly what that will be.

With that in mind:

> Here you find an explanation of how to grant such a capability:
> https://stackoverflow.com/q/26504457/3974309
> 
> Basically:
> $ sudo setcap cap_sys_admin+ep /path/to/ffmpeg
> 
> Afterwards, run ffmpeg *without* sudo.

I expect this answer will work, because you get CAP_SYS_ADMIN for kmsgrab but 
are still your own user for pulseaudio.

Thanks,

- Mark
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] fMP4 generation speed

[Carl Zwanzig]

On 6/25/2018 2:41 PM, Carl Eugen Hoyos wrote:

2018-06-25 15:02 GMT+02:00, Ronak:

1. Apple does not create temp files

Isn't that generally a disadvantage?


Why would it be (not creating temp files)? Seems sensible from here.

A better question is why, it appears, is ffmpeg making temp files and where 
does it put them? If the files are created in the CWD and that's on a 
spinning drive, it's going to be slow; OTOH if they're created in /tmp and 
that's in a memory-resident file system it won't be much slower than just 
keeping large buffers.


Anyway, different drives for source and output files is usually a very good 
idea, as is a memory-resident /tmp file system (assuming you have the memory 
to hold it). Another option is turn off atime on those file systems; 
updating that can take up a lot of time and usually isn't useful.


Phil- I'm not sure I agree with you about temp files (in general), a lot 
depends on the what/where/how-many files are being used.


Later,

z!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] fMP4 generation speed

[Phil Rhodes]

 



On Monday, 25 June 2018, 22:41:42 BST, Carl Eugen Hoyos  
wrote:


>2018-06-25 15:02 GMT+02:00, Ronak :

>> 1. Apple does not create temp files

>Isn't that generally a disadvantage?
In an environment where people may be dealing with very large amounts of data, 
creating temp files is bad.
Phil  
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Adaptive Streaming between heaac and lcaac

[Carl Eugen Hoyos]

2018-06-25 14:37 GMT+02:00, Ronak :

> Another interesting thing I saw is that their generated fMP4s don't include
> sidx boxes, since the stream is audio only created from an AAC file.
> Why does ffmpeg include sidx boxes? Can those be removed?

You can test "-movflags -global_sidx"

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] fMP4 generation speed

[Carl Eugen Hoyos]

2018-06-25 15:02 GMT+02:00, Ronak :

> 1. Apple does not create temp files

Isn't that generally a disadvantage?

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] fMP4 generation speed

[Carl Eugen Hoyos]

2018-06-22 21:53 GMT+02:00, Ronak :
>
>
>> On Jun 20, 2018, at 4:48 PM, Carl Eugen Hoyos  wrote:
>>
>> 2018-06-20 18:37 GMT+02:00, Ronak :
>>
>>> That command took the following time:
>>>
>>> real3m19.316s
>>> user3m14.730s
>>> sys 0m1.830s
>>>
>>> I'm curious about your thoughts on this. With -codec copy, the decoder
>>> should not be involved, so it shouldn't be a bottleneck.
>>
>> Yes.
>>
>>> I'm wondering if the extra file I/O is the culprit here?
>>
>> Yes.
>>
>> You can now specify "-loglevel verbose" to get some useful
>> I/O info at the end of the console output.

> [AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
> [AVIOContext @ 0x2310e80] Statistics: 0 seeks, 2107 writeouts
> [AVIOContext @ 0x22c72c0] Statistics: 541488832 bytes read, 2 seeks

This indicates that nothing absurd with regard to seeking happens.

Try with different drives for input and output to make sure we know
the culprit.

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Adaptive Streaming between heaac and lcaac

[Moritz Barsnick]

On Mon, Jun 25, 2018 at 08:37:05 -0400, Ronak wrote:
> >>> HEAACv2 44khz/32kbps
> >>> HEAACv2 44/64
> >>> LCAAC 44/128
> >>> LCAAC 44/256
> >>> LCAAC 44/320
> I ran Apple's HLS mediafilesegmenter tool, and I can confirm that they set 
> 1024 for the defaultSampleDurations in all moof segments for HE-AACv2 mp4s.
> 
> Can this be fixed in ffmpeg? I'm happy to send a patch to the devel mailing 
> list to correct this.

I assume you're using libfdk_aac for these? Or MacOSX's AudioToolBox?

It's really much more informative if you show us an actual command line
and the command's complete, uncut console output.

That said, I tried to understand fdk_aac's code, and it does seem it
makes some differentiation between LC and HE there - whether or not
correct I cannot tell. I believe it is *not* ffmpeg doing this.

> Another interesting thing I saw is that their generated fMP4s don't
> include sidx boxes, since the stream is audio only created from an
> AAC file. Why does ffmpeg include sidx boxes? Can those be removed?

I don't know much about MOV/MP4/fMP4 and atoms. I couldn't find
anything forbidding sidx though. If you think this is incorrect, or
inconvenient, please wait for other answers from fMP$ experts, or file
a bug ticket (if incorrect) or a feature ticket (if inconvenient, i.e.
you wish a flag to disable it), on https://trac.ffmpeg.org/

It would be good if you add a reference to some specification
describing the requirements more clearly.

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Hls Variable Substitution

[Ronak Patel]

Hi,

I was curious if ffmpeg has plans to support hlsv8 generation.

The ability to do variable substitution in manifest is huge and can really help 
reduce manifest sizes.

Ronak

Sent from my iPhone
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] fMP4 generation speed

[Ronak]

> On Jun 23, 2018, at 12:07 AM, Ronak  wrote:
> 
> 
> 
>> On Jun 22, 2018, at 7:59 PM, Ronak Patel  wrote:
>> 
>> 
>>> On Jun 22, 2018, at 5:03 PM, Carl Zwanzig  wrote:
>>> 
 On 6/22/2018 1:37 PM, Ronak wrote:
 We have audio files that are more than 100 hours long, and we need them
 to be fragmented quickly. It totally seems like there's an I/O problem
 here because fragmentation is faster the longer we set our fragment size
 to.
>>> Sounds like it's time to break out iostat or sar (or even dtrace) and do 
>>> some snooping.
>>> 
>>> Are you reading and writing to different drives?  (The usual metric for a 
>>> spinning drive is 150 IOPS for random access, RAID doesn't necessarily 
>>> speed that up.)
>>> 
>> 
>> Nope it’s the same disk that we’re reading and writing to. I’m really 
>> curious why we can’t just buffer fragments in ram and write them out in 
>> larger bursts. Why not make this an option we can set?
>> 
>> This would simulate the performance for a 10 sec fragment size.
>> 
>> I’d imagine you have the same reading buffer regardless of the fragment size.
>> 
>> I’m thinking of running this on even more powerful machines to see if I can 
>> get the times down. But is it possible to get an option to tweak the output 
>> buffer size?
>> 
> 
> The problem is probably because of this:
> 
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.m4s' for reading
> [dash @ 0x7f92cd005600] Opening 'test_60_hr_10sec.mpd.tmp' for writing
> [dash @ 0x7f92cd005600] Opening 'media_0.m3u8.tmp' for writing
> 
> Ffmpeg constantly makes this tmp files, and seems to be opening and closing 
> the file handles constantly.
> Is there a way to just keep the main files open and just keep appending to 
> it? Why make temp files at all?
> 

I just tested Apple's segmentation tools: mediafilesegmenter, and I can confirm 
that a 26 hour file took only:

real1m35.576s
user1m32.617s
sys 0m29.705s

time to fragment on a 2015 Macbook Pro 2.2 GHz, 16 GB of RAM.

The big differences I see are:

1. Apple does not create temp files nor open & close file handles repeatedly.
2. Apple does not write out sidx boxes, only moof for these fMP4 files. It 
seems like sidx boxes are not required when the content only contains audio. Is 
this true? Can ffmpeg be configured to skip generating them?
3. Apple's fragmentation is consistent. Every single fragment has exactly the 
same duration.
4. Apple sets the defaultSampleDuration in the moof atoms to 1024 for HE-AACv2 
streams, the same as LC-AAC at the same sampling rate. 

I would like to see how I can fix these 4 flaws in ffmpeg

Can anyone please give me pointers on which source files to look at and 
pointers on how to make these code changes?
I'd like to submit patches for these issues soon.

Thanks,

Ronak

>>> Later,
>>> 
>>> z!
>>> ___
>>> ffmpeg-user mailing list
>>> ffmpeg-user@ffmpeg.org 
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 
>>> 
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-user-requ...@ffmpeg.org  with 
>>> subject "unsubscribe".
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 
> 
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-user 

Re: [FFmpeg-user] Adaptive Streaming between heaac and lcaac

[Ronak]

> On Jun 22, 2018, at 4:45 PM, Ronak  wrote:
> 
> 
> 
>>> Hi,
>>> 
>>> We are trying to setup an adaptive stream across two heaac streams and 
>>> higher order lcaac ones.
>>> 
>>> So we’d have something like so:
>>> 
>>> HEAACv2 44khz/32kbps
>>> HEAACv2 44/64
>>> LCAAC 44/128
>>> LCAAC 44/256
>>> LCAAC 44/320
>>> 
>>> I setup a test stream this way and I’m seeing some problems.
>>> 
>>> Exoplayer is seeing this stream as not being able to support seamless 
>>> adaptive switching because the defaultSampleDurations in the HE-AACv2 
>>> fMP4's moof boxes is 2048 while the LC-AAC file has 1024.
>>> 
>>> Why does HE-AACv2 have a higher sample duration when the sampling rate is 
>>> supposed to be 44100, equivalent to the sampling rate of the LC-AAC audio?
>>> 
>> 
>> 
>> Has anyone ever tried to do this before? Is this a problem with how ffmpeg 
>> is generating the HEAACv2 fmp4 files?
>> 
>> 
> 
> 
> Could anyone please shed any light on why the defaultSampleDurations in moof 
> are different between LC & HE-AAC at the same sampling rates?
> 
> 

I ran Apple's HLS mediafilesegmenter tool, and I can confirm that they set 1024 
for the defaultSampleDurations in all moof segments for HE-AACv2 mp4s.

Can this be fixed in ffmpeg? I'm happy to send a patch to the devel mailing 
list to correct this.


Another interesting thing I saw is that their generated fMP4s don't include 
sidx boxes, since the stream is audio only created from an AAC file. 
Why does ffmpeg include sidx boxes? Can those be removed?

> 
>>> Thanks,
>>> 
>>> Ronak
>>> ___
>>> ffmpeg-user mailing list
>>> ffmpeg-user@ffmpeg.org 
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 
>>> 
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-user-requ...@ffmpeg.org  with 
>>> subject "unsubscribe".
>> 
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org 
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 
>> 
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-requ...@ffmpeg.org  with 
>> subject "unsubscribe".
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] kmsgrab on Intel 8th generation aka h/w accelerated screen capture

[Moritz Barsnick]

On Mon, Jun 25, 2018 at 09:10:29 +0800, Kai Hendry wrote:
> However since kmsgrab requires CAP_SYS_ADMIN as it points out to its
> friendly documentation
> https://www.ffmpeg.org/ffmpeg-devices.html#kmsgrab I believe I need to
> run it with `sudo`.

Actually, the documentation says: "If you don’t understand what all of
that means, you probably don’t want this." ;-)

My understanding (<- that's a disclaimer ;-)):

CAP_SYS_ADMIN is a Linux capability. Such a capability is something you
(or the system administrator) grants a program. In effect, this
particular capability is somewhat like root permissions, but sudo just
won't suffice anymore, a program *must* have this capability in order
to access DRM (which kmsgrab uses). I consider this unfortunate, that a
program has to be granted general CAP_SYS_ADMIN, but *sigh*.

Here you find an explanation of how to grant such a capability:
https://stackoverflow.com/q/26504457/3974309

Basically:
$ sudo setcap cap_sys_admin+ep /path/to/ffmpeg

Afterwards, run ffmpeg *without* sudo.

Hope this helps,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Upscaling SD 4x3 to FullHD 16x9 - Aspect Ratio problem

[Christoph Gerstbauer]

Gyan Doshi

thank you, that worked fine!

2018-06-22 15:09 GMT+02:00 Gyan Doshi :

>
>
> On 22-06-2018 06:13 PM, Christoph Gerstbauer wrote:
>
>
>> CommandLineOutput:
>>
>> ffmpeg -i "F:\scaler test\_5sec.avi" -vf "crop=720:576:0:32, setfield=tff,
>> yadif=1:0:0, scale=-1:1080, tinterlace=interleave_top, fieldorder=tff"
>> -vcodec ffvhuff -an -s 1920x1080 -aspect 16:9 "F:\scaler
>>
>
> Since you're scaling proportionally ("-1:1080"), you need to pad out the
> frame to FHD.
>
> ffmpeg -i in -vf "crop=720:576:0:32,setfield=tff,yadif=1:0:0,
>   scale=-1:1080,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,
>   tinterlace=interleave_top, fieldorder=tff,
>   setsar=1"
>-c:v ffvhuff -an -aspect 16:9   out
>
> Additionally, since your input isn't square-pixels, the following scale
> may be more accurate,
>
> scale=oh*4/3:1080
>
> Regards,
> Gyan
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] "Smoothing" RTSP over wlan

[Michael Fritscher]

Good morning,

Scenario: Using RTSP over wlan to get video from a webcam, using the lib 
itself. the WLAN has the characteristic to "pause" for e.g. 300 ms, and send 
all the data at once. This makes the stream not exactly smooth. Is there a way 
to tell the libav to buffer / wait 500 ms and let the lib smooth it itself (bei 
e.g. using the embedded timestamps)? Or must I smooth it myself (by buffering 
the pictures - which needs a lot of memory - 25/2*1280*720*3 = round about = 35 
MB).

Best regards,
Michael Fritscher
-- 
ZfT - Zentrum für Telematik e.V.
Michael Fritscher
Magdalene-Schoch-Straße 5
97074 Würzburg
Tel: +49 (931) 615 633 - 57
Fax: +49 (931) 615 633 - 11
Email: michael.fritsc...@telematik-zentrum.de
Web: http://www.telematik-zentrum.de

Vorstand:
Prof. Dr. Klaus Schilling, Hans-Joachim Leistner
Sitz: Gerbrunn
USt.-ID Nr.: DE 257 244 580, Steuer-Nr.:  257/111/70203
Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] kmsgrab on Intel 8th generation aka h/w accelerated screen capture

[Kai Hendry]

On Mon, 25 Jun 2018 at 09:49, robertlazarski  wrote:
> That command worked for me though of course without your external dep.

You managed to record sound with your kmsgrab? Not sure what you mean
by external dep!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".