kornelski ( Kornel )

pull request commentsindresorhus/Gifski

Improve file size estimate

Regarding naive estimate:

Show a min-max range. "20MB-50MB" makes it clearer how imprecise it is.
Once you get any better estimate, remember the ratio between the naive and the better estimates. Apply that ratio to later naive estimates. This will give you decent estimates real time for changing parameters.

sindresorhus

comment created time in 15 hours

issue commentmozilla/mozjpeg

Default compression profile mismatch between libjpeg and libjpeg-turbo APIs

It's been done for tests. I didn't expect anyone to use this library for the turbo API.

I guess it will need a smarter switch. Maybe read an env var?

PJK136

comment created time in 16 hours

issue commentImageOptim/gifski

cargo install gifski failed on Windows

Please close the issue at rust-lang/cargo. It's not a cargo bug.

liudonghua123

comment created time in 16 hours

issue commentImageOptim/gifski

cargo install gifski failed on Windows

Try:

cargo install gifski --no-default-features

it looks like gifsicle feature isn't Windows-compatible.

liudonghua123

comment created time in 16 hours

Pull request review commentmozilla/mp4parse-rust

AVIF alpha channel support

 fn read_infe<T: Read>(src: &mut BMFFBox<T>) -> Result<ItemInfoEntry> {     Ok(ItemInfoEntry { item_id, item_type }) } +fn read_iref<T: Read>(src: &mut BMFFBox<T>) -> Result<TryVec<ItemReferenceEntry>> {+    let mut entries = TryVec::new();+    let version = read_fullbox_version_no_flags(src)?;+    if version > 1 {+        return Err(Error::Unsupported("iref version"));+    }++    let mut iter = src.box_iter();+    while let Some(mut b) = iter.next_box()? {+        let from_item_id = if version == 0 {+            be_u16(&mut b)? as u32+        } else {+            be_u32(&mut b)?+        };+        let item_count = be_u16(&mut b)?;+        for _ in 0..item_count {+            let to_item_id = if version == 0 {+                be_u16(&mut b)? as u32+            } else {+                be_u32(&mut b)?+            };+            entries.push(ItemReferenceEntry {+                item_type: b.head.name.into(),+                from_item_id,+                to_item_id,+            })?;+        }+    }+    Ok(entries)+}++fn read_iprp<T: Read>(src: &mut BMFFBox<T>) -> Result<TryVec<AssociatedProperty>> {+    let mut iter = src.box_iter();+    let mut properties = TryVec::new();+    let mut associations = TryVec::new();++    while let Some(mut b) = iter.next_box()? {+        match b.head.name {+            BoxType::ItemPropertyContainerBox => {+                properties = read_ipco(&mut b)?;+            }+            BoxType::ItemPropertyAssociationBox => {+                associations = read_ipma(&mut b)?;+            }+            _ => return Err(Error::InvalidData("unexpected ipco child")),+        }+    }

I see you prefer strictly validating parser, rather than merely parser that can read spec-compliant files.

In this case I think code could be simpler if validity was checked separately after parsing.

kornelski

comment created time in 17 hours

Pull request review commentmozilla/mp4parse-rust

AVIF alpha channel support

 impl<'a, T: Read> BMFFBox<'a, T> {     } } -impl<'a, T: Read + Offset> BMFFBox<'a, T> {-    /// Check whether the beginning of `extent` is within the bounds of the `BMFFBox`.-    /// We assume extents to not cross box boundaries. If so, this will cause an error-    /// in `read_extent`.-    fn contains_extent(&self, extent: &ExtentRange) -> bool {-        if self.offset() <= extent.start() {-            let start_offset = extent.start() - self.offset();-            start_offset < self.bytes_left()-        } else {-            false-        }-    }--    /// Read the range specified by `extent` into `buf` or return an error if the range is not-    /// fully contained within the `BMFFBox`.-    fn read_extent(&mut self, extent: &ExtentRange, buf: &mut TryVec<u8>) -> Result<()> {-        let start_offset = extent-            .start()-            .checked_sub(self.offset())-            .expect("box does not contain extent");-        skip(self, start_offset)?;-        match extent {-            ExtentRange::WithLength(range) => {-                let len = range-                    .end-                    .checked_sub(range.start)-                    .expect("range start > end");-                if len > self.bytes_left() {-                    return Err(Error::InvalidData("extent crosses box boundary"));-                }-                self.take(len).try_read_to_end(buf)?;-            }-            ExtentRange::ToEnd(_) => {-                self.try_read_to_end(buf)?;-            }-        }-        Ok(())-    }-}-

I agree there's still room for improvement, but I'd prefer to tackle it separately.

The existing approach to matching between items and extents can be O(n^2), so a malicious file could use it for DoS. It should be refactored into something more elegant that sorts extents by start offset. Or perhaps changed entirely into an API that can stream the data instead of buffering it all.

kornelski

comment created time in 17 hours

Pull request review commentmozilla/mp4parse-rust

AVIF alpha channel support

 fn read_infe<T: Read>(src: &mut BMFFBox<T>) -> Result<ItemInfoEntry> {     Ok(ItemInfoEntry { item_id, item_type }) } +fn read_iref<T: Read>(src: &mut BMFFBox<T>) -> Result<TryVec<ItemReferenceEntry>> {+    let mut entries = TryVec::new();+    let version = read_fullbox_version_no_flags(src)?;+    if version > 1 {+        return Err(Error::Unsupported("iref version"));+    }++    let mut iter = src.box_iter();+    while let Some(mut b) = iter.next_box()? {+        let from_item_id = if version == 0 {+            be_u16(&mut b)? as u32+        } else {+            be_u32(&mut b)?+        };+        let item_count = be_u16(&mut b)?;+        for _ in 0..item_count {+            let to_item_id = if version == 0 {+                be_u16(&mut b)? as u32+            } else {+                be_u32(&mut b)?+            };+            entries.push(ItemReferenceEntry {+                item_type: b.head.name.into(),+                from_item_id,+                to_item_id,+            })?;+        }+    }

It'd be nice to automate it, but it could be tackled as a separate refactoring.

Perhaps it could be automated by having BMFFBox keep a mutable reference to its BoxIter, and BMFFBox's drop could "poison" the iterator to return an error if the previous box hasn't been read fully.

kornelski

comment created time in 17 hours

Pull request review commentmozilla/mp4parse-rust

AVIF alpha channel support

 pub fn read_avif<T: Read>(f: &mut T, context: &mut AvifContext) -> Result<()> {         check_parser_state!(b.content);     } -    // If the `mdat` box came before the `meta` box, we need to fill in our primary item data-    let primary_item_extents =-        primary_item_extents.ok_or(Error::InvalidData("primary item extents missing"))?;-    for (extent, data) in primary_item_extents+    let meta = meta.ok_or(Error::InvalidData("missing meta"))?;++    let alpha_item_id = meta+        .item_references         .iter()-        .zip(primary_item_extents_data.iter_mut())-    {-        if data.is_empty() {+        // Auxiliary image for the primary image+        .filter(|iref| {+            iref.to_item_id == meta.primary_item_id+                && iref.from_item_id != meta.primary_item_id+                && iref.item_type == b"auxl"+        })+        .map(|iref| iref.from_item_id)+        // which has the alpha property+        .filter(|&item_id| {+            meta.properties.iter().any(|prop| {+                prop.item_id == item_id+                    && match &prop.property {+                        ImageProperty::AuxiliaryType(urn) => {+                            urn.as_slice()+                                == "urn:mpeg:mpegB:cicp:systems:auxiliary:alpha".as_bytes()+                        }+                        _ => false,+                    }+            })+        })+        .next();

I can add a check. It's amusing that the format uses complicated mechanism for arbitrary many to many relationships only to define a fixed 1:1 relationship :)

kornelski

comment created time in 17 hours

Pull request review commentmozilla/mp4parse-rust

AVIF alpha channel support

 struct ItemInfoEntry {     item_type: u32, } +/// See ISO 14496-12:2015 § 8.11.12+#[derive(Debug)]+struct ItemReferenceEntry {+    item_type: FourCC,+    from_item_id: u32,+    to_item_id: u32,

I've written it this way because a flattened structure is easier to create and easier to use. It's functionally equivalent to spec's structure, so there's nothing lost AFAIK.

I haven't seen files where one-to-many relationship would be actually needed, so I expect it to be pretty much always used with only a single to ID. Heap-allocating for just one 4-byte ID is wasteful, and creating SmallTryVec for just this case would be an overkill.

kornelski

comment created time in 17 hours

PullRequestReviewEvent

issue comment3Hren/msgpack-rust

Question about zero-copy decoding

I'm not sure, since I haven't used zero-copy decoding myself. Have you tried using &[u8] instead?

akiradeveloper