[Bug 729371] dash/qtdemux: Reported video size does not correspond to what avdec_h264 states

[GStreamer (GNOME Bugzilla)]

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

Seungha Yang <sh.yang at lge.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sh.yang at lge.com

--- Comment #11 from Seungha Yang <sh.yang at lge.com> ---
(In reply to Thiago Sousa Santos from comment #8)
> Yes, but the stsd box needs to have multiple entries. One for each
> representation, this is how the initialization segment can actually have
> information on all of them.
> 
> If you read the qtff or the mpeg4 file format specification you can see that
> the stsd box can contain multiple format definitions. The same trak can have
> different formats/resolutions/... 
> 
> I believe the sample needs to be fixed.
> 
> 
> I've started looking at qtdemux to check how to properly handle this. We
> have 2 options:
> 
> 1) Create one qtdemux QtDemuxStream for each trak and then inside this have
> a new entity that contains the different formats. Seems more aligned with
> what the format allows one to do but what happens when we need to push a
> sample from another format in the same trak? Push a caps event and hope for
> the best? Do a pad group switch? Wait for decodebin3?
> 
> 2) Expose each stsd entry as a different stream and pad and handle them
> independently. The drawback here is that the samples table is the same so it
> would be messy to keep track of positions in the different pads using a
> single samples list. Also pushing gaps to cover for empty spaces. Sounds
> unnatural.
> 
> I'll start coding option 1 unless someone has a better alternative.

I really wanna vote your option 1 (keep the # of pad based on trak #, and
change only caps). Actually, I've encountered this issue quite for a long time,
but did not have very nice way to solve this problem. So, I've dealt with this
issue using work-around way (which is not suitable for share with other
people....). Is there some progress on top of current work on gst-plugins-good
master branch? Or, some reference which can be used for test? 
It's very helpful for me to implement gstreamer based DASH playback
environment.
Anyway, I hope that this issue is still on progress.

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