GNOME Bugzilla – Bug 584104
MPEG1 ps container doesn't play with playbin2 and custom sinks
Last modified: 2009-08-10 23:32:38 UTC
Please describe the problem: i am working on the dreambox again and somebody discovered mpeg 1 clips which don't play correctly anymore now that we switched over to playbin2. when plugging a manual pipeline, the playback of both the mpeg 1 video and the mpeg 1 layer 2 audio stream went fine. Steps to reproduce: 1. gst-launch filesrc location=Futurama_S1E01.mpg ! flupsdemux name=d ! video/mpeg ! { queue ! dvbvideosink } d. ! audio/mpeg ! { queue ! dvbaudiosink} 2. gst-launch playbin2 uri=file:///media/hdd/movie/mpeg1/Futurama_S1E01.mpg Actual results: 1. plays fine 2. no audio and video stops after a second Expected results: the playbin2 pipeline to play correctly like the manual one Does this happen every time? yes Other information: log file to be uploaded, link to an example video upon request
Created attachment 135488 [details] log files of mpeg1 playbin2 problem root@dm8000:/media/hdd/movie/mpeg1# GST_DEBUG=*:5 gst-launch --gst-debug-no-color filesrc location=Futurama_S1E01.mpg ! flupsdemux name=d ! video/mpeg ! { queue ! dvbvideosink } d. ! audio/mpeg ! { queue ! dvbaudiosink} >logfile_manuell.log 2>&1 root@dm8000:/media/hdd/movie/mpeg1# GST_DEBUG=*:5 gst-launch --gst-debug-no-color playbin2 uri=file:///media/hdd/movie/mpeg1/Futurama_S1E01.mpg >logfile_playbin2.log 2>&1
now also AVI files appeared that show the same behaviour: video playback starts without sound and after a second stops again
ftp://test4711@82.149.226.170/No_more_Star_Trek.mpg <- works ftp://test4711@82.149.226.170/Futurama_S1E01.mpg <- buggy avi will follow as soon as i've laid hands on it
Created attachment 135765 [details] [review] possible patch This patch makes the initial stream finding use up to a maximum of 2MB of memory. The idea is that for badly muxed streams we are not so much concerned about the amount of time that we need to check but that we check as much as we possibly can without using up too much memory. 2MB is still an arbitrary limit but it seems reasonable. After streams are detected, we lower the multiqueue limits again so that the queue sizes slowly drop to a 5 buffers mininum.
this didn't fix the issue... instead, also mpeg1 files that used to work before, preroll endlessly now.
That futurame mpeg has an SCR wraparound but the PTS does not wrap with it. We fail to generate the right timestamps for this file. The patch in comment #4 makes it preroll correctly, though (but then hangs on the wrong video timestamp)
i see! annoyingly enough with the wraparound. but for me, with the patch, No_more_Star_Trek.mpg fails too :/
This patch is the right thing to do so I commited it. Please provide files that fail. commit f444f0edce37af2126547b85c8b5b8cd213c43ac Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Jun 5 16:49:58 2009 +0200 decodebin2: increase stream probing queues When we are probing for streams, we want to set the queue size in such a way that we can scan a maximum amount of data without consuming too much memory. Therefore, remove the time limit on the queue and only stop scanning after 2MB of data. See #584104.
with varargs patch ef1030ee6e8f7ce8fbdd035c8e407c039e043da3 issue is now from my side acknowledged solved! thanks a lot and have a nice weekend