GNOME Bugzilla – Bug 705026
asfdemux: add support dvr-ms files
Last modified: 2017-11-13 10:20:48 UTC
dvr-ms are asf files (with some extensions) that can contain mpeg-2 video and mp2 or ac-3 audio. In order to support dvr-ms few things need to be done: 1) Audio streams are declared in stream-specific data of streams with type guid ASF_STREAM_EXT_EMBED_HEADER 2) payload timestamps are stored in replicated data extension (ASF_PAYLOAD_EXTENSION_TIMING). These timestamps should replace original payload timestamps. 3) Setting demux->first_ts must be delayed until there are payload in every stream. This is because of 2). It is possible now that packet P2 from stream Y is stored after packet P1 from stream X, but pts(P2) < pts(P1). This is addressed this by calculating first_ts during activation. 4) Audio stream codecTag can not be used to determine caps. It is unreliable and often set to wrong value. The only reliable way seems to be inspect payload data. Apart from these some other minor things are addressed, such as ignoring warnings for payload from streams that were declared (just not supported).
Created attachment 250304 [details] [review] Patch
Some sample files can be found here https://s3.amazonaws.com/MatejK/Samples/dvr-ms-samples.zip They all play well in Windows Center and with gstreamer (after the patch). Not so well in VLC.
Comment on attachment 250304 [details] [review] Patch The patch looks good but that doesn't seem to be complete. For example Test21.dvr-ms and today.dvr-ms are playing very... bursty. Play a few frames, stop, play a few frames, stop, etc. Some others play fine though.
They play fine for me, but I have an extra filter that fixes missing mpeg 2 timestamps, maybe that's the issue? (currently mpeg video parser doesn't do that)
I can confirm that I have the same effect when I remove the timestamp fixing element. But it also breaks playback of some other mpeg files for me (in other containers). I don't think the demuxer should be attempting to fix the timestamps. I anything this should probably be added to parser.
Created attachment 250349 [details] Mpeg Timestamp Parser This is the plugin I'm currently using to fix mpeg timestamps. Without it many mpeg files play wrong. If there is interest I can make patch for mpegvideoparse. In any case, I don't think it's demuxer that's at fault here.
Thanks, that makes sense. I didn't look closer. Can you open a bug for that? commit 1803b3c18530cb0100d140c2b8e49a8dfe41f941 Author: Matej Knopp <matej.knopp@gmail.com> Date: Sun Jul 28 16:43:28 2013 +0200 asfdemux: Add support for dvr-ms https://bugzilla.gnome.org/show_bug.cgi?id=705026
Created attachment 250481 [details] [review] Fix seeking in push mode There was a regression. The first patch broke seeking in push mode, this one should fix it.
Created attachment 250566 [details] [review] Patch to fix compilation on C89 compilers
commit fad302b57385af058ea2e0add54f08984e3b6699 Author: Matej Knopp <matej.knopp@gmail.com> Date: Thu Aug 1 01:34:05 2013 +0200 asfdemux: fix build on C89 compilers commit f27c832011a96a277bcabdb0a858077a42b46ebc Author: Matej Knopp <matej.knopp@gmail.com> Date: Tue Jul 30 17:28:17 2013 +0200 asfdemux: fix seeking in push mode
fwiw, I had to push this to fix a regression that was introduced by those patches. afaics it shouldn't break the dvr-ms feature. commit f86751d9f7a90ceea7a331edb5f54b314e7e3dd3 (HEAD -> master, origin/master, origin/HEAD) Author: Edward Hervey <edward@centricular.com> Date: Mon Nov 13 11:13:30 2017 +0100 asfdemux: Fix prerolling files with "empty" streams This is a regression that was introduced by commit 1803b3c18530cb0100d140c2b8e49a8dfe41f941 " asfdemux: Add support for dvr-ms" The problem is that some files/streams might contain stream definition but there is no actual packets for those streams. This was used to "define" streams with different bitrates for example. The first_ts calculation resulted in never ever finding a valid first_ts since some streams were empty, and therefore never "activating" itself. Instead of that we first check if we are prerolled. And if we are we unconditionally get the "first_ts" The preroll check has been adapted to check whether streams of each defined type (i.e. audio/video/sub) has been prerolled. This solves the problem of having different streams of a particular type where only one stream actually has data.