After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705026 - asfdemux: add support dvr-ms files
asfdemux: add support dvr-ms files
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other All
: Normal enhancement
: 1.1.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-28 14:41 UTC by Matej Knopp
Modified: 2017-11-13 10:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (23.56 KB, patch)
2013-07-28 14:45 UTC, Matej Knopp
committed Details | Review
Mpeg Timestamp Parser (4.99 KB, application/zip)
2013-07-29 08:00 UTC, Matej Knopp
  Details
Fix seeking in push mode (2.27 KB, patch)
2013-07-30 15:37 UTC, Matej Knopp
committed Details | Review
Patch to fix compilation on C89 compilers (1.02 KB, patch)
2013-07-31 23:35 UTC, Matej Knopp
committed Details | Review

Description Matej Knopp 2013-07-28 14:41:17 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).
Comment 1 Matej Knopp 2013-07-28 14:45:02 UTC
Created attachment 250304 [details] [review]
Patch
Comment 2 Matej Knopp 2013-07-28 14:53:47 UTC
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 3 Sebastian Dröge (slomo) 2013-07-29 07:30:05 UTC
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.
Comment 4 Matej Knopp 2013-07-29 07:37:47 UTC
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)
Comment 5 Matej Knopp 2013-07-29 07:58:49 UTC
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.
Comment 6 Matej Knopp 2013-07-29 08:00:37 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2013-07-29 08:08:43 UTC
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
Comment 8 Matej Knopp 2013-07-30 15:37:31 UTC
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.
Comment 9 Matej Knopp 2013-07-31 23:35:58 UTC
Created attachment 250566 [details] [review]
Patch to fix compilation on C89 compilers
Comment 10 Sebastian Dröge (slomo) 2013-08-08 09:56:56 UTC
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
Comment 11 Edward Hervey 2017-11-13 10:20:48 UTC
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.