carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

openMax h264 non reference P frame

Mon Jan 08, 2018 6:10 am

Hi all:

I am using openMax to encode h264 stream on Raspberry Pi. The core is BCM2835. I am using h264 baseline profile so there is only I and P pictures. One gop picture looks like the following: I P P P P ... I P P P... I set only one reference picture. I want to know if there is a way to set openMax so that all the P pictures in a GOP refers to the I picture as reference (that said, all the P pictures are NOT reference pictures). Please let me know if such setting exists.

Thanks! Carial

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 7:37 am

Not that I'm aware of, mainly as the compression will get steadily worse as the scene shifts from the reference frame over time, and if I'm understanding you correctly you're only sending one I at the start of the recording.
What's your use case where you think that would actually help?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:22 pm

Thank you for the reply. There will be one I frame in each GOP (each GOP is about 1 second). So there will be an intra coded frame at each second. The use case is that, if the current P frame gets lost, the next P frame can still be decoded without retransmitting the current P frame (otherwise, without retransmission, one need to wait until the next I frame). For video conferencing usage, since most background is not moving, the encoding efficiency will be OK even all P frames refer to the first I frame in a GOP.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20447
Joined: Sat Jul 30, 2011 7:41 pm

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:28 pm

But will P frames get lost in that way? It's a bitstream, so doesn't map on to any 'packet' of the underlying transport (although that might depend on the transport), so you cannot really 'lose' a single but entire P frame. You can lose bits of it of course, and will get the associated corruption (if no retransmit) until the next I frame.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:34 pm

Thank you Jamesh for your reply. My point is that if a P frame get corrupted (or lost), it can be skipped without retransmission. The next P frame can be decoded because it references the I frame (instead of the previous P frame). At client side, there is one frame skip. If the current P frame is referenced by later P frames, one needs to re-transmit the P frame for all following P frames get decoded correctly.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:38 pm

Also the use case is trying to minimize the delay (so minimum re-transmission) and minimum error propagation. The transmission layer protocol is UDP. So if there is error in P frame, we would rather skip it instead decoding it (and show some corruption).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:41 pm

OK, there appears to be some support in the codec, but only to make every other P frame a non-reference frame.
Setting OMX_IndexParamBrcmDroppablePFrames to OMX_TRUE (OMX_CONFIG_BOOLEANTYPE) should do that for you.

There is a conditional to control which frames to drop (alongside a TODO comment of improving the algorithm!). If you can confirm that OMX_IndexParamBrcmDroppablePFrames does actually do what the comments imply, then I can look at extending it to vary the number of droppable frames per GOP (it always gets reset on an IDR frame).
If you have a simple tool of some form to confirm which frames are used as references, then that would speed up my hacking around in the codec :)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:42 pm

carial wrote:
Mon Jan 08, 2018 5:38 pm
Also the use case is trying to minimize the delay (so minimum re-transmission) and minimum error propagation. The transmission layer protocol is UDP. So if there is error in P frame, we would rather skip it instead decoding it (and show some corruption).
I assume from that that you have some mechanism to retransmit I frames if they get dropped. You're rather sunk if not.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 5:58 pm

Thank you 6by9 for your reply and support! Regarding to your comments:

(1) Yes. we will cache I frames at server and retransmit I frame if it gets lost or corrupted.

(2) Before I asked in this forum, I tried previously OMX_IndexParamBrcmDroppablePFrames. It works as stated in the document. Without this being set (the default), the frames look like the following:

I P (reference) P(reference) P(reference) P(reference)...

If I set this, the frames look like the following:

I P(reference) P(NON reference/droppable) P(reference) P(NON reference/droppable) P(reference) P(NON reference/droppable)...

So it makes every other P frame as NON reference. What I want is a scheme that all P frame is NON reference frame (or: one can specify for each P frame whether it is a reference or not).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 10:18 pm

carial wrote:
Mon Jan 08, 2018 5:58 pm
(2) Before I asked in this forum, I tried previously OMX_IndexParamBrcmDroppablePFrames. It works as stated in the document. Without this being set (the default), the frames look like the following:

I P (reference) P(reference) P(reference) P(reference)...

If I set this, the frames look like the following:

I P(reference) P(NON reference/droppable) P(reference) P(NON reference/droppable) P(reference) P(NON reference/droppable)...

So it makes every other P frame as NON reference. What I want is a scheme that all P frame is NON reference frame (or: one can specify for each P frame whether it is a reference or not).
It would have been useful for you to have said that you'd tried OMX_IndexParamBrcmDroppablePFrames in the first place - it would have given me a reference point in the code start searching from.
If that is giving the behaviour you have described, then it gives me confidence that I'm looking in the right place, and it should be fairly easy to alter the pattern of droppable frames. I'll add it to the list of jobs, but it should be almost just a case of plumbing some numbers through.

As asked previously, what tool are you using to check which frames are droppable or not? I haven't got many H264 bitstream analysis tools to hand, and I don't want to have to go digging through the spec to determine it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Mon Jan 08, 2018 11:04 pm

Thank you 6by9 for the reply! I am sorry I should have mentioned the OMX_IndexParamBrcmDroppablePFrames parameters first. Regarding to the tool to check frame dependency, I just use h264 reference decoder (JM) since it is easy to see if a P frame is a reference frame or not (check the Pic# field, if a P frame is used as reference, its Pic# will increase).

Could you please tell me which part of the code that controls the droppable P frames?

Thank you!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Tue Jan 09, 2018 9:52 am

carial wrote:
Mon Jan 08, 2018 11:04 pm
Could you please tell me which part of the code that controls the droppable P frames?
It's part of the closed source VideoCore firmware.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Wed Jan 10, 2018 12:11 am

Thank you 6by9 for the reply! May I ask when you expect the change will be finished and released? Thanks again!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Wed Jan 10, 2018 8:15 am

carial wrote:
Wed Jan 10, 2018 12:11 am
Thank you 6by9 for the reply! May I ask when you expect the change will be finished and released? Thanks again!
I had a spare half hour yesterday so poked around on this. I have it working and a merge request up internally for review. Unless I've dropped a howler, then it should be in the next rpi-update release (normally fairly frequent, but not on a regular schedule. Should be within a week or so).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Wed Jan 10, 2018 5:57 pm

Great! Please let me know when the update is ready. One more question: could you please tell me what the change is? Did you change the OMX_IndexParamBrcmDroppablePFrames so that the app could specify how many P frames is droppable? Thanks again!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Wed Jan 10, 2018 9:22 pm

carial wrote:
Wed Jan 10, 2018 5:57 pm
Great! Please let me know when the update is ready. One more question: could you please tell me what the change is? Did you change the OMX_IndexParamBrcmDroppablePFrames so that the app could specify how many P frames is droppable? Thanks again!
I've added OMX_IndexParamBrcmDroppablePFrameLength taking a OMX_PARAM_U32TYPE with nPortIndex being the output port. It'll produce 1 P reference frame in nU32 frames. Default is 2 to give the same behaviour as before. Set it to > GOP length and all P frames will be droppable.
(You have just reminded me that I forgot to add GetParameter for it, so I need to update the patch tomorrow).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Wed Jan 10, 2018 10:52 pm

Great! Please let me know after the patch has been published. It adds great flexibility to encoding pictures. Thanks a lot for your work!

Sorry for one more question: So when OMX_IndexParamBrcmDroppablePFrameLength is available, one do not need to set OMX_IndexParamBrcmDroppablePFrame, right? Just set OMX_IndexParamBrcmDroppablePFrameLength will do the work, is it correct?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Thu Jan 11, 2018 4:42 pm

carial wrote:
Wed Jan 10, 2018 10:52 pm
Great! Please let me know after the patch has been published. It adds great flexibility to encoding pictures. Thanks a lot for your work!
Either watch https://mobile.twitter.com/rpf_dev_updates/ or https://github.com/Hexxeh/rpi-firmware/
carial wrote:Sorry for one more question: So when OMX_IndexParamBrcmDroppablePFrameLength is available, one do not need to set OMX_IndexParamBrcmDroppablePFrame, right? Just set OMX_IndexParamBrcmDroppablePFrameLength will do the work, is it correct?
No, you still need to set OMX_IndexParamBrcmDroppablePFrame to OMX_TRUE, and set OMX_IndexParamBrcmDroppablePFrameLength to the value you desire. That's mainly to ensure backward compatibility as we can't control apps that are already out there.

I'll correct myself from earlier - the default value that you'll read back for OMX_IndexParamBrcmDroppablePFrameLength is actually 0, which should be interpreted as adopting a default of 2 (alternating).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Thu Jan 11, 2018 5:26 pm

Thank you! some more questions following your previous post:

(1) For other values except the default (2) set to OMX_IndexParamBrcmDroppablePFrameLength, the "GetParameter" will return the actual value it is been set, right?

(2) Will OMX_IndexParamBrcmDroppablePFrameLength be reset to default at each IDR frame? From my test, OMX_IndexParamBrcmDroppablePFrames will not change at each IDR.

(3) Any instructions on how to update the firmware (rpi-update)?

Thanks again!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Fri Jan 12, 2018 11:14 am

carial wrote:
Thu Jan 11, 2018 5:26 pm
(1) For other values except the default (2) set to OMX_IndexParamBrcmDroppablePFrameLength, the "GetParameter" will return the actual value it is been set, right?
If you set OMX_IndexParamBrcmDroppablePFrameLength then GetParameter will return the value set.
carial wrote:(2) Will OMX_IndexParamBrcmDroppablePFrameLength be reset to default at each IDR frame? From my test, OMX_IndexParamBrcmDroppablePFrames will not change at each IDR.
No, why would it? It'd be a bit like defaulting the GOP at every IDR.
carial wrote:(3) Any instructions on how to update the firmware (rpi-update)?
The change was released last night - https://github.com/Hexxeh/rpi-firmware/ ... 9eed210bb4
"sudo rpi-update" will update to it. There is a small chance of regressions, so please only do that on a Pi that you can sacrifice or recover.

The headers introducing the new parameter enums has been applied to the rpi-firmware repo, but not userland one yet. Copy/paste them across for now if needed.
My tests were with RaspiVid and adding:

Code: Select all

diff --git a/host_applications/linux/apps/raspicam/RaspiVid.c b/host_applications/linux/apps/raspicam/RaspiVid.c
index b9b9b6d..171e1fb 100755
--- a/host_applications/linux/apps/raspicam/RaspiVid.c
+++ b/host_applications/linux/apps/raspicam/RaspiVid.c
@@ -2223,6 +2223,16 @@ static MMAL_STATUS_T create_encoder_component(RASPIVID_STATE *state)
          goto error;
       }
    }
+   status = mmal_port_parameter_set_boolean(encoder->control, MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAMES, MMAL_TRUE);
+   if (status != MMAL_SUCCESS)
+   {
+      vcos_log_error("Unable to set MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAMES");
+   }
+   status = mmal_port_parameter_set_boolean(encoder->output[0], MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAME_LENGTH, 61);
+   if (status != MMAL_SUCCESS)
+   {
+      vcos_log_error("Unable to set MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAME_LENGTH");
+   }
 
    //  Enable component
    status = mmal_component_enable(encoder);
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Wed Jan 17, 2018 12:16 am

Hi 6by9:

Regarding to the sample code in your last post:

(1) Should I use OMX_SetParameter or OMX_SetConfig? The newly added index name is "OMX_IndexConfigBrcmDroppableRunLength", So I should use OMX_SetConfig?

(2) In your sample code,

+ status = mmal_port_parameter_set_boolean(encoder->output[0], MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAME_LENGTH, 61);

Is the above correct, since OMX_IndexConfigBrcmDroppableRunLength is of OMX_PARAM_U32TYPE?

Thank you!

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Wed Jan 17, 2018 1:35 am

Hi 6by9:

Could you tell me what tool did you use to decode/verify the encoded bitstream? It seems that I can encode with all P frames not referenced, but when I tried to decode the h264 bitstream using reference decoder (JM version 19.0), it cannot decode the bitstream.

Thank you!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Wed Jan 17, 2018 11:12 am

carial wrote:
Wed Jan 17, 2018 12:16 am
(1) Should I use OMX_SetParameter or OMX_SetConfig? The newly added index name is "OMX_IndexConfigBrcmDroppableRunLength", So I should use OMX_SetConfig?
They are actually synonymous on the Pi. The component itself checks what state it is in when it gets the call to judge whether it is valid or not.
carial wrote:(2) In your sample code,

+ status = mmal_port_parameter_set_boolean(encoder->output[0], MMAL_PARAMETER_VIDEO_DROPPABLE_PFRAME_LENGTH, 61);

Is the above correct, since OMX_IndexConfigBrcmDroppableRunLength is of OMX_PARAM_U32TYPE?
Typo - it should be mmal_port_parameter_set_uint32, but seeing as the IPC uses a 32bit word for booleans it makes no difference in this case.
carial wrote:
Wed Jan 17, 2018 1:35 am
Could you tell me what tool did you use to decode/verify the encoded bitstream? It seems that I can encode with all P frames not referenced, but when I tried to decode the h264 bitstream using reference decoder (JM version 19.0), it cannot decode the bitstream.
IIRC I just threw it back at omxplayer to play. Trying that now seems to decode fine.
I'm seeing if the reference decoder will compile trivially and see what it says.
I'm not an expert on how the codec code is working, I was observing that there appeared to be a simple place that chose how to encode a frame. If it isn't doing what is expected, digging in to the guts of that code is not something I have time for now.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5657
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: openMax h264 non reference P frame

Wed Jan 17, 2018 11:24 am

This is getting beyond the time I have available now.
Feeding it into JM 19.0 ldecod.exe I get

Code: Select all

Setting Default Parameters...
Parsing Configfile decoder.cfg
...............

----------------------------- JM 19.0 (FRExt) -----------------------------
--------------------------------------------------------------------------
 Input H.264 bitstream                  : foo.h264 
 Output decoded YUV                     : test_dec.yuv 
 Input reference file                   : test_rec.yuv 
--------------------------------------------------------------------------
 Input reference file                   : test_rec.yuv does not exist 
                                          SNR values are not available
Profile IDC  : 100
Image Format : 1920x1080 (1920x1088)
Color Format : 4:2:0 (8:8:8)
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
  Frame          POC  Pic#   QP    SnrY     SnrU     SnrV   Y:U:V Time(ms)
--------------------------------------------------------------------------
00000(IDR)        0     0    35                             4:2:0      41
Maximum number of supported slices exceeded. 
Please recompile with increased value for MAX_NUM_SLICES
Reducing it to 4 results in:

Code: Select all

Setting Default Parameters...
Parsing Configfile decoder.cfg
...............

----------------------------- JM 19.0 (FRExt) -----------------------------
--------------------------------------------------------------------------
 Input H.264 bitstream                  : foo.h264 
 Output decoded YUV                     : test_dec.yuv 
 Input reference file                   : test_rec.yuv 
--------------------------------------------------------------------------
 Input reference file                   : test_rec.yuv does not exist 
                                          SNR values are not available
Profile IDC  : 100
Image Format : 1920x1080 (1920x1088)
Color Format : 4:2:0 (8:8:8)
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
  Frame          POC  Pic#   QP    SnrY     SnrU     SnrV   Y:U:V Time(ms)
--------------------------------------------------------------------------
00000(IDR)        0     0    35                             4:2:0      37
00001( P )        2     1    33                             4:2:0      42
00002( P )        4     2    25                             4:2:0      80
00003( P )        6     3    20                             4:2:0      50
00004( P )        8     4    20                             4:2:0      79
00005( P )       10     5    20                             4:2:0      64
00006( P )       12     6    21                             4:2:0      76
00007( P )       14     7    21                             4:2:0      74
00008( P )       16     8    21                             4:2:0      53
00009( P )       18     9    20                             4:2:0     102
00010( P )       20    10    20                             4:2:0      65
00011( P )       22    11    20                             4:2:0      82
00012( P )       24    12    24                             4:2:0      40
00013( P )       26    13    22                             4:2:0      45
00014( P )       28    14    22                             4:2:0      56
00015( P )       30    15    20                             4:2:0      58
00000(IDR)        0     0    20                             4:2:0      67
00001( P )        2     1    21                             4:2:0      57
00002( P )        4     2    20                             4:2:0      46
00003( P )        6     3    20                             4:2:0      67
00004( P )        8     4    20                             4:2:0      67
00005( P )       10     5    21                             4:2:0      44
00006( P )       12     6    20                             4:2:0      52
00007( P )       14     7    20                             4:2:0      78
00008( P )       16     8    20                             4:2:0      56
00009( P )       18     9    21                             4:2:0      49
00010( P )       20    10    21                             4:2:0      64
00011( P )       22    11    20                             4:2:0      58
00012( P )       24    12    20                             4:2:0      84
00013( P )       26    13    20                             4:2:0      70
00014( P )       28    14    20                             4:2:0      51
00015( P )       30    15    21                             4:2:0      57
00000(IDR)        0     0    20                             4:2:0      80
00001( P )        2     1    20                             4:2:0      57
00002( P )        4     2    21                             4:2:0      63
00003( P )        6     3    21                             4:2:0      63
00004( P )        8     4    20                             4:2:0      68
-------------------- Average SNR all frames ------------------------------
 SNR Y(dB)           :  0.00
 SNR U(dB)           :  0.00
 SNR V(dB)           :  0.00
 Total decoding time : 2.320 sec (15.948 fps)[37 frm/2320 ms]
--------------------------------------------------------------------------
 Exit JM 19 (FRExt) decoder, ver 19.0 
 Output status file                     : log.dec 
72 frames are decoded.
which from how I'm reading what you said before means they're all still references.
This is getting to the level where the bitstream needs to be analysed in detail, and I really don't have time for that now.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carial
Posts: 23
Joined: Mon Jan 08, 2018 6:01 am

Re: openMax h264 non reference P frame

Thu Jan 18, 2018 5:18 am

Hi 6by9:

I appreciate all your kind help and time spent on this issue. I debugged into the reference decoder (JM 19.0) and it seems that the cause is the picture order count type is set to 2 (pic_order_cnt_type in SPS). Picture order count type 2 support up to one non-reference picture between two reference pictures. So the "all droppable P frame" case cannot use picture order count type 2. I checked the OMX_index.h file and there is no such parameter or config that one can set the picture order count type. I wonder if you know that there is a way to change picture order count type?

Thank you very much for all the kind help.

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: Imperf3kt, Mayki and 9 guests