Correction to "I'm stuck into a demuxer problem"

[franchan]

Hello,

[I made some wrong conclusions and added corrections at the end]

I seek some suggestions to find a bug in my own mp4 demuxer.
This is actually a wrapper around a proprietary mp4 parser.
(For inspiration I looked into qtdemux, so it is based on that pull scheduling).
The demuxer only support pull scheduling
(I seem to better understand that operation model).

The pipeline works fine when it is "hard-coded" e.g.
filesrc ! mp4demux name=demux \
  demux.video_01! queue ! video_decoder ! ffmpegcolorspace! xvimagesink \
  demux.audio_01! queue ! audio_decoder ! audioconvert ! alsasink

When I use the playbin to create my pipeline,
typefinding works fine until a certain point:
source links with demux links the video and audio queues (always in that order).

But further linking the pipeline is not happening anymore.
My correction: the alsa/xvimagesink sinks are created,
as well, the different converters (aconv/abin/resampler/vscale/vconc/)
The tracing information regarding linking elements stops with:

0:00:00.827352748  5855  0x8dfa700 INFO      GST_ELEMENT_PADS
gstelement.c:887:gst_element_get_static_pad: found pad
preroll_audio_src1:sink
0:00:00.827372788  5855  0x8dfa700 INFO      GST_ELEMENT_PADS
gstelement.c:887:gst_element_get_static_pad: found pad
preroll_video_src0:sink

These seem not to be linked (can it be that these occur multipe times
in the tracing?)

The video & audio decoder, which are proprietery as well,
seem to be stuck in their gst_queue_push()

It is as if playbin thinks that all is done.
Why does it not continue creating the renderers (alsasink/xvimagesink).
It seldom goes into the PLAYING state.
(1 in 30 times it may start playing though).

I'm out of inspiration on what might be wrong ...

When the qtdemux is selected by playbin, all works as expected,
I think the qtdemux might not operate in pull scheduling though.
That's why I think the problem is in the mp4 demuxer
(not in the other proprietary decoders).

Thanks in advance,
francis

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Tue, 2008-11-25 at 15:53 +0100, franchan wrote:

> Hello,
>
> [I made some wrong conclusions and added corrections at the end]
>
> I seek some suggestions to find a bug in my own mp4 demuxer.
> This is actually a wrapper around a proprietary mp4 parser.
> (For inspiration I looked into qtdemux, so it is based on that pull scheduling).
> The demuxer only support pull scheduling
> (I seem to better understand that operation model).
>
> The pipeline works fine when it is "hard-coded" e.g.
> filesrc ! mp4demux name=demux \
>   demux.video_01! queue ! video_decoder ! ffmpegcolorspace! xvimagesink \
>   demux.audio_01! queue ! audio_decoder ! audioconvert ! alsasink
>
> When I use the playbin to create my pipeline,
> typefinding works fine until a certain point:
> source links with demux links the video and audio queues (always in that order).
>
> But further linking the pipeline is not happening anymore.
> My correction: the alsa/xvimagesink sinks are created,
> as well, the different converters (aconv/abin/resampler/vscale/vconc/)
> The tracing information regarding linking elements stops with:
>
> 0:00:00.827352748  5855  0x8dfa700 INFO      GST_ELEMENT_PADS
> gstelement.c:887:gst_element_get_static_pad: found pad
> preroll_audio_src1:sink
> 0:00:00.827372788  5855  0x8dfa700 INFO      GST_ELEMENT_PADS
> gstelement.c:887:gst_element_get_static_pad: found pad
> preroll_video_src0:sink
>
> These seem not to be linked (can it be that these occur multipe times
> in the tracing?)
>
> The video & audio decoder, which are proprietery as well,
> seem to be stuck in their gst_queue_push()
>
> It is as if playbin thinks that all is done.
> Why does it not continue creating the renderers (alsasink/xvimagesink).
> It seldom goes into the PLAYING state.
> (1 in 30 times it may start playing though).
>
> I'm out of inspiration on what might be wrong ...

I can keep on guessing...maybe you are not setting caps on the dynamic
pads before adding them?

Wim

>
> When the qtdemux is selected by playbin, all works as expected,
> I think the qtdemux might not operate in pull scheduling though.
> That's why I think the problem is in the mp4 demuxer
> (not in the other proprietary decoders).
>
> Thanks in advance,
> francis
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel