Hello,
I have been successful in using gstreamer and its plugins to play majority of the video file formats within Qt Phonon with gstreamer backend. I'd like to thank all contributors of the gstreamer for creating this fantastic media framework! I am able to play most of the Quicktime videos with gst-ffmpeg plugin with an exception to one particular HD Quicktime video. I am able to play the file with ffmpeg just fine, but gstreamer compains that it cannot handle the file. Here is my command line pipeline that duplicates the problem: ./gst-launch playbin uri=file:///0002DC.mov And the message I receive: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ** Message: don't know how to handle video/x-gst-fourcc-dvhp, width=(int)960, height=(int)720, framerate=(fraction)2997/50, pixel-aspect-ratio=(fraction)1/1 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstAudioSinkClock Got EOS from element "playbin0". Execution ended after 14914789298 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... Seeing that ffmpeg already knows how to handle the dvhp codec, I am thinking that ffmpeg plugin is not including the 'video/x-gst-fourcc-dvhp' caps although it can handle it. What are your thoughts? Any insight would be appreciated. Thank you very much! -- Jin _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hello,
I have an update to this issue. It seems that qtdemux bin doesn't know to forward the dvhp codec to an appropriate caps, and defaults to the following line in qtdemux.c: (line 9071 to 9080) case GST_MAKE_FOURCC ('k', 'p', 'c', 'd'): default: { char *s; s = g_strdup_printf ("video/x-gst-fourcc-%" GST_FOURCC_FORMAT, GST_FOURCC_ARGS (fourcc)); caps = gst_caps_new_simple (s, NULL); break; } I'm going to try to add to this method to properly assign a caps so that ffmpeg plugin can pick up on the media with dvhp codec.. As always, any input will be greatly appreciated. Thanks! -- Jin On Thursday 12 May 2011 6:48:07 pm jin wrote: > Hello, > > I have been successful in using gstreamer and its plugins to play majority > of the video file formats within Qt Phonon with gstreamer backend. I'd > like to thank all contributors of the gstreamer for creating this > fantastic media framework! > > I am able to play most of the Quicktime videos with gst-ffmpeg plugin with > an exception to one particular HD Quicktime video. I am able to play the > file with ffmpeg just fine, but gstreamer compains that it cannot handle > the file. > > Here is my command line pipeline that duplicates the problem: > ./gst-launch playbin uri=file:///0002DC.mov > > And the message I receive: > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > ** Message: don't know how to handle video/x-gst-fourcc-dvhp, > width=(int)960, height=(int)720, framerate=(fraction)2997/50, > pixel-aspect-ratio=(fraction)1/1 Pipeline is PREROLLED ... > Setting pipeline to PLAYING ... > New clock: GstAudioSinkClock > Got EOS from element "playbin0". > Execution ended after 14914789298 ns. > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > Seeing that ffmpeg already knows how to handle the dvhp codec, I am > thinking that ffmpeg plugin is not including the 'video/x-gst-fourcc-dvhp' > caps although it can handle it. > > What are your thoughts? > Any insight would be appreciated. > > Thank you very much! > -- Jin Soho VFX _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Fri, 2011-05-13 at 17:24 -0400, jin wrote:
Hi, as you suspect it's a mapping issue, either just in qtdemux (and other demuxers possibly) or also in gst-ffmpeg. It would be good if you could file a bug in bugzilla ( http://gstreamer.freedesktop.org/bugs/ ) and make sample file available somewhere (even the first 1MB of the file might be useful already: head --bytes=990k foo.mov > start.mov) If you can come up with a patch, that'd be even better of course (add it to the bug in bugzilla then please). Thanks! Cheers -Tim > I have an update to this issue. It seems that qtdemux bin doesn't know to > forward the dvhp codec to an appropriate caps, and defaults to the following > line in qtdemux.c: > > (line 9071 to 9080) > case GST_MAKE_FOURCC ('k', 'p', 'c', 'd'): > default: > { > char *s; > > s = g_strdup_printf ("video/x-gst-fourcc-%" GST_FOURCC_FORMAT, > GST_FOURCC_ARGS (fourcc)); > caps = gst_caps_new_simple (s, NULL); > break; > } > > I'm going to try to add to this method to properly assign a caps so that > ffmpeg plugin can pick up on the media with dvhp codec.. > > > As always, any input will be greatly appreciated. > > Thanks! > -- > Jin > > > On Thursday 12 May 2011 6:48:07 pm jin wrote: > > Hello, > > > > I have been successful in using gstreamer and its plugins to play majority > > of the video file formats within Qt Phonon with gstreamer backend. I'd > > like to thank all contributors of the gstreamer for creating this > > fantastic media framework! > > > > I am able to play most of the Quicktime videos with gst-ffmpeg plugin with > > an exception to one particular HD Quicktime video. I am able to play the > > file with ffmpeg just fine, but gstreamer compains that it cannot handle > > the file. > > > > Here is my command line pipeline that duplicates the problem: > > ./gst-launch playbin uri=file:///0002DC.mov > > > > And the message I receive: > > Setting pipeline to PAUSED ... > > Pipeline is PREROLLING ... > > ** Message: don't know how to handle video/x-gst-fourcc-dvhp, > > width=(int)960, height=(int)720, framerate=(fraction)2997/50, > > pixel-aspect-ratio=(fraction)1/1 Pipeline is PREROLLED ... > > Setting pipeline to PLAYING ... > > New clock: GstAudioSinkClock > > Got EOS from element "playbin0". > > Execution ended after 14914789298 ns. > > Setting pipeline to PAUSED ... > > Setting pipeline to READY ... > > Setting pipeline to NULL ... > > Freeing pipeline ... > > > > Seeing that ffmpeg already knows how to handle the dvhp codec, I am > > thinking that ffmpeg plugin is not including the 'video/x-gst-fourcc-dvhp' > > caps although it can handle it. > > > > What are your thoughts? > > Any insight would be appreciated. > > > > Thank you very much! > > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hello, I was able to implement a workaround to get ffmpeg to handle video/x-
dv. I'm sorry I could not provide you with the sample of video due to the sensitive nature of the contents (movie industry), but I will file a formal bug with the sample attached if I get a clearance to provide you with one. Overview of the solution 1) (in gst-plugins-good) - qtdemux.c: qtdemux_video_caps add case GST_MAKE_FOURCC ('d', 'v', 'h', 'p'): just below case GST_MAKE_FOURCC ('d', 'v', 'h', '6'): This makes qtdemux recognize dvhp codec (and forward the information to be matched with available decoder) (This alone will make libdv plugin to pickup the dvhp codec, but the video output is all jumbled up when using libdv plugin. I was not able to verify if it is a problem on gstreamer's libdv plugin of on libdv libraries itself) (The following steps enable dvhp playback using ffmpeg) 2) if libdv was enabled in good plugins (meaning libdv was installed and no -- disable-libdv was specified in configure time of the good plugins) (in gst-ffmpeg) - gstffmpegdec.c: gst_ffmpegdec_register move case CODEC_ID_DVVIDEO: to just below case CODEC_ID_COOK: so that ffmpeg will be flagged as a primary handler of video/x-dv codec (in gst-plugins-good) - gstdv.c: plugin_init change if (!gst_element_register (plugin, "dvdemux", GST_RANK_PRIMARY, to if (!gst_element_register (plugin, "dvdemux", GST_RANK_SECONDARY, and change if (!gst_element_register (plugin, "dvdec", GST_RANK_PRIMARY, to if (!gst_element_register (plugin, "dvdec", GST_RANK_MARGINAL so that even if libdv plugin is installed, it will give way to ffmpeg plugin when handling video/x-dv. 3) (in gst-ffmpeg) gstffmpegcodecmap.c: gst_ff_vid_caps_new replace the following code case CODEC_ID_DVVIDEO: { static struct { guint32 csp; gint width, height; gint par_n, par_d; gint framerate_n, framerate_d; } profiles[] = { { GST_MAKE_FOURCC ('Y', '4', '1', 'B'), 720, 480, 10, 11, 30000, 1001}, { GST_MAKE_FOURCC ('Y', '4', '1', 'B'), 720, 480, 40, 33, 30000, 1001}, { GST_MAKE_FOURCC ('I', '4', '2', '0'), 720, 576, 59, 54, 25, 1}, { GST_MAKE_FOURCC ('I', '4', '2', '0'), 720, 576, 118, 81, 25, 1}, { GST_MAKE_FOURCC ('Y', '4', '1', 'B'), 720, 576, 59, 54, 25, 1}, { GST_MAKE_FOURCC ('Y', '4', '1', 'B'), 720, 576, 118, 81, 25, 1} }; GstCaps *temp; gint n_sizes = G_N_ELEMENTS (profiles); caps = gst_caps_new_empty (); for (i = 0; i < n_sizes; i++) { temp = gst_caps_new_simple (mimetype, "width", G_TYPE_INT, profiles[i].width, "height", G_TYPE_INT, profiles[i].height, "framerate", GST_TYPE_FRACTION, profiles[i].framerate_n, profiles[i].framerate_d, "pixel-aspect-ratio", GST_TYPE_FRACTION, profiles[i].par_n, profiles[i].par_d, NULL); gst_caps_append (caps, temp); } break; } with this case CODEC_ID_DVVIDEO: { GstCaps *temp; caps = gst_caps_new_empty (); temp = gst_caps_new_simple (mimetype, NULL); gst_caps_append (caps, temp); break; } This way, we are removing very specific caps (saying "I can handle video/x-dv only if width is 500, height is 300, framerate is 60, pixel aspect ratio is 1.5, or I can handle video/x-dv only if width is 500, height is 300, framerate is 50, pixel aspect ratio is 1.5, or etc") that ffmpeg registers to gstreamer regarding what kind of video/x-dv it can handle and adding a generic "I can handle any kind of video/x-dv" declaration. background info on the caps matching (as I understand it): gstdecodebin (responsible for automatically finding the decoder that can handle the video stream - matches the video stream's caps to the available decoders' caps) uses gstelementfactory.c: gst_element_factory_list_filter, pass in list of decoder elements and the video caps to for the matching of the caps (matching video stream's caps to decoder's caps). The factory, in turn, looks to match a more specific caps (video stream's caps, e.g. video/x-dv, height:500, width: 400, framerate:60, etc) to a more generic caps (decoders' caps e.g. video/x-dv). If the decoder's list of caps is subset of the video stream's caps (like the above examples), then it means that the decoder has broader capabilities, some of which can be used to decode the video stream. ffmpeg will NOT pick up the video/x-dv stream with all the specific caps it declares because qtdemux always declares the dv video stream with the broadest caps ("video/x-dv"), which will never match with any decoder with anything more restricted than just ("video/x-dv"). Thank you! -- Jin On Friday 13 May 2011 6:14:09 pm Tim-Philipp Müller wrote: > On Fri, 2011-05-13 at 17:24 -0400, jin wrote: > > Hi, > > as you suspect it's a mapping issue, either just in qtdemux (and other > demuxers possibly) or also in gst-ffmpeg. > > It would be good if you could file a bug in bugzilla > ( http://gstreamer.freedesktop.org/bugs/ ) and make sample file > available somewhere (even the first 1MB of the file might be useful > already: head --bytes=990k foo.mov > start.mov) > > If you can come up with a patch, that'd be even better of course (add it > to the bug in bugzilla then please). > > Thanks! > > Cheers > -Tim > > > I have an update to this issue. It seems that qtdemux bin doesn't know to > > forward the dvhp codec to an appropriate caps, and defaults to the > > following line in qtdemux.c: > > > > (line 9071 to 9080) > > case GST_MAKE_FOURCC ('k', 'p', 'c', 'd'): > > default: > > { > > char *s; > > > > s = g_strdup_printf ("video/x-gst-fourcc-%" GST_FOURCC_FORMAT, > > GST_FOURCC_ARGS (fourcc)); > > caps = gst_caps_new_simple (s, NULL); > > break; > > } > > > > I'm going to try to add to this method to properly assign a caps so that > > ffmpeg plugin can pick up on the media with dvhp codec.. > > > > > > As always, any input will be greatly appreciated. > > > > Thanks! > > -- > > Jin > > > > On Thursday 12 May 2011 6:48:07 pm jin wrote: > > > Hello, > > > > > > I have been successful in using gstreamer and its plugins to play > > > majority of the video file formats within Qt Phonon with gstreamer > > > backend. I'd like to thank all contributors of the gstreamer for > > > creating this fantastic media framework! > > > > > > I am able to play most of the Quicktime videos with gst-ffmpeg plugin > > > with an exception to one particular HD Quicktime video. I am able to > > > play the file with ffmpeg just fine, but gstreamer compains that it > > > cannot handle the file. > > > > > > Here is my command line pipeline that duplicates the problem: > > > ./gst-launch playbin uri=file:///0002DC.mov > > > > > > And the message I receive: > > > Setting pipeline to PAUSED ... > > > Pipeline is PREROLLING ... > > > ** Message: don't know how to handle video/x-gst-fourcc-dvhp, > > > width=(int)960, height=(int)720, framerate=(fraction)2997/50, > > > pixel-aspect-ratio=(fraction)1/1 Pipeline is PREROLLED ... > > > Setting pipeline to PLAYING ... > > > New clock: GstAudioSinkClock > > > Got EOS from element "playbin0". > > > Execution ended after 14914789298 ns. > > > Setting pipeline to PAUSED ... > > > Setting pipeline to READY ... > > > Setting pipeline to NULL ... > > > Freeing pipeline ... > > > > > > Seeing that ffmpeg already knows how to handle the dvhp codec, I am > > > thinking that ffmpeg plugin is not including the > > > 'video/x-gst-fourcc-dvhp' caps although it can handle it. > > > > > > What are your thoughts? > > > Any insight would be appreciated. > > > > > > Thank you very much! > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > -- Jin Soho VFX _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Thu, Jun 16, 2011 at 12:55:02PM -0400, jin wrote:
> Hello, I was able to implement a workaround to get ffmpeg to handle video/x- > dv. I'm sorry I could not provide you with the sample of video due to the > sensitive nature of the contents (movie industry), but I will file a formal > bug with the sample attached if I get a clearance to provide you with one. > > Overview of the solution > 1) (in gst-plugins-good) > - qtdemux.c: qtdemux_video_caps > add > case GST_MAKE_FOURCC ('d', 'v', 'h', 'p'): > > just below > case GST_MAKE_FOURCC ('d', 'v', 'h', '6'): Please create a patch and put it in a bugzilla bug report. > (This alone will make libdv plugin to pickup the dvhp codec, but the video > output is all jumbled up when using libdv plugin. I was not able to verify if > it is a problem on gstreamer's libdv plugin of on libdv libraries itself) It's a problem in libdv, it only supports 25 Mbit/sec DV. We need to add a field to the video/x-dv caps to indicate the variety, and then make the libdv-based plugin disallow the ones it doesn't support. (I can do this, just remind me in the bug report that you'll be filing above.) > so that ffmpeg will be flagged as a primary handler of video/x-dv codec See https://bugzilla.gnome.org/show_bug.cgi?id=595286 David _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |