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 771707 - avidemux: h264 variant itu, regression from 0.10
avidemux: h264 variant itu, regression from 0.10
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-20 11:42 UTC by Nicola
Modified: 2018-11-03 15:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
avidemux: make sure H264 caps always have stream-format set (1.33 KB, patch)
2016-09-20 13:20 UTC, Tim-Philipp Müller
none Details | Review

Description Nicola 2016-09-20 11:42:24 UTC
I have an avi with h264 variant itu, here are the caps:

video/x-h264, variant=(string)itu, framerate=(fraction)120/1, width=(int)320, height=(int)240, codec_data=(buffer)2000000127644014ac2b40a0fd8088000003000800000301e42000000128ee1f2c0000000000000000000000000000000000

this file works fine in 0.10 but in 1.0 give not negotiated, in 0.10 ffdec_h264 show sink caps as:

SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-h264
                  width: [ 16, 4096 ]
                 height: [ 16, 4096 ]
              framerate: [ 0/1, 2147483647/1 ]

while in 1.0 the format are restricted:

SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-h264
              alignment: au
          stream-format: { avc, byte-stream }


if I change avdec_h264 so that gst-inspect shows this:

SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-h264

then the file plays fine,

is this acceptable? Do you have other suggestions for a better patch?
Comment 1 Tim-Philipp Müller 2016-09-20 11:47:53 UTC
That doesn't look acceptable, no.

Could you make the file available?
Comment 2 Nicola 2016-09-20 12:26:49 UTC
here is a sample file

http://195.250.34.59/temp/test_h264_itu.avi

plays fine in 0.10, vlc, ffplay ecc..  but not in 1.0
Comment 3 Nicola 2016-09-20 12:32:14 UTC
h264parse should handle this variant too, actually it errors out with something like this:

h264parse gsth264parse.c:2487:gst_h264_parse_set_caps: video/x-h264 caps with codec_data but no stream-format=avc
Comment 4 Tim-Philipp Müller 2016-09-20 13:20:30 UTC
Created attachment 335932 [details] [review]
avidemux: make sure H264 caps always have stream-format set

Instead of letting downstream guess based on presence or not of a codec_data field.
Comment 5 Nicola 2016-09-20 13:30:02 UTC
works fine, thanks!
Comment 6 Nicola 2016-09-20 13:32:24 UTC
but if you do something like avidemux ! h264parse

this still does not work:

gsth264parse.c:2677:gst_h264_parse_set_caps:<h264parse0> refused caps video/x-h264, variant=(string)itu, framerate=(fraction)120/1, width=(int)320, height=(int)240, codec_data=(buffer)2000000127644014ac2b40a0fd8088000003000800000301e42000000128ee1f2c0000000000000000000000000000000000, stream-format=(string)avc, alignment=(string)au
Comment 7 Nicola 2016-09-21 10:37:21 UTC
Tim, what do you think about making h264parse work in passthrough mode in this case? You can play and even remux the file just fine whitout using h264parse
Comment 8 Nicola 2016-09-27 12:40:05 UTC
(In reply to Nicola from comment #7)
> Tim, what do you think about making h264parse work in passthrough mode in
> this case? You can play and even remux the file just fine whitout using
> h264parse

any opinions?
Comment 9 Tim-Philipp Müller 2016-09-27 12:57:17 UTC
I don't know what "this case" is. Why is it refusing it? And why does playback work then, where h264parse is also plugged after avidemux? It sounds like there's something after h264parse causing problems.
Comment 10 Nicola 2016-09-27 13:14:55 UTC
after applying the patch to avidemux, these pipeline work:

filesrc ! avidemux ! fakesink
filesrc ! avidemux ! avdec_h264 ! xvimagesink

this one does not work

filesrc ! avidemux ! h264parse ! fakesink

h264parse fails with this error:

h264parse gsth264parse.c:2672:gst_h264_parse_set_caps:<h264parse0> wrong avcC version

so h264 contained in this file can be handled by ffmpeg but is not handled in h264parse,

the ideal solution would be to properly handle this format in h264parse too, a temporary solution could be to let h264parse work in passthrough mode when it does not recognize the h264 stream and no conversion (avc-> byte stream ecc..) is required
Comment 11 Tim-Philipp Müller 2016-09-27 13:32:32 UTC
Ah, I can reproduce this. I think the patch is not quite right actually.

The codec_data contains a byte-stream sync marker, but not at the beginning, so I wonder what format/packing that codec_data is.

Needs more investigation then.
Comment 12 GStreamer system administrator 2018-11-03 15:11:44 UTC
-- 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-good/issues/299.