http://neuron2.net/misc/rp227.pdf is the spec

In theory this should've been fixed by this commit but the sample file does not work for me.

commit 1a9b54b7818b59786c524ff2604fd58cf926d3b7
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Fri Aug 7 19:00:23 2009 +0200

    mpegtsdemux: added VC1, EAC3 and LPCM related to blueray/hdmv

ffdec_vc1 won't accept the data output from mpegtsdemux because it a) doesn't have any extradata b) isn't packetised

I think the best way to handle this is a parser element that gets plugged on the output of mpegtsdemux a-la mpegvideoparse and friends. It needs to pull the sequence and entry point headers out of the stream and put them on the caps.

*** Bug 592547 has been marked as a duplicate of this bug. ***

Can someone either confirm this is still the issue, or provide a sample (the one from comment #0 no longer exists) ?

It's still an issue in the sense that these files don't play because of what Jan wrote in comment #3.

If this is an issue with tsdemux or just indicates that we need a vc1 parser to be autoplugged that does conversions, I don't kow.

Jan's comment is from 2009, that's why I want someone to *confirm* that it's still an issue.

I herewith confirm that it is still an issue.

great, got a sample ?

I found http://samples.mplayerhq.hu/ffmpeg-bugs/roundup/issue414/sample-no-video-vc1.m2ts

(In reply to comment #6)
> It's still an issue in the sense that these files don't play because of what
> Jan wrote in comment #3.

Correct

> 
> If this is an issue with tsdemux or just indicates that we need a vc1 parser to
> be autoplugged that does conversions, I don't kow.

It's an issue regarding avdec_vc1. tsdemux is providing all the available info (there's nothing else in the PMT regarding that stream).

fwiw, vlc implemented a packetizer (their term for parser) for vc1 in order to handle these files.

We do have a vc1parser but it has a rank of none, and adding it manually between tsdemux and avdec_vc1 doesn't change anything.

Adjusting bug title accordingly.

At a quick glance, it doesn't look like vc1parse does what avdec_vc1 would need it to do: Suck the header packets out of the stream and put them into the caps. The avdec VC1 decoder can't handle the stream unless it gets given the header packets as extradata - it can't get them from the stream on its own for whatever reason.

To be honest ... I don't quite understand the vc1parse element behaviour.

Theoretically it should behave like the h264parse element. That is, continually scan the input until it detects SPS/PPS, at that point it negotiates and sets output caps and outputs data from that point on.

Right now vc1parse is using the GstBaseParse::detect vmethod ... and seems to massively fail at that.

Note that vc1parse *does* set the codec_data expected from avdec_vc1 (puts the seqhdr and entrypoint in it). It's just the part before which is weird.

So the code seems correct, just that it assumes the incoming stream to start from a "access unit" (in generic terms) starting point. It will therefore fail with streams that are not like that (such as those coming from mpeg-ts).

Bumping to blocker, we need to be able to play those files by 1.2

Why? It's not a regression, and making vc1parse autoplugged is likely to cause more issue than it fixes at this stage, I'm not very keen on it.

One could make demuxer + decoder set stream-format bits, so that playbin recognises that there's no suitable decoder/parser and ignores the video stream. Or maybe it's enough to enable a parser in libav for vc1?

Yes, not a blocke because of what Tim said. If someone wants to fix that before 1.2 that would be nice nonetheless but we shouldn't wait for it ;)

Looking at the VC1 parser, it also seems to fail with GST_FLOW_ERROR in many places, instead of just complaining and moving on.

fwiw, the error still happens with git of today

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/9.