After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764370 - codecparser: vp9: Wrong default values in non-intraonly/non-keyframe header fields
codecparser: vp9: Wrong default values in non-intraonly/non-keyframe header f...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal major
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 764082
 
 
Reported: 2016-03-30 14:53 UTC by sreerenj
Modified: 2016-04-15 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
codecparser: vp9: move persistent fields from GstVp9FrameHdr to GstVp9Parser (9.61 KB, patch)
2016-03-31 11:32 UTC, sreerenj
none Details | Review
codecparser: vp9: move persistent fields from GstVp9FrameHdr to GstVp9Parser (9.56 KB, patch)
2016-03-31 12:17 UTC, sreerenj
committed Details | Review

Description sreerenj 2016-03-30 14:53:16 UTC
The bit_depth, color_space, color_range, subsampling_x and subsampling_y fields in frame_headers will be present only when the frames are either keyframe or intra-only frame.

The current code just assigning default values for these fields when the frame is nonkey/non-intraonly which is wrong. For eg: this will assign bitdepth=8 even fro 10-bit frames.

Either we have to move these fields from FrameHdr structure to global GstVp9Parser structure. Which is no extra copy but with ABI change.

OR

We should keep the copies of all these fields in Private structure (GstVp9ParserPrivate), and copy them
back to FrameHdr for each non-keyframe/non-intraonly frame.

Not sure which one is preferred :)
Comment 1 sreerenj 2016-03-31 11:32:47 UTC
Created attachment 325076 [details] [review]
codecparser: vp9: move persistent fields from GstVp9FrameHdr to GstVp9Parser

The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames. This is an ABI change.
    
https://bugzilla.gnome.org/show_bug.cgi?id=764370
Comment 2 sreerenj 2016-03-31 12:17:42 UTC
Created attachment 325081 [details] [review]
codecparser: vp9: move persistent fields from GstVp9FrameHdr to GstVp9Parser

There was a g_message() debug log in the previous patch ;), removed it
Comment 3 sreerenj 2016-04-01 09:50:56 UTC
Had few regression testing, didn't find any issue.
Also had few discussions about the desired approach in IRC.

I am going to push this.
Comment 4 sreerenj 2016-04-01 11:17:39 UTC
commit 88a3b4da3c297f9f59bc833f9fde19e6345cd435
Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Date:   Fri Apr 1 14:12:08 2016 +0300

    codecparser: vp9: move persistent fields from GstVp9FrameHdr to GstVp9Parser
    
    The subsampling_x, subsampling_y, bit_depth, color_space and color_range
    fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
    These fields are only present in keyframe or intra-only frame, no need to
    duplicate them for inter-frames. This is an ABI change.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=764370
Comment 5 sreerenj 2016-04-01 11:18:50 UTC
Review of attachment 325081 [details] [review]:

pushed, closing.
Comment 6 Tim-Philipp Müller 2016-04-15 10:20:50 UTC
Thanks. When closing bugs please also set the target_milestone field to the version that will include the fix, i.e. in this case 1.9.1 since it only landed in git master (if it was also cherry-picked into the 1.8 branch it would be 1.8.1 since that's the upcoming 1.8 release). That makes things easier for your release monke^Hmanagers.
Comment 7 sreerenj 2016-04-15 11:45:49 UTC
(In reply to Tim-Philipp Müller from comment #6)
> Thanks. When closing bugs please also set the target_milestone field to the
> version that will include the fix, i.e. in this case 1.9.1 since it only
> landed in git master (if it was also cherry-picked into the 1.8 branch it
> would be 1.8.1 since that's the upcoming 1.8 release). That makes things
> easier for your release monke^Hmanagers.

Sure, will take care of it next time..thanks..