GNOME Bugzilla – Bug 697665
Add format=WMV3 for WMV 3 video
Last modified: 2014-01-06 09:59:06 UTC
There is already format=WMVA and format=WVC1, but caps for WMV3 fourcc don't have any.
Created attachment 241087 [details] [review] Path for gstriff
Created attachment 241088 [details] [review] Patch for gstav
<__tim> slomo, the WMV3 one - sure, why not? <slomo> __tim: because backwards compatibility maybe :) <__tim> slomo, but we're not setting a format now for that, do we? <slomo> no <__tim> so how can adding the field cause problems? <__tim> anything that works now must already accept it without the field because of the stricter subset checks <__tim> so then it will accept it with the extra field as well, no? <slomo> __tim: avdec_wmv3 will have that on its sinkpad caps now... so demuxers must add that field to be able to link to avdec_wmv3 <__tim> oh I didn't see the decoder change, I thought you meant the riff change <__tim> tricky, I guess it mostly matters for third party demuxers, and the question is if anyone will use those without third party decoders <__tim> otherwise it should be ok to announce as something to look out for in the 1.2.0 release notes, if we think it makes sense <slomo> ok, it makes sense ;) and i'm not aware of any third party demuxers for 1.0 (yet) <__tim> AD-N770: any thoughts? <__tim> the other alternative might be to give vc1parse a rank and make it accept non-tagged input (?) <slomo> i don't think vc1parse is ready yet :) <__tim> k
<AD-N770> __tim, slomo: was distracted with my code <AD-N770> what's the topic? <slomo> AD-N770: https://bugzilla.gnome.org/show_bug.cgi?id=697665 and backwards compatibility <slomo> AD-N770: do you have a custom asf demuxer in 1.0 still? <AD-N770> yes <__tim> AD-N770, if changing avdec_wmv3 from video/x-wmv to video/x-wmv,format=WMV3 would cause problems (it might with custom demuxers/parsers that don't set that additional field) <__tim> the question is if anyone is likely to ever use your demuxer with gst-libav codecs <__tim> or if it's more of a theoretical issue <AD-N770> no, that's the expected caps <AD-N770> our fluasfdemux produces video/x-wmv, format = { WMV3, WMVA, WVC1) <slomo> AD-N770: it's already having format=WMV3? :) <slomo> great <AD-N770> and decoder expects it <__tim> excellent
Comment on attachment 241087 [details] [review] Path for gstriff commit 90620b236ac1cd3b037338c1d1b4f44aff9ce0b9 Author: Matej Knopp <matej.knopp@gmail.com> Date: Tue Apr 9 22:07:15 2013 +0200 riff: add format=WMV3 for WMV 3 caps https://bugzilla.gnome.org/show_bug.cgi?id=697665
commit 710c92d83063d5bfb02f9dc13c060790ccafb81d Author: Matej Knopp <matej.knopp@gmail.com> Date: Tue Apr 9 22:13:42 2013 +0200 av: Add WMV3 format for WMV 3 caps
For what it's worth, this libav commit caused a regression. What we were missing is that avdec_wmv3 previously also handled files with format=WMVA in addition to those with format=WMV3, and adding the format=WMV3 on avdec_wmv3's sink pad template caps now means it won't be plugged any more for that.
I though WMVA was handled by the VC1 decoder
It wasn't apparently :) I'm fixing it.
commit 8770f227359897e42000ea044ff99f0c4a9daccc Author: Tim-Philipp Müller <tim@centricular.com> Date: Fri Jan 3 15:58:26 2014 +0000 avcodecmap: fix regression with wmv3 video in WMVA format The VC-1 decoder should handle that. Before avdec_wmv3 handled it, but then we added format=WMV3 to its sink pad template caps, at which point nothing handled WMVA any longer. https://bugzilla.gnome.org/show_bug.cgi?id=697665