GNOME Bugzilla – Bug 610923
matroskamux can't handle variable resolution
Last modified: 2010-03-23 11:35:39 UTC
in the latest version of matroskamux it's changed to require a caps with the actual resolution of the input stream eg. h264. which is very problematic if i try to put a variable resolution h264 stream into a matroska container. currently gstreamer not bale to handle caps re-negotiation while the pipeline in PLAY state. so if i've live video input stream where the resolution can be change (eg. most ip camera can change the resolution on the fly) i've to stop and start the pipeline. which means i'll lose a few frames, what's more if it's a rtsp ip camera i can't detect the resolution change just only the first frame with different resolution arrive in the rtp stream. and since i can't re-negotiate the running pipelines caps i have to drop this (and a few more next) frame stop the pipeline, rewrite the cap filter in the pipeline and restart it. it'd be useful if we can add more section to a matroska file (since it's possible in a matroska file), but it'd be useful if matroskamux or h264parse can handle this ie. if h264parse recognize a new resolution than change the caps and if matroskamux see that the caps change then start a new section or as it was before this version use the same session in the matoska file but change the frames resolution (which would be the best solution). currently i can only use: gst-launch filesrc location=resolution_variable.h264 ! h264parse split-packetized=true ! capsfilter caps="video/x-h264,width=352,height=288,framerate=1/1" ! matroskamux ! filesink location=out.mkv while if i can use this pipeline: gst-launch filesrc location=resolution_variable.h264 ! h264parse split-packetized=true ! matroskamux ! filesink location=out.mkv and h264parse always set the proper caps or matroskamux always set the proper resolution in the file than it's can be done realtime. currently matroskamux fill the matroska's resolution with dummy 0 x <verylargenumber> resolution. is there any solution to this? anybody has nay tipp?
On the one hand, above pipelines are a bit off: * split-packetized=true only has any effect if the input is packetized, which it is not in case of some raw file input * a recent h264parse should parse the stream and determine width/height, which might then conflict with capsfilter On the other hand, do you have more specific info on the problem with "caps renegotiation in PLAYING". For example, afaics, matroskamux has been recently changed to require input caps to provide width/height, but it should not complain if the width/height change at some point. Things will then be a bit borderline having track metadata that only corresponds to part of the stream (as they would be with any container). Particularly, codec-data could have some problems, but it could/should work out provided the appropriate sps/pps are contained in the stream. Sort of summary: a recent h264parse should provide width/height in caps, which will then go into matroska resolution info, and if appropriate sps/pps (containing a.o. resolution data) are in-stream, a resolution change should work. It might also be useful having h264parse produce avc output (using properties or output caps negotiation).
this is almost true, but the real problem that in gstreamer in a running pipeline there is no caps renegotiation:-( or at least we're not able to do it. so even if our stream has proper sps/pps and the right width/height in the raw stream we can't put into a matroska file:-( while in the previous version when matroskamux do NOT require caps with width/height we can put the stream into a matroska file...
Why "there is no caps renegotiation". Any details, logs, example stream and pipeline where it fails (as it normally should not fail), ... ?
i can send you the file in #1 which contain a h264 stream with variable resolution (which is actually capture through a capture card but it doesn't important here). this raw h264 stream can be played eg. with mplayer and it'll change the display size. we try to create many different pipeline to put this stream into matroska and we're not able to do so, since we can't force caps to renegotiate...
seems to fixed in the latest release:-)