[FFmpeg-devel] [RFC] support for Cam_PAL_D1_inter_Field_25fps_2.5MBS.mp4

Michael Niedermayer michaelni
Tue Apr 1 04:02:40 CEST 2008


On Tue, Apr 01, 2008 at 01:08:26AM +0200, Reimar D?ffinger wrote:
> On Tue, Apr 01, 2008 at 12:47:21AM +0200, Michael Niedermayer wrote:
> > On Wed, Mar 26, 2008 at 09:57:35AM +0100, Reimar D?ffinger wrote:
> > > Hello,
> > > On Wed, Mar 26, 2008 at 03:46:59AM +0100, Michael Niedermayer wrote:
> > > > On Fri, Mar 21, 2008 at 01:50:47PM +0100, Reimar D?ffinger wrote:
> > > > > @@ -7600,6 +7614,10 @@
> > > > >               * NAL unit stuff to context 0 and restart. Note that
> > > > >               * rbsp_buffer is not transfered, but since we no longer
> > > > >               * run in parallel mode this should not be an issue. */
> > > > > +            if(context_count) {
> > > > > +                execute_decode_slices(h, context_count);
> > > > > +                context_count = 0;
> > > > > +            }
> > > > 
> > > > What values do context_count and h->max_contexts have here? and why
> > > > does the 
> > > > if(context_count == h->max_contexts) {
> > > > above not trigger?
> > > > 
> > > > max_contexts should be 1 and context_count should be 1 as well i think
> > > 
> > > In this case yes, but my idea was that the code should also work and
> > > decode in parallel if each field is coded into multiple slices.
> > > Since I have no actual file to test that, I could have done nonsense I
> > > admit...
> > 
> > I assume that all the other changes are actually needed or are there further
> > that are just there because they could do some good in some hyphothetical case?
> 
> Probably they are necessary, but I do not know for sure. I was actually
> hoping that this patch would be enough for someone with actual H.264
> knowledge to take over. E.g. the sample file always has the bottom field
> last, if that was always true, the available_fields context variable
> would not be needed.

There is noone who fully understands h264.c anymore i fear :)
Also i have a strong disslike for h264, its very complex and i dont see how
most of this complexity could affect compression/quality. Why for example
are there 2 modes to code interlaced pictures? Why is interlacing still
supported at all !?!? Why such idiocy like arbitrary
macroblock and slice order, why are there a dozen ways to store POC in the
header but then absolutely critical information like the reorder buffer size
being optional. And all the pseudo nonsene like POC, its such totally idiotic
abstraction of an abstraction. Put a single PTS in each frame, there are
simple ways to store this efficiently, and a huge amount of complexity to
deabstract all the nonsese would dissapear, one being the timestamp
interpolation for MPEG-PS/TS.
</rant>

Anyway, i think the following might be a fix, not to h264 being a mess but
the actual issue here (Note i do not claim to fully
understand the problem so what i say could be stupid)

decode_slice_header() should check for the case of being feeded a second
field without having the first done, it should return a special error code
for that case.

the code currently around the call to execute_ref_pic_marking() should
be moved somewhere else, like im its own function. And this should be
called from decode_nal_units() "when a field is done".

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080401/21857f7f/attachment.pgp>



More information about the ffmpeg-devel mailing list