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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Olivier Crête <olivier.crete at ocrete.ca> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> > 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 :)

I think it's fine to say that you need a h264parse before a mp4mux always and
push this, as we're trying to fix a nastier regression where the SPS change is
just not communicated. mp4mux can require parsed=true and so require a parser.

> 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.

Afaik, in the AVC1 case, it should renumber and keep them all around until the
parser/depayloader is reset to READY as this is the only way to make a truly
valid stream. As I think having "filesrc ! tsdemux! h264parse ! mp4mux !
filesink" should produce a single continuous file even if you do flushing
seeks.

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