Re: NPAPI plug-in use case: live video broadcast

[Oliver Lietz]

> 
> 
> Firefox WebRTC supports H.264.
Yes but only Baseline profile and not with high quality.
Focus is for WebRTC, not for streaming.
Broadcast quality encoding requires more than just enabling h264,
it requires specific access on encoding features and algorithms.
(I/P/Keyframe structure, profile/level, bitrate control, ...)
Furthermore there might be specific capture devices which need
special driver support (e.g. Blackmagic)

> 
> In any case, this is the set of use cases WebRTC is intended to support and 
> so the right direction to be going is to work with WebRTC 
> (potentially helping us
> enhance WebRTC to support your applications) rather than doubling
> down on NPAPI.
> 
> -Ekr

We are working with WebRTC and it has it's good use cases.
However it would not replace a complete live broadcast architecture
(at least not yet) without adding a server component which makes
the whole setup much more complicated.
At the moment we can directly send live streams to CDN like Akamai
with highest possible H264 quality.
This is definitely not possible with WebRTC.

What would "helping us" mean for you, and how can we do this?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NPAPI plug-in use case: live video broadcast

[Oliver Lietz]

On Saturday, September 26, 2015 at 3:07:03 AM UTC+2, Jonas Sicking wrote:
> On Sep 26, 2015 09:33, "Eric Rescorla"  wrote:
> >
> > On Fri, Sep 25, 2015 at 3:20 PM,  wrote:
> >
> > > On Saturday, September 19, 2015 at 8:15:50 PM UTC+2, Eric Rescorla
> wrote:
> > > > On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz 
> wrote:
> > > >
> > > > > Hi,
> > > > > our nanoStream plugin supports live encoding and streaming with
> > > > > h264/aac/rtmp from live camera sources and capture devices.
> > > > > We needed to replace this with a native extension on Chrome.
> > > > > WebRTC is a possible future option but not a suitable replacement
> for
> > > all
> > > > > use cases.
> > > > >
> > > >
> > > > One or both of WebRTC and MSE is intended to cover precisely these
> > > > use cases. What are they missing here?
> > > >
> > > > -Ekr
> > > >
> > > >
> > > > NPAPI stills works on Firefox, but how long will it remain?
> > > > > What options do we have in the future for implementing native
> > > extensions?
> > > > > Thanks, Oliver
> > > > > ___
> > > > > dev-platform mailing list
> > > > > dev-platform@lists.mozilla.org
> > > > > https://lists.mozilla.org/listinfo/dev-platform
> > > > >
> > >
> > > MSE is playback only, so no option for live broadcast.
> 
> MSE can be used to play live broadcast. I'm willing to bet that that is
> what YouTube uses for their live broadcast support.
> 
> / Jonas

Not sure how MSE plays live broadcasts, as youtube primarily is VOD.
It might be possible with any kind of MPEG DASH combination.
Anyway it is PLAYBACK only, not SEND BROADCASTS from the camera.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NPAPI plug-in use case: live video broadcast

[Eric Rescorla]

On Tue, Sep 29, 2015 at 3:44 AM, Oliver Lietz  wrote:

>
> >
> >
> > Firefox WebRTC supports H.264.
> Yes but only Baseline profile and not with high quality.
>

I believe that OpenH264 has started to add some high profile
features, but yes, it's not currently HP.

Focus is for WebRTC, not for streaming.
> Broadcast quality encoding requires more than just enabling h264,
> it requires specific access on encoding features and algorithms.
> (I/P/Keyframe structure, profile/level, bitrate control, ...)
>

Sure. You will be able to negotiate some but not all of this, depending
on API surface.


> Furthermore there might be specific capture devices which need
> special driver support (e.g. Blackmagic)


Yes, for this you will obviously need external support.


> In any case, this is the set of use cases WebRTC is intended to support
> and so the right direction to be going is to work with WebRTC
> > (potentially helping us
> > enhance WebRTC to support your applications) rather than doubling
> > down on NPAPI.
> >
> > -Ekr
>
> We are working with WebRTC and it has it's good use cases.
> However it would not replace a complete live broadcast architecture
> (at least not yet) without adding a server component which makes
> the whole setup much more complicated.
> At the moment we can directly send live streams to CDN like Akamai
> with highest possible H264 quality.
> This is definitely not possible with WebRTC.
>
> What would "helping us" mean for you, and how can we do this?


In some cases, submitting patches that provide the functionality you want.
In others, working to get new APIs standardized to support that
functionality.

However, it also sounds like you may need some very specialized stuff
that isn't really likely to come to the general browser use case for a
while.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Ehsan Akhgari]

On 2015-09-29 12:52 AM, Gregory Szorc wrote:

On Mon, Sep 28, 2015 at 6:45 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:

On 2015-09-28 5:41 PM, Gregory Szorc wrote:

When writing thousands of files in rapid succession, this 1+ms pause
(assuming synchronous I/O) piles up. Assuming a 1ms pause,
writing 100,000
files spends 100s in CloseFile()! The process profile also shows
the bulk
of the time in CloseFile(), so this is a real hot spot.


There is no CloseFile() on Windows.  Did you mean CloseHandle()?


While this is probably something I should know, I confess to blindly
copying results from Sysinternals'  procmon utility, which reports file
closes as the "CloseFile()" "operation." I reckon it is being
intelligent and converting CloseHandle() to something more useful for
reporting purposes. In my defense, procmon does report "operations" that
I know are actual Windows functions. Kinda weird it is inconsistent. Who
knows.


Fair!  Honestly I haven't used procmon in years, I don't even remember 
it having any profiling tools when I last saw it.  :-)  But it probably 
tracks which handles are being passed to CloseHandle().



The reason I'm asking is that CloseHandle() can close various types
of kernel objects, and if that is showing up in profiles, it's worth
to verify that the handle passed to it is actually coming from
CreateFile(Ex).


Procmon is reporting lots of CreateFile() calls. And I'm 100% certain
the underlying C code is calling CreateFile().


Good.  I'm assuming you mean CreateFile() directly, not wrappers such as 
_open or fopen.



Closing handles on a background thread doesn't help with performance
if you're invoking sub-processes that need to close a handle and
wait for the operation to finish.  It would help if you provided
more details on the constraints you're dealing with, e.g., where do
these handles come from?  Are they being created by one long running
process or by several short lived ones?  etc.  Another idea to
experiment with is leaking the handles and letting the kernel close
them for you when your process is terminated.  I _think_ (but I'm
not sure) that won't count towards the handle of the process to
become signaled so if you're spawning a process that needs to close
the file and wait for that to finish, that may be faster.


I'm dealing with a single threaded single long-running process that
performs synchronous I/O, 1 open file at a time. CreateFile,
CloseHandle, CreateFile, CloseHandle, ... I'm pretty sure leaking
handles is out of the question, as we need to write to thousands or even
tens of thousands of files and this will exhaust open files limits.


You'd be surprised.  :-)

Windows doesn't really have a notion of open file limits similar to 
Unix.  File handles opened using _open can go up to a maximum of 2048. 
fopen has a cap of 512 which can be raised up to 2048 using 
_setmaxstdio().  *But* these are just CRT limits, and if you use Win32 
directly, you can open up to 2^24 handles all at once 
.  Since we 
will never need to open that many file handles, you may very well be 
able to use this approach.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Ehsan Akhgari]

On 2015-09-29 9:05 AM, Ehsan Akhgari wrote:

You'd be surprised.  :-)

Windows doesn't really have a notion of open file limits similar to
Unix.  File handles opened using _open can go up to a maximum of 2048.
fopen has a cap of 512 which can be raised up to 2048 using
_setmaxstdio().  *But* these are just CRT limits, and if you use Win32
directly, you can open up to 2^24 handles all at once
.  Since we
will never need to open that many file handles, you may very well be
able to use this approach.


Sorry, the link was meant to be: 



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Neil]

Gregory Szorc wrote:


Files are opened with _fopen() in "a+" mode if it matters. I can also repro in 
"a" mode.
 


...


Short of going full overlapped I/O

Overlapped I/O isn't supported for operations that change the valid data 
length of the file.

http://blogs.msdn.com/b/oldnewthing/archive/2011/09/23/10215586.aspx

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Gregory Szorc]

On Tue, Sep 29, 2015 at 6:05 AM, Ehsan Akhgari 
wrote:

> On 2015-09-29 12:52 AM, Gregory Szorc wrote:
>
>> On Mon, Sep 28, 2015 at 6:45 PM, Ehsan Akhgari > > wrote:
>>
>> On 2015-09-28 5:41 PM, Gregory Szorc wrote:
>>
>> When writing thousands of files in rapid succession, this 1+ms
>> pause
>> (assuming synchronous I/O) piles up. Assuming a 1ms pause,
>> writing 100,000
>> files spends 100s in CloseFile()! The process profile also shows
>> the bulk
>> of the time in CloseFile(), so this is a real hot spot.
>>
>>
>> There is no CloseFile() on Windows.  Did you mean CloseHandle()?
>>
>>
>> While this is probably something I should know, I confess to blindly
>> copying results from Sysinternals'  procmon utility, which reports file
>> closes as the "CloseFile()" "operation." I reckon it is being
>> intelligent and converting CloseHandle() to something more useful for
>> reporting purposes. In my defense, procmon does report "operations" that
>> I know are actual Windows functions. Kinda weird it is inconsistent. Who
>> knows.
>>
>
> Fair!  Honestly I haven't used procmon in years, I don't even remember it
> having any profiling tools when I last saw it.  :-)  But it probably tracks
> which handles are being passed to CloseHandle().
>

It has some very limited profiling tools built in. I had to dump the output
and write a script to perform the analysis I needed :) It does in fact
track various arguments so you can get filename-level activity for all I/O
operations.


>
> The reason I'm asking is that CloseHandle() can close various types
>> of kernel objects, and if that is showing up in profiles, it's worth
>> to verify that the handle passed to it is actually coming from
>> CreateFile(Ex).
>>
>>
>> Procmon is reporting lots of CreateFile() calls. And I'm 100% certain
>> the underlying C code is calling CreateFile().
>>
>
> Good.  I'm assuming you mean CreateFile() directly, not wrappers such as
> _open or fopen.
>

We're calling CreateFile() or CreateFileA() directly. However...


>
> Closing handles on a background thread doesn't help with performance
>> if you're invoking sub-processes that need to close a handle and
>> wait for the operation to finish.  It would help if you provided
>> more details on the constraints you're dealing with, e.g., where do
>> these handles come from?  Are they being created by one long running
>> process or by several short lived ones?  etc.  Another idea to
>> experiment with is leaking the handles and letting the kernel close
>> them for you when your process is terminated.  I _think_ (but I'm
>> not sure) that won't count towards the handle of the process to
>> become signaled so if you're spawning a process that needs to close
>> the file and wait for that to finish, that may be faster.
>>
>>
>> I'm dealing with a single threaded single long-running process that
>> performs synchronous I/O, 1 open file at a time. CreateFile,
>> CloseHandle, CreateFile, CloseHandle, ... I'm pretty sure leaking
>> handles is out of the question, as we need to write to thousands or even
>> tens of thousands of files and this will exhaust open files limits.
>>
>
> You'd be surprised.  :-)
>
> Windows doesn't really have a notion of open file limits similar to Unix.
> File handles opened using _open can go up to a maximum of 2048. fopen has a
> cap of 512 which can be raised up to 2048 using _setmaxstdio().  *But*
> these are just CRT limits, and if you use Win32 directly, you can open up
> to 2^24 handles all at once <
> https://technet.microsoft.com/en-us/library/bb896645.aspx>.  Since we
> will never need to open that many file handles, you may very well be able
> to use this approach.
>

I experimented with a background thread for just processing file closes.
This drastically increases performance! However, the queue periodically
accumulates and I was seeing errors for too many open files - despite using
CreateFile()! We do make a call to _open_osfhandle() after CreateFile().
I'm guessing the file limit is on file descriptors (not handles) and
_open_osfhandle() triggers the 512 default ceiling? This call is necessary
because Python file objects speak in terms of file descriptors. Not calling
_open_osfhandle() would mean re-implementing Python's file object, which
I'm going to say is too much work for the interim.

Buried in that last paragraph is that a background threading closing files
resulted in significant performance wins - ~5:00 wall on an operation that
was previously ~16:00 wall! And I'm pretty sure it would go faster if
multiple closing threads were used. Still not as fast as Linux. But much
better than the 3x increase from before.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Ehsan Akhgari]

On 2015-09-29 1:47 PM, Gregory Szorc wrote:

You'd be surprised.  :-)

Windows doesn't really have a notion of open file limits similar to
Unix.  File handles opened using _open can go up to a maximum of
2048. fopen has a cap of 512 which can be raised up to 2048 using
_setmaxstdio().  *But* these are just CRT limits, and if you use
Win32 directly, you can open up to 2^24 handles all at once
.  Since
we will never need to open that many file handles, you may very well
be able to use this approach.


I experimented with a background thread for just processing file closes.
This drastically increases performance! However, the queue periodically
accumulates and I was seeing errors for too many open files - despite
using CreateFile()! We do make a call to _open_osfhandle() after
CreateFile(). I'm guessing the file limit is on file descriptors (not
handles) and _open_osfhandle() triggers the 512 default ceiling?


Yeah that would go through the CRT so you would be subject to the CRT 
limit of 512 (which you can bump up to 2048 as I said before.)



This
call is necessary because Python file objects speak in terms of file
descriptors. Not calling _open_osfhandle() would mean re-implementing
Python's file object, which I'm going to say is too much work for the
interim.


Ugh.  In that case, closing file handles on a background thread is the 
best you can do, I think.



Buried in that last paragraph is that a background threading closing
files resulted in significant performance wins - ~5:00 wall on an
operation that was previously ~16:00 wall! And I'm pretty sure it would
go faster if multiple closing threads were used. Still not as fast as
Linux. But much better than the 3x increase from before.


Cool!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 29 Sep 2015 at 4:00PM PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by the new sampling based
memory profiler:
https://bugzilla.mozilla.org/show_bug.cgi?id=1123237

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 29 Sep 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-29-09/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NPAPI plug-in use case: live video broadcast

[Chris Pearce]

On 9/29/2015 11:46 PM, Oliver Lietz wrote:
Not sure how MSE plays live broadcasts, as youtube primarily is VOD. 
It might be possible with any kind of MPEG DASH combination. Anyway it 
is PLAYBACK only, not SEND BROADCASTS from the camera. 


MSE can play fragmented MP4. If your live broadcast muxes into 
fragmented MP4, you just need a way to ensure your player is 
receiving/requesting the most recent fragments, and appending that to 
the MediaSource's SourceBuffers.




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform