Closed Bug 992568 Opened 10 years ago Closed 10 years ago

[RTSP] Refactor RtspChannel to support HTTP->RTSP redirection and rendering inside the browser

Categories

(Firefox OS Graveyard :: RTSP, defect)

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(feature-b2g:2.0, tracking-b2g:backlog)

VERIFIED FIXED
1.4 S6 (25apr)
feature-b2g 2.0
tracking-b2g backlog

People

(Reporter: ethan, Assigned: ethan)

References

Details

(Whiteboard: [p=8] [priority])

Attachments

(3 files, 5 obsolete files)

This bug is a follow-up of bug 990862 (Rename RtspChannel to RtspChannelChild).
It is also aimed to resolve several important features of RTSP.

Until v1.4, RTSP on B2G only supports <video> and <a> tags, it supports audio-only streaming and is rendered in the video app.
We are going to extend the capabilities of RTSP to achieve the following features:
1. Support HTTP->RTSP redirection (bug 949675)
2. Support RTSP in URL bar (bug 945603)
3. Support RTSP in iframe (bug 940840)

Besides, according to the conclusion of discussions in bug 963565 (https://bugzilla.mozilla.org/show_bug.cgi?id=963565#c13), we will render all cases of RTSP in the built-in media player of the system browser, instead of an externSo, this bug converge the implementation works of these bugsal Gaia app. This conclusion results in a 4th feature.
4. Render RTSP inside the browser.

The accomplishment of these four features all involve a refactoring work of RtspChannel (and some modifications of creating RtspController).
So, the implementation works of these bugs are converged to this bug.
Blocks: 949675, 945603, 940840
blocking-b2g: --- → 1.5?
(In reply to Ethan Tseng [:ethan] from comment #0)
> Besides, according to the conclusion of discussions in bug 963565
> (https://bugzilla.mozilla.org/show_bug.cgi?id=963565#c13), we will render
> all cases of RTSP in the built-in media player of the system browser,
> instead of an externSo, this bug converge the implementation works of these
> bugsal Gaia app. This conclusion results in a 4th feature.
Fixed a typo in this sentence.
Besides, according to the conclusion of discussions in bug 963565 (https://bugzilla.mozilla.org/show_bug.cgi?id=963565#c13), we will render all cases of RTSP in the built-in media player of the system browser, instead of an external Gaia app. This conclusion results in a 4th feature.
4. Render RTSP inside the browser.
Target Milestone: --- → 1.4 S3 (14mar)
This patch did two things:
1. Make RTSP as an exposed protocol by changing the preference.
   RTSP will be handled internally by Gecko, not the external handler.
2. Add RTSP into the supported media types list of DecoderTraits.
Target Milestone: 1.4 S3 (14mar) → 1.4 S5 (11apr)
Just update the patch comment.
Attachment #8402220 - Attachment is obsolete: true
This patch did the following:
1. Add RtspChannelParent and implement IPDL for RtspChannel.
2. RtspChannelChild implements nsIChildChannel.
3. RtspChannelParent implements nsIParentChannel.
4. Accomplish HTTP->RTSP redirection.
5. Transfer the responsibility of creating RtspController from RtspMediaResource to RtspChannelChild.
6. Add RtspChannelChild into the load group and implement Cancel() to do clean-up.
Status: NEW → ASSIGNED
Assignee: nobody → ettseng
Blocks: 971593
Comment on attachment 8402223 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Review of attachment 8402223 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great! Btw, I don't remember reviewing this before - can you add a link to that review, please?

::: content/media/RtspMediaResource.cpp
@@ +359,5 @@
> +  mMediaStreamController =
> +    static_cast<RtspChannelChild*>(aChannel)->GetController();
> +  MOZ_ASSERT(mMediaStreamController);
> +  mListener = new Listener(this);
> +  mMediaStreamController->AsyncOpen(mListener);

Looks good.

Add a MOZ_ASSERT(aChannel).

::: content/media/moz.build
@@ +171,5 @@
>  LOCAL_INCLUDES += [
>      '/content/base/src',
>      '/layout/generic',
>      '/layout/xul',
> +    '/netwerk/base/src',

What are you including here? Would it be better to export it?

::: netwerk/ipc/NeckoChannelParams.ipdlh
@@ +108,5 @@
> +union RtspChannelCreationArgs
> +{
> +  RtspChannelOpenArgs;     // For AsyncOpen: the common case.
> +  RtspChannelConnectArgs;  // Used for redirected-to channels
> +};

I think you only need RtspChannelConnectArgs. It looks like we only send the constructor message for redirects, so we shouldn't need RtspChannelOpenArgs or RtspChannelCreationArgs. Probably, you can just pass RtspChannelConnectArgs, and maybe you should rename Init to InitAndConnectChild??

::: netwerk/ipc/NeckoParent.cpp
@@ +337,5 @@
>    return true;
>  }
>  
> +PRtspChannelParent*
> +NeckoParent::AllocPRtspChannelParent(const RtspChannelCreationArgs& aArgs)

So, IPDL for HTTP and FTP is somewhat more complicated than this. We also pass the PBrowser actor (i.e. the tab), and the load context. Now, RtspChannelParent doesn't do anything, but I think we should look into doing the same thing for Rtsp.

Take a look at AllocPHttpChannelParent to see what I mean. For now, I think we shouldn't block on this. Please file it as a follow up, and we can discuss how we want to proceed later.

@@ +342,5 @@
> +{
> +#ifdef NECKO_PROTOCOL_rtsp
> +  const RtspChannelConnectArgs& c = aArgs.get_RtspChannelConnectArgs();
> +  nsCOMPtr<nsIURI> uri = DeserializeURI(c.uri());
> +  RtspChannelParent *p = new RtspChannelParent(uri);

Since you're passing the args into p->Init() in RecvPRtsp..., I don't think you need to use this constructor here. You can probably just use a no-args constructor and let RtspChannelParent take care of parsing the RtspChannelConnectArgs object.

::: netwerk/protocol/rtsp/RtspChannelChild.cpp
@@ +91,5 @@
> +
> +NS_IMETHODIMP
> +RtspChannelChild::Resume()
> +{
> +  return NS_OK;

Looks like Suspend and Resume might never be called. I think you should MOZ_CRASH in these.

@@ +117,5 @@
> +  nsCOMPtr<nsIStreamingProtocolControllerService> mediaControllerService =
> +    do_GetService(MEDIASTREAMCONTROLLERSERVICE_CONTRACTID);
> +  if (!mediaControllerService) {
> +    return NS_ERROR_FAILURE;
> +  }

Is there a case where this is normal and ok? Seems like MOZ_RELEASE_ASSERT is ok here.

@@ +119,5 @@
> +  if (!mediaControllerService) {
> +    return NS_ERROR_FAILURE;
> +  }
> +  mediaControllerService->Create(this, getter_AddRefs(mMediaStreamController));
> +  MOZ_ASSERT(mMediaStreamController);

Nice.

@@ +124,5 @@
> +
> +  // Add ourselves to the load group.
> +  if (mLoadGroup) {
> +    mLoadGroup->AddRequest(this, nullptr);
> +  }

Cool.

@@ +142,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelChild::OnStartRequest(nsIRequest *aRequest, nsISupports *aContext)
> +{
> +  return NS_OK;

I think MOZ_CRASH for these. They should never be called, right?

::: netwerk/protocol/rtsp/RtspChannelChild.h
@@ +36,5 @@
>  
> +  // nsBaseChannel::nsIChannel::nsIRequest
> +  NS_IMETHOD Cancel(nsresult status);
> +  NS_IMETHOD Suspend();
> +  NS_IMETHOD Resume();

For each function you override, please add MOZ_OVERRIDE MOZ_FINAL.

@@ +68,5 @@
> +  void ReleaseIPDLReference();
> +
> +  // RtspChannelChild
> +  RtspChannelChild(nsIURI *aUri);
> +  ~RtspChannelChild();

Please put constructor and destructor at the top of the class definition, after the NS_DECL statements - see HttpChannelChild.h.

@@ +79,4 @@
>  };
>  
>  }
>  } // namespace mozilla::net

nit: 

Either
"}} // namespace mozilla::net"
or
"} // namespace mozilla
 } // namespace net"

Very minor thing, but since you're changing the rest of the file, this would be nice :)

::: netwerk/protocol/rtsp/RtspChannelParent.cpp
@@ +47,5 @@
> +    case RtspChannelCreationArgs::TRtspChannelOpenArgs:
> +    {
> +      //const RtspChannelOpenArgs& a = aArgs.get_RtspChannelOpenArgs();
> +      return true;
> +    }

Yeah, I don't think you need RtspChannelOpenArgs.

@@ +67,5 @@
> +  nsCOMPtr<nsIChannel> channel;
> +  rv = NS_LinkRedirectChannels(channelId, this, getter_AddRefs(channel));
> +
> +  return true;
> +}

Looks good.

@@ +75,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelParent::Cancel(nsresult status)
> +{
> +  return NS_OK;

Hmm. So, I think most Cancels should come from the child and we can probably ignore this. But try a MOZ_CRASH for now - it should turn up something quick in testing.

@@ +103,5 @@
> +
> +NS_IMETHODIMP
> +RtspChannelParent::AsyncOpen(nsIStreamListener *aListener, nsISupports *aContext)
> +{
> +  return NS_OK;

Good.

@@ +113,5 @@
> +NS_IMETHODIMP
> +RtspChannelParent::OnStartRequest(nsIRequest *aRequest,
> +                            nsISupports *aContext)
> +{
> +  return NS_OK;

MOZ_CRASH - these should never be called, right?

@@ +154,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelParent::SetParentListener(HttpChannelParentListener *aListener)
> +{
> +  return NS_OK;

I think this should be ok. The HttpChannelParentListener is there to serve as a bridge between the 'real' channel in the parent and the HttpChannelParent which is the parent actor for IPDL comms. However, we don't want to do any IPDL from parent to child, and there are no redirects after we get to RTSP. So, I think that it's ok to not connect to the listener like this, and just let it be released to deletion.

Let's keep this in mind. I don't think it should leak, but let's just be aware that it might happen.

::: netwerk/protocol/rtsp/RtspChannelParent.h
@@ +26,5 @@
> +
> +  // nsBaseChannel::nsIChannel::nsIRequest
> +  NS_IMETHOD Cancel(nsresult status);
> +  NS_IMETHOD Suspend();
> +  NS_IMETHOD Resume();

MOZ_OVERRIDE MOZ_FINAL

@@ +54,5 @@
> +                               nsIChannel **aChannel) MOZ_OVERRIDE MOZ_FINAL;
> +
> +  // RtspChannelParent
> +  RtspChannelParent(nsIURI *aUri);
> +  ~RtspChannelParent();

Move to top of class like HttpChannelParent.

@@ +68,5 @@
> +  virtual void ActorDestroy(ActorDestroyReason why) MOZ_OVERRIDE;
> +};
> +
> +}
> +} // namespace mozilla::net

Same as comment for RtspChannelChild.h.

::: netwerk/protocol/rtsp/RtspHandler.cpp
@@ +68,5 @@
>  NS_IMETHODIMP
>  RtspHandler::NewChannel(nsIURI *aURI, nsIChannel **aResult)
>  {
>    bool isRtsp = false;
> +  nsRefPtr<nsBaseChannel> channel;

You don't have to rename this to channel, but it's ok to do it if you want :)
Attachment #8402223 - Flags: feedback+
Comment on attachment 8402223 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Review of attachment 8402223 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/rtsp/RtspChannelChild.cpp
@@ +131,5 @@
> +  // an RtspMediaResource and use RtspController we just created to manage the
> +  // control and data streams to and from the network.
> +  mListener = aListener;
> +  mListenerContext = aContext;
> +  mListener->OnStartRequest(this, aContext);

This is what you want to dispatch to the main thread. We shouldn't call OnStartRequest in the same context - it is expected to be called AFTER AsyncOpen completes. So, create an OnStartRequestEvent and just do a simple dispatch here.
Comment on attachment 8402223 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Review of attachment 8402223 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/moz.build
@@ +171,5 @@
>  LOCAL_INCLUDES += [
>      '/content/base/src',
>      '/layout/generic',
>      '/layout/xul',
> +    '/netwerk/base/src',

I include this patch because of the following compiler error:
In file included from /home/ethan/workspace/hg/mozilla-central/content/media/RtspMediaResource.cpp:18:
../../dist/include/mozilla/net/RtspChannelChild.h:12:27: error: nsBaseChannel.h: No such file or directory

nsBaseChannel.h, which is included by RtspChannelChild.h, it not exported to dist/include. Should I export it instead of add the path here?
Comment on attachment 8402223 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Review of attachment 8402223 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/ipc/NeckoChannelParams.ipdlh
@@ +108,5 @@
> +union RtspChannelCreationArgs
> +{
> +  RtspChannelOpenArgs;     // For AsyncOpen: the common case.
> +  RtspChannelConnectArgs;  // Used for redirected-to channels
> +};

Yes! You are right. I didn't think clearly about this in the first place and now I realize we just need RtspChannelConnectArgs here. Thanks for pointing it.

::: netwerk/protocol/rtsp/RtspChannelChild.cpp
@@ +131,5 @@
> +  // an RtspMediaResource and use RtspController we just created to manage the
> +  // control and data streams to and from the network.
> +  mListener = aListener;
> +  mListenerContext = aContext;
> +  mListener->OnStartRequest(this, aContext);

Good advice! I will do it.

@@ +142,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelChild::OnStartRequest(nsIRequest *aRequest, nsISupports *aContext)
> +{
> +  return NS_OK;

Yes. I will use MOZ_CRASH for all the methods that should never be called.

::: netwerk/protocol/rtsp/RtspChannelParent.cpp
@@ +154,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelParent::SetParentListener(HttpChannelParentListener *aListener)
> +{
> +  return NS_OK;

So, is it okay to just return NS_OK for now? Should I replace it by something else?
(In reply to Steve Workman [:sworkman] from comment #6)
> Comment on attachment 8402223 [details] [diff] [review]
> Part 2 - Refactor RtspChannel to support redirection
> -----------------------------------------------------------------
> Looks great! Btw, I don't remember reviewing this before - can you add a
> link to that review, please?
No, I didn't request for review of this before.
I had a draft WIP patch in bug 949675. It was too far from completion, so I didn't ask for review.
(https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=949675&attachment=8401212)

The more I looked into the way to implement redirection, the more I feel we should refactor RtspChannel to resolve many issues at once. Thus I filed this bug to merge the works of those bugs (as mentioned in comment 0), including bug 949675.
What I did in this patch:
1. Addressed most of the issues raised in comment 6 and comment 7, except for two points (described below).
2. In RtspChannelChild::Cancel(), call mListerner->OnStopRequest().
   This could resolve bug 971593 (Resource leak of HTMLMediaElement containing RTSP media resource).
3. Update code comments to reflect the changes.

Steve, the following are the issues you proposed but I have not changed code for them:
a. content/media/moz.build still includes the path '/netwerk/base/src' (see comment 8).
b. RtspChannelParent's constructor still has an argument nsIURI*.
   The reason is we need to call nsBaseChannel::SetURI() here. Is it necessary to remove the argument?
Attachment #8402223 - Attachment is obsolete: true
Flags: needinfo?(sworkman)
(In reply to Ethan Tseng [:ethan] from comment #11)
> Steve, the following are the issues you proposed but I have not changed code
> for them:
> a. content/media/moz.build still includes the path '/netwerk/base/src' (see
> comment 8).

My understanding and preference is that if a header is exported, it shouldn't depend on non-exported headers. However, I might be reaching for a perfect world ;) So, if you can spend some time to make it exportable in a clean way, then please do that. But don't block on it. File a follow-up if you need. (This seems to be my new catchphrase).

> b. RtspChannelParent's constructor still has an argument nsIURI*.
>    The reason is we need to call nsBaseChannel::SetURI() here. Is it
> necessary to remove the argument?

No. If you need to call SetURI, then leave it as is.

In reply to comment 9
::: netwerk/protocol/rtsp/RtspChannelParent.cpp
@@ +154,5 @@
> +//-----------------------------------------------------------------------------
> +NS_IMETHODIMP
> +RtspChannelParent::SetParentListener(HttpChannelParentListener *aListener)
> +{
> +  return NS_OK;

So, is it okay to just return NS_OK for now? Should I replace it by something else?

NS_OK is fine for now.
Flags: needinfo?(sworkman)
Whiteboard: [p=8]
Target Milestone: 1.4 S5 (11apr) → 1.4 S6 (25apr)
Blocks: 877065
Depends on: 996688
blocking-b2g: 2.0? → backlog
Whiteboard: [p=8] → [p=8] [priority]
Polish the patch:
1. Add mCanceled to RtspChannelChild to guarantee RtspChannel will not be canceled more than once.
2. In RtspChannelParent::Cancel(), return NS_OK instead of MOZ_CRASH().
3. In RtspMediaResource::Suspend/Resume(), add mullptr checks for mDecoder.
Attachment #8403831 - Attachment is obsolete: true
Attachment #8402221 - Flags: review?(sworkman)
Comment on attachment 8407357 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Hi Steve,

I think all the major issues are resolved and this patch is ready to review now. :)
According to our discussions in the comments and emails, there will be follow-ups for some minor issues. I will file bugs for them soon.
Attachment #8407357 - Flags: review?(sworkman)
Steve, in case you already started to review my patch.
This update just fixes build errors happened on desktop. There's no big change that should affect your review. :)
Attachment #8407357 - Attachment is obsolete: true
Attachment #8407357 - Flags: review?(sworkman)
Attachment #8408847 - Flags: review?(sworkman)
Attachment #8402221 - Flags: review?(sworkman) → review+
Comment on attachment 8408847 [details] [diff] [review]
Part 2 - Refactor RtspChannel to support redirection

Review of attachment 8408847 [details] [diff] [review]:
-----------------------------------------------------------------

I think this all looks good. Let's get it landed. r=me.

::: content/media/RtspMediaResource.cpp
@@ +365,5 @@
> +  MOZ_ASSERT(mMediaStreamController);
> +  mListener = new Listener(this);
> +  mMediaStreamController->AsyncOpen(mListener);
> +#else
> +  MOZ_CRASH("Should not be called except for B2G platform");

Put this MOZ_CRASH at the top of the constructor with an #ifndef NECKO_PROTOCOL_rtsp. I think you can put all of the rest of the statements in the subsequent #else block.

::: netwerk/protocol/rtsp/RtspChannelChild.cpp
@@ +70,5 @@
> +
> +//-----------------------------------------------------------------------------
> +// nsBaseChannel::nsIChannel::nsIRequest
> +//-----------------------------------------------------------------------------
> +class OnStopRequestEvent : public nsRunnable

Let's rename this and OnStartRequestEvent to clarify that they're not for calling this class's OnStart/StopRequest.

CallListenerOnStartRequestEvent?
CallListenerOnStopRequestEvent?

Those are long names, but they're self-commenting.

@@ +98,3 @@
>  
>  NS_IMETHODIMP
> +RtspChannelChild::Cancel(nsresult status)

Nit: Can you move Cancel to after AsyncOpen? I expected to see AsyncOpen and the OnStartRequest event before these.

@@ +188,5 @@
> +  if (mLoadGroup) {
> +    mLoadGroup->AddRequest(this, nullptr);
> +  }
> +
> +  // Call mListener's OnStartRequest directly. mListener is expected to create

"Dispatch ..."

::: netwerk/protocol/rtsp/RtspChannelChild.h
@@ +20,5 @@
>  //-----------------------------------------------------------------------------
>  // RtspChannelChild is a dummy channel used to aid MediaResource creation in
> +// HTMLMediaElement. The real e10s, including network control and data flows,
> +// are managed by an RtspController object, which is created by us and
> +// manipulated by RtspMediaResource.

"Network control and data flows are managed by an RtspController object ... This object is also responsible for inter-process communication with the parent process.

@@ +22,5 @@
> +// HTMLMediaElement. The real e10s, including network control and data flows,
> +// are managed by an RtspController object, which is created by us and
> +// manipulated by RtspMediaResource.
> +// When RtspChannelChild::AsyncOpen is called, it will create an RtspController
> +// object and invoke mListener->OnStartRequest immediately. We expect an

Ah. It should dispatch an OnStartRequest and immediately return.

::: netwerk/protocol/rtsp/RtspChannelParent.cpp
@@ +66,5 @@
> +  // nsXMLHttpRequest::CloseRequestWithError while closing the browser app.
> +  // However, the root cause is RtspChannelParent will be created by
> +  // nsXMLHttpRequest::Open when we navigate away from an RTSP web page.
> +  // We should find out why it happens and decide how to fix it.
> +  return NS_OK;

Sounds good to me. Let's make it work for now and fix it later.

::: netwerk/protocol/rtsp/RtspChannelParent.h
@@ +15,5 @@
> +namespace mozilla {
> +namespace net {
> +
> +//-----------------------------------------------------------------------------
> +class RtspChannelParent : public PRtspChannelParent

Can you add a brief comment here to explain why this class exists; please mention that two instances will be created, one by the original HTTP channel and one by IPDL. It will be useful in the future to explain that this class is mostly just dummy code to allow (somewhat) generic redirects.
Attachment #8408847 - Flags: review?(sworkman) → review+
(In reply to Steve Workman [:sworkman] from comment #16)
> Review of attachment 8408847 [details] [diff] [review]:
> -----------------------------------------------------------------
> I think this all looks good. Let's get it landed. r=me.
Steve, thanks for your review!

 
> ::: netwerk/protocol/rtsp/RtspChannelChild.cpp
> > +class OnStopRequestEvent : public nsRunnable
> Let's rename this and OnStartRequestEvent to clarify that they're not for
> calling this class's OnStart/StopRequest.
> CallListenerOnStartRequestEvent?
> CallListenerOnStopRequestEvent?
> Those are long names, but they're self-commenting.
I totally stand for self-explained codes!!
Will apply your suggestion.


> >  NS_IMETHODIMP
> > +RtspChannelChild::Cancel(nsresult status)
> Nit: Can you move Cancel to after AsyncOpen? I expected to see AsyncOpen and
> the OnStartRequest event before these.
Sure.
I will change the orders in both RtspChannelChild and RtspChannelParent.

 
> ::: netwerk/protocol/rtsp/RtspChannelParent.cpp
> @@ +66,5 @@
> > +  // nsXMLHttpRequest::CloseRequestWithError while closing the browser app.
> > +  // However, the root cause is RtspChannelParent will be created by
> > +  // nsXMLHttpRequest::Open when we navigate away from an RTSP web page.
> > +  // We should find out why it happens and decide how to fix it.
> > +  return NS_OK; 
> Sounds good to me. Let's make it work for now and fix it later.
A follow-up for this will be filed soon.


> ::: netwerk/protocol/rtsp/RtspChannelParent.h
> > +//-----------------------------------------------------------------------------
> > +class RtspChannelParent : public PRtspChannelParent
> Can you add a brief comment here to explain why this class exists; please
> mention that two instances will be created, one by the original HTTP channel
> and one by IPDL. It will be useful in the future to explain that this class
> is mostly just dummy code to allow (somewhat) generic redirects.
Sure. Thanks for your reminder.
Addressed the issues in comment 16.
Attachment #8408847 - Attachment is obsolete: true
Attachment #8410158 - Flags: review+
Follow-ups of this bug are filed:
  Bug 1000195 - [RTSP] Follow-up of 992568 - RTSP audio does not auto-play
  Bug 1000229 - [RTSP] Follow-up of 992568 - RtspChannelParent is constructed unexpectedly by nsXMLHttpRequest::Open()
  Bug 1000279 - [RTSP] Follow-up of 992568 - Refine parameters of NeckoParent::AllocPRtspChannelParent()
  Bug 1000286 - [RTSP] Follow-up of 992568 - Integration test of RTSP with system browser
  Bug 1000293 - [RTSP] Follow-up of 992568 - Resume function does not work as expected

These issues are not urgent for now.
Plus one follow-up.
  Bug 1000340 - [RTSP] Follow-up of 992568 - Remove codes to launch video app for RTSP
Verified it.
Thanks!

* Build information:
 - Gaia      e8a08a3f7a608993f0b302371e016e73faceea70
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/2897fb554990
 - BuildID   20140505160203
 - Version   32.0a1
Status: RESOLVED → VERIFIED
feature-b2g: --- → 2.0
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.