GNOME Bugzilla – Bug 679838
asfdemux fails to demux audio
Last modified: 2012-08-06 12:57:46 UTC
Created attachment 218686 [details] sample media that show the problem gstreamer often fails to detect audio in some http asf streams, only the video is detected while vlc,mplayer etc. work every time. Attached a test stream captured with: curl http://... > /tmp/stream.raw you can play and hear audio with vlc,mplayer,ffplay but not with gstreamer the video is jpeg while the audio is adpcm, here is the error: gst-launch -v filesrc location=/tmp/stream.raw ! asfdemux ! adpcmdec ! alsasink sync=false Impostazione della pipeline a PAUSED ... La pipeline è in PREROLLING ... ERRORE: dall'elemento /GstPipeline:pipeline0/GstASFDemux:asfdemux0: Errore interno dello stream di dati. Informazioni di debug aggiuntive: gstasfdemux.c(1674): gst_asf_demux_loop (): /GstPipeline:pipeline0/GstASFDemux:asfdemux0: streaming stopped, reason not-linked ERRORE: la pipeline non vuole fare il preroll. Impostazione della pipeline a NULL ... /GstPipeline:pipeline0/GstASFDemux:asfdemux0.GstPad:video_00: caps = NULL Esecuzione di free sulla pipeline... if I capture the media with curl several times (or connect to the live stream several times) sometime the above pipeline work
This makes it at least stop with EOS: commit fb8a3d2174005ee07649415cf09229f6ca5ee60c Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Jul 13 11:36:40 2012 +0200 asf: don't push on inactive streams
Created attachment 218697 [details] sample media that gstreamer play fine this file is captured with curl as the previous one but this time gstreamer can play it just fine: gst-launch -v filesrc location=/tmp/stream1.asf ! asfdemux ! adpcmdec ! alsasink sync=false Impostazione della pipeline a PAUSED ... La pipeline è in PREROLLING ... /GstPipeline:pipeline0/ADPCMDec:adpcmdec0.GstPad:sink: caps = audio/x-adpcm, layout=(string)dvi, rate=(int)8000, channels=(int)1, block_align=(int)164, codec_data=(buffer)4001 /GstPipeline:pipeline0/ADPCMDec:adpcmdec0.GstPad:src: caps = audio/x-raw-int, rate=(int)8000, channels=(int)1, width=(int)16, depth=(int)16, endianness=(int)1234, signed=(boolean)true /GstPipeline:pipeline0/GstAlsaSink:alsasink0.GstPad:sink: caps = audio/x-raw-int, rate=(int)8000, channels=(int)1, width=(int)16, depth=(int)16, endianness=(int)1234, signed=(boolean)true La pipeline è in PREROLLED ... Impostazione della pipeline a PLAYING ... New clock: GstAudioSinkClock Ottenuto EOS dall'elemento «pipeline0». Execution ended after 3451462718 ns. Impostazione della pipeline a PAUSED ... Impostazione della pipeline a READY ... /GstPipeline:pipeline0/GstAlsaSink:alsasink0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/ADPCMDec:adpcmdec0.GstPad:src: caps = NULL /GstPipeline:pipeline0/ADPCMDec:adpcmdec0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstASFDemux:asfdemux0.GstPad:audio_00: caps = NULL /GstPipeline:pipeline0/GstASFDemux:asfdemux0.GstPad:video_00: caps = NULL Impostazione della pipeline a NULL ... Esecuzione di free sulla pipeline... a working sample could be useful, thanks
enabling ffdemux_asf seems to solve the problem, Nicola
looking at the gst log for asfdemux I can see this: asfpacket.c:133:gst_asf_payload_queue_for_stream:<asfdemux0> Got payload for stream 1 ts:0:02:06.280000000 0:00:00.409618508 25207 0x21e9770 LOG asfdemux gstasfdemux.c:1199:all_streams_prerolled:<'':video_00> checking if 0:02:06.280000000 > 0:00:01.000000000 0:00:00.409630451 25207 0x21e9770 LOG asfdemux gstasfdemux.c:1190:all_streams_prerolled:<'':audio_00> no data queued 0:00:00.409640298 25207 0x21e9770 LOG asfdemux gstasfdemux.c:1270:gst_asf_demux_check_activate_streams:<'':video_00> is prerolled - activate! 0:00:00.409649797 25207 0x21e9770 INFO asfdemux gstasfdemux.c:2322:gst_asf_demux_activate_stream:<asfdemux0> Activating stream 1, pad video_00, caps image/jpeg, width=(int)640, height=(int)480, format=(fourcc)MJPG 0:00:00.409743035 25207 0x21e9770 LOG asfdemux gstasfdemux.c:1273:gst_asf_demux_check_activate_streams:<'':audio_00> no data, ignoring stream 0:00:00.409754628 25207 0x21e9770 DEBUG asfdemux so the first video frame has a timestamp more than 2 minutes and as soon as asfdemux get this ts ignore audio, the problem is that also the first timestamp for the audio is more than 2 minutes. Looking at the code seems that asfdemux assume that the fisrt ts is 0 from the asf header and not after receiving the first real frame, as workaround one can modify the arbitrary 500 ms here: http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/tree/gst/asfdemux/gstasfdemux.c?h=0.10#n1177 but this can have side effects, maybe we can simply wait for another payload if the difference beetween two consecutive timestamps is too big?
Created attachment 218948 [details] [review] allow at least a payload len of 10 this commit: http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?h=0.10&id=5ac4ea3f1b77655effba2346bfcaef8f13e7a120 added a check to wait at lease 500 ms for prerolling, but if the stream has discontinuities as the one posted the prerolling time is exceeded at the second frame, so add a check for the frame number too
these patchs: http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?id=fb8a3d2174005ee07649415cf09229f6ca5ee60c http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?id=0c6e50a7b8c0590c7aab8858607a568c70f17634 should be applied to 0.10 git too
Created attachment 218951 [details] [review] asfdemux: Convert invalid TS into GST_CLOCK_TIME_NONE I was looking at this file and saw that all buffers in the preroll have ts set to 0, which is equivalent of invalid time in the ASF format. Converting them to GST_TIME_CLOCK_NONE seems a decent solution.
thanks Nicolas, your patch works fine and is much better than the one I posted since the timestamps start at 0
commit 27fc66d14f3f9c519432545ec2897de2fe4569d9 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Mon Jul 16 17:36:19 2012 -0400 asfdemux: convert invalid 0 payload TS into GST_CLOCK_TIME_NONE ... so it does not get used as first (valid) payload ts, whereas the first real valid payload ts may be considerably larger. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679838
This seems to have caused an issue, see bug #681291 .