[Bug 790000] rtph264depay: doesn't update resolution if format is avc

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=790000

--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Olivier Crête from comment #10)
> I think this patch is correct, and slomo's change in 8dda570e4 (which
> introduced this behaviour) was just wrong.
> 
> If the SPS/PPS change, h264parse should have the same behaviour.

I only made it behave the same as h264parse back then, where it was
intentionally done like this IIRC. Also that seems unrelated to this bug, or
not? If the resolution changes, both would still update the caps.

However I agree that a codec data change should be reflected in the (AVC) caps,
always. Before doing that we will need to fix other elements (mp4mux
specifically) though, as they will otherwise fail in situations that worked
just fine before (which is why the commit in rtph264depay happened).

> I know this
> will be a problem for mp4 file, in that case, h264parse should probably
> renumber the SPS if the goal is to create a single valid stream.. And it
> means that mp4mux would need to replace the codec_data it already wrote with
> the new one. Anyway, this isn't so relevant here.

See above, it actually is quite relevant. We can't just change
h264parse/rtph264depay and break situations that worked fine before, even if by
accident. People rely on them :)

Fixing mp4mux is going to be a little bit tricky though. Renumbering would have
to happen like you say, but h264parse would have to detect this case (and you
probably don't want to do this forever and keep around all SPS/PPS ever seen).
And mp4mux would also have to handle this, which depending on the muxing mode
might not be trivial.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.