Re: [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

> On Jul 12, 2018, at 6:21 PM, Ronak Patel  
> wrote:
> 
> Hey Carl,
> 
> So I dug into this more today and I have root caused what's exactly happening 
> here. 
> 
> The problematic code is this: 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 
> 
> This is where the filename is set and the next line actually opens the file. 
> 
> The logic for this hls_window method is the following:
> 
> 1. Make a new temporary file.
> 2. Write out a new HLS manifest header.
> 3. Loop through all available segments and write out all of the entries for 
> them.
> 4. Close the temporary file when finished.
> 5. Rename the temporary file to the target file name.
> 6. Rinse and repeat for every single fragment.
> 
> Therefore, if you can imagine a 153 hour audio file, we write out a totally 
> new HLS manifest 550800 times (153 * 60 * 60 assuming a 1s fragment duration) 
> that gets progressively larger as each fragment is generated.
> 
> This is a classic O(N^2) algorithm implementation, instead of:
> 
> 1. Creating the destination file up front & write the manifest header.
> 2. Append the new segment to the file.
> 3. If this is the last segment, write out EXT-X-ENDLIST.
> 
> There's no looping involved, nor the need to make temporary files.
> 
> FYI that I've noticed the same sort of pattern being applied to MPEG DASH: 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 
> 
> 
> To implement something like this, looks like we'd have to significantly 
> re-engineer the code. Do you have any pointers on how to go about doing this? 
> Or, would you be able to help do this?
> 

I was thinking about this and I think it must have been implemented this way 
because of live hls streams? Not writing to the main manifest directly and 
keeping that stream open does release any file system locks that there would be 
otherwise. 

Is this the reason why this was done this way at all?


> Thanks for all your help,
> 
> Ronak
> 
>> On Jun 27, 2018, at 2:04 PM, Carl Zwanzig  wrote:
>> 
>> Hi,
>> 
>> I haven't traced it out completely, but take a look at the flag 
>> HLS_TEMP_FILE in libavformat/hlsenc.c.
>> 
>> 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".

Re: [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

Hey Carl,

So I dug into this more today and I have root caused what's exactly happening 
here. 

The problematic code is this: 
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 

This is where the filename is set and the next line actually opens the file. 

The logic for this hls_window method is the following:

1. Make a new temporary file.
2. Write out a new HLS manifest header.
3. Loop through all available segments and write out all of the entries for 
them.
4. Close the temporary file when finished.
5. Rename the temporary file to the target file name.
6. Rinse and repeat for every single fragment.

Therefore, if you can imagine a 153 hour audio file, we write out a totally new 
HLS manifest 550800 times (153 * 60 * 60 assuming a 1s fragment duration) that 
gets progressively larger as each fragment is generated.

This is a classic O(N^2) algorithm implementation, instead of:

1. Creating the destination file up front & write the manifest header.
2. Append the new segment to the file.
3. If this is the last segment, write out EXT-X-ENDLIST.

There's no looping involved, nor the need to make temporary files.

FYI that I've noticed the same sort of pattern being applied to MPEG DASH: 
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 


To implement something like this, looks like we'd have to significantly 
re-engineer the code. Do you have any pointers on how to go about doing this? 
Or, would you be able to help do this?

Thanks for all your help,

Ronak

> On Jun 27, 2018, at 2:04 PM, Carl Zwanzig  wrote:
> 
> Hi,
> 
> I haven't traced it out completely, but take a look at the flag HLS_TEMP_FILE 
> in libavformat/hlsenc.c.
> 
> 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

[Ronak]

> On Jun 27, 2018, at 1:50 AM, Carl Zwanzig  wrote:
> 
> On 6/26/2018 9:20 PM, Ronak wrote:
>> The temp files are made in the CWD. And they are constantly created and
>> destroyed for every single fragment it seems. I looked into the ffmpeg
>> code and it looks like every single method in hlsenc and dashenc opens
>> and closes these file handles.
>> I would like to make modifications to the code to fix it, but it's hard
>> to follow exactly which methods to modify.
> First thing I'd look at doing is to create the temp files in /tmp (*nix) or 
> /temp (windoze); just that and a memory file system for /tmp would do wonders 
> for throughput. Admittedly, it's not a real solution.
> 
> Past that, I suspect that any other change to use memory buffers instead of 
> files will be a more structural change. If I have a chance, I'll look at the 
> code tomorrow.
> 
> (z wonders why the code's author thought this was a good idea...)
> 
> Later,
> 
> z!

Ok great thanks Carl!


> ___
> 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] fMP4 generation speed

[Carl Zwanzig]

On 6/26/2018 9:20 PM, Ronak wrote:

The temp files are made in the CWD. And they are constantly created and
destroyed for every single fragment it seems. I looked into the ffmpeg
code and it looks like every single method in hlsenc and dashenc opens
and closes these file handles.
I would like to make modifications to the code to fix it, but it's hard
to follow exactly which methods to modify.
First thing I'd look at doing is to create the temp files in /tmp (*nix) or 
/temp (windoze); just that and a memory file system for /tmp would do 
wonders for throughput. Admittedly, it's not a real solution.


Past that, I suspect that any other change to use memory buffers instead of 
files will be a more structural change. If I have a chance, I'll look at the 
code tomorrow.


(z wonders why the code's author thought this was a good idea...)

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

[Gyan Doshi]

On 27-06-2018 09:50 AM, Ronak wrote:


Just to clarify, I'm making a single fMP4 file here; not multiple.


Just to confirm. Test with the MP4 muxer and create a fragmented MP4 to 
check speed.



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".

Re: [FFmpeg-user] fMP4 generation speed

[Ronak]

> On Jun 25, 2018, at 6:03 PM, Carl Zwanzig  wrote:
> 
> 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.
> 

The temp files are made in the CWD. And they are constantly created and 
destroyed for every single fragment it seems. I looked into the ffmpeg code and 
it looks like every single method in hlsenc and dashenc opens and closes these 
file handles.
I would like to make modifications to the code to fix it, but it's hard to 
follow exactly which methods to modify.

Just to clarify, I'm making a single fMP4 file here; not multiple.

Does anyone have any pointers? 

> 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".

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] 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] 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] fMP4 generation speed

[Ronak]

> 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?

>> 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".

Re: [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

Sent from my iPhone

> 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?

> 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".

Re: [FFmpeg-user] fMP4 generation speed

[Carl Zwanzig]

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.)


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

[Ronak]

> On Jun 22, 2018, at 4:31 PM, Ronak  wrote:
> 
> 
> 
>> On Jun 22, 2018, at 3:59 PM, David Favor  wrote:
>> 
>> I'd say you're looking at a very long transcode time,
>> as your video dump shows...
>> 
>>  Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s
>> 
>> So... a 52 hour video... well... better fire up the popcorn
>> maker + settle in for a very long night...
> 
> 
> This is not video, only AAC audio. And there shouldn't be any transcoding 
> here. I'm using -codec copy. We're going from MP4 -> fMP4 here.

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.
I don't imagine the cost of creating more fMP4 boxes would tax the CPU and slow 
everything down.

> 
>> ___
>> 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] fMP4 generation speed

[Ronak]

> On Jun 22, 2018, at 3:59 PM, David Favor  wrote:
> 
> I'd say you're looking at a very long transcode time,
> as your video dump shows...
> 
>   Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s
> 
> So... a 52 hour video... well... better fire up the popcorn
> maker + settle in for a very long night...


This is not video, only AAC audio. And there shouldn't be any transcoding here. 
I'm using -codec copy. We're going from MP4 -> fMP4 here.

> ___
> 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] fMP4 generation speed

[David Favor]

I'd say you're looking at a very long transcode time,
as your video dump shows...

   Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s

So... a 52 hour video... well... better fire up the popcorn
maker + settle in for a very long night...
___
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 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:
>> 
>> real 3m19.316s
>> user 3m14.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.
> 
> Please remember not to top-post here, Carl Eugen


Hi Carl,

I got more logs, here's what I got:

[dash @ 0x22c3f80] Opening 'bk_potr_06_22_64_1sec_test.m4s' for reading
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 4236 bytes read, 1 seeks
[dash @ 0x22c3f80] Representation 0 media segment 69894 written to: 
bk_potr_06_22_64_1sec_test.m4s
[dash @ 0x22c3f80] Opening 'bk_potr_06_22_64_1sec_test.mpd.tmp' for writing
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467754, dts 68162362630
size=N/A time=18:56:02.36 bitrate=N/A speed=9.37x
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467755, dts 68162409070
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467756, dts 68162455510
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467757, dts 68162501950
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467758, dts 68162548390
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467759, dts 68162594830
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x22be580] stream 0, sample 1467760, dts 68162641270
No more output streams to write to, finishing.
[dash @ 0x22c3f80] Opening 'bk_potr_06_22_64_1sec_test.m4s' for reading
[file @ 0x23540c0] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 bytes read, 1 seeks
[dash @ 0x22c3f80] Representation 0 media segment 69895 written to: 
bk_potr_06_22_64_1sec_test.m4s
[dash @ 0x22c3f80] Opening 'bk_potr_06_22_64_1sec_test.mpd.tmp' for writing
[file @ 0x2382c80] Setting default whitelist 'file,crypto'
[AVIOContext @ 0x23b9140] Statistics: 0 seeks, 15 writeouts
[AVIOContext @ 0x2310e80] Statistics: 0 seeks, 2107 writeouts
size=N/A time=18:56:02.64 bitrate=N/A speed=9.37x
video:0kB audio:522488kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: unknown
Input file #0 (bk_potr_06_22_64.mp4):
  Input stream #0:0 (audio): 1467761 packets read (535027204 bytes); 
  Total: 1467761 packets (535027204 bytes) demuxed
Output file #0 (bk_potr_06_22_64_1sec_test.mpd):
  Output stream #0:0 (audio): 1467761 packets muxed (535027204 bytes); 
  Total: 1467761 packets (535027204 bytes) muxed
0 frames successfully decoded, 0 decoding errors
[AVIOContext @ 0x22c72c0] Statistics: 541488832 bytes read, 2 seeks

This file took about 6 hours of clock time to get through on a 4 Core Computer 
running at 2.4 Ghz with 16 GB of RAM.

Are there any options for parallelization that we can use so the load is spread 
across the cores? Or does ffmpeg does this already?
If we're strictly I/O bound for this, is it possible to buffer more individual 
fragments in RAM before we write them out to disk?

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".

Re: [FFmpeg-user] fMP4 generation speed

[Carl Zwanzig]

On 6/20/2018 2:50 PM, Ronak wrote:

What do you mean by top-post? I'm just responding to the email chain
through the mailing list. What's the correct etiquette?
Putting your reply _above_ what you're replying to (as you have done). It's 
more appropriate to put your reply _below_ and to remove extraneous text and 
is the preferred style for this mailing list.


You can read about top- and bottom-posting at 
https://en.wikipedia.org/wiki/Posting_style


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

[Ronak]

What do you mean by top-post? I'm just responding to the email chain through 
the mailing list. What's the correct etiquette?


> 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:
>> 
>> real 3m19.316s
>> user 3m14.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.
> 
> Please remember not to top-post here, 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".

___
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-20 18:37 GMT+02:00, Ronak :

> That command took the following time:
>
> real  3m19.316s
> user  3m14.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.

Please remember not to top-post here, 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

[Ronak]

Hey Carl,

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.
I'm wondering if the extra file I/O is the culprit here? Either in writing more 
logs or not buffering enough content in RAM to write out to disk in larger 
bursts.

Ronak

> On Jun 20, 2018, at 12:12 PM, Carl Eugen Hoyos  wrote:
> 
> 2018-06-20 16:51 GMT+02:00, Ronak :
> 
>> Ffmpeg -I "${FILE}.mp4" -codec copy -f dash -single_file_name
>> "${FILE}_1sec.m4s" -min_seg_duration 975238.095238095 -hls_playlist 1
>> "${FILE}_1sec.mpd"
>> 
>> Here's an abbreviated dump of the logs for a 52:15:29.84 hour audio file.
>> You can find the full log here:
>> https://drive.google.com/open?id=13GyppqvUJRYQNG9XhJ0feDATjvL1FvFf
>> 
>> 
>> To note, this file took over 1 day to fragment, which is totally not
>> acceptable for our SLAs.
> 
> Understandably.
> Please also test the following:
> $ ffmpeg -i bk_argo_001199_44_64.mp4 -f null -
> 
> 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".

___
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-20 16:51 GMT+02:00, Ronak :

> Ffmpeg -I "${FILE}.mp4" -codec copy -f dash -single_file_name
> "${FILE}_1sec.m4s" -min_seg_duration 975238.095238095 -hls_playlist 1
> "${FILE}_1sec.mpd"
>
> Here's an abbreviated dump of the logs for a 52:15:29.84 hour audio file.
> You can find the full log here:
> https://drive.google.com/open?id=13GyppqvUJRYQNG9XhJ0feDATjvL1FvFf
> 
>
> To note, this file took over 1 day to fragment, which is totally not
> acceptable for our SLAs.

Understandably.
Please also test the following:
$ ffmpeg -i bk_argo_001199_44_64.mp4 -f null -

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

[Ronak]

Hi Gyan,

This log is from this command:

Ffmpeg -I "${FILE}.mp4" -codec copy -f dash -single_file_name 
"${FILE}_1sec.m4s" -min_seg_duration 975238.095238095 -hls_playlist 1 
"${FILE}_1sec.mpd"

Here's an abbreviated dump of the logs for a 52:15:29.84 hour audio file. You 
can find the full log here: 
https://drive.google.com/open?id=13GyppqvUJRYQNG9XhJ0feDATjvL1FvFf 


To note, this file took over 1 day to fragment, which is totally not acceptable 
for our SLAs. Is there a way to cut this down to several minutes instead of 
days?

ffmpeg version N-91283-gdaf38d0 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
  configuration: --prefix=/home/ronakp/ffmpeg_build --pkg-config-flags=--static 
--extra-cflags=-I/home/ronakp/ffmpeg_build/include 
--extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
--extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-libfdk_aac 
--enable-libmp3lame --enable-libopus --enable-nonfree
  libavutil  56. 18.102 / 56. 18.102
  libavcodec 58. 20.101 / 58. 20.101
  libavformat58. 17.100 / 58. 17.100
  libavdevice58.  4.101 / 58.  4.101
  libavfilter 7. 25.100 /  7. 25.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc55.  2.100 / 55.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bk_argo_001199_44_64.mp4':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isom
creation_time   : 2016-10-20T23:05:48.00Z
  Duration: 52:15:29.84, start: 0.00, bitrate: 63 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 61 kb/s (default)
Metadata:
  creation_time   : 2016-10-20T23:04:25.00Z
  handler_name: awdenewlogo_aax_lc_44_64_2_y.aac - Imported with GPAC 
0.5.0-rev0
[dash @ 0x22c3fc0] The min_seg_duration option is deprecated and will be 
removed. Please use the -seg_duration
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for writing
Output #0, dash, to 'bk_argo_001199_44_64_1sec.mpd':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isom
encoder : Lavf58.17.100
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 61 kb/s (default)
Metadata:
  creation_time   : 2016-10-20T23:04:25.00Z
  handler_name: awdenewlogo_aax_lc_44_64_2_y.aac - Imported with GPAC 
0.5.0-rev0
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing 
size=N/A time=00:33:37.79 bitrate=N/A speed= 128x
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
size=N/A time=00:34:36.30 bitrate=N/A speed= 128x 
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 0x22c3fc0] Opening 'media_0.m3u8.tmp' for writing
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.m4s' for reading
[dash @ 0x22c3fc0] Opening 'bk_argo_001199_44_64_1sec.mpd.tmp' for writing
[dash @ 

Re: [FFmpeg-user] fMP4 generation speed

[Gyan Doshi]

On 12-06-2018 11:59 PM, Ronak wrote:


We've noticed that ffmpeg is really slow at segmenting the content at such a 
small fragmentation size.

What's the reason behind this?

Here's the command we're running: ffmpeg -i "${FILE}.mp4" -codec copy -hls_time 
9.75238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list -hls_playlist_type vod 
"${FILE}_10sec_v7.m3u8"

There's no encoding here, so what's causing ffmpeg to take so long?


What speed do you get? Share full log.


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] fMP4 generation speed

[Ronak]

Hi all,

So we're investigating using ffmpeg to generate fMP4 assets at a 1s 
fragmentation size for our audio content. Our content has no video.

We've noticed that ffmpeg is really slow at segmenting the content at such a 
small fragmentation size.

What's the reason behind this?

Here's the command we're running: ffmpeg -i "${FILE}.mp4" -codec copy -hls_time 
9.75238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list 
-hls_playlist_type vod "${FILE}_10sec_v7.m3u8"

There's no encoding here, so what's causing ffmpeg to take so long?

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".