How can I get full information about a media file?

[wl2776]

I need to know the number of streams in a file (video, audio, subtitles, etc).
How can I do this?

typefind element returns something simple and generic, like video/x-msvideo, or "video/mpeg, systemstream=(boolean)true, mpegversion=(int)2"

I tried to set up a pipeline: filesrc ! decodebin2 ! fakesink, but fakesink is not linked, and decodebin2 doesn't construct the same complex pipeline, like it did while included in the playbin2.

My code is the following:

GstElement *bin = gst_pipeline_new("playbin");
GstElement *filesrc = gst_element_factory_make("filesrc","filesrc");
g_object_set(G_OBJECT(filesrc),"location",g_convert(filename,-1,"UTF-8","CP1251",NULL,NULL,NULL),NULL);
GstElement *decodebin2 = gst_element_factory_make("decodebin2","decodebin");
GstElement *sink = gst_element_factory_make("fakesink","sink");
gst_bin_add_many(GST_BIN(bin),filesrc,decodebin2,sink,NULL);
gst_element_link_many(filesrc,decodebin2,sink,NULL);
GstElement *bus = (GstElement *)gst_pipeline_get_bus(GST_PIPELINE(m_player));
gst_bus_set_sync_handler (GST_BUS(bus), (GstBusSyncHandler)gst_bus_sync_handler, this);
gst_bus_add_watch (GST_BUS(bus), bus_call, this);
gst_object_unref(bus);

gst_element_set_state(GST_ELEMENT(bin),GST_STATE_PLAYING);

GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(bin),GST_DEBUG_GRAPH_SHOW_ALL,"decodebin");
gst_element_set_state(GST_ELEMENT(bin),GST_STATE_NULL);
gst_object_unref(bin);

The resulting dot file is this (50kb): decodebin.png
However, when I create a playbin2, the resutling dot file is this (500kb): player-full.png

Apparently, decodebin2 instance in the playbin is much more complex.
What am I doing wrong?

In order to save people's traffic, original dot files are here: decodebin.dot (3kb) decodebin.dot and playbin2.dot (22kb): player.dot

[lrn-2]

On 30.03.2010 19:11, wl2776 wrote:

> I need to know the number of streams in a file (video, audio, subtitles,
> etc).
> How can I do this?
>
> typefind element returns something simple and generic, like video/x-msvideo,
> or "video/mpeg, systemstream=(boolean)true, mpegversion=(int)2"
>
> I tried to set up a pipeline: filesrc ! decodebin2 ! fakesink, but fakesink
> is not linked, and decodebin2 doesn't construct the same complex pipeline,
> like it did while included in the playbin2.
>  

An approach that worked for me:

Create a pipeline, bus.
Create uridecodebin, set its uri property (or create filesrc, decodebin
and link them)
Set up "no-more-pads", "unknown-type" handlers
Add to pipeline, link.
Set pipeline to PAUSED
Pull messages from the bus and send them to your bus message handler
until it returns FALSE.

bus message handler should:
return FALSE on GST_MESSAGE_ASYNC_DONE
set pipeline state to NULL and return FALSE on GST_MESSAGE_EOS
memorize each tag from GST_MESSAGE_TAG messages (if you want to read tags)
return FALSE on error
otherwise return TRUE

"no-more-pads" handler should:
gst_element_iterate_src_pads of uridecodebin
each pad corresponds to a stream. You can also get stream caps (stream
information) there. To keep pipeline working you also have to extend
pipeline by linking elements to each pad (if you don't it will crash due
to being 'not-linked'). In your case fakesink should do the trick (since
you don't seem to be interested in data).

"unknown-type" handler will allow you to obtain stream caps for streams
that GStreamer can't decode (you might want them too).

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[wl2776]

lrn-2 wrote

An approach that worked for me:

Create a pipeline, bus.
Create uridecodebin, set its uri property (or create filesrc, decodebin
and link them)
Set up "no-more-pads", "unknown-type" handlers

Thank you! This almost works.
The problem is, the "no-more-pads" callback is not always called. It is called only if I trace my program in a debugger. If the program runs freely, it doesn't called.

My code is the following (error checking is omitted for brevity).
Big question is should I call gst_message_unref both in bus the cycle, polling a bus, and in bus_watch?

parse()
{
  gboolean r=TRUE;
  GstMessage *msg;

  m_pipeline = gst_pipeline_new("playbin");
  m_uridecodebin = gst_element_factory_make("uridecodebin","decode");

  g_object_set(G_OBJECT(m_uridecodebin),"uri",m_filename,NULL);
  g_signal_connect(G_OBJECT(m_uridecodebin),"no-more-pads",G_CALLBACK(no_more_pads_cb),this);
  g_signal_connect(G_OBJECT(m_uridecodebin),"unknown-type",G_CALLBACK(unknown_type_cb),this);

  gst_bin_add(GST_BIN(m_pipeline),m_uridecodebin);
  bus = gst_pipeline_get_bus(GST_PIPELINE(m_pipeline));

  gst_element_set_state(GST_ELEMENT(m_pipeline),GST_STATE_PAUSED);
       
  while ((msg = gst_bus_pop (bus)) && r) {
    r=bus_watch(bus, msg);
    gst_message_unref (msg);
  }
}

gboolean bus_watch(GstBus* bus, GstMessage *msg)
{
  if(msg->structure)
    gst_structure_foreach(msg->structure,foreach_func,msg);

  switch (GST_MESSAGE_TYPE (msg)) {
    case GST_MESSAGE_ASYNC_DONE:
      gst_message_unref(msg);
      return FALSE;
    case GST_MESSAGE_EOS:
      gst_element_set_state(GST_ELEMENT(m_pipeline),GST_STATE_NULL);
      gst_message_unref(msg);
      return FALSE;
    case GST_MESSAGE_TAG: //TODO collect tags
      break;
    default:
      break;
  }
  gst_message_unref(msg);
  return TRUE;
}

[lrn-2]

On 31.03.2010 18:49, wl2776 wrote:

>
> lrn-2 wrote:
>  
>> An approach that worked for me:
>>
>> Create a pipeline, bus.
>> Create uridecodebin, set its uri property (or create filesrc, decodebin
>> and link them)
>> Set up "no-more-pads", "unknown-type" handlers
>>
>>    
> Thank you! This almost works.
> The problem is, the "no-more-pads" callback is not always called. It is
> called only if I trace my program in a debugger. If the program runs freely,
> it doesn't called.
>
> My code is the following (error checking is omitted for brevity).
> Big question is should I call gst_message_unref both in bus the cycle,
> polling a bus, and in bus_watch?
>  

I've used this:

   while (TRUE)
   {
      GstMessage *msg = gst_bus_pop(mBus);
      if (msg)
      {
        if (!OnBusMessage(mBus,msg))
          break;
      }
   }

OnBusMessage() here doesn't call gst_message_unref() either. I don't
know, maybe it's a bug on my part.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wesley J. Miller]

Hi All,

I am looking to do some work with an Axis camera that supplies me an MJPEG stream. I am new to gstreamer so I need some startup help understanding what's going on.

I am using souphttpsrc as my source element.  The detected mime type from the camera after souphttpsrc is multipart/x-mixed-replace as expected.  

        gst-launch-0.10.exe -e souphttpsrc location="...?camera=2,  \
                width=320,height=240,framerate=(fraction)1/25" \
  do-timestamp=true is_live=true


If I now send this stream to a file, is it stored as MJPEG?  

        gst-launch-0.10.exe -e souphttpsrc location=... ! filesink location=soup.mjpg



FWIW, I tried a tool called JPLAYER from the net, a supposed mjpeg player.  It will play the "live" stream from http://10.xx.yy.zz but it won't play file:///.../soup.mjpg.  

Is MJPG a correct file type? (just in case jplayer is dumb enough to check the file extension and not the mime-type.)  The divx player can't play the file either.



However, the stored file will "play" using the same stream I use to see the live video feed.

        gst-launch-0.10.exe -e souphttpsrc location=... ! multipartdemux \
                ! jpegdec ! ffmpegcolorspace ! autovideosink

        // (swap filesrc for souphttpsrc)

        gst-launch-0.10.exe -e filesrc location=A.mjpg ! multipartdemux \
                ! jpegdec ! ffmpegcolorspace ! autovideosink



Piping from souphttpsrc into multipartdemux yields a mime-type of image/jpeg.  This is the type of each demuxed frame, right?

If I choose to store the output of the demuxer, does it remain a motion stream?  What type of file and/or stream is it?  Is there a preferred file extension for it?



If I attempt to play back the post-demuxer file, time elapses and the pipe terminates ok, but there is no output video shown.

        gst-launch-0.10.exe -e filesrc location=post-demux.jpg \
                ! jpegdec ! ffmpegcolorspace ! autovideosink



Thanks for the any help.  

Wes

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[wl2776]

lrn-2 wrote

   while (TRUE)
   {
      GstMessage *msg = gst_bus_pop(mBus);
      if (msg)
      {
        if (!OnBusMessage(mBus,msg))
          break;
      }
   }

OnBusMessage() here doesn't call gst_message_unref() either. I don't
know, maybe it's a bug on my part.

The documentation:
===
gst_bus_pop()
Returns :
The GstMessage that is on the bus, or NULL if the bus is empty. The message is taken from the bus and needs to be unreffed with gst_message_unref() after usage. MT safe.
===
So, one gst_message_unref() should be.

Now, when the pipeline is built, how can I get an information about the media?
I see only one way - gst_bin_iterate_... elements then, for each element iterate its pads and gst_pad_get_negotiated_caps().
By the way, gst_pad_get_negotiated_caps() returns null, when called right after gst_element_link_pads()
from the no-more-pads handler.

I'd like to somewhat shorten the procedure - for example, iterate sinks and iterate sink pads.
From what I've seen on the pictures, built by GST_DEBUG_BIN_TO_DOT_FILE, I need only decoder elements.
There is a function gst_bin_iterate_all_by_interface().
Is there any interface, that all decoders support?

However, this method also doesn't give a full information, if there is more than 2 streams in a file. As far as I understand, uridecodebin will not render more than two streams.

[lrn-2]

On 01.04.2010 13:17, wl2776 wrote:

>
> lrn-2 wrote:
>  
>>    while (TRUE)
>>    {
>>       GstMessage *msg = gst_bus_pop(mBus);
>>       if (msg)
>>       {
>>         if (!OnBusMessage(mBus,msg))
>>           break;
>>       }
>>    }
>>
>> OnBusMessage() here doesn't call gst_message_unref() either. I don't
>> know, maybe it's a bug on my part.
>>
>>    
> The documentation:
> ===
> gst_bus_pop()
> Returns :
> The GstMessage that is on the bus, or NULL if the bus is empty. The message
> is taken from the bus and needs to be unreffed with gst_message_unref()
> after usage. MT safe.
> ===
> So, one gst_message_unref() should be.
>
>  

Thanks, i'll remember that.
> Now, when the pipeline is built, how can I get an information about the
> media?
> I see only one way - gst_bin_iterate_... elements then, for each element
> iterate its pads and gst_pad_get_negotiated_caps().
> By the way, gst_pad_get_negotiated_caps() returns null, when called right
> after gst_element_link_pads()
> from the no-more-pads handler.
>  
In no-more-pads i've used gst_element_iterate_src_pads() on decodebin
element (with gst_iterator_next() and a standard gstiterator spell). For
each pad it returns you can gst_pad_get_caps(),
gst_caps_get_structure(), etc
> I'd like to somewhat shorten the procedure - for example, iterate sinks and
> iterate sink pads.
>  
srcs, not sinks. Src pads of decodebin are the output pads of decodebin.
Sink pads are the input pads. With filesrc ! decodebin pipeline you
should see only one sinkpad of decodebin - the one that gets raw data
from filesrc. Obviously, it is not interesting at all (sink pads never are).
> From what I've seen on the pictures, built by GST_DEBUG_BIN_TO_DOT_FILE, I
> need only decoder elements.
> There is a function gst_bin_iterate_all_by_interface().
> Is there any interface, that all decoders support?
>
>  
It is enough to iterate source pads of the bin as a whole, without
digging into its internal organs. By doing this you'll get all
decodeable streams of the source file, and 'unknown' handler will
provide some info on undecodeable streams.
> However, this method also doesn't give a full information, if there is more
> than 2 streams in a file. As far as I understand, uridecodebin will not
> render more than two streams.
>  
uridecodebin (or decodebin) will have one src pad for each decodeable
stream (regardless of how many streams there are).

P.S. GStreamer devs, am i explaining this wrong, or have i missed
something important in my explanation? I expected that by now someone
would comment on this discussion.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[wl2776]

lrn-2 wrote

In no-more-pads i've used gst_element_iterate_src_pads() on decodebin
element (with gst_iterator_next() and a standard gstiterator spell). For
each pad it returns you can gst_pad_get_caps(),
gst_caps_get_structure(), etc

I tried getting negotiated caps on the sink pads of the fakesinks, and they were null .

lrn-2 wrote

srcs, not sinks.
   
It is enough to iterate source pads of the bin as a whole, without
digging into its internal organs. By doing this you'll get all
decodeable streams of the source file, and 'unknown' handler will
provide some info on undecodeable streams.

Yes, I've realized about srcs.
I used gst_bin_iterate_recurse, because I also wanted to know the codec.

[lrn-2]

On 02.04.2010 14:50, wl2776 wrote:

>
> lrn-2 wrote:
>  
>> In no-more-pads i've used gst_element_iterate_src_pads() on decodebin
>> element (with gst_iterator_next() and a standard gstiterator spell). For
>> each pad it returns you can gst_pad_get_caps(),
>> gst_caps_get_structure(), etc
>>
>>    
> I tried getting negotiated caps on the sink pads of the fakesinks, and they
> were null .
>  

Well, probably because there was nothing negotiated between decodebin
and fakesinks at that moment (you've just linked them together,
negotiation takes place once the data flows).

>
> lrn-2 wrote:
>  
>> srcs, not sinks.
>>    
>> It is enough to iterate source pads of the bin as a whole, without
>> digging into its internal organs. By doing this you'll get all
>> decodeable streams of the source file, and 'unknown' handler will
>> provide some info on undecodeable streams.
>>
>>    
> Yes, I've realized about srcs.
> I used gst_bin_iterate_recurse, because I also wanted to know the codec.
>  

Generally you can't know the codec used to encode a stream, only data
format. That is, if it's H.264, it could have been encoded by any
H.264-compatible codec. While they often leave behind some marks to
identify, i do not think they are generally accessible from GStreamer.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[wl2776]

lrn-2 wrote

> I used gst_bin_iterate_recurse, because I also wanted to know the codec.
Generally you can't know the codec used to encode a stream, only data
format.

Yep, I meant the data format. I can find caps like video/mpeg, mpegversion=2, or audio/mpeg, mpegversion=4, from digging decodebin.

[Marc Leeman]

> FWIW, I tried a tool called JPLAYER from the net, a supposed mjpeg player.  It will play the "live" stream from http://10.xx.yy.zz but it won't play file:///.../soup.mjpg.  
> Is MJPG a correct file type? (just in case jplayer is dumb enough to check the file extension and not the mime-type.)  The divx player can't play the file either.

I don't know the format of a mjpeg file; but this command will just
store your jpeg files sequentially.

One JPEG after the other one.

If you send it on the network and listen to it again; you'll see that
you get one jpeg coming in after the other.

--
  greetz, marc
What is now proved was once only imagin'd.
                -- William Blake
crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel