GStreamer-devel

My H.264 encoder cound not work well with the MP4 muxer

Classic

List

Threaded

30 messages Options

michael smith-6-3

Re: who will call x264enc's _setcap function?

2009/8/20 Chen, Weian <[hidden email]>:
>
> Thanks Michael.
>
> I have some information (couple of bytes) has to be passed to next element before it call _set_caps.

As I said, if you provide _specific details_, we can try to advise
about what you should do. You're refusing to provide specific details,
so we can't suggest the proper way to do things - all we can do is
guess at what you actually want to do.

For an element like x264enc (in your example) it would be totally
inappropriate to add codec_data to the upstream element's srcpad caps.
So, either your example is completely different from what you actually
want to do, or you need to explain _exactly_ what you want to do so
that we can tell you what the proper approach is.

Mike

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Chen, Weian

Re: who will call x264enc's _setcap function?

Hi Mike,

What I want to pass from upstream element (camera source element) to next element (encode element) is the buffer ID of the hardware (such as camera's image buffer), which should be use in encode element's _set_caps for encoder's initialization.

I am not sure whether the information is enough.

thanks,
Weian

-----Original Message-----
From: Michael Smith [mailto:[hidden email]]
Sent: 2009年8月21日 7:10
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] who will call x264enc's _setcap function?

2009/8/20 Chen, Weian <[hidden email]>:
>
> Thanks Michael.
>
> I have some information (couple of bytes) has to be passed to next element before it call _set_caps.

As I said, if you provide _specific details_, we can try to advise
about what you should do. You're refusing to provide specific details,
so we can't suggest the proper way to do things - all we can do is
guess at what you actually want to do.

For an element like x264enc (in your example) it would be totally
inappropriate to add codec_data to the upstream element's srcpad caps.
So, either your example is completely different from what you actually
want to do, or you need to explain _exactly_ what you want to do so
that we can tell you what the proper approach is.

Mike

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Josep Torra

Re: who will call x264enc's _setcap function?

Hi Weian,

Caps aren't appropriate to transport information that changes for each buffer.

I can't really figure out what are you trying to do but I will expose you a possible scenario.

Having a src element that is capable to generate image buffers with video data stored in graphics
memory that can be referenced by an ID (hardware surface).

Having a video encoder that can encode a hardware surface like recent additions VAAPI.

The problem related to this scenario is how to pass surface ID between elements to avoid
pull/push the video data in main memory.

In this use case what is recommended is that both elements negotiate a kind of stream like
between video/x-raw-yuv and video/x-raw-va choices.

The content of buffers will be different depending on which kind of stream is negotiated:

video/x-raw-yuv : a frame per buffer in the form of raw video data in planar form.
video/x-raw-va : a frame per buffer in the form of an specialized structure containing the
hardware surface ID.

I'm in process to introduce video acceleration to gstreamer in a generic way, maybe are you
interested on reading the draft about the topic [1].

Current status is write/design the code for simple playback uses cases and the plan is extend it
into more use cases in the future.

[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/docs/design/draft-va.txt

Best regards.

Josep

Chen, Weian wrote:

> Hi Mike,
>
> What I want to pass from upstream element (camera source element) to next element (encode element) is the buffer ID of the hardware (such as camera's image buffer), which should be use in encode element's _set_caps for encoder's initialization.
>
> I am not sure whether the information is enough.
>
> thanks,
> Weian
>
> -----Original Message-----
> From: Michael Smith [mailto:[hidden email]]
> Sent: 2009年8月21日 7:10
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] who will call x264enc's _setcap function?
>
> 2009/8/20 Chen, Weian <[hidden email]>:
>> Thanks Michael.
>>
>> I have some information (couple of bytes) has to be passed to next element before it call _set_caps.
>
> As I said, if you provide _specific details_, we can try to advise
> about what you should do. You're refusing to provide specific details,
> so we can't suggest the proper way to do things - all we can do is
> guess at what you actually want to do.
>
> For an element like x264enc (in your example) it would be totally
> inappropriate to add codec_data to the upstream element's srcpad caps.
> So, either your example is completely different from what you actually
> want to do, or you need to explain _exactly_ what you want to do so
> that we can tell you what the proper approach is.
>
> Mike
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Chen, Weian

Re: who will call x264enc's _setcap function?

Josep,

Awesome work.

It is great that you can know VAAPI. But my usage is a little bit different. The camera's buffer IDs I want to transport in caps would be used by vaCreateSurface, suppose it should be in _get_caps function but not _chain function. And further more, these buffer IDs will not change once they are created.

And what you are talking about are next step I need to do, you help me a lot. :)

thanks,
Weian
-----Original Message-----
From: Josep Torra [mailto:[hidden email]]
Sent: 2009年8月21日 16:08
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] who will call x264enc's _setcap function?

Hi Weian,

Caps aren't appropriate to transport information that changes for each buffer.

I can't really figure out what are you trying to do but I will expose you a possible scenario.

Having a src element that is capable to generate image buffers with video data stored in graphics
memory that can be referenced by an ID (hardware surface).

Having a video encoder that can encode a hardware surface like recent additions VAAPI.

The problem related to this scenario is how to pass surface ID between elements to avoid
pull/push the video data in main memory.

In this use case what is recommended is that both elements negotiate a kind of stream like
between video/x-raw-yuv and video/x-raw-va choices.

The content of buffers will be different depending on which kind of stream is negotiated:

video/x-raw-yuv : a frame per buffer in the form of raw video data in planar form.
video/x-raw-va : a frame per buffer in the form of an specialized structure containing the
hardware surface ID.

I'm in process to introduce video acceleration to gstreamer in a generic way, maybe are you
interested on reading the draft about the topic [1].

Current status is write/design the code for simple playback uses cases and the plan is extend it
into more use cases in the future.

[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/docs/design/draft-va.txt

Best regards.

Josep

Chen, Weian wrote:

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Chen, Weian

Question on x264enc + mp4mux

In reply to this post by Chen, Weian

Hi All

I have a problem when doing encode + mux:

Encode pipeline is as following: gst-launch videotestsrc ! x264enc ! mp4mux ! filesink location=test.mp4, and then I use crtl + c to destroy the pipeline, then using gst-launch filesrc location=1.mp4 ! qtdemux ! ffdec_h264 ! xvimagesink to decoder, but the pipeline is hang up with log:

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

But if I use gst-launch videotestsrc num-buffers=30 ! x264enc ! mp4mux ! filesink location=test.mp4, and do not use ctrl + c to destroy, the decoder pipeline can work well.

Could anyone here help to explain this strange phenomenon to me?

Thanks in advanced.

thanks,

Weian

Thiago Sousa Santos-2

Re: Question on x264enc + mp4mux

On Mon, Aug 24, 2009 at 6:29 AM, Chen, Weian <[hidden email]> wrote:

Hi All

I have a problem when doing encode + mux:

Encode pipeline is as following: gst-launch videotestsrc ! x264enc ! mp4mux ! filesink location=test.mp4, and then I use crtl + c to destroy the pipeline, then using gst-launch filesrc location=1.mp4 ! qtdemux ! ffdec_h264 ! xvimagesink to decoder, but the pipeline is hang up with log:

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

But if I use gst-launch videotestsrc num-buffers=30 ! x264enc ! mp4mux ! filesink location=test.mp4, and do not use ctrl + c to destroy, the decoder pipeline can work well.

Could anyone here help to explain this strange phenomenon to me?

When you press ctrl+c the source element does not push an EOS event to the downstream elements, the pipeline is simply shut down. The muxer needs to receive an EOS event to know that the data streaming has ended and properly finish the mp4 file (like seeking back to the start of the file to rewrite some fields that he coudn't write back at the start).

if you use '-e' option in gst-launch it forces an EOS at the pipeline when ctrl+c is pressed and all should work fine.

Thanks in advanced.

thanks,

Weian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Thiago Sousa Santos

Embedded Systems and Pervasive Computing Lab (Embedded)
Center of Electrical Engineering and Informatics (CEEI)
Federal University of Campina Grande (UFCG)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

michael smith-6-3

Re: Question on x264enc + mp4mux

In reply to this post by Chen, Weian

On Mon, Aug 24, 2009 at 2:29 AM, Chen, Weian<[hidden email]> wrote:

> Hi All
>
>
>
> I have a problem when doing encode + mux:
>
>
>
> Encode pipeline is as following: gst-launch videotestsrc ! x264enc ! mp4mux
> ! filesink location=test.mp4, and then I use crtl + c to destroy the

Chen, Weian

Re: Question on x264enc + mp4mux

Thanks all.
If use decodebin or decodebin2, also no error out.

Then I will file a bug later.

thanks,
Weian
-----Original Message-----
From: Michael Smith [mailto:[hidden email]]
Sent: 2009年8月25日 1:41
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Question on x264enc + mp4mux

On Mon, Aug 24, 2009 at 2:29 AM, Chen, Weian<[hidden email]> wrote:

This will create an invalid mp4 file since you just terminated the
pipeline without EOSing properly, so it doesn't have a chance to write
the final file headers correctly.

> pipeline, then using gst-launch filesrc location=1.mp4 ! qtdemux !
> ffdec_h264 ! xvimagesink to decoder, but the pipeline is hang up with log:
>
> Setting pipeline to PAUSED ...
>
> Pipeline is PREROLLING ...

However, given an invalid file, I'd expect it to error out - does it
do so if you use decodebin or decodebin2?

If not, sounds like a bug, you should file a bug report.

Mike

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Chen, Weian

New developed video-sink could not work well with totem

Hi all,

We developed a video-sink plug-in, but have some problem to work with totem.

When we display the video to the Totem window, video is sometimes very munged, but When using the window created by video-sink, it all looks good.

Could anybody here to give me some hints?

Thanks in advanced.

thanks,
Weian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

michael smith-6-3

Re: New developed video-sink could not work well with totem

On Wed, Aug 26, 2009 at 5:51 AM, Chen, Weian<[hidden email]> wrote:
> Hi all,
>
> We developed a video-sink plug-in, but have some problem to work with totem.
>
> When we display the video to the Totem window, video is sometimes very munged, but When using the window created by video-sink, it all looks good.
>
> Could anybody here to give me some hints?

You'll need to give vastly more detail for us to be able to help.

What exactly is wrong with the display? Does it depend on the video
size? The pixel aspect ratio? Something else?

Mike

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel