GNOME Bugzilla – Bug 584599
encoders should forward pixel-aspect-ratio in output caps
Last modified: 2012-12-17 11:18:13 UTC
When testing creating files for my cellphone I noticed that GStreamer generated files always get the DAR value wrong for files with non-square pixels. Testing with ffenc_mpeg4 it seems qtmux is never told the PAR and thus assumes DAR is equal to pixel height and pixel width. My phone complains about corrupt file and refuse to play it and this DAR value is one of the last items different from the working file that ffmpeg creates. The GStreamer created DAR is 1.22, but since the PAR is 12/11 it should be 4:3
It seems sensible that the encoder should copy the pixel-aspect-ratio to the output caps, at the least when it's different to 1:1. That would be complementary behaviour to decoding - where the container demuxer provides the pixel-aspect-ratio, which overrides the pixel-aspect-ratio encoded into the video, when the pixel-aspect-ratio from the container is different to 1:1
You should probably clone this bug at least once for every plugin module that needs fixing, if not for every encoder plugin, if you ever want this to go anywhere :)
This is filed against core, which is not particularly useful. Moving to -base.
ok, changing this to ffenc_mpeg4 bug, will create new bugs as I test for other plugins.
All video encoders should do that, and they should also do it in the other direction (i.e. if upstream calls getcaps, we should forward downstream PAR if present)
No, really, *ALL* encoders. Don't change the subject of this bug Christian.
And this also applies to audio encoders, not only video encoders (number of channels, sampling rate, ...) Also see bug #651564 and the same probably applies to encoders in good/bad/ugly too.
IIRC the base audio encoder class in #642690 caters for such caps proxying, and doing something similar for base video encoder should be quite possible.
With most elements now ported to the new baseclasses should this bug be marked as solved?
> With most elements now ported to the new baseclasses should this bug be marked > as solved? It's currently assigned to gst-ffmpeg, so unless this is implemented in gst-ffmpeg encoders already, this bug should probably stay open.
This seems to work fine for me now: gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,pixel-aspect-ratio=2/1 ! avenc_mpeg4 ! qtmux ! filesink location=/tmp/v.qt gst-launch-1.0 playbin uri=file:///tmp/v.qt -v | grep Xv /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)2/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, framerate=(fraction)30/1 And both audio and video encoders and decoders now use the base classes, so hopefully handle this correctly. I think this can be close now, or is anything missing?
This should be fine now, the base classes handle all this.